From owner-ietf-openproxy@mail.imc.org  Tue Jan  7 18:36:58 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03605
	for <opes-archive@ietf.org>; Tue, 7 Jan 2003 18:36:56 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h07N3p705935
	for ietf-openproxy-bks; Tue, 7 Jan 2003 15:03:51 -0800 (PST)
Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h07N3oo05931
	for <ietf-openproxy@imc.org>; Tue, 7 Jan 2003 15:03:50 -0800 (PST)
Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9])
	by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h07N3qLI017825
	for <ietf-openproxy@imc.org>; Tue, 7 Jan 2003 18:03:52 -0500 (EST)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h07N3jY38884
	for <ietf-openproxy@imc.org>; Tue, 7 Jan 2003 18:03:45 -0500 (EST)
Received: from mhof.com (biena [135.180.160.86])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA17908
	for <ietf-openproxy@imc.org>; Tue, 7 Jan 2003 18:03:45 -0500 (EST)
Message-ID: <3E1B5CEB.3070108@mhof.com>
Date: Tue, 07 Jan 2003 18:04:11 -0500
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OPES Group <ietf-openproxy@imc.org>
Subject: OPES Status and IETF 56
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Folks,

the design teams of the threat/risk and of the policy requirements 
drafts are currently in progress to address the remaining open issues. 
We expect this to be finished by next week, issue WG last call and 
wrap up those documents. If you had some additional thoughts on these 
documents over the holidays, *now* is the time to speak up!

With respect to meeting at IETF 56 in San Francisco, we're waiting on 
requesting a slot until we see enough *new* material to discuss (with 
'new' referring to work on the protocol and the rules language). We do 
*not* intend requesting meeting time if the old documents are still on 
our plate and no new work has started. As such, if you've any thoughts 
on the protocol issue or on the rules language, or suggestions on how 
to get things rolling, please speak up!

We've also requested an update on our goals and milestones to better 
reflect the status of our WG - see 
http://ietf.org/html.charters/opes-charter.html for the updated 
milestones.

And... happy new year to all of you!

-Markus



From owner-ietf-openproxy@mail.imc.org  Sat Jan 25 10:58:48 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25435
	for <opes-archive@ietf.org>; Sat, 25 Jan 2003 10:58:44 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0PEial26881
	for ietf-openproxy-bks; Sat, 25 Jan 2003 06:44:36 -0800 (PST)
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0PEiYo26877
	for <ietf-openproxy@imc.org>; Sat, 25 Jan 2003 06:44:35 -0800 (PST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0PEi0c05105;
	Sat, 25 Jan 2003 09:44:00 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DPZ23XKS>; Sat, 25 Jan 2003 09:44:00 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD75404AE570C@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: Internet-Drafts@ietf.org
Cc: Markus Hofmann <hofmann@bell-labs.com>,
        Marshall Rose <mrose@dbc.mtview.ca.us>,
        OPES Group <ietf-openproxy@imc.org>,
        "Abbie Barbir" <abbieb@nortelnetworks.com>
Subject: publish draft-ietf-opes-threats-01
Date: Sat, 25 Jan 2003 09:43:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C2C480.304048D4"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


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_01C2C480.304048D4
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2C480.304048D4"


------_=_NextPart_001_01C2C480.304048D4
Content-Type: text/plain

hi,

please publish the attached OPES WG draft as "draft-ietf-opes-threats-01".

thanks
Abbie
Nortel Networks


------_=_NextPart_001_01C2C480.304048D4
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>publish draft-ietf-opes-threats-01</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>hi,</FONT>
</P>

<P><FONT SIZE=2>please publish the attached OPES WG draft as &quot;draft-ietf-opes-threats-01&quot;.</FONT>
</P>

<P><FONT SIZE=2>thanks</FONT>
<BR><FONT SIZE=2>Abbie</FONT>
<BR><FONT SIZE=2>Nortel Networks</FONT>
</P>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C2C480.304048D4--

------_=_NextPart_000_01C2C480.304048D4
Content-Type: text/plain;
	name="draft-ietf-opes-threats-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-threats-01.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                         A. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: July 26, 2003                                        O. =
Batuner
                                                  Independent =
consultant
                                                             B. =
Srinivas
                                                                   =
Nokia
                                                              M. =
Hofmann
                                           Bell Labs/Lucent =
Technologies
                                                                H. =
Orman
                                               Purple Streak =
Development
                                                        January 25, =
2003


                  Security Threats and Risks for OPES
                       draft-ietf-opes-threats-01

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 July 26, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The document investigates the security threats associated with OPES.
   The effects of security threats on the underlying architecture are
   discussed.  The main goal of this document is threat discovery and
   analysis.  The document does not specify or recommend any solutions.



Barbir , et al.          Expires July 26, 2003                  [Page =
1]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   =
3
   2.     OPES Data Flow Threats . . . . . . . . . . . . . . . . . .   =
5
   2.1    OPES Flow Network Level Threats  . . . . . . . . . . . . .   =
6
   2.1.1  Connection-Flow Denial-of-Service (DoS)  . . . . . . . . .   =
6
   2.1.2  Threats to network robustness  . . . . . . . . . . . . . .   =
7
   2.2    OPES Flow Application Level Threats  . . . . . . . . . . .   =
7
   2.2.1  Unauthorized OPES entities . . . . . . . . . . . . . . . .   =
7
   2.2.2  Unauthorized actions of legitimate OPES entities . . . . .   =
7
   2.2.3  Unwanted content transformations . . . . . . . . . . . . .   =
8
   2.2.4  Corrupted content  . . . . . . . . . . . . . . . . . . . .   =
8
   2.2.5  Threats to message structure integrity . . . . . . . . . .   =
8
   2.2.6  Granularity of protection  . . . . . . . . . . . . . . . .   =
9
   2.2.7  Risks of hop-by-hop protection . . . . . . . . . . . . . .   =
9
   2.2.8  Threats to integrity of complex data . . . . . . . . . . .  =
10
   2.2.9  Denial of Service (DoS)  . . . . . . . . . . . . . . . . .  =
10
   2.2.10 Tracing and notification information . . . . . . . . . . .  =
10
   2.2.11 Unauthenticated Communication in OPES Flow . . . . . . . .  =
10
   3.     Threats to out-of-band data  . . . . . . . . . . . . . . .  =
11
   3.1    Threats that endanger the OPES data flow . . . . . . . . .  =
11
   3.2    Inaccurate Accounting Information  . . . . . . . . . . . .  =
11
   3.3    OPES service request repudiation . . . . . . . . . . . . .  =
12
   3.4    Inconsistent privacy policy  . . . . . . . . . . . . . . .  =
12
   3.5    Exposure of privacy preferences  . . . . . . . . . . . . .  =
12
   3.6    Exposure of security settings  . . . . . . . . . . . . . .  =
12
   3.7    Improper enforcement of privacy and security policy  . . .  =
13
   3.8    DOS Attacks  . . . . . . . . . . . . . . . . . . . . . . .  =
13
   4.     Security Considerations  . . . . . . . . . . . . . . . . .  =
14
          Normative References . . . . . . . . . . . . . . . . . . .  =
15
          Informative References . . . . . . . . . . . . . . . . . .  =
16
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  =
16
   A.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  =
18
          Intellectual Property and Copyright Statements . . . . . .  =
19

















Barbir , et al.          Expires July 26, 2003                  [Page =
2]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


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 details
   of the OPES architecture can be found in  [1].

   Security threats with respect to OPES can be viewed from different
   angles.  There are security risks that affect content consumer
   applications, and those that affect the data provider applications.
   These threats affect the quality and integrity of data that the
   applications either produce or consume.  On the other hand, the
   security risks can also be categorized into trust within the system
   (i.e.  OPES service providers) and protection of the system from
   threats imposed by outsiders such as hackers and attackers.  =
Insiders
   are those parties that are part of the OPES system.  Outsiders are
   those entities that are not participating in the OPES system.

   It must be noted that not everyone in an OPES  delivery path is
   equally trusted.  Each OPES administrative trust domain must protect
   itself from all outsiders.  Furthermore,  it may have limited trust
   relationship with another OPES administrative domain for certain
   purposes.

   OPES service provide must use authentication as the  basis for
   building trust relationships between administrative domains.
   Insiders can intentionally or unintentionally inflict harm and =
damage
   on the data consumer and data provider applications.  This can be
   through bad system configuration, execution of bad software or, if
   their networks are compromised, by inside or outside hackers.

   Depending on the deployment scenario, the trust within the OPES
   system is based on a set of transitive trust relationships between
   the data provider application, the OPES entities and the data
   consumer application.  Threats to OPES entities can be at the OPES
   flow level and/or at the network level.

   In considering threats to the OPES system, the document will follow =
a
   threat analysis model that identifies the threats from the
   perspective of how they will affect the data consumer and the data
   provider applications.

   The main goal of this document is threat discovery and analysis.  =
The



Barbir , et al.          Expires July 26, 2003                  [Page =
3]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   document does not specify or recommend any solutions.

   It is important to mention that the OPES architecture has many
   similarities with other so called overlay networks, specifically web
   caches and content delivery networks (CDN) (see [2] , [4] ).  This
   document focuses on threats that are introduced by the existence of
   the OPES processor and callout servers.  Security threats specific =
to
   content services that do not use the OPES architecture are =
considered
   out-of-scope of this document.  However, this document can be used =
as
   input when considering security implications for web caches and =
CDNs.

   The document is organized as follows: Section 2 discusses threats to
   OPES data flow on network and application level, section 3 discusses
   threats to other parts of the system and section 4 discusses =
security
   considerations.




































Barbir , et al.          Expires July 26, 2003                  [Page =
4]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


2. OPES Data Flow Threats

   Threats to OPES data flow can affect the data consumer and data
   provider applications.  At the OPES flow level, threats can occur at
   Policy Enforcement Points and Policy Decision Points [3]  and along
   the OPES flow path where network elements are used to process the
   data.

   A serious problem is posed by the very fact that the OPES
   architecture is based on widely adopted protocols (HTTP is used as =
an
   example).  The architecture document specifically requires that "the
   presence of an OPES processor in the data request/response flow =
SHALL
   NOT interfere with the operations of non-OPES aware clients and
   servers".  This greatly facilitates OPES deployment but on the other
   hand a vast majority of clients (browsers) will not be able to
   exploit any safeguards added as  base protocol extensions.

   For the usual data consumer, who might have questions such as (Where
   does this content come from? Can I get it another way? What is the
   difference? Is it legitimate?).  Even if there are facilities and
   technical expertise present to pursue these questions, such thorough
   examination of each result is prohibitively expensive in terms of
   time and effort.  OPES-aware content providers may try to protect
   themselves by adding verification scripts and special page
   structures.  OPES-aware end users may use special tools.  In all
   other cases (non-OPES aware clients and servers) protection will =
rely
   on monitoring services and investigation of occasionally discovered
   anomalies.

   An OPES system poses a special danger as a possible base for
   classical man-in-the-middle attacks.  One of the reasons why such
   attacks are relatively rare is the difficulty in finding an
   appropriate base: a combination of a traffic interception point
   controlling a large flow of data and an application codebase running
   on  a high-performance hardware with sufficient performance to
   analyze and possible modify all passing data.  An OPES processor
   meets this definition.  This calls for  special attention to
   protection measures at all levels of the system.

   Any compromise of an OPES processor or remote callout server can =
have
   a ripple effect on the integrity of the affected OPES services =
across
   all service providers that use the service.  To mitigate this threat
   appropriate security procedures and tools (e.g., a firewall) should
   be applied.

   Specific threats can exist at the network level and at OPES data =
flow
   level.




Barbir , et al.          Expires July 26, 2003                  [Page =
5]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


2.1 OPES Flow Network Level Threats

   OPES processor and callout servers are susceptible to network level
   attacks from outsiders or from the networks of other OPES service
   providers (i.e.  if the network of a contracted OPES service is
   compromised).

   The OPES architecture is based on common application protocols that
   do not provide strong guarantees of privacy, authentication, or
   integrity.  The IAB considerations [4] require that the IP address =
of
   an OPES processor be accessible to data consumer applications at the
   IP addressing level.  This requirement limit the ability of service
   providers of positioning the OPES processor behind firewalls and may
   exposes the OPES processor,  including remote callout servers, to
   network level attacks.  For example, the use of TCP/IP as network
   level protocol makes OPES processors subject to many known attacks,
   such as IP spoofing and session stealing.

   The OPES system is also susceptible to a number of security threats
   that are commonly associated with network infrastructure.  These
   threats include snooping, denial of service, sabotage, vandalism,
   industrial espionage and  theft of service.

   There are best practice solutions to mitigate network level threats.
   It is recommended that the security of the OPES entities at the
   network level be enhanced using known techniques and methods that
   minimize the risks of IP spoofing, snooping, denial of service and
   session stealing.

   At the OPES Flow level, connection-level security between the OPES
   processor and callout servers is an important consideration.  For
   example, it is possible to spoof the OPES processor or the remote
   callout server.  There are threats to data confidentiality between
   the OPES processor and the remote callout server in an OPES flow.

   The next subsections covers possible DOS attack on OPES processor,
   remote callout server or data consumer application and network
   robustness.

2.1.1 Connection-Flow Denial-of-Service (DoS)

   OPES processors, or callout servers or data consumer applications =
can
   be vulnerable to DOS attacks.  DOS attacks can be of various types.
   One example of DOS attacks is the overloading of OPES processors or
   callout servers by spurious service requests issued by a malicious
   node, which denies the legal data traffic the necessary resources to
   render service.  The resources include CPU cycles, memory, network
   interfaces, etc.  A Denial-of-Service attack can be selective,



Barbir , et al.          Expires July 26, 2003                  [Page =
6]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   generic or random in terms of which communication streams are
   affected.

   Distributed DoS is also possible when an attacker successfully
   directs multiple nodes over the network to initiate spurious service
   requests to an OPES processor(or callout server) simultaneously.

2.1.2 Threats to network robustness

   If OPES implementation does violate end-to-end addressing =
principles,
   it could endanger the Internet infrastructure by complicating =
routing
   and connection management.  If it does not use flow-control
   principles for managing connections, or if it interferes with
   end-to-end flow control of connections that it did not originate,
   then it could cause Internet congestion.

   An implementation that violates the IAB requirement of explicit IP
   level addressing (for example by adding OPES functional capabilities
   to an interception proxy) may defeat some of the protective
   mechanisms and safeguards built into the OPES architecture.

2.2 OPES Flow Application Level Threats

   At the content level, threats to the OPES system can come from
   outsiders or insiders.  The threat from outsiders is frequently
   intentional.  Threats from insiders can be intentional or due to
   inappropriate implementations such as programming and configuration
   errors that result in bad system behavior.

   Application level problems and threats to the OPES systems are
   discussed below:

2.2.1 Unauthorized OPES entities

   Although one party authorization is mandated by the OPES
   architecture, such authorization  occurs out-of-band.  Discovering
   the presence of an OPES entity and verifying authorization requires
   special actions and may present a problem.

   Adding notification and authorization information to the data
   messages (by using base protocol extensions) may help, especially if
   the data consumer's software is aware of such extensions.

2.2.2 Unauthorized actions of legitimate OPES entities

   According to the OPES architecture, the authorization is not tightly
   coupled with specific rules and procedures triggered by the rules.
   Even if a requirement to approve each particular rule and procedure



Barbir , et al.          Expires July 26, 2003                  [Page =
7]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   was set, it looks at least impractical if not impossible to request
   such permission from the end user.  The authorization is basically
   given for the class of transformations.  The actual rules and
   triggered procedures may (maliciously or due to a programming error)
   perform actions that they are not authorized for.


2.2.3 Unwanted content transformations

   An authorized OPES service may perform actions that do not adhere to
   the expectations of the party that gave the authorization for the
   service.  Examples may include ad flooding by a local ad insertion
   service or use of inappropriate policy by a content filtering
   service.

   On the other hand an OPES entity acting on behalf of one party may
   perform transformations that another party deems inappropriate.
   Examples may include replacing ads initially inserted by the content
   provider or applying filtering transformations that change the
   meaning of the text.

2.2.4 Corrupted content

   The OPES system may deliver outdated or otherwise distorted
   information due to programming problems or as a result of malicious
   attacks.  For example, a compromised server, instead of performing
   OPES service, may inject bogus content.  Such an action may be an =
act
   of cyber-vandalism (including virus injection) or intentional
   distribution of misleading information (such as manipulations with
   financial data).

   A compromised OPES server or malicious entity in the data flow may
   introduce changes specifically intended to cause improper actions in
   the OPES server or callout server.  These changes may be in the
   message body, headers or both.  This type of threat is discussed in
   more detail below.

2.2.5 Threats to message structure integrity

   An OPES server may add, remove or delete certain headers in a =
request
   and/or response message (for example to implement additional privacy
   protection or assist in content filtering).  Such changes may =
violate
   end-to-end integrity requirements or defeat services that use
   information provided in such headers (for example some local
   filtering services or reference-based services).






Barbir , et al.          Expires July 26, 2003                  [Page =
8]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


2.2.6 Granularity of protection

   OPES services have implicit permission to modify content.  However,
   the permissions generally apply only to portions of the content, for
   example, URL's between particular HTML tags, or text in headlines, =
or
   URL's matching particular patterns.  In order to express such
   policies, one must be able to refer to portions of messages and to
   detect modifications to message parts.

   Because there is currently very little support for policies that are
   expressed in terms of message parts, it will be difficult to
   attribute any particular modification to a particular OPES =
processor,
   or to automatically detect policy violations.

   A fine-grained policy language should be devised, and it could be
   enforced using digital signatures.  This would avoid the problems
   inherent in hop-by-hop data integrity measures (see next section).

2.2.7 Risks of hop-by-hop protection

   OPES services cannot be applied to data protected with end-to-end
   encryption methods because, by definition, the decryption key cannot
   be shared with OPES processors.  This means that if the endpoint
   policies permit OPES services, the data must either be transmitted
   without confidentiality protections or else with an alternative to
   end-to-end encryption: hop-by-hop encryption.  In the latter case,
   all the parties in the OPES processing path must understand the
   encryption requirement and negotiate encrypted connections with =
their
   OPES partners.

   Hop-by-hop protection is less effective than end-to-end protection,
   because any processor in the path which shares a cryptographic key,
   can violate the confidentiality or integrity of the data without
   detection.

   If a pair of processors in the delivery path use weak cryptography =
or
   manage keys poorly, there is a danger of data leakage.  For this
   reason, different cryptographic keys should be used for each leg of
   the data stream.

   Even if the data is not confidential, one might desire some checks =
on
   data integrity, to avoid modifications by unauthorized parties.  The
   comments above apply to the use of end-to-end integrity, if it is
   based on shared-key cryptography.  Again, it should be possible to
   use hop-by-hop data integrity to protect data as it moves between
   protection domains.

   Currently there is no method to signal hop-by-hop encryption or



Barbir , et al.          Expires July 26, 2003                  [Page =
9]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   integrity requirements.  Either this must be added to the =
application
   protocol, or OPES must define its own signaling protocol, or all =
OPES
   traffic MUST ALWAYS be encrypted.

2.2.8 Threats to integrity of complex data

   The OPES system may violate data integrity by applying inconsistent
   transformations to interrelated data objects or references within =
the
   data object.  Problems may range from a broken reference structure
   (modified/missing targets, references to wrong locations or missing
   documents) to deliberate replacement/deletion/insertion of links =
that
   violate intentions of the content provider.


2.2.9 Denial of Service (DoS)

   The data consumer application may not be able to access data if the
   OPES system fails for any reason.

   A malicious or malfunctioning node may be able to block all traffic.
   The data traffic destined for the OPES processor (or callout server)
   may not be able to use the services of the OPES device.  The DoS may
   be achieved by preventing the data traffic from reaching the
   processor  or the callout server.

2.2.10 Tracing and notification information

   Inadequate or vulnerable implementation of the tracing and
   notification mechanisms may defeat safeguards built into the OPES
   architecture.

   Tracing and notification facilities may become a target of malicious
   attack.  Such an attack may  create problems in discovering and
   stopping other attacks.

   The absence of a standard for tracing and notification information
   may present an additional problem.  This information is produced and
   consumed by the independent entities (OPES servers/user agents/
   content provider facilities).  This calls for a set of standards
   related to each base protocol in use.

2.2.11 Unauthenticated Communication in OPES Flow

   There are risks and threats that could arise from unauthenticated
   communication between the OPES server and callout servers.  Lack of
   use of strong authentication between OPES processors and callout
   servers may open security holes whereby DOS and other types of
   attacks (see sections [2 and 3]) can be performed.



Barbir , et al.          Expires July 26, 2003                 [Page =
10]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


3. Threats to out-of-band data

   The OPES architecture separates a data flow from a control
   information flow (loading rulesets, trust establishment, tracing,
   policy propagation, etc.).  There are certain requirements set for
   the latter but no specific mechanism is prescribed.  This gives more
   flexibility for implementations but creates more burden for
   implementers and potential customers to ensure that each specific
   implementation meets all requirements for data security, entity
   authentication and action authorization.

   In addition to performing correct actions on the OPES data flow, any
   OPES implementation has to provide an adequate mechanism to satisfy
   requirements for out-of-band data and signaling information
   integrity.

   Whatever the specific mechanism may be, it inevitably becomes =
subject
   to multiple security threats and possible attacks.  The way the
   threats and attacks may be realized depends on implementation
   specifics but the resulting harm generally falls into two =
categories:
   threats to OPES data flow and threats to data integrity.

   The specific threats are:

3.1 Threats that endanger the OPES data flow

   Any weakness in the implementation of a security, authentication, or
   authorization mechanism may open the door to the attacks described =
in
   section 2.

   An OPES system implementation should address all these threats and
   prove its robustness and ability to withstand malicious attacks or
   networking and programming problems.

3.2 Inaccurate Accounting Information

   Collecting and reporting accurate accounting data may be vital when
   OPES servers are used to extend a business model of content =
provider,
   service provider or as a basis  for third party service.  Ability to
   collect and process accounting data is an important part of OPES
   system functionality.  This functionality may be challenged by
   distortion or destruction of base accounting data (usually logs),
   processed accounting data, accounting parameters and reporting
   configuration.

   As a result a data consumer may be inappropriately charged for
   viewing content that was not successfully delivered, or a content
   provider or independent OPES services provider may not be =
compensated



Barbir , et al.          Expires July 26, 2003                 [Page =
11]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   for the services performed.

   OPES system may use accounting information to distribute resources
   between different consumers or limit resource usage by a specific
   consumer.  In this case an attack on accounting system (by =
distortion
   of data or issuing false configuration commands) may result in
   incorrect resource management and DoS by artificial resource
   starvation.

3.3 OPES service request repudiation

   An entity (producer or consumer) makes an authorized request and
   claim, later, that it did not make that request.  As a result an =
OPES
   entity may be held liable for unauthorized changes to the data flow,
   or will be unable to receive compensation for a service.

   There SHOULD be a clear request that this service is required and
   there SHOULD be a clear course of action on the behalf of all
   parties.  This action  SHOULD have a request, and SHOULD have an
   action, and SHOULD have a means of repudiation of the request, and
   SHOULD have a means to specify the effect of the action.


3.4 Inconsistent privacy policy

   The OPES entities may have privacy policies that are not consistent
   with the data consumer application or content provider application.

   Privacy related problems may be further complicated if OPES =
entities,
   content providers and end users belong to different jurisdictions
   with different requirements and different levels of legal =
protection.
   As a result the end user may not be aware that he or she does not
   have the expected  legal protection.  The content provider may be
   exposed to legal risks due to a failure to comply with regulation
   which he is not even aware of.

3.5 Exposure of privacy preferences

   The OPES system may inadvertently or maliciously expose end user
   privacy settings and requirements.

3.6 Exposure of security settings

   There are risks that the OPES system may expose end user security
   settings when handling the request and responses.  The user data =
must
   be handled as sensitive system information and protected against
   accidental and deliberate disclosure.




Barbir , et al.          Expires July 26, 2003                 [Page =
12]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


3.7 Improper enforcement of privacy and security policy

   OPES entities are part of the content distribution system and as =
such
   take on certain obligations to support security and privacy policies
   mandated by content producer and/or end user.  However there is a
   danger that these policies are not properly implemented and =
enforced.
   The data consumer application may not be aware that its protections
   are no longer in effect.

   There is also the possibility of security and privacy leaks due to
   the accidental misconfiguration or, due to missunderstanding what
   rules are in effect for a particular user or request.

   Privacy and security related parts of the systems can be targeted by
   malicious attacks and ability to withstand such attacks is of
   paramount importance.

3.8 DOS Attacks

   DOS attacks can be of various types.  One type of DOS attacks can
   take effect by overloading the client.  For example, an intruder can
   direct an OPES processor to issue numerous responses to a client.
   There is also additional DOS risk from a rule misconfiguration that
   would have the OPES processor ignore a data consumer application.



























Barbir , et al.          Expires July 26, 2003                 [Page =
13]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


4. Security Considerations

   This document discusses multiple security and privacy issues related
   to the OPES services.















































Barbir , et al.          Expires July 26, 2003                 [Page =
14]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


Normative 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-04.txt, Aug 2002.

   [2]  A. Barbir et. al, "OPES Use Cases and Deployment Scenarios",
        Internet-Draft: http://www.ietf.org/
        draft-ietf-opes-scenarios-01, July 2002.

   [3]  A. Barbir et. al, "Requirements for Policy, Authorization  and
        Enforcement of OPES Services", Internet-Draft: http://
        www.ietf.org/internet-  drafts/
        draft-ietf-opes-authorization-00.txt , October  2002.





































Barbir , et al.          Expires July 26, 2003                 [Page =
15]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


Informative References

   [4]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [5]  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.

   [6]  Cooper, I., "Internet Web Replication and Caching Taxonomy", =
RFC
        3040, January 2001.


Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com


   Oskar Batuner
   Independent consultant



   EMail: batuner@attbi.com


   Bindignavile Srinivas
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   USA

   EMail: bindignavile.srinivas@nokia.com










Barbir , et al.          Expires July 26, 2003                 [Page =
16]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   Markus Hofmann
   Bell Labs/Lucent Technologies
   Room 4F-513
   101 Crawfords Corner Road
   Holmdel, NJ  07733
   US

   Phone: +1 732 332 5983
   EMail: hofmann@bell-labs.com


   Hilarie Orman
   Purple Streak Development



   Phone:
   EMail: ho@alum.mit.edu

































Barbir , et al.          Expires July 26, 2003                 [Page =
17]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


Appendix A. Acknowledgements

   TBD
















































Barbir , et al.          Expires July 26, 2003                 [Page =
18]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances =
of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification =
can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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 assignees.

   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



Barbir , et al.          Expires July 26, 2003                 [Page =
19]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   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 July 26, 2003                 [Page =
20]
=0C




------_=_NextPart_000_01C2C480.304048D4--


From owner-ietf-openproxy@mail.imc.org  Mon Jan 27 02:46:48 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09181
	for <opes-archive@ietf.org>; Mon, 27 Jan 2003 02:46:43 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0R67hI22776
	for ietf-openproxy-bks; Sun, 26 Jan 2003 22:07:43 -0800 (PST)
Received: from server2.fastmail.fm (ny2.fastmail.fm [66.111.4.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R67fo22771
	for <ietf-openproxy@imc.org>; Sun, 26 Jan 2003 22:07:41 -0800 (PST)
Received: from www.fastmail.fm (server1.internal [10.202.2.132])
	by fastmail.fm (Postfix) with ESMTP id 05F0E44247
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 01:07:44 -0500 (EST)
Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm
  with SMTP; Mon, 27 Jan 2003 01:07:44 -0500
X-Epoch: 1043647664
X-Sasl-enc: LRl9OPVO4vzc12C5xBJr9A
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
	by www.fastmail.fm (Postfix) with ESMTP id D528123C4
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 01:07:40 -0500 (EST)
Message-ID: <3E34CCAC.5080607@mhof.com>
Date: Mon, 27 Jan 2003 01:07:40 -0500
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us
MIME-Version: 1.0
To: OPES Group <ietf-openproxy@imc.org>
Subject: WG Last Call: draft-ietf-opes-threats-01
Content-Type: multipart/mixed;
 boundary="------------060407030809030809070101"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.
--------------060407030809030809070101
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

We are starting WG last call on the threats/risk document (see 
attached). The last call period closes on Monday, 3 February at 5pm 
EST. Please post any comments, etc. to the mailing list, and please 
point out whether you feel your comment is editorial or a show-stopper.

Thanks,
   Markus

--------------060407030809030809070101
Content-Type: message/rfc822;
 name="publish draft-ietf-opes-threats-01"
Content-Disposition: inline;
 filename="publish draft-ietf-opes-threats-01"

Return-Path: <owner-ietf-openproxy@mail.imc.org>
Received: from server3.fastmail.fm (server3.internal [10.202.2.134])
	by server2.fastmail.fm (Cyrus v2.1.9) with LMTP; Sat, 25 Jan 2003 10:57:22 -0500
X-Sieve: CMU Sieve 2.2
Received: from server3.fastmail.fm (server3.internal [10.202.2.134])
	by server3.fastmail.fm (Cyrus v2.1.9) with LMTP; Sat, 25 Jan 2003 10:57:22 -0500
Received: from server3.fastmail.fm (localhost [127.0.0.1])
	by fastmail.fm (Postfix) with ESMTP id C977B397FD
	for <hofmann@fastmail.fm>; Sat, 25 Jan 2003 10:57:21 -0500 (EST)
X-Attached: draft-ietf-opes-threats-01.txt
X-Virus-checked: Yes
Received: from 127.0.0.1 ([127.0.0.1] helo=server3.fastmail.fm) by fastmail.fm
  with SMTP; Sat, 25 Jan 2003 10:57:22 -0500
X-Mail-from: owner-ietf-openproxy@mail.imc.org
X-Delivered-to: <markus@mhof.com>
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by server3.fastmail.fm (Postfix) with ESMTP id DB9C9399C6
	for <markus@mhof.com>; Sat, 25 Jan 2003 10:55:37 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0PEial26881
	for ietf-openproxy-bks; Sat, 25 Jan 2003 06:44:36 -0800 (PST)
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0PEiYo26877
	for <ietf-openproxy@imc.org>; Sat, 25 Jan 2003 06:44:35 -0800 (PST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0PEi0c05105;
	Sat, 25 Jan 2003 09:44:00 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DPZ23XKS>; Sat, 25 Jan 2003 09:44:00 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD75404AE570C@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: Internet-Drafts@ietf.org
Cc: Markus Hofmann <hofmann@bell-labs.com>,
	Marshall Rose <mrose@dbc.mtview.ca.us>,
	OPES Group <ietf-openproxy@imc.org>,
	"Abbie Barbir" <abbieb@nortelnetworks.com>
Subject: publish draft-ietf-opes-threats-01
Date: Sat, 25 Jan 2003 09:43:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C2C480.304048D4"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


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_01C2C480.304048D4
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2C480.304048D4"


------_=_NextPart_001_01C2C480.304048D4
Content-Type: text/plain

hi,

please publish the attached OPES WG draft as "draft-ietf-opes-threats-01".

thanks
Abbie
Nortel Networks


------_=_NextPart_001_01C2C480.304048D4
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>publish draft-ietf-opes-threats-01</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>hi,</FONT>
</P>

<P><FONT SIZE=2>please publish the attached OPES WG draft as &quot;draft-ietf-opes-threats-01&quot;.</FONT>
</P>

<P><FONT SIZE=2>thanks</FONT>
<BR><FONT SIZE=2>Abbie</FONT>
<BR><FONT SIZE=2>Nortel Networks</FONT>
</P>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C2C480.304048D4--

------_=_NextPart_000_01C2C480.304048D4
Content-Type: text/plain;
	name="draft-ietf-opes-threats-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-threats-01.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                         A. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: July 26, 2003                                        O. =
Batuner
                                                  Independent =
consultant
                                                             B. =
Srinivas
                                                                   =
Nokia
                                                              M. =
Hofmann
                                           Bell Labs/Lucent =
Technologies
                                                                H. =
Orman
                                               Purple Streak =
Development
                                                        January 25, =
2003


                  Security Threats and Risks for OPES
                       draft-ietf-opes-threats-01

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 July 26, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The document investigates the security threats associated with OPES.
   The effects of security threats on the underlying architecture are
   discussed.  The main goal of this document is threat discovery and
   analysis.  The document does not specify or recommend any solutions.



Barbir , et al.          Expires July 26, 2003                  [Page =
1]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   =
3
   2.     OPES Data Flow Threats . . . . . . . . . . . . . . . . . .   =
5
   2.1    OPES Flow Network Level Threats  . . . . . . . . . . . . .   =
6
   2.1.1  Connection-Flow Denial-of-Service (DoS)  . . . . . . . . .   =
6
   2.1.2  Threats to network robustness  . . . . . . . . . . . . . .   =
7
   2.2    OPES Flow Application Level Threats  . . . . . . . . . . .   =
7
   2.2.1  Unauthorized OPES entities . . . . . . . . . . . . . . . .   =
7
   2.2.2  Unauthorized actions of legitimate OPES entities . . . . .   =
7
   2.2.3  Unwanted content transformations . . . . . . . . . . . . .   =
8
   2.2.4  Corrupted content  . . . . . . . . . . . . . . . . . . . .   =
8
   2.2.5  Threats to message structure integrity . . . . . . . . . .   =
8
   2.2.6  Granularity of protection  . . . . . . . . . . . . . . . .   =
9
   2.2.7  Risks of hop-by-hop protection . . . . . . . . . . . . . .   =
9
   2.2.8  Threats to integrity of complex data . . . . . . . . . . .  =
10
   2.2.9  Denial of Service (DoS)  . . . . . . . . . . . . . . . . .  =
10
   2.2.10 Tracing and notification information . . . . . . . . . . .  =
10
   2.2.11 Unauthenticated Communication in OPES Flow . . . . . . . .  =
10
   3.     Threats to out-of-band data  . . . . . . . . . . . . . . .  =
11
   3.1    Threats that endanger the OPES data flow . . . . . . . . .  =
11
   3.2    Inaccurate Accounting Information  . . . . . . . . . . . .  =
11
   3.3    OPES service request repudiation . . . . . . . . . . . . .  =
12
   3.4    Inconsistent privacy policy  . . . . . . . . . . . . . . .  =
12
   3.5    Exposure of privacy preferences  . . . . . . . . . . . . .  =
12
   3.6    Exposure of security settings  . . . . . . . . . . . . . .  =
12
   3.7    Improper enforcement of privacy and security policy  . . .  =
13
   3.8    DOS Attacks  . . . . . . . . . . . . . . . . . . . . . . .  =
13
   4.     Security Considerations  . . . . . . . . . . . . . . . . .  =
14
          Normative References . . . . . . . . . . . . . . . . . . .  =
15
          Informative References . . . . . . . . . . . . . . . . . .  =
16
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  =
16
   A.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  =
18
          Intellectual Property and Copyright Statements . . . . . .  =
19

















Barbir , et al.          Expires July 26, 2003                  [Page =
2]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


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 details
   of the OPES architecture can be found in  [1].

   Security threats with respect to OPES can be viewed from different
   angles.  There are security risks that affect content consumer
   applications, and those that affect the data provider applications.
   These threats affect the quality and integrity of data that the
   applications either produce or consume.  On the other hand, the
   security risks can also be categorized into trust within the system
   (i.e.  OPES service providers) and protection of the system from
   threats imposed by outsiders such as hackers and attackers.  =
Insiders
   are those parties that are part of the OPES system.  Outsiders are
   those entities that are not participating in the OPES system.

   It must be noted that not everyone in an OPES  delivery path is
   equally trusted.  Each OPES administrative trust domain must protect
   itself from all outsiders.  Furthermore,  it may have limited trust
   relationship with another OPES administrative domain for certain
   purposes.

   OPES service provide must use authentication as the  basis for
   building trust relationships between administrative domains.
   Insiders can intentionally or unintentionally inflict harm and =
damage
   on the data consumer and data provider applications.  This can be
   through bad system configuration, execution of bad software or, if
   their networks are compromised, by inside or outside hackers.

   Depending on the deployment scenario, the trust within the OPES
   system is based on a set of transitive trust relationships between
   the data provider application, the OPES entities and the data
   consumer application.  Threats to OPES entities can be at the OPES
   flow level and/or at the network level.

   In considering threats to the OPES system, the document will follow =
a
   threat analysis model that identifies the threats from the
   perspective of how they will affect the data consumer and the data
   provider applications.

   The main goal of this document is threat discovery and analysis.  =
The



Barbir , et al.          Expires July 26, 2003                  [Page =
3]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   document does not specify or recommend any solutions.

   It is important to mention that the OPES architecture has many
   similarities with other so called overlay networks, specifically web
   caches and content delivery networks (CDN) (see [2] , [4] ).  This
   document focuses on threats that are introduced by the existence of
   the OPES processor and callout servers.  Security threats specific =
to
   content services that do not use the OPES architecture are =
considered
   out-of-scope of this document.  However, this document can be used =
as
   input when considering security implications for web caches and =
CDNs.

   The document is organized as follows: Section 2 discusses threats to
   OPES data flow on network and application level, section 3 discusses
   threats to other parts of the system and section 4 discusses =
security
   considerations.




































Barbir , et al.          Expires July 26, 2003                  [Page =
4]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


2. OPES Data Flow Threats

   Threats to OPES data flow can affect the data consumer and data
   provider applications.  At the OPES flow level, threats can occur at
   Policy Enforcement Points and Policy Decision Points [3]  and along
   the OPES flow path where network elements are used to process the
   data.

   A serious problem is posed by the very fact that the OPES
   architecture is based on widely adopted protocols (HTTP is used as =
an
   example).  The architecture document specifically requires that "the
   presence of an OPES processor in the data request/response flow =
SHALL
   NOT interfere with the operations of non-OPES aware clients and
   servers".  This greatly facilitates OPES deployment but on the other
   hand a vast majority of clients (browsers) will not be able to
   exploit any safeguards added as  base protocol extensions.

   For the usual data consumer, who might have questions such as (Where
   does this content come from? Can I get it another way? What is the
   difference? Is it legitimate?).  Even if there are facilities and
   technical expertise present to pursue these questions, such thorough
   examination of each result is prohibitively expensive in terms of
   time and effort.  OPES-aware content providers may try to protect
   themselves by adding verification scripts and special page
   structures.  OPES-aware end users may use special tools.  In all
   other cases (non-OPES aware clients and servers) protection will =
rely
   on monitoring services and investigation of occasionally discovered
   anomalies.

   An OPES system poses a special danger as a possible base for
   classical man-in-the-middle attacks.  One of the reasons why such
   attacks are relatively rare is the difficulty in finding an
   appropriate base: a combination of a traffic interception point
   controlling a large flow of data and an application codebase running
   on  a high-performance hardware with sufficient performance to
   analyze and possible modify all passing data.  An OPES processor
   meets this definition.  This calls for  special attention to
   protection measures at all levels of the system.

   Any compromise of an OPES processor or remote callout server can =
have
   a ripple effect on the integrity of the affected OPES services =
across
   all service providers that use the service.  To mitigate this threat
   appropriate security procedures and tools (e.g., a firewall) should
   be applied.

   Specific threats can exist at the network level and at OPES data =
flow
   level.




Barbir , et al.          Expires July 26, 2003                  [Page =
5]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


2.1 OPES Flow Network Level Threats

   OPES processor and callout servers are susceptible to network level
   attacks from outsiders or from the networks of other OPES service
   providers (i.e.  if the network of a contracted OPES service is
   compromised).

   The OPES architecture is based on common application protocols that
   do not provide strong guarantees of privacy, authentication, or
   integrity.  The IAB considerations [4] require that the IP address =
of
   an OPES processor be accessible to data consumer applications at the
   IP addressing level.  This requirement limit the ability of service
   providers of positioning the OPES processor behind firewalls and may
   exposes the OPES processor,  including remote callout servers, to
   network level attacks.  For example, the use of TCP/IP as network
   level protocol makes OPES processors subject to many known attacks,
   such as IP spoofing and session stealing.

   The OPES system is also susceptible to a number of security threats
   that are commonly associated with network infrastructure.  These
   threats include snooping, denial of service, sabotage, vandalism,
   industrial espionage and  theft of service.

   There are best practice solutions to mitigate network level threats.
   It is recommended that the security of the OPES entities at the
   network level be enhanced using known techniques and methods that
   minimize the risks of IP spoofing, snooping, denial of service and
   session stealing.

   At the OPES Flow level, connection-level security between the OPES
   processor and callout servers is an important consideration.  For
   example, it is possible to spoof the OPES processor or the remote
   callout server.  There are threats to data confidentiality between
   the OPES processor and the remote callout server in an OPES flow.

   The next subsections covers possible DOS attack on OPES processor,
   remote callout server or data consumer application and network
   robustness.

2.1.1 Connection-Flow Denial-of-Service (DoS)

   OPES processors, or callout servers or data consumer applications =
can
   be vulnerable to DOS attacks.  DOS attacks can be of various types.
   One example of DOS attacks is the overloading of OPES processors or
   callout servers by spurious service requests issued by a malicious
   node, which denies the legal data traffic the necessary resources to
   render service.  The resources include CPU cycles, memory, network
   interfaces, etc.  A Denial-of-Service attack can be selective,



Barbir , et al.          Expires July 26, 2003                  [Page =
6]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   generic or random in terms of which communication streams are
   affected.

   Distributed DoS is also possible when an attacker successfully
   directs multiple nodes over the network to initiate spurious service
   requests to an OPES processor(or callout server) simultaneously.

2.1.2 Threats to network robustness

   If OPES implementation does violate end-to-end addressing =
principles,
   it could endanger the Internet infrastructure by complicating =
routing
   and connection management.  If it does not use flow-control
   principles for managing connections, or if it interferes with
   end-to-end flow control of connections that it did not originate,
   then it could cause Internet congestion.

   An implementation that violates the IAB requirement of explicit IP
   level addressing (for example by adding OPES functional capabilities
   to an interception proxy) may defeat some of the protective
   mechanisms and safeguards built into the OPES architecture.

2.2 OPES Flow Application Level Threats

   At the content level, threats to the OPES system can come from
   outsiders or insiders.  The threat from outsiders is frequently
   intentional.  Threats from insiders can be intentional or due to
   inappropriate implementations such as programming and configuration
   errors that result in bad system behavior.

   Application level problems and threats to the OPES systems are
   discussed below:

2.2.1 Unauthorized OPES entities

   Although one party authorization is mandated by the OPES
   architecture, such authorization  occurs out-of-band.  Discovering
   the presence of an OPES entity and verifying authorization requires
   special actions and may present a problem.

   Adding notification and authorization information to the data
   messages (by using base protocol extensions) may help, especially if
   the data consumer's software is aware of such extensions.

2.2.2 Unauthorized actions of legitimate OPES entities

   According to the OPES architecture, the authorization is not tightly
   coupled with specific rules and procedures triggered by the rules.
   Even if a requirement to approve each particular rule and procedure



Barbir , et al.          Expires July 26, 2003                  [Page =
7]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   was set, it looks at least impractical if not impossible to request
   such permission from the end user.  The authorization is basically
   given for the class of transformations.  The actual rules and
   triggered procedures may (maliciously or due to a programming error)
   perform actions that they are not authorized for.


2.2.3 Unwanted content transformations

   An authorized OPES service may perform actions that do not adhere to
   the expectations of the party that gave the authorization for the
   service.  Examples may include ad flooding by a local ad insertion
   service or use of inappropriate policy by a content filtering
   service.

   On the other hand an OPES entity acting on behalf of one party may
   perform transformations that another party deems inappropriate.
   Examples may include replacing ads initially inserted by the content
   provider or applying filtering transformations that change the
   meaning of the text.

2.2.4 Corrupted content

   The OPES system may deliver outdated or otherwise distorted
   information due to programming problems or as a result of malicious
   attacks.  For example, a compromised server, instead of performing
   OPES service, may inject bogus content.  Such an action may be an =
act
   of cyber-vandalism (including virus injection) or intentional
   distribution of misleading information (such as manipulations with
   financial data).

   A compromised OPES server or malicious entity in the data flow may
   introduce changes specifically intended to cause improper actions in
   the OPES server or callout server.  These changes may be in the
   message body, headers or both.  This type of threat is discussed in
   more detail below.

2.2.5 Threats to message structure integrity

   An OPES server may add, remove or delete certain headers in a =
request
   and/or response message (for example to implement additional privacy
   protection or assist in content filtering).  Such changes may =
violate
   end-to-end integrity requirements or defeat services that use
   information provided in such headers (for example some local
   filtering services or reference-based services).






Barbir , et al.          Expires July 26, 2003                  [Page =
8]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


2.2.6 Granularity of protection

   OPES services have implicit permission to modify content.  However,
   the permissions generally apply only to portions of the content, for
   example, URL's between particular HTML tags, or text in headlines, =
or
   URL's matching particular patterns.  In order to express such
   policies, one must be able to refer to portions of messages and to
   detect modifications to message parts.

   Because there is currently very little support for policies that are
   expressed in terms of message parts, it will be difficult to
   attribute any particular modification to a particular OPES =
processor,
   or to automatically detect policy violations.

   A fine-grained policy language should be devised, and it could be
   enforced using digital signatures.  This would avoid the problems
   inherent in hop-by-hop data integrity measures (see next section).

2.2.7 Risks of hop-by-hop protection

   OPES services cannot be applied to data protected with end-to-end
   encryption methods because, by definition, the decryption key cannot
   be shared with OPES processors.  This means that if the endpoint
   policies permit OPES services, the data must either be transmitted
   without confidentiality protections or else with an alternative to
   end-to-end encryption: hop-by-hop encryption.  In the latter case,
   all the parties in the OPES processing path must understand the
   encryption requirement and negotiate encrypted connections with =
their
   OPES partners.

   Hop-by-hop protection is less effective than end-to-end protection,
   because any processor in the path which shares a cryptographic key,
   can violate the confidentiality or integrity of the data without
   detection.

   If a pair of processors in the delivery path use weak cryptography =
or
   manage keys poorly, there is a danger of data leakage.  For this
   reason, different cryptographic keys should be used for each leg of
   the data stream.

   Even if the data is not confidential, one might desire some checks =
on
   data integrity, to avoid modifications by unauthorized parties.  The
   comments above apply to the use of end-to-end integrity, if it is
   based on shared-key cryptography.  Again, it should be possible to
   use hop-by-hop data integrity to protect data as it moves between
   protection domains.

   Currently there is no method to signal hop-by-hop encryption or



Barbir , et al.          Expires July 26, 2003                  [Page =
9]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   integrity requirements.  Either this must be added to the =
application
   protocol, or OPES must define its own signaling protocol, or all =
OPES
   traffic MUST ALWAYS be encrypted.

2.2.8 Threats to integrity of complex data

   The OPES system may violate data integrity by applying inconsistent
   transformations to interrelated data objects or references within =
the
   data object.  Problems may range from a broken reference structure
   (modified/missing targets, references to wrong locations or missing
   documents) to deliberate replacement/deletion/insertion of links =
that
   violate intentions of the content provider.


2.2.9 Denial of Service (DoS)

   The data consumer application may not be able to access data if the
   OPES system fails for any reason.

   A malicious or malfunctioning node may be able to block all traffic.
   The data traffic destined for the OPES processor (or callout server)
   may not be able to use the services of the OPES device.  The DoS may
   be achieved by preventing the data traffic from reaching the
   processor  or the callout server.

2.2.10 Tracing and notification information

   Inadequate or vulnerable implementation of the tracing and
   notification mechanisms may defeat safeguards built into the OPES
   architecture.

   Tracing and notification facilities may become a target of malicious
   attack.  Such an attack may  create problems in discovering and
   stopping other attacks.

   The absence of a standard for tracing and notification information
   may present an additional problem.  This information is produced and
   consumed by the independent entities (OPES servers/user agents/
   content provider facilities).  This calls for a set of standards
   related to each base protocol in use.

2.2.11 Unauthenticated Communication in OPES Flow

   There are risks and threats that could arise from unauthenticated
   communication between the OPES server and callout servers.  Lack of
   use of strong authentication between OPES processors and callout
   servers may open security holes whereby DOS and other types of
   attacks (see sections [2 and 3]) can be performed.



Barbir , et al.          Expires July 26, 2003                 [Page =
10]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


3. Threats to out-of-band data

   The OPES architecture separates a data flow from a control
   information flow (loading rulesets, trust establishment, tracing,
   policy propagation, etc.).  There are certain requirements set for
   the latter but no specific mechanism is prescribed.  This gives more
   flexibility for implementations but creates more burden for
   implementers and potential customers to ensure that each specific
   implementation meets all requirements for data security, entity
   authentication and action authorization.

   In addition to performing correct actions on the OPES data flow, any
   OPES implementation has to provide an adequate mechanism to satisfy
   requirements for out-of-band data and signaling information
   integrity.

   Whatever the specific mechanism may be, it inevitably becomes =
subject
   to multiple security threats and possible attacks.  The way the
   threats and attacks may be realized depends on implementation
   specifics but the resulting harm generally falls into two =
categories:
   threats to OPES data flow and threats to data integrity.

   The specific threats are:

3.1 Threats that endanger the OPES data flow

   Any weakness in the implementation of a security, authentication, or
   authorization mechanism may open the door to the attacks described =
in
   section 2.

   An OPES system implementation should address all these threats and
   prove its robustness and ability to withstand malicious attacks or
   networking and programming problems.

3.2 Inaccurate Accounting Information

   Collecting and reporting accurate accounting data may be vital when
   OPES servers are used to extend a business model of content =
provider,
   service provider or as a basis  for third party service.  Ability to
   collect and process accounting data is an important part of OPES
   system functionality.  This functionality may be challenged by
   distortion or destruction of base accounting data (usually logs),
   processed accounting data, accounting parameters and reporting
   configuration.

   As a result a data consumer may be inappropriately charged for
   viewing content that was not successfully delivered, or a content
   provider or independent OPES services provider may not be =
compensated



Barbir , et al.          Expires July 26, 2003                 [Page =
11]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   for the services performed.

   OPES system may use accounting information to distribute resources
   between different consumers or limit resource usage by a specific
   consumer.  In this case an attack on accounting system (by =
distortion
   of data or issuing false configuration commands) may result in
   incorrect resource management and DoS by artificial resource
   starvation.

3.3 OPES service request repudiation

   An entity (producer or consumer) makes an authorized request and
   claim, later, that it did not make that request.  As a result an =
OPES
   entity may be held liable for unauthorized changes to the data flow,
   or will be unable to receive compensation for a service.

   There SHOULD be a clear request that this service is required and
   there SHOULD be a clear course of action on the behalf of all
   parties.  This action  SHOULD have a request, and SHOULD have an
   action, and SHOULD have a means of repudiation of the request, and
   SHOULD have a means to specify the effect of the action.


3.4 Inconsistent privacy policy

   The OPES entities may have privacy policies that are not consistent
   with the data consumer application or content provider application.

   Privacy related problems may be further complicated if OPES =
entities,
   content providers and end users belong to different jurisdictions
   with different requirements and different levels of legal =
protection.
   As a result the end user may not be aware that he or she does not
   have the expected  legal protection.  The content provider may be
   exposed to legal risks due to a failure to comply with regulation
   which he is not even aware of.

3.5 Exposure of privacy preferences

   The OPES system may inadvertently or maliciously expose end user
   privacy settings and requirements.

3.6 Exposure of security settings

   There are risks that the OPES system may expose end user security
   settings when handling the request and responses.  The user data =
must
   be handled as sensitive system information and protected against
   accidental and deliberate disclosure.




Barbir , et al.          Expires July 26, 2003                 [Page =
12]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


3.7 Improper enforcement of privacy and security policy

   OPES entities are part of the content distribution system and as =
such
   take on certain obligations to support security and privacy policies
   mandated by content producer and/or end user.  However there is a
   danger that these policies are not properly implemented and =
enforced.
   The data consumer application may not be aware that its protections
   are no longer in effect.

   There is also the possibility of security and privacy leaks due to
   the accidental misconfiguration or, due to missunderstanding what
   rules are in effect for a particular user or request.

   Privacy and security related parts of the systems can be targeted by
   malicious attacks and ability to withstand such attacks is of
   paramount importance.

3.8 DOS Attacks

   DOS attacks can be of various types.  One type of DOS attacks can
   take effect by overloading the client.  For example, an intruder can
   direct an OPES processor to issue numerous responses to a client.
   There is also additional DOS risk from a rule misconfiguration that
   would have the OPES processor ignore a data consumer application.



























Barbir , et al.          Expires July 26, 2003                 [Page =
13]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


4. Security Considerations

   This document discusses multiple security and privacy issues related
   to the OPES services.















































Barbir , et al.          Expires July 26, 2003                 [Page =
14]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


Normative 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-04.txt, Aug 2002.

   [2]  A. Barbir et. al, "OPES Use Cases and Deployment Scenarios",
        Internet-Draft: http://www.ietf.org/
        draft-ietf-opes-scenarios-01, July 2002.

   [3]  A. Barbir et. al, "Requirements for Policy, Authorization  and
        Enforcement of OPES Services", Internet-Draft: http://
        www.ietf.org/internet-  drafts/
        draft-ietf-opes-authorization-00.txt , October  2002.





































Barbir , et al.          Expires July 26, 2003                 [Page =
15]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


Informative References

   [4]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [5]  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.

   [6]  Cooper, I., "Internet Web Replication and Caching Taxonomy", =
RFC
        3040, January 2001.


Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com


   Oskar Batuner
   Independent consultant



   EMail: batuner@attbi.com


   Bindignavile Srinivas
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   USA

   EMail: bindignavile.srinivas@nokia.com










Barbir , et al.          Expires July 26, 2003                 [Page =
16]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   Markus Hofmann
   Bell Labs/Lucent Technologies
   Room 4F-513
   101 Crawfords Corner Road
   Holmdel, NJ  07733
   US

   Phone: +1 732 332 5983
   EMail: hofmann@bell-labs.com


   Hilarie Orman
   Purple Streak Development



   Phone:
   EMail: ho@alum.mit.edu

































Barbir , et al.          Expires July 26, 2003                 [Page =
17]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


Appendix A. Acknowledgements

   TBD
















































Barbir , et al.          Expires July 26, 2003                 [Page =
18]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances =
of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification =
can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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 assignees.

   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



Barbir , et al.          Expires July 26, 2003                 [Page =
19]
=0C
Internet-Draft    Security Threats and Risks for OPES       January =
2003


   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 July 26, 2003                 [Page =
20]
=0C




------_=_NextPart_000_01C2C480.304048D4--


--------------060407030809030809070101--



From owner-ietf-openproxy@mail.imc.org  Mon Jan 27 13:13:03 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21595
	for <opes-archive@ietf.org>; Mon, 27 Jan 2003 13:13:03 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0RHgne22020
	for ietf-openproxy-bks; Mon, 27 Jan 2003 09:42:49 -0800 (PST)
Received: from hosting.altserver.com ([209.124.80.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RHglo22015
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 09:42:48 -0800 (PST)
Received: from lns03m-4-204.w.club-internet.fr ([212.194.51.204] helo=mine.utel.net)
	by hosting.altserver.com with esmtp (Exim 3.36 #1)
	id 18dDHU-0003SC-00
	for ietf-openproxy@imc.org; Mon, 27 Jan 2003 09:42:48 -0800
Message-Id: <5.2.0.9.0.20030127174200.02b4adb0@mail.utel.net>
X-Sender: info+utel.net@mail.utel.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 27 Jan 2003 17:43:10 +0100
To: OPES Group <ietf-openproxy@imc.org>
From: jfcm <info@utel.net>
Subject: Re: WG Last Call: draft-ietf-opes-threats-01
In-Reply-To: <3E34CCAC.5080607@mhof.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; x-avg-checked=avg-ok-50FF6B12; boundary="=======4F86908======="
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.altserver.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - utel.net
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--=======4F86908=======
Content-Type: text/plain; x-avg-checked=avg-ok-50FF6B12; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit

At 07:07 27/01/03, Markus Hofmann wrote:
>We are starting WG last call on the threats/risk document (see attached). 
>The last call period closes on Monday, 3 February at 5pm EST. Please post 
>any comments, etc. to the mailing list, and please point out whether you 
>feel your comment is editorial or a show-stopper.

Before venturing comments on this document which seems to be extremely 
clear and well done I would like to get through the archives. My httping of 
them is extremely slow. Would there be a way to ftp them? Deep thanks. 

--=======4F86908=======--



From owner-ietf-openproxy@mail.imc.org  Mon Jan 27 14:08:17 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23075
	for <opes-archive@ietf.org>; Mon, 27 Jan 2003 14:08:16 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0RIiTM24014
	for ietf-openproxy-bks; Mon, 27 Jan 2003 10:44:29 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RIiRo24010
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 10:44:27 -0800 (PST)
Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9])
	by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0RIiThN040616;
	Mon, 27 Jan 2003 13:44:29 -0500 (EST)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0RIiJY87257;
	Mon, 27 Jan 2003 13:44:19 -0500 (EST)
Received: from mhof.com (biena [135.180.160.86])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA20737;
	Mon, 27 Jan 2003 13:44:18 -0500 (EST)
Message-ID: <3E357E20.9040504@mhof.com>
Date: Mon, 27 Jan 2003 13:44:48 -0500
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: jfcm <info@utel.net>
CC: OPES Group <ietf-openproxy@imc.org>
Subject: Re: WG Last Call: draft-ietf-opes-threats-01
References: <5.2.0.9.0.20030127174200.02b4adb0@mail.utel.net>
In-Reply-To: <5.2.0.9.0.20030127174200.02b4adb0@mail.utel.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


jfcm wrote:

> Before venturing comments on this document which seems to be extremely 
> clear and well done I would like to get through the archives. My httping 
> of them is extremely slow. Would there be a way to ftp them? Deep thanks.

Did you try the link given at 
http://www.imc.org/ietf-openproxy/index.html? The linke given ther 
seems to work ok t the moment. I'm not aware on how to access the 
archive fia FTP, though.

-Markus



From owner-ietf-openproxy@mail.imc.org  Mon Jan 27 14:18:28 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23359
	for <opes-archive@ietf.org>; Mon, 27 Jan 2003 14:18:22 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0RImGj24087
	for ietf-openproxy-bks; Mon, 27 Jan 2003 10:48:16 -0800 (PST)
Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RIm9o24080
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 10:48:09 -0800 (PST)
Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10])
	by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0RImALI007352
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 13:48:10 -0500 (EST)
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 h0RIluI86650
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 13:47:56 -0500 (EST)
Received: from mhof.com (biena [135.180.160.86])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA20960
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 13:47:56 -0500 (EST)
Message-ID: <3E357EFB.9080308@mhof.com>
Date: Mon, 27 Jan 2003 13:48:27 -0500
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OPES Group <ietf-openproxy@imc.org>
Subject: [Fwd: publish draft: draft-ietf-opes-authorization-01]
Content-Type: multipart/mixed;
 boundary="------------060609060000080608040703"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.
--------------060609060000080608040703
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

We are starting WG last call on the policy requirements document (see 
attached). The last call period closes on Monday, 3 February at 5pm 
EST. Please post any comments, etc. to the mailing list, and please 
point out whether you feel your comment is editorial or a show-stopper.

Thanks,
   Markus

--------------060609060000080608040703
Content-Type: message/rfc822;
 name="publish draft: draft-ietf-opes-authorization-01"
Content-Disposition: inline;
 filename="publish draft: draft-ietf-opes-authorization-01"

Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA19843
	for <hofmann@dnrc.bell-labs.com>; Mon, 27 Jan 2003 13:23:57 -0500 (EST)
Received: from grubby.research.bell-labs.com (localhost.research.bell-labs.com [127.0.0.1])
	by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0RINpY85640
	for <hofmann@dnrc.bell-labs.com>; Mon, 27 Jan 2003 13:23:51 -0500 (EST)
Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7])
	by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0RINfY85595
	for <hofmann@bell-labs.com>; Mon, 27 Jan 2003 13:23:42 -0500 (EST)
Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157])
	by dusty.research.bell-labs.com (8.12.6/8.12.6) with ESMTP id h0RILFoJ085713
	for <hofmann@bell-labs.com>; Mon, 27 Jan 2003 13:21:15 -0500 (EST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0RINQ311727;
	Mon, 27 Jan 2003 13:23:26 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DPZ2P1MF>; Mon, 27 Jan 2003 13:23:26 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD75404B3C728@zcard0k6.ca.nortel.com>
From: "Barbir, Abbie [CAR:1A00:EXCH]" <abbieb@americasm01.nt.com>
To: "'Internet-Drafts@ietf.org'" <Internet-Drafts@ietf.org>
Cc: "'Markus Hofmann'" <hofmann@bell-labs.com>,
        "'Marshall Rose'"
	 <mrose@dbc.mtview.ca.us>,
        "'OPES Group'" <ietf-openproxy@imc.org>,
        "Barbir, Abbie [CAR:1A00:EXCH]" <abbieb@americasm01.nt.com>
Subject: publish draft: draft-ietf-opes-authorization-01
Date: Mon, 27 Jan 2003 13:23:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C2C631.29F92F2E"
X-SpamBouncer: 1.5 (12/13/02)
X-SBRule: Pattern Match (Disclaimer) (Score: 2300)
X-SBRule: Pattern Match (Other Patterns) (Score: 900)
X-SBClass: Blocked

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_01C2C631.29F92F2E
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2C631.29F92F2E"


------_=_NextPart_001_01C2C631.29F92F2E
Content-Type: text/plain

please publish the atatched OPES WG document as
draft-ietf-opes-authorization-01

thanks
Abbie Barbir
Nortel Networks


------_=_NextPart_001_01C2C631.29F92F2E
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>publish draft: draft-ietf-opes-authorization-01</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>please publish the atatched OPES WG document as draft-ietf-opes-authorization-01</FONT>
</P>

<P><FONT SIZE=2>thanks</FONT>
<BR><FONT SIZE=2>Abbie Barbir</FONT>
<BR><FONT SIZE=2>Nortel Networks</FONT>
</P>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C2C631.29F92F2E--

------_=_NextPart_000_01C2C631.29F92F2E
Content-Type: text/plain;
	name="draft-ietf-opes-authorization-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-authorization-01.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                         A. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: July 28, 2003                                        O. =
Batuner
                                                              =
Consultant
                                                                 A. =
Beck
                                                     Lucent =
Technologies
                                                                 T. =
Chan
                                                                   =
Nokia
                                                                H. =
Orman
                                               Purple Streak =
Development
                                                        January 27, =
2003


       Policy, Authorization and Enforcement Requirements of OPES
                    draft-ietf-opes-authorization-01

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 July 28, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes policy, authorization and enforcement
   requirements for  the selection of the services to be applied to a
   given OPES flow.




Barbir , et al.          Expires July 28, 2003                  [Page =
1]
=0C
Internet-Draft            Policy Requirements               January =
2003


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
   3.3   Requirements for Policy Expression . . . . . . . . . . . . . =
11
   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
         Intellectual Property and Copyright Statements . . . . . . . =
20
















Barbir , et al.          Expires July 28, 2003                  [Page =
2]
=0C
Internet-Draft            Policy Requirements               January =
2003


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 evaluation 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 July 28, 2003                  [Page =
3]
=0C
Internet-Draft            Policy Requirements               January =
2003


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 July 28, 2003                  [Page =
4]
=0C
Internet-Draft            Policy Requirements               January =
2003


         +--------+                         +--------+
         |  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
   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.



Barbir , et al.          Expires July 28, 2003                  [Page =
5]
=0C
Internet-Draft            Policy Requirements               January =
2003


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
   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.




Barbir , et al.          Expires July 28, 2003                  [Page =
6]
=0C
Internet-Draft            Policy Requirements               January =
2003


            +--------+       +-----------+       +---------+
            |        |<------|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 July 28, 2003                  [Page =
7]
=0C
Internet-Draft            Policy Requirements               January =
2003


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 July 28, 2003                  [Page =
8]
=0C
Internet-Draft            Policy Requirements               January =
2003


   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
   services.  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 July 28, 2003                  [Page =
9]
=0C
Internet-Draft            Policy Requirements               January =
2003


   o  Rule providers should be able to specify 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 July 28, 2003                 [Page =
10]
=0C
Internet-Draft            Policy Requirements               January =
2003


   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.

3.3 Requirements for Policy Expression

   OPES processors must enforce policy requirements set by data
   consumers and/or data publishers in accordance with the architecture
   [ref ARCH] and this document.  They cannot do this consistently
   unless there is an unambiguous semantics and representation of the
   data elements mentioned in the policy.  For example, this document
   mentions protection of user "identity" and "profile" information.  =
If
   a user specifies that his identity must not be shared with other =
OPES
   administrative trust domains and later discovers that his family =
name
   has been shared, he might complain.  If he were told that "family
   names are not considered 'identities' by this site", he would
   probably feel that he had cause for complaint.  Or, he might be told
   that when he selected "do not share identity" on a web form offered
   by the OPES service provider, that this only covered his login name,
   and that a different part of the form had to be filled out to =
protect
   family name.  A further breakdown can occur if the configuration
   information provided by such a web form gets translated into
   configuration elements given to an OPES processor, and those
   configuration elements are difficult for a software engineer to
   translate into policy enforcement.  The data elements might have
   confusing names or be split into groupings that are difficult to
   relate to one another.

   The examples illustrate why OPES policy must have definitions of =
data
   elements, their relationships, and how they relate to enforcement.
   These semantics of essential items do not require a separate
   protocol, but they must be agreed upon by all OPES service =
providers,
   and the users of OPES services must be assured that they have the
   ability to know their settings, to change them if the service
   provider policy allows the changes, and to have reasonable assurance
   that they are enforced with reasonable interpretations.

   The requirements for policy data elements in the OPES specification
   do not have to be all-inclusive, but they must cover the minimal set
   of elements that enable the policies that protect the data of end
   users and publishers.










Barbir , et al.          Expires July 28, 2003                 [Page =
11]
=0C
Internet-Draft            Policy Requirements               January =
2003


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 July 28, 2003                 [Page =
12]
=0C
Internet-Draft            Policy Requirements               January =
2003


   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.  It is recommended that the service
   provider 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.

   Because of the sensitivity of user profiles, the PEP Interface
   between the PEP and the PDP MUST use a secure transport protocol.
   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



Barbir , et al.          Expires July 28, 2003                 [Page =
13]
=0C
Internet-Draft            Policy Requirements               January =
2003


   service profiles.  PEP's must be aware of the unique name for each
   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,



Barbir , et al.          Expires July 28, 2003                 [Page =
14]
=0C
Internet-Draft            Policy Requirements               January =
2003


      the publisher must be able to request and receive profile
      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 (to within a very large
      probabilistic certainty) for each requestor/responder pair.  This
      helps to protect the privacy of enduser data from insider attacks
      or configuration errors while it transits the provider's network.




Barbir , et al.          Expires July 28, 2003                 [Page =
15]
=0C
Internet-Draft            Policy Requirements               January =
2003


4.5 Privacy

   The PDP must have a privacy policy regarding OPES data such as user
   profiles for services.  Users 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.  A mechanism
   is needed to specify these preferences and a protocol to distribute
   that (see section 3.3).




























Barbir , et al.          Expires July 28, 2003                 [Page =
16]
=0C
Internet-Draft            Policy Requirements               January =
2003


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-04.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


   Oskar Batuner
   Consultant



   EMail: batuner@attbi.com


   Andre Beck
   Lucent Technologies
   101 Crawfords Corner Road
   Holmdel, NJ  07733
   USA

   EMail: abeck@bell-labs.com




Barbir , et al.          Expires July 28, 2003                 [Page =
17]
=0C
Internet-Draft            Policy Requirements               January =
2003


   Tat Chan
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   USA

   EMail: Tat.Chan@nokia.com


   Hilarie Orman
   Purple Streak Development



   Phone:
   EMail: ho@alum.mit.edu



































Barbir , et al.          Expires July 28, 2003                 [Page =
18]
=0C
Internet-Draft            Policy Requirements               January =
2003


Appendix A. Acknowledgements

   Many thanks to Andreas Terzis, and TBA
















































Barbir , et al.          Expires July 28, 2003                 [Page =
19]
=0C
Internet-Draft            Policy Requirements               January =
2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances =
of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification =
can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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 assignees.

   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



Barbir , et al.          Expires July 28, 2003                 [Page =
20]
=0C
Internet-Draft            Policy Requirements               January =
2003


   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 July 28, 2003                 [Page =
21]
=0C




------_=_NextPart_000_01C2C631.29F92F2E--

--------------060609060000080608040703--



From owner-ietf-openproxy@mail.imc.org  Mon Jan 27 15:01:22 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24758
	for <opes-archive@ietf.org>; Mon, 27 Jan 2003 15:01:14 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0RJW7p25611
	for ietf-openproxy-bks; Mon, 27 Jan 2003 11:32:07 -0800 (PST)
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RJW6o25602
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 11:32:06 -0800 (PST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0RJW1m20560
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 14:32:02 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <DPZ2PGR9>; Mon, 27 Jan 2003 14:32:02 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD75404B3C813@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: "'OPES Group'" <ietf-openproxy@imc.org>
Subject: FW: publish draft: draft-ietf-opes-authorization-01
Date: Mon, 27 Jan 2003 14:31:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C2C63A.BF9E0122"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


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_01C2C63A.BF9E0122
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2C63A.BF9E0122"


------_=_NextPart_001_01C2C63A.BF9E0122
Content-Type: text/plain

list problems,
resending

abbie


> -----Original Message-----
> From: Barbir, Abbie [CAR:1A00:EXCH] 
> Sent: Monday, January 27, 2003 1:23 PM
> To: 'Internet-Drafts@ietf.org'
> Cc: 'Markus Hofmann'; 'Marshall Rose'; 'OPES Group'; Barbir, 
> Abbie [CAR:1A00:EXCH]
> Subject: publish draft: draft-ietf-opes-authorization-01
> 
> 
> please publish the atatched OPES WG document as 
> draft-ietf-opes-authorization-01
> 
> thanks
> Abbie Barbir
> Nortel Networks
> 


------_=_NextPart_001_01C2C63A.BF9E0122
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>FW: publish draft: draft-ietf-opes-authorization-01</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>list problems,</FONT>
<BR><FONT SIZE=2>resending</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Barbir, Abbie [CAR:1A00:EXCH] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, January 27, 2003 1:23 PM</FONT>
<BR><FONT SIZE=2>&gt; To: 'Internet-Drafts@ietf.org'</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'Markus Hofmann'; 'Marshall Rose'; 'OPES Group'; Barbir, </FONT>
<BR><FONT SIZE=2>&gt; Abbie [CAR:1A00:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Subject: publish draft: draft-ietf-opes-authorization-01</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; please publish the atatched OPES WG document as </FONT>
<BR><FONT SIZE=2>&gt; draft-ietf-opes-authorization-01</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; thanks</FONT>
<BR><FONT SIZE=2>&gt; Abbie Barbir</FONT>
<BR><FONT SIZE=2>&gt; Nortel Networks</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C2C63A.BF9E0122--

------_=_NextPart_000_01C2C63A.BF9E0122
Content-Type: text/plain;
	name="draft-ietf-opes-authorization-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-authorization-01.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                         A. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: July 28, 2003                                        O. =
Batuner
                                                              =
Consultant
                                                                 A. =
Beck
                                                     Lucent =
Technologies
                                                                 T. =
Chan
                                                                   =
Nokia
                                                                H. =
Orman
                                               Purple Streak =
Development
                                                        January 27, =
2003


       Policy, Authorization and Enforcement Requirements of OPES
                    draft-ietf-opes-authorization-01

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 July 28, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes policy, authorization and enforcement
   requirements for  the selection of the services to be applied to a
   given OPES flow.




Barbir , et al.          Expires July 28, 2003                  [Page =
1]
=0C
Internet-Draft            Policy Requirements               January =
2003


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
   3.3   Requirements for Policy Expression . . . . . . . . . . . . . =
11
   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
         Intellectual Property and Copyright Statements . . . . . . . =
20
















Barbir , et al.          Expires July 28, 2003                  [Page =
2]
=0C
Internet-Draft            Policy Requirements               January =
2003


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 evaluation 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 July 28, 2003                  [Page =
3]
=0C
Internet-Draft            Policy Requirements               January =
2003


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 July 28, 2003                  [Page =
4]
=0C
Internet-Draft            Policy Requirements               January =
2003


         +--------+                         +--------+
         |  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
   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.



Barbir , et al.          Expires July 28, 2003                  [Page =
5]
=0C
Internet-Draft            Policy Requirements               January =
2003


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
   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.




Barbir , et al.          Expires July 28, 2003                  [Page =
6]
=0C
Internet-Draft            Policy Requirements               January =
2003


            +--------+       +-----------+       +---------+
            |        |<------|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 July 28, 2003                  [Page =
7]
=0C
Internet-Draft            Policy Requirements               January =
2003


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 July 28, 2003                  [Page =
8]
=0C
Internet-Draft            Policy Requirements               January =
2003


   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
   services.  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 July 28, 2003                  [Page =
9]
=0C
Internet-Draft            Policy Requirements               January =
2003


   o  Rule providers should be able to specify 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 July 28, 2003                 [Page =
10]
=0C
Internet-Draft            Policy Requirements               January =
2003


   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.

3.3 Requirements for Policy Expression

   OPES processors must enforce policy requirements set by data
   consumers and/or data publishers in accordance with the architecture
   [ref ARCH] and this document.  They cannot do this consistently
   unless there is an unambiguous semantics and representation of the
   data elements mentioned in the policy.  For example, this document
   mentions protection of user "identity" and "profile" information.  =
If
   a user specifies that his identity must not be shared with other =
OPES
   administrative trust domains and later discovers that his family =
name
   has been shared, he might complain.  If he were told that "family
   names are not considered 'identities' by this site", he would
   probably feel that he had cause for complaint.  Or, he might be told
   that when he selected "do not share identity" on a web form offered
   by the OPES service provider, that this only covered his login name,
   and that a different part of the form had to be filled out to =
protect
   family name.  A further breakdown can occur if the configuration
   information provided by such a web form gets translated into
   configuration elements given to an OPES processor, and those
   configuration elements are difficult for a software engineer to
   translate into policy enforcement.  The data elements might have
   confusing names or be split into groupings that are difficult to
   relate to one another.

   The examples illustrate why OPES policy must have definitions of =
data
   elements, their relationships, and how they relate to enforcement.
   These semantics of essential items do not require a separate
   protocol, but they must be agreed upon by all OPES service =
providers,
   and the users of OPES services must be assured that they have the
   ability to know their settings, to change them if the service
   provider policy allows the changes, and to have reasonable assurance
   that they are enforced with reasonable interpretations.

   The requirements for policy data elements in the OPES specification
   do not have to be all-inclusive, but they must cover the minimal set
   of elements that enable the policies that protect the data of end
   users and publishers.










Barbir , et al.          Expires July 28, 2003                 [Page =
11]
=0C
Internet-Draft            Policy Requirements               January =
2003


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 July 28, 2003                 [Page =
12]
=0C
Internet-Draft            Policy Requirements               January =
2003


   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.  It is recommended that the service
   provider 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.

   Because of the sensitivity of user profiles, the PEP Interface
   between the PEP and the PDP MUST use a secure transport protocol.
   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



Barbir , et al.          Expires July 28, 2003                 [Page =
13]
=0C
Internet-Draft            Policy Requirements               January =
2003


   service profiles.  PEP's must be aware of the unique name for each
   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,



Barbir , et al.          Expires July 28, 2003                 [Page =
14]
=0C
Internet-Draft            Policy Requirements               January =
2003


      the publisher must be able to request and receive profile
      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 (to within a very large
      probabilistic certainty) for each requestor/responder pair.  This
      helps to protect the privacy of enduser data from insider attacks
      or configuration errors while it transits the provider's network.




Barbir , et al.          Expires July 28, 2003                 [Page =
15]
=0C
Internet-Draft            Policy Requirements               January =
2003


4.5 Privacy

   The PDP must have a privacy policy regarding OPES data such as user
   profiles for services.  Users 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.  A mechanism
   is needed to specify these preferences and a protocol to distribute
   that (see section 3.3).




























Barbir , et al.          Expires July 28, 2003                 [Page =
16]
=0C
Internet-Draft            Policy Requirements               January =
2003


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-04.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


   Oskar Batuner
   Consultant



   EMail: batuner@attbi.com


   Andre Beck
   Lucent Technologies
   101 Crawfords Corner Road
   Holmdel, NJ  07733
   USA

   EMail: abeck@bell-labs.com




Barbir , et al.          Expires July 28, 2003                 [Page =
17]
=0C
Internet-Draft            Policy Requirements               January =
2003


   Tat Chan
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   USA

   EMail: Tat.Chan@nokia.com


   Hilarie Orman
   Purple Streak Development



   Phone:
   EMail: ho@alum.mit.edu



































Barbir , et al.          Expires July 28, 2003                 [Page =
18]
=0C
Internet-Draft            Policy Requirements               January =
2003


Appendix A. Acknowledgements

   Many thanks to Andreas Terzis, and TBA
















































Barbir , et al.          Expires July 28, 2003                 [Page =
19]
=0C
Internet-Draft            Policy Requirements               January =
2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances =
of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification =
can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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 assignees.

   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



Barbir , et al.          Expires July 28, 2003                 [Page =
20]
=0C
Internet-Draft            Policy Requirements               January =
2003


   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 July 28, 2003                 [Page =
21]
=0C




------_=_NextPart_000_01C2C63A.BF9E0122--


From owner-ietf-openproxy@mail.imc.org  Tue Jan 28 03:18:59 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19112
	for <opes-archive@ietf.org>; Tue, 28 Jan 2003 03:18:58 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0S7k4H19927
	for ietf-openproxy-bks; Mon, 27 Jan 2003 23:46:04 -0800 (PST)
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.11.6/8.11.3) with SMTP id h0S7k2o19922
	for <ietf-openproxy@imc.org>; Mon, 27 Jan 2003 23:46:03 -0800 (PST)
Received: from hermes.webwasher.com [192.168.1.3] id DR3X4YA8; 28 Jan 2003 09:10:09 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: ICAP header extensions
Date: Tue, 28 Jan 2003 08:42:57 +0100
Message-ID: <72992B39BBD9294BB636A960E89AE02E8FD0E8@hermes.webwasher.com>
Thread-Topic: ICAP header extensions
Thread-Index: AcLGoUcXbwcRRXEcSYONLuEyPLFVzg==
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "ICAP Forum Discussion Group (E-mail)" <ICAP-Discussions@yahoogroups.com>,
        "OPES WG (E-mail)" <ietf-openproxy@imc.org>,
        "squid-icapClient" <icap-server-squidclient@lists.sourceforge.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0S7k3o19923
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,

the ICAP protocol defines in section 4.3:
"User-defined header extensions are allowed. [... They] MUST follow the "X-"
naming convention [...]"

There are already a bunch of user-defined headers in use, unfortunately only two of them have been published officialy (X-Client-IP and X-Subscriber-ID in draft-beck-opes-icap-subid-00.txt), many more have been exchanged between organisations.

With the growing number of ICAP client and server implementations we see more and more user-defined headers being introduced.
Unfortunately there are already some with the identical meaning but different names.

To ensure further interoperability even beyond the standard feature set, I propose that we publish the X-headers that are in use.

Please find below a first list of headers that I am going to describe in the next days. Maybe we can simply extend the draft-beck-opes-icap-subid-00.txt document.

There is also a definition for an OTPIONS response's opt-body format that will be included in the description.

Knowing that there are more X-headers out there, I invite everybody to send his/her headers with a short discription so that we can add them to the document.
As soon as I hear about other headers and get the confirmation that their description can be published, I will add them as an ongoing process.

Best Regards
Martin Stecher


Current list - has to be extended, specifications will be added:

REQMOD/RESPMOD request headers
	X-Client-IP
	X-Server-IP
	X-Subscriber-ID
	X-Authenticated-User		
	X-Authenticated-Groups

REQMOD/RESPMOD response headers
	X-Attribute
	X-Attribute-Cacheability
	X-Attribute-Prefix
	X-ICAP-Profile

OPTIONS response headers
	X-Include

OPTIONS response opt-body
	Opt-Body-Type: Attribute-List


From owner-ietf-openproxy@mail.imc.org  Tue Jan 28 07:13:47 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23141
	for <opes-archive@ietf.org>; Tue, 28 Jan 2003 07:13:45 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0SBnGb14836
	for ietf-openproxy-bks; Tue, 28 Jan 2003 03:49:16 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SBnFo14830
	for <ietf-openproxy@imc.org>; Tue, 28 Jan 2003 03:49:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21914;
	Tue, 28 Jan 2003 06:45:44 -0500 (EST)
Message-Id: <200301281145.GAA21914@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-01.txt
Date: Tue, 28 Jan 2003 06:45:43 -0500
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--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		: Policy, Authorization and Enforcement Requirements of 
                          OPES
	Author(s)	: A. Barbir et al.
	Filename	: draft-ietf-opes-authorization-01.txt
	Pages		: 21
	Date		: 2003-1-27
	
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-01.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-01.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-01.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:	<2003-1-27141252.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-authorization-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-authorization-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-27141252.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Tue Jan 28 07:18:18 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23251
	for <opes-archive@ietf.org>; Tue, 28 Jan 2003 07:18:17 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0SBn0514802
	for ietf-openproxy-bks; Tue, 28 Jan 2003 03:49:00 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SBmxo14798
	for <ietf-openproxy@imc.org>; Tue, 28 Jan 2003 03:48:59 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21862;
	Tue, 28 Jan 2003 06:45:27 -0500 (EST)
Message-Id: <200301281145.GAA21862@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-threats-01.txt
Date: Tue, 28 Jan 2003 06:45:27 -0500
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--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		: Security Threats and Risks for Open
	Author(s)	: A. Barbir et al.
	Filename	: draft-ietf-opes-threats-01.txt
	Pages		: 20
	Date		: 2003-1-27
	
The document investigates the security threats associated with OPES.
The effects of security threats on the underlying architecture are
discussed.  The main goal of this document is threat discovery and
analysis.  The document does not specify or recommend any solutions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-threats-01.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-threats-01.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-threats-01.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:	<2003-1-27081604.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-threats-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-threats-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-27081604.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Tue Jan 28 13:01:41 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02471
	for <opes-archive@ietf.org>; Tue, 28 Jan 2003 13:01:40 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0SHV7304367
	for ietf-openproxy-bks; Tue, 28 Jan 2003 09:31:07 -0800 (PST)
Received: from measurement-factory.com (measurement-factory.com [206.168.0.5])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SHV5o04363
	for <ietf-openproxy@imc.org>; Tue, 28 Jan 2003 09:31:05 -0800 (PST)
Received: from measurement-factory.com (localhost [127.0.0.1])
	by measurement-factory.com (8.12.6/8.12.5) with ESMTP id h0SHV6eM071379;
	Tue, 28 Jan 2003 10:31:06 -0700 (MST)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.6/8.12.5/Submit) id h0SHV6L9071378;
	Tue, 28 Jan 2003 10:31:06 -0700 (MST)
	(envelope-from rousskov)
Date: Tue, 28 Jan 2003 10:31:06 -0700 (MST)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: Martin Stecher <martin.stecher@webwasher.com>
cc: "ICAP Forum Discussion Group (E-mail)" <ICAP-Discussions@yahoogroups.com>,
        "OPES WG (E-mail)" <ietf-openproxy@imc.org>,
        squid-icapClient <icap-server-squidclient@lists.sourceforge.net>
Subject: Re: ICAP header extensions
In-Reply-To: <72992B39BBD9294BB636A960E89AE02E8FD0E8@hermes.webwasher.com>
Message-ID: <Pine.BSF.4.44.0301281022020.68873-100000@measurement-factory.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


On Tue, 28 Jan 2003, Martin Stecher wrote:

> the ICAP protocol defines in section 4.3: "User-defined header
> extensions are allowed. [... They] MUST follow the "X-" naming
> convention [...]"
>
> There are already a bunch of user-defined headers in use,
> unfortunately only two of them have been published officialy
> (X-Client-IP and X-Subscriber-ID in
> draft-beck-opes-icap-subid-00.txt), many more have been exchanged
> between organisations.
>
> With the growing number of ICAP client and server implementations we
> see more and more user-defined headers being introduced.
> Unfortunately there are already some with the identical meaning but
> different names.
>
> To ensure further interoperability even beyond the standard feature
> set, I propose that we publish the X-headers that are in use.

Would it be a good idea to follow [1] and [2] with this?
Looks like those IDs attempt to solve the same problem.
 [1] http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-06.txt
 [2] http://www.ietf.org/internet-drafts/draft-nottingham-hdrreg-http-00.txt

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance



From owner-ietf-openproxy@mail.imc.org  Wed Jan 29 09:58:34 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20760
	for <opes-archive@ietf.org>; Wed, 29 Jan 2003 09:58:33 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0TESAn11010
	for ietf-openproxy-bks; Wed, 29 Jan 2003 06:28:10 -0800 (PST)
Received: from hosting.altserver.com ([209.124.80.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TES9o11006
	for <ietf-openproxy@imc.org>; Wed, 29 Jan 2003 06:28:09 -0800 (PST)
Received: from f01v-19-172.d1.club-internet.fr ([213.44.250.172] helo=mine.utel.net)
	by hosting.altserver.com with esmtp (Exim 3.36 #1)
	id 18dtC8-0003B7-00
	for ietf-openproxy@imc.org; Wed, 29 Jan 2003 06:28:04 -0800
Message-Id: <5.2.0.9.0.20030129152937.024df0a0@mail.utel.net>
X-Sender: info+utel.net@mail.utel.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 29 Jan 2003 15:33:38 +0100
To: <ietf-openproxy@imc.org>
From: jfcm <info@utel.net>
Subject: to share OPES operations experience
In-Reply-To: <87609AFB433BD5118D5E0002A52CD75404B3C813@zcard0k6.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; x-avg-checked=avg-ok-375A28CA; boundary="=======59BB5F4E======="
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.altserver.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - utel.net
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--=======59BB5F4E=======
Content-Type: text/plain; x-avg-checked=avg-ok-375A28CA; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit

as I develop a real operations OPES I would be interested in sharing 
experience. Is there a place where I could get a list of operational solutions.
thank you.
jfc


--=======59BB5F4E=======--



From owner-ietf-openproxy@mail.imc.org  Wed Jan 29 10:46:43 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22261
	for <opes-archive@ietf.org>; Wed, 29 Jan 2003 10:46:42 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0TFP9616139
	for ietf-openproxy-bks; Wed, 29 Jan 2003 07:25:09 -0800 (PST)
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TFP8o16133
	for <ietf-openproxy@imc.org>; Wed, 29 Jan 2003 07:25:08 -0800 (PST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0TFOxk16315;
	Wed, 29 Jan 2003 10:24:59 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <D6JCVT02>; Wed, 29 Jan 2003 10:24:59 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD75404B9B8A9@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: jfcm <info@utel.net>, ietf-openproxy@imc.org
Subject: RE: to share OPES operations experience
Date: Wed, 29 Jan 2003 10:24:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2C7AA.94B57384"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


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_001_01C2C7AA.94B57384
Content-Type: text/plain

Hi,

In my opinion, u can start on this list.

if it gets too wild, we can move it to somewhaere else.

abbie


> -----Original Message-----
> From: jfcm [mailto:info@utel.net] 
> Sent: Wednesday, January 29, 2003 9:34 AM
> To: ietf-openproxy@imc.org
> Subject: to share OPES operations experience
> 
> 
> as I develop a real operations OPES I would be interested in sharing 
> experience. Is there a place where I could get a list of 
> operational solutions. thank you. jfc
> 
> 

------_=_NextPart_001_01C2C7AA.94B57384
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: to share OPES operations experience</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi,</FONT>
</P>

<P><FONT SIZE=2>In my opinion, u can start on this list.</FONT>
</P>

<P><FONT SIZE=2>if it gets too wild, we can move it to somewhaere else.</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: jfcm [<A HREF="mailto:info@utel.net">mailto:info@utel.net</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, January 29, 2003 9:34 AM</FONT>
<BR><FONT SIZE=2>&gt; To: ietf-openproxy@imc.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: to share OPES operations experience</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; as I develop a real operations OPES I would be interested in sharing </FONT>
<BR><FONT SIZE=2>&gt; experience. Is there a place where I could get a list of </FONT>
<BR><FONT SIZE=2>&gt; operational solutions. thank you. jfc</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2C7AA.94B57384--


From owner-ietf-openproxy@mail.imc.org  Wed Jan 29 11:16:49 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22812
	for <opes-archive@ietf.org>; Wed, 29 Jan 2003 11:16:43 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0TFk8b17242
	for ietf-openproxy-bks; Wed, 29 Jan 2003 07:46:08 -0800 (PST)
Received: from mercury.cs.wayne.edu (mercury.cs.wayne.edu [141.217.16.41])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TFk6o17238
	for <ietf-openproxy@imc.org>; Wed, 29 Jan 2003 07:46:06 -0800 (PST)
Received: from cs.wayne.edu (horus.cs.wayne.edu [141.217.16.91])
	by mercury.cs.wayne.edu (Postfix) with ESMTP
	id 5710C2EE4C; Wed, 29 Jan 2003 10:38:51 -0500 (EST)
Message-ID: <3E37F73E.4060209@cs.wayne.edu>
Date: Wed, 29 Jan 2003 10:46:06 -0500
From: Weisong Shi <weisong@cs.wayne.edu>
Reply-To: weisong@cs.wayne.edu
Organization: Wayne State University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Abbie Barbir <abbieb@nortelnetworks.com>
Cc: "'OPES Group'" <ietf-openproxy@imc.org>
Subject: Re: FW: publish draft: draft-ietf-opes-authorization-01
References: <87609AFB433BD5118D5E0002A52CD75404B3C813@zcard0k6.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Abbie,
	I have one question about the Section 3.1.2. Requirements for Using State 
Inforamtion.

	I don't think the notion of group and membership is a good idea here. 
Sometime, it is incorrect.  For example, let assume user Alice wants 
service 1 and service 2, and in the order 1,2. user Bob wants service 2 
and service 1 too, but in the order 2,1.  In this case, without calling 
the service for each request send by either Alice or Bob, we can not 
guarantee the correcness of service execution.

	The problem with group is you assuming there is a fix order among all of 
the services, which is not always correct.


Thanks.

-Weisong


Abbie Barbir wrote:
> list problems,
> resending
> 
> abbie
> 
> 
>  > -----Original Message-----
>  > From: Barbir, Abbie [CAR:1A00:EXCH]
>  > Sent: Monday, January 27, 2003 1:23 PM
>  > To: 'Internet-Drafts@ietf.org'
>  > Cc: 'Markus Hofmann'; 'Marshall Rose'; 'OPES Group'; Barbir,
>  > Abbie [CAR:1A00:EXCH]
>  > Subject: publish draft: draft-ietf-opes-authorization-01
>  >
>  >
>  > please publish the atatched OPES WG document as
>  > draft-ietf-opes-authorization-01
>  >
>  > thanks
>  > Abbie Barbir
>  > Nortel Networks
>  >
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Network Working Group                                         A. Barbir
> Internet-Draft                                           Nortel Networks
> Expires: July 28, 2003                                        O. Batuner
>                                                               Consultant
>                                                                  A. Beck
>                                                      Lucent Technologies
>                                                                  T. Chan
>                                                                    Nokia
>                                                                 H. Orman
>                                                Purple Streak Development
>                                                         January 27, 2003
> 
> 
>        Policy, Authorization and Enforcement Requirements of OPES
>                     draft-ietf-opes-authorization-01
> 
> 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 July 28, 2003.
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> 
> Abstract
> 
>    This document describes policy, authorization and enforcement
>    requirements for  the selection of the services to be applied to a
>    given OPES flow.
> 
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                  [Page 1]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
> 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
>    3.3   Requirements for Policy Expression . . . . . . . . . . . . . 11
>    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
>          Intellectual Property and Copyright Statements . . . . . . . 20
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                  [Page 2]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
> 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 evaluation 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 July 28, 2003                  [Page 3]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
> 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 July 28, 2003                  [Page 4]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
>          +--------+                         +--------+
>          |  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
>    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.
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                  [Page 5]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
> 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
>    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.
> 
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                  [Page 6]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
>             +--------+       +-----------+       +---------+
>             |        |<------|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 July 28, 2003                  [Page 7]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
> 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 July 28, 2003                  [Page 8]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
>    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
>    services.  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 July 28, 2003                  [Page 9]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
>    o  Rule providers should be able to specify 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 July 28, 2003                 [Page 10]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
>    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.
> 
> 3.3 Requirements for Policy Expression
> 
>    OPES processors must enforce policy requirements set by data
>    consumers and/or data publishers in accordance with the architecture
>    [ref ARCH] and this document.  They cannot do this consistently
>    unless there is an unambiguous semantics and representation of the
>    data elements mentioned in the policy.  For example, this document
>    mentions protection of user "identity" and "profile" information.  If
>    a user specifies that his identity must not be shared with other OPES
>    administrative trust domains and later discovers that his family name
>    has been shared, he might complain.  If he were told that "family
>    names are not considered 'identities' by this site", he would
>    probably feel that he had cause for complaint.  Or, he might be told
>    that when he selected "do not share identity" on a web form offered
>    by the OPES service provider, that this only covered his login name,
>    and that a different part of the form had to be filled out to protect
>    family name.  A further breakdown can occur if the configuration
>    information provided by such a web form gets translated into
>    configuration elements given to an OPES processor, and those
>    configuration elements are difficult for a software engineer to
>    translate into policy enforcement.  The data elements might have
>    confusing names or be split into groupings that are difficult to
>    relate to one another.
> 
>    The examples illustrate why OPES policy must have definitions of data
>    elements, their relationships, and how they relate to enforcement.
>    These semantics of essential items do not require a separate
>    protocol, but they must be agreed upon by all OPES service providers,
>    and the users of OPES services must be assured that they have the
>    ability to know their settings, to change them if the service
>    provider policy allows the changes, and to have reasonable assurance
>    that they are enforced with reasonable interpretations.
> 
>    The requirements for policy data elements in the OPES specification
>    do not have to be all-inclusive, but they must cover the minimal set
>    of elements that enable the policies that protect the data of end
>    users and publishers.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                 [Page 11]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
> 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 July 28, 2003                 [Page 12]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
>    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.  It is recommended that the service
>    provider 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.
> 
>    Because of the sensitivity of user profiles, the PEP Interface
>    between the PEP and the PDP MUST use a secure transport protocol.
>    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
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                 [Page 13]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
>    service profiles.  PEP's must be aware of the unique name for each
>    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,
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                 [Page 14]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
>       the publisher must be able to request and receive profile
>       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 (to within a very large
>       probabilistic certainty) for each requestor/responder pair.  This
>       helps to protect the privacy of enduser data from insider attacks
>       or configuration errors while it transits the provider's network.
> 
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                 [Page 15]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
> 4.5 Privacy
> 
>    The PDP must have a privacy policy regarding OPES data such as user
>    profiles for services.  Users 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.  A mechanism
>    is needed to specify these preferences and a protocol to distribute
>    that (see section 3.3).
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                 [Page 16]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
> 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-04.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
> 
> 
>    Oskar Batuner
>    Consultant
> 
> 
> 
>    EMail: batuner@attbi.com
> 
> 
>    Andre Beck
>    Lucent Technologies
>    101 Crawfords Corner Road
>    Holmdel, NJ  07733
>    USA
> 
>    EMail: abeck@bell-labs.com
> 
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                 [Page 17]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
>    Tat Chan
>    Nokia
>    5 Wayside Road
>    Burlington, MA  01803
>    USA
> 
>    EMail: Tat.Chan@nokia.com
> 
> 
>    Hilarie Orman
>    Purple Streak Development
> 
> 
> 
>    Phone:
>    EMail: ho@alum.mit.edu
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                 [Page 18]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
> Appendix A. Acknowledgements
> 
>    Many thanks to Andreas Terzis, and TBA
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                 [Page 19]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
> Intellectual Property Statement
> 
>    The IETF takes no position regarding the validity or scope of any
>    intellectual property or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; neither does it represent that it
>    has made any effort to identify any such rights.  Information on the
>    IETF's procedures with respect to rights in standards-track and
>    standards-related documentation can be found in BCP-11.  Copies of
>    claims of rights made available for publication and any assurances of
>    licenses to be made available, or the result of an attempt made to
>    obtain a general license or permission for the use of such
>    proprietary rights by implementors or users of this specification can
>    be obtained from the IETF Secretariat.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights which may cover technology that may be required to practice
>    this standard.  Please address the information to the IETF Executive
>    Director.
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2003).  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 assignees.
> 
>    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
> 
> 
> 
> Barbir , et al.          Expires July 28, 2003                 [Page 20]
> 
> Internet-Draft            Policy Requirements               January 2003
> 
> 
>    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 July 28, 2003                 [Page 21]
> 
> 
> 
> 




From owner-ietf-openproxy@mail.imc.org  Thu Jan 30 10:38:18 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01571
	for <opes-archive@ietf.org>; Thu, 30 Jan 2003 10:38:16 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0UFA1M08791
	for ietf-openproxy-bks; Thu, 30 Jan 2003 07:10:01 -0800 (PST)
Received: from hosting.altserver.com ([209.124.80.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UF9xo08780
	for <ietf-openproxy@imc.org>; Thu, 30 Jan 2003 07:09:59 -0800 (PST)
Received: from f07a-11-94.d1.club-internet.fr ([212.194.154.94] helo=mine.utel.net)
	by hosting.altserver.com with esmtp (Exim 3.36 #1)
	id 18eGKA-0002GO-00
	for ietf-openproxy@imc.org; Thu, 30 Jan 2003 07:09:55 -0800
Message-Id: <5.2.0.9.0.20030130151334.00aad6c0@mail.utel.net>
X-Sender: info+utel.net@mail.utel.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 30 Jan 2003 16:15:38 +0100
To: ietf-openproxy@imc.org
From: jfcm <info@utel.net>
Subject: RE: to share OPES operations experience
In-Reply-To: <87609AFB433BD5118D5E0002A52CD75404B9B8A9@zcard0k6.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; x-avg-checked=avg-ok-2B5CF97; boundary="=======6AA52B1C======="
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.altserver.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - utel.net
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--=======6AA52B1C=======
Content-Type: multipart/alternative; x-avg-checked=avg-ok-2B5CF97; boundary="=====================_3933767==.ALT"


--=====================_3933767==.ALT
Content-Type: text/plain; x-avg-checked=avg-ok-2B5CF97; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit

On 16:24 29/01/03, Abbie Barbir said:
>Hi,
>In my opinion, u can start on this list.
>if it gets too wild, we can move it to somewhaere else.

Thank you. May be not too wild, but I may ask things already discussed (I 
had not time to read the whole archives I cannot FTP) and I may be 
confusing because I includes OPES into a broader architecture, I sold as 
"Network Extended Services", a long ago. My target is not to discuss that 
aspect before I have fully understood what has already been done and 
discussed in here.

Since this is public list I will also try to keep general and I thank you 
to respect whatever could be IP worth.

Basically I am trying to develop a test simple yet operational system and 
to gain technical, commercial, legal, operational experience from it. I 
will name the project "smart pipe". The idea is to get data flows and to 
forward them to the final host (at least for us). To see how it works and 
then to build from it. This is very basic: i suppose some already done it?.

First point is that we may get data in through several protocols and data 
out though several other protocols. Has someone developed something already 
in that area or a doctrine?

Next is what type of system should we develop? Web services are supposed to 
be http related. Has someone developed an experience? or comments?

I understand OPC is to relate with other OPES through an "overlay" (I am 
not sure the meaning is good). I feel there is also a need for another 
relation (I would name "underlay" what may carry a good image) interworking 
dispatchers.

So the design I think about is as follow ;

(fixed character set)

              +------------------------+
underlay <===| open services internal |===>
              [ remote internet switch |
              +------------------------+
           ---|    HTTP I/O      |  D  |
              +------------------+  i  +
           ---|    FTP I/O       |  s  |
              +------------------+  p  +
           ---|    MAIL I/O      |  a  |
              +------------------+  t  +
overlay   ---|    OPC           |  c  |
              +------------------+  h  +
              |    Statistics    |  e  |
              +------------------+  r  +
              |    local OPES    |     |
              +------------------+-----+

I note that the OPC protocol would be embedded in the underlay network 
protocol when the remote OPES is under our own same architecture. Also, if 
we have this architecture managing the whole telemate (tele-automate) the 
underlay network system would form some kind of network operating system 
not necessarily under IP.

I would be interested in every comment. Thank you.
jfc



--=====================_3933767==.ALT
Content-Type: text/html; x-avg-checked=avg-ok-2B5CF97; charset=us-ascii
Content-Transfer-Encoding: 8bit

<html>
<body>
On 16:24 29/01/03, Abbie Barbir said:<br>
<blockquote type=cite class=cite cite><font size=2>Hi,</font> <br>
<font size=2>In my opinion, u can start on this list.</font> <br>
<font size=2>if it gets too wild, we can move it to somewhaere
else.</font> </blockquote><br>
Thank you. May be not too wild, but I may ask things already discussed (I
had not time to read the whole archives I cannot FTP) and I may be
confusing because I includes OPES into a broader architecture, I sold as
&quot;Network Extended Services&quot;, a long ago. My target is not to
discuss that aspect before I have fully understood what has already been
done and discussed in here.<br><br>
Since this is public list I will also try to keep general and I thank you
to respect whatever could be IP worth.<br><br>
Basically I am trying to develop a test simple yet operational system and
to gain technical, commercial, legal, operational experience from it. I
will name the project &quot;smart pipe&quot;. The idea is to get data
flows and to forward them to the final host (at least for us). To see how
it works and then to build from it. This is very basic: i suppose some
already done it?.<br><br>
First point is that we may get data in through several protocols and data
out though several other protocols. Has someone developed something
already in that area or a doctrine?<br><br>
Next is what type of system should we develop? Web services are supposed
to be http related. Has someone developed an experience? or comments?
<br><br>
I understand OPC is to relate with other OPES through an
&quot;overlay&quot; (I am not sure the meaning is good). I feel there is
also a need for another relation (I would name &quot;underlay&quot; what
may carry a good image) interworking dispatchers.<br><br>
So the design I think about is as follow ;<br><br>
<font face="Courier New, Courier">(fixed character set)<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------------+<br>
underlay &lt;===| open services internal |===&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[ remote internet switch |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
---|&nbsp;&nbsp;&nbsp; HTTP I/O&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
D&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp; i&nbsp; +<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
---|&nbsp;&nbsp;&nbsp; FTP I/O&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; s&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp; p&nbsp; +<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
---|&nbsp;&nbsp;&nbsp; MAIL I/O&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
a&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp; t&nbsp; +<br>
overlay&nbsp;&nbsp; ---|&nbsp;&nbsp;&nbsp;
OPC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
c&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp; h&nbsp; +<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; Statistics&nbsp;&nbsp;&nbsp; |&nbsp; e&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp; r&nbsp; +<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; local OPES&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+-----+<br><br>
</font>I note that the OPC protocol would be embedded in the underlay
network protocol when the remote OPES is under our own same architecture.
Also, if we have this architecture managing the whole telemate
(tele-automate) the underlay network system would form some kind of
network operating system not necessarily under IP.<br><br>
I would be interested in every comment. Thank you.<br>
jfc<br><br>
</body>
</html>


--=====================_3933767==.ALT--

--=======6AA52B1C=======--



From owner-ietf-openproxy@mail.imc.org  Thu Jan 30 14:03:04 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07107
	for <opes-archive@ietf.org>; Thu, 30 Jan 2003 14:03:03 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0UIWke21648
	for ietf-openproxy-bks; Thu, 30 Jan 2003 10:32:46 -0800 (PST)
Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UIWjo21644
	for <ietf-openproxy@imc.org>; Thu, 30 Jan 2003 10:32:45 -0800 (PST)
Received: from localhost.localdomain (pl109438.fiber.net [216.83.152.26] (may be forged))
	by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h0UIxLO4031126;
	Thu, 30 Jan 2003 11:59:22 -0700
Received: (from ho@localhost)
	by localhost.localdomain (8.11.6/8.11.6) id h0UIXs922403;
	Thu, 30 Jan 2003 11:33:54 -0700
Date: Thu, 30 Jan 2003 11:33:54 -0700
Message-Id: <200301301833.h0UIXs922403@localhost.localdomain>
From: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
To: info@utel.net
Cc: ietf-openproxy@imc.org
In-reply-to: Yourmessage <5.2.0.9.0.20030130151334.00aad6c0@mail.utel.net>
Subject: RE: to share OPES operations experience
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


First, this is a public mailing list, see the ietf.org website about
policies governing working group mailing lists.  Don't post anything
here that you want "protected" or "respected" by competitors.

OPES works with HTTP messages.  We may address RTP in the future.

Your "overlay" looks very much like an ordinary operating system's
API to network protocols, so I'm unsure what its point is.  Your comment
about "not necessarily under IP" is confusing because it's more common
to speak of these protocols as running "over" IP (or do you you mean
"intellectual property"? :-)  ).  Trying to continue guessing, I'll ask
if you mean that the "dispatcher" is remotely controlled, using something
like OPES rules?  Are you suggesting that this function be implemented
as a "web service"?

A few years ago I saw a system called "Delegate" that provided a
fairly general API so that people could write filters that could take
in data from one (protocol, port) pair and forward that data (possibly
altered) to another pair or deliver it locally.  It might be closer to
what you are describing than OPES is.  OPES is more specific, and it
concentrates on some details of HTTP (and possibly RTP) semantics, the
callout protocol, and issues about configuration and tracing.

It might help the discussion if you could give some examples of what
you'd like to see systems like this do.

Hilarie







From owner-ietf-openproxy@mail.imc.org  Thu Jan 30 21:03:17 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16226
	for <opes-archive@ietf.org>; Thu, 30 Jan 2003 21:03:15 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0V1Xhm04293
	for ietf-openproxy-bks; Thu, 30 Jan 2003 17:33:43 -0800 (PST)
Received: from hosting.altserver.com ([209.124.80.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0V1Xgo04288
	for <ietf-openproxy@imc.org>; Thu, 30 Jan 2003 17:33:42 -0800 (PST)
Received: from f13v-5-128.d1.club-internet.fr ([212.195.176.128] helo=mine.utel.net)
	by hosting.altserver.com with esmtp (Exim 3.36 #1)
	id 18eQ3p-0004wn-00
	for ietf-openproxy@imc.org; Thu, 30 Jan 2003 17:33:42 -0800
Message-Id: <5.2.0.9.0.20030131020115.02ea7ca0@pop.online.fr>
X-Sender: info+utel.net@mail.utel.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 31 Jan 2003 02:04:25 +0100
To: ietf-openproxy@imc.org
From: jfcm <info@utel.net>
Subject: to share OPES operations experience
Mime-Version: 1.0
Content-Type: multipart/mixed; x-avg-checked=avg-ok-4AED6A14; boundary="=======85648EB======="
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.altserver.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - utel.net
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--=======85648EB=======
Content-Type: text/plain; x-avg-checked=avg-ok-4AED6A14; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit

Dear Hilarie,
thank you for your comments. I respond on the list, but I am not sure it is 
appropriate as it seems more an interaction over a project than a debate 
over a document preparation.

On 19:33 30/01/03, The Purple Streak, Hilarie Orman said:
>First, this is a public mailing list, see the ietf.org website about
>policies governing working group mailing lists.  Don't post anything
>here that you want "protected" or "respected" by competitors.

I understand this. This is why I asked about other places. I only follow on 
Abbie's suggestion. When I say "respected", I mean "please do not flame me 
because I do not tell you everything you may ask". I will try however to 
detail what I can. If this is felt appropriate by the members of the list.

>OPES works with HTTP messages.  We may address RTP in the future.

I said that I have a wider vision, documented for a long, of the "network 
extended services", where OPES fit in. As explained I do not want to 
dispute semantics, I just work on some architecture which may help as an 
example and benefit from your inputs. I am not limited by the protocol.

>Your "overlay" looks very much like an ordinary operating system's

I suppose what I name "underlay"? "Overlay" is the word used for the 
callout system as far as I understand?

>API to network protocols, so I'm unsure what its point is.  Your comment
>about "not necessarily under IP" is confusing because it's more common
>to speak of these protocols as running "over" IP (or do you you mean
>"intellectual property"? :-)  ).

Accepted. Frenglish, sorry. But it also wants to render "not under the 
limitations imposed by IP". I understand that the same rationale applies to 
the callout protocol considerations?

Now, you may see on my draft that entries into the dispatcher may come from 
an external I/O, from OPES one, from the callout interface relating with a 
remote OPES. And the same for outbound traffic, from the dispatcher into 
any of those interface and through the callout protocol into other systems.

I feel this is conform to the OPES scheme, however not draft the same way. 
This shows the way the dispatcher is used. There may be non documented 
presentation functions to convert from a protocol to the dispatcher and 
from the dispatcher level to another protocol level. Right now, I keep them 
into the I/O blocks (they might be or not by-passed if the "in" and the 
"out" protocol were the same?). So they are not just APIs.

>Trying to continue guessing, I'll ask
>if you mean that the "dispatcher" is remotely controlled, using something
>like OPES rules?

No. This why I use the word "underlay". The dispatchers may relate together 
to stay mutually informed, for example about some thresholds they have 
reached which might affect rules.

They might also exchange meta-data over the callout protocol to speed up 
some exchanges in a more specific manner, for example?

>Are you suggesting that this function be implemented as a "web service"?

It depends on what you name a web service. I suppose it could use a service 
- like a shared repository. But I doubt it could use a controller: this 
could conflict with the dispatcher rules. Obviously the rules could be 
remotely controlled. But it seems too rigid a concept. This is not 
automatism, but telematism. There are delays, risks of failures etc. Each 
system should be standalone. Related, not tied.

>A few years ago I saw a system called "Delegate" that provided a
>fairly general API so that people could write filters that could take
>in data from one (protocol, port) pair and forward that data (possibly
>altered) to another pair or deliver it locally.  It might be closer to
>what you are describing than OPES is.

Really interesting. Do you recall where I could find details.

>OPES is more specific, and it concentrates on some details of HTTP (and 
>possibly RTP) semantics, the callout protocol, and issues about 
>configuration and tracing.

I am ready to accept that. This is why I asked and said that what we have 
in mind might not fit. Yet, are not protocol verification and conversion 
services as any other one? I miss the reason why the callout protocol would 
be HTTP/RTP specific?

>It might help the discussion if you could give some examples of what you'd 
>like to see systems like this do.

As I said, right now we are investigating what we are involved in. To 
understand the architecture, find the most appropriate design, development 
tools, network system to use to switch information between related systems, 
where to place them. It may take time. OPES examples have been given in a 
specific IETF-draft. We are OK with them as test examples.

Let say for discussion sake that we have three OPES, one, two, three. OPES 
one is on the main machine, OPES two on another machine with the same 
technology, connected through the underlay network and using callout 
protocol. OPES three is on a third party machine connected through the 
callout protocol alone.

 From then I try to understand how it works. I feel that considerations 
quoted about the callout protocol might have to be addressed between the 
I/O block and the dispatcher? Also I am not certain where the loops in the 
dispatcher are checked and blocked in the OPES scheme? But may be I just 
not fully understood the things.

jfc




--=======85648EB=======--



From owner-ietf-openproxy@mail.imc.org  Thu Jan 30 21:50:44 2003
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16783
	for <opes-archive@ietf.org>; Thu, 30 Jan 2003 21:50:40 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id h0V2KcH06662
	for ietf-openproxy-bks; Thu, 30 Jan 2003 18:20:38 -0800 (PST)
Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id h0V2Kbo06657
	for <ietf-openproxy@imc.org>; Thu, 30 Jan 2003 18:20:37 -0800 (PST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0V2KU704442;
	Thu, 30 Jan 2003 21:20:31 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <D6JCWT4S>; Thu, 30 Jan 2003 21:20:31 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD75404BE91E9@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: jfcm <info@utel.net>, ietf-openproxy@imc.org
Subject: RE: to share OPES operations experience
Date: Thu, 30 Jan 2003 21:20:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2C8CF.52E855FE"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


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_001_01C2C8CF.52E855FE
Content-Type: text/plain

hi all,

discussion is ok (in my opinion) as long as it is related to technical
merits.

thanks
abbie


> -----Original Message-----
> From: jfcm [mailto:info@utel.net] 
> Sent: Thursday, January 30, 2003 8:04 PM
> To: ietf-openproxy@imc.org
> Subject: to share OPES operations experience
> 
> 
> Dear Hilarie,
> thank you for your comments. I respond on the list, but I am 
> not sure it is 
> appropriate as it seems more an interaction over a project 
> than a debate 
> over a document preparation.
> 
> On 19:33 30/01/03, The Purple Streak, Hilarie Orman said:
> >First, this is a public mailing list, see the ietf.org website about 
> >policies governing working group mailing lists.  Don't post anything 
> >here that you want "protected" or "respected" by competitors.
> 
> I understand this. This is why I asked about other places. I 
> only follow on 
> Abbie's suggestion. When I say "respected", I mean "please do 
> not flame me 
> because I do not tell you everything you may ask". I will try 
> however to 
> detail what I can. If this is felt appropriate by the members 
> of the list.
> 
> >OPES works with HTTP messages.  We may address RTP in the future.
> 
> I said that I have a wider vision, documented for a long, of 
> the "network 
> extended services", where OPES fit in. As explained I do not want to 
> dispute semantics, I just work on some architecture which may 
> help as an 
> example and benefit from your inputs. I am not limited by the 
> protocol.
> 
> >Your "overlay" looks very much like an ordinary operating system's
> 
> I suppose what I name "underlay"? "Overlay" is the word used for the 
> callout system as far as I understand?
> 
> >API to network protocols, so I'm unsure what its point is.  Your 
> >comment about "not necessarily under IP" is confusing 
> because it's more 
> >common to speak of these protocols as running "over" IP (or 
> do you you 
> >mean "intellectual property"? :-)  ).
> 
> Accepted. Frenglish, sorry. But it also wants to render "not 
> under the 
> limitations imposed by IP". I understand that the same 
> rationale applies to 
> the callout protocol considerations?
> 
> Now, you may see on my draft that entries into the dispatcher 
> may come from 
> an external I/O, from OPES one, from the callout interface 
> relating with a 
> remote OPES. And the same for outbound traffic, from the 
> dispatcher into 
> any of those interface and through the callout protocol into 
> other systems.
> 
> I feel this is conform to the OPES scheme, however not draft 
> the same way. 
> This shows the way the dispatcher is used. There may be non 
> documented 
> presentation functions to convert from a protocol to the 
> dispatcher and 
> from the dispatcher level to another protocol level. Right 
> now, I keep them 
> into the I/O blocks (they might be or not by-passed if the 
> "in" and the 
> "out" protocol were the same?). So they are not just APIs.
> 
> >Trying to continue guessing, I'll ask
> >if you mean that the "dispatcher" is remotely controlled, using 
> >something like OPES rules?
> 
> No. This why I use the word "underlay". The dispatchers may 
> relate together 
> to stay mutually informed, for example about some thresholds 
> they have 
> reached which might affect rules.
> 
> They might also exchange meta-data over the callout protocol 
> to speed up 
> some exchanges in a more specific manner, for example?
> 
> >Are you suggesting that this function be implemented as a "web 
> >service"?
> 
> It depends on what you name a web service. I suppose it could 
> use a service 
> - like a shared repository. But I doubt it could use a 
> controller: this 
> could conflict with the dispatcher rules. Obviously the rules 
> could be 
> remotely controlled. But it seems too rigid a concept. This is not 
> automatism, but telematism. There are delays, risks of 
> failures etc. Each 
> system should be standalone. Related, not tied.
> 
> >A few years ago I saw a system called "Delegate" that 
> provided a fairly 
> >general API so that people could write filters that could 
> take in data 
> >from one (protocol, port) pair and forward that data (possibly
> >altered) to another pair or deliver it locally.  It might be 
> closer to 
> >what you are describing than OPES is.
> 
> Really interesting. Do you recall where I could find details.
> 
> >OPES is more specific, and it concentrates on some details 
> of HTTP (and
> >possibly RTP) semantics, the callout protocol, and issues about 
> >configuration and tracing.
> 
> I am ready to accept that. This is why I asked and said that 
> what we have 
> in mind might not fit. Yet, are not protocol verification and 
> conversion 
> services as any other one? I miss the reason why the callout 
> protocol would 
> be HTTP/RTP specific?
> 
> >It might help the discussion if you could give some examples of what 
> >you'd
> >like to see systems like this do.
> 
> As I said, right now we are investigating what we are involved in. To 
> understand the architecture, find the most appropriate 
> design, development 
> tools, network system to use to switch information between 
> related systems, 
> where to place them. It may take time. OPES examples have 
> been given in a 
> specific IETF-draft. We are OK with them as test examples.
> 
> Let say for discussion sake that we have three OPES, one, 
> two, three. OPES 
> one is on the main machine, OPES two on another machine with the same 
> technology, connected through the underlay network and using callout 
> protocol. OPES three is on a third party machine connected 
> through the 
> callout protocol alone.
> 
>  From then I try to understand how it works. I feel that 
> considerations 
> quoted about the callout protocol might have to be addressed 
> between the 
> I/O block and the dispatcher? Also I am not certain where the 
> loops in the 
> dispatcher are checked and blocked in the OPES scheme? But 
> may be I just 
> not fully understood the things.
> 
> jfc
> 
> 
> 
> 

------_=_NextPart_001_01C2C8CF.52E855FE
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: to share OPES operations experience</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>hi all,</FONT>
</P>

<P><FONT SIZE=2>discussion is ok (in my opinion) as long as it is related to technical merits.</FONT>
</P>

<P><FONT SIZE=2>thanks</FONT>
<BR><FONT SIZE=2>abbie</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: jfcm [<A HREF="mailto:info@utel.net">mailto:info@utel.net</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 30, 2003 8:04 PM</FONT>
<BR><FONT SIZE=2>&gt; To: ietf-openproxy@imc.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: to share OPES operations experience</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dear Hilarie,</FONT>
<BR><FONT SIZE=2>&gt; thank you for your comments. I respond on the list, but I am </FONT>
<BR><FONT SIZE=2>&gt; not sure it is </FONT>
<BR><FONT SIZE=2>&gt; appropriate as it seems more an interaction over a project </FONT>
<BR><FONT SIZE=2>&gt; than a debate </FONT>
<BR><FONT SIZE=2>&gt; over a document preparation.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On 19:33 30/01/03, The Purple Streak, Hilarie Orman said:</FONT>
<BR><FONT SIZE=2>&gt; &gt;First, this is a public mailing list, see the ietf.org website about </FONT>
<BR><FONT SIZE=2>&gt; &gt;policies governing working group mailing lists.&nbsp; Don't post anything </FONT>
<BR><FONT SIZE=2>&gt; &gt;here that you want &quot;protected&quot; or &quot;respected&quot; by competitors.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I understand this. This is why I asked about other places. I </FONT>
<BR><FONT SIZE=2>&gt; only follow on </FONT>
<BR><FONT SIZE=2>&gt; Abbie's suggestion. When I say &quot;respected&quot;, I mean &quot;please do </FONT>
<BR><FONT SIZE=2>&gt; not flame me </FONT>
<BR><FONT SIZE=2>&gt; because I do not tell you everything you may ask&quot;. I will try </FONT>
<BR><FONT SIZE=2>&gt; however to </FONT>
<BR><FONT SIZE=2>&gt; detail what I can. If this is felt appropriate by the members </FONT>
<BR><FONT SIZE=2>&gt; of the list.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;OPES works with HTTP messages.&nbsp; We may address RTP in the future.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I said that I have a wider vision, documented for a long, of </FONT>
<BR><FONT SIZE=2>&gt; the &quot;network </FONT>
<BR><FONT SIZE=2>&gt; extended services&quot;, where OPES fit in. As explained I do not want to </FONT>
<BR><FONT SIZE=2>&gt; dispute semantics, I just work on some architecture which may </FONT>
<BR><FONT SIZE=2>&gt; help as an </FONT>
<BR><FONT SIZE=2>&gt; example and benefit from your inputs. I am not limited by the </FONT>
<BR><FONT SIZE=2>&gt; protocol.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;Your &quot;overlay&quot; looks very much like an ordinary operating system's</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I suppose what I name &quot;underlay&quot;? &quot;Overlay&quot; is the word used for the </FONT>
<BR><FONT SIZE=2>&gt; callout system as far as I understand?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;API to network protocols, so I'm unsure what its point is.&nbsp; Your </FONT>
<BR><FONT SIZE=2>&gt; &gt;comment about &quot;not necessarily under IP&quot; is confusing </FONT>
<BR><FONT SIZE=2>&gt; because it's more </FONT>
<BR><FONT SIZE=2>&gt; &gt;common to speak of these protocols as running &quot;over&quot; IP (or </FONT>
<BR><FONT SIZE=2>&gt; do you you </FONT>
<BR><FONT SIZE=2>&gt; &gt;mean &quot;intellectual property&quot;? :-)&nbsp; ).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Accepted. Frenglish, sorry. But it also wants to render &quot;not </FONT>
<BR><FONT SIZE=2>&gt; under the </FONT>
<BR><FONT SIZE=2>&gt; limitations imposed by IP&quot;. I understand that the same </FONT>
<BR><FONT SIZE=2>&gt; rationale applies to </FONT>
<BR><FONT SIZE=2>&gt; the callout protocol considerations?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Now, you may see on my draft that entries into the dispatcher </FONT>
<BR><FONT SIZE=2>&gt; may come from </FONT>
<BR><FONT SIZE=2>&gt; an external I/O, from OPES one, from the callout interface </FONT>
<BR><FONT SIZE=2>&gt; relating with a </FONT>
<BR><FONT SIZE=2>&gt; remote OPES. And the same for outbound traffic, from the </FONT>
<BR><FONT SIZE=2>&gt; dispatcher into </FONT>
<BR><FONT SIZE=2>&gt; any of those interface and through the callout protocol into </FONT>
<BR><FONT SIZE=2>&gt; other systems.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I feel this is conform to the OPES scheme, however not draft </FONT>
<BR><FONT SIZE=2>&gt; the same way. </FONT>
<BR><FONT SIZE=2>&gt; This shows the way the dispatcher is used. There may be non </FONT>
<BR><FONT SIZE=2>&gt; documented </FONT>
<BR><FONT SIZE=2>&gt; presentation functions to convert from a protocol to the </FONT>
<BR><FONT SIZE=2>&gt; dispatcher and </FONT>
<BR><FONT SIZE=2>&gt; from the dispatcher level to another protocol level. Right </FONT>
<BR><FONT SIZE=2>&gt; now, I keep them </FONT>
<BR><FONT SIZE=2>&gt; into the I/O blocks (they might be or not by-passed if the </FONT>
<BR><FONT SIZE=2>&gt; &quot;in&quot; and the </FONT>
<BR><FONT SIZE=2>&gt; &quot;out&quot; protocol were the same?). So they are not just APIs.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;Trying to continue guessing, I'll ask</FONT>
<BR><FONT SIZE=2>&gt; &gt;if you mean that the &quot;dispatcher&quot; is remotely controlled, using </FONT>
<BR><FONT SIZE=2>&gt; &gt;something like OPES rules?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No. This why I use the word &quot;underlay&quot;. The dispatchers may </FONT>
<BR><FONT SIZE=2>&gt; relate together </FONT>
<BR><FONT SIZE=2>&gt; to stay mutually informed, for example about some thresholds </FONT>
<BR><FONT SIZE=2>&gt; they have </FONT>
<BR><FONT SIZE=2>&gt; reached which might affect rules.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; They might also exchange meta-data over the callout protocol </FONT>
<BR><FONT SIZE=2>&gt; to speed up </FONT>
<BR><FONT SIZE=2>&gt; some exchanges in a more specific manner, for example?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;Are you suggesting that this function be implemented as a &quot;web </FONT>
<BR><FONT SIZE=2>&gt; &gt;service&quot;?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It depends on what you name a web service. I suppose it could </FONT>
<BR><FONT SIZE=2>&gt; use a service </FONT>
<BR><FONT SIZE=2>&gt; - like a shared repository. But I doubt it could use a </FONT>
<BR><FONT SIZE=2>&gt; controller: this </FONT>
<BR><FONT SIZE=2>&gt; could conflict with the dispatcher rules. Obviously the rules </FONT>
<BR><FONT SIZE=2>&gt; could be </FONT>
<BR><FONT SIZE=2>&gt; remotely controlled. But it seems too rigid a concept. This is not </FONT>
<BR><FONT SIZE=2>&gt; automatism, but telematism. There are delays, risks of </FONT>
<BR><FONT SIZE=2>&gt; failures etc. Each </FONT>
<BR><FONT SIZE=2>&gt; system should be standalone. Related, not tied.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;A few years ago I saw a system called &quot;Delegate&quot; that </FONT>
<BR><FONT SIZE=2>&gt; provided a fairly </FONT>
<BR><FONT SIZE=2>&gt; &gt;general API so that people could write filters that could </FONT>
<BR><FONT SIZE=2>&gt; take in data </FONT>
<BR><FONT SIZE=2>&gt; &gt;from one (protocol, port) pair and forward that data (possibly</FONT>
<BR><FONT SIZE=2>&gt; &gt;altered) to another pair or deliver it locally.&nbsp; It might be </FONT>
<BR><FONT SIZE=2>&gt; closer to </FONT>
<BR><FONT SIZE=2>&gt; &gt;what you are describing than OPES is.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Really interesting. Do you recall where I could find details.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;OPES is more specific, and it concentrates on some details </FONT>
<BR><FONT SIZE=2>&gt; of HTTP (and</FONT>
<BR><FONT SIZE=2>&gt; &gt;possibly RTP) semantics, the callout protocol, and issues about </FONT>
<BR><FONT SIZE=2>&gt; &gt;configuration and tracing.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I am ready to accept that. This is why I asked and said that </FONT>
<BR><FONT SIZE=2>&gt; what we have </FONT>
<BR><FONT SIZE=2>&gt; in mind might not fit. Yet, are not protocol verification and </FONT>
<BR><FONT SIZE=2>&gt; conversion </FONT>
<BR><FONT SIZE=2>&gt; services as any other one? I miss the reason why the callout </FONT>
<BR><FONT SIZE=2>&gt; protocol would </FONT>
<BR><FONT SIZE=2>&gt; be HTTP/RTP specific?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;It might help the discussion if you could give some examples of what </FONT>
<BR><FONT SIZE=2>&gt; &gt;you'd</FONT>
<BR><FONT SIZE=2>&gt; &gt;like to see systems like this do.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; As I said, right now we are investigating what we are involved in. To </FONT>
<BR><FONT SIZE=2>&gt; understand the architecture, find the most appropriate </FONT>
<BR><FONT SIZE=2>&gt; design, development </FONT>
<BR><FONT SIZE=2>&gt; tools, network system to use to switch information between </FONT>
<BR><FONT SIZE=2>&gt; related systems, </FONT>
<BR><FONT SIZE=2>&gt; where to place them. It may take time. OPES examples have </FONT>
<BR><FONT SIZE=2>&gt; been given in a </FONT>
<BR><FONT SIZE=2>&gt; specific IETF-draft. We are OK with them as test examples.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Let say for discussion sake that we have three OPES, one, </FONT>
<BR><FONT SIZE=2>&gt; two, three. OPES </FONT>
<BR><FONT SIZE=2>&gt; one is on the main machine, OPES two on another machine with the same </FONT>
<BR><FONT SIZE=2>&gt; technology, connected through the underlay network and using callout </FONT>
<BR><FONT SIZE=2>&gt; protocol. OPES three is on a third party machine connected </FONT>
<BR><FONT SIZE=2>&gt; through the </FONT>
<BR><FONT SIZE=2>&gt; callout protocol alone.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; From then I try to understand how it works. I feel that </FONT>
<BR><FONT SIZE=2>&gt; considerations </FONT>
<BR><FONT SIZE=2>&gt; quoted about the callout protocol might have to be addressed </FONT>
<BR><FONT SIZE=2>&gt; between the </FONT>
<BR><FONT SIZE=2>&gt; I/O block and the dispatcher? Also I am not certain where the </FONT>
<BR><FONT SIZE=2>&gt; loops in the </FONT>
<BR><FONT SIZE=2>&gt; dispatcher are checked and blocked in the OPES scheme? But </FONT>
<BR><FONT SIZE=2>&gt; may be I just </FONT>
<BR><FONT SIZE=2>&gt; not fully understood the things.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; jfc</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2C8CF.52E855FE--