Subject: I-D ACTION:draft-ietf-opes-end-comm-04.txt

From: [email-masked]
Date: Mon, 20 Oct 2003 15:45:20 -0400

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		: OPES processor and end points communications
	Author(s)	: A. Barbir
	Filename	: draft-ietf-opes-end-comm-04.txt
	Pages		: 20
	Date		: 2003-10-20
	
This memo documents tracing requirements for Open Pluggable Edge
Services (OPES)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-end-comm-04.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-end-comm-04.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-opes-end-comm-04.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.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 20 Oct 2003 22:32:52 -0600 (MDT)

Abbie,

	Yet another significantly improved draft version, thank you!
Here are a few remaining (mostly high-level) issues that I could spot
after a quick review:

* Please cite RFC 2119

* In Section 3.2 "Requirements for OPES System" you list 5 MUST-level
requirements for adding information to the trace and then finish off
with informative (not-normative) text saying that most of the above
requirements can be satisfied by providing a URL to a web site. If we
ignore informative text, the requirements are likely to cause too
large trace entries. We need to convert informative text to a
normative one. For example, you could add another requirement similar
to the one below:

	When providing required information, an OPES System MAY
	use a single URI to identify a resource containing several
	required items. For example, an OPES System can point to
	a single web page with a reference to System privacy policy
	and technical contact information.

I also believe that we must add explicit text clarifying the meaning
of the terms used by this section rules. Something along these lines:

	This specification does not define the meaning of the terms
	privacy policy, policy enforcement, or technical contact and
	contains no requirements regarding encoding, language, format,
	or any other aspects of that information.

In other words, we are saying that Systems must provide something that
they believe is a privacy policy or technical contact OR that other
specs may define these terms and details. This is a very important
"full disclosure" statement of our inability to fully address a known
problem.

> An OPES system MUST add its identification to the trace.

Any requirements regarding System identification? Is it supposed to be
globally unique, for example? If yes, then are we proposing a registry
for system IDs?? If not, then a system can use "system" as an
identifier and satisfy the above requirement.

> An OPES System MUST include information that identifies, to the
> technical contact, the OPES processors involved in processing the
> message.

This contradicts the fact that OPES processor tracing is not a MUST,
does not it? Given this two contradicting requirements, it is not
clear whether an end is guaranteed a processor trace entry for each
processor involved. Please resolve this important conflict.

> Each OPES processor MUST support tracing, policy can be used to turn
> tracing on and to determine its granularity.

I continue to note that the above requirement does not make much sense
to me. If a policy can be used, can I use a policy that always turns
tracing off and have that as the only, hard-coded policy? I think this
is a failed attempt to appear directly compliant with an IAB
consideration and it should be removed.

> OPES processor SHOULD be able to trace it's own invocation and
> service(s) execution since it understands the application protocol.

Is it a requirement or a consequence of the "since it understands"
part? There is another "SHOULD ... since" requirement elsewhere in the
draft.

* Please make sure that all "May"s are converted to "MAY"s or "may"s.

* Please include a Compliance Considerations section or equivalent.
  What does it mean to be compliant with your spec? Are there multiple
  levels of compliance?

> the definition of "non-OPES" content is provider-dependent and may
> include content adapted by OPES.

I agree with the first part, but cannot concatenate that with the
second part. Given an OPES-adapted content, a content provider may
designate any other content as a non-OPES content, but that designated
content cannot be OPES-adapted.

> Examples include content that is adapted for Black
> and White hand held devices or logging services.

Is this an example of non-OPES content or OPES content? Please give a
single example that contains both so that the difference becomes
clear.

> An  OPES System MUST include information about its bypass policy.

> An OPES System MUST identify the party responsible for setting
> and enforcing the bypass policy.

> An OPES System MUST include information that identifies, to a
> technical contact, the OPES  processors involved in processing the
> bypass request.

MUST include/identify where? In a trace? Then these should be moved to
tracing requirements.

> OPES processor SHOULD be able to bypass it's own invocation

Isn't this a self-contradiction? Like lifting oneself by one's own
hair? If the processor is looking at the bypass instruction, it is
already invoked.

> Specific protocol binding documents ought to take these security
> threats into consideration. It is recommended that protocol bindings
> provide safe features into their specifications. Such features may
> include a place holder in the message header that indicates the size
> of the trace.

I am not sure what you mean here. The documented security threats do
not seem to be application-specific so it it not clear why or how
application-specific specifications can "take them into
consideration".

* Please add "inconsistent/selective bypass" as a threat: One end can
  try to bypass a subset of OPES entities so that the resulting
  content is malformed and crashes or compromises entities that
  process that content (and expect that content to be complete and
  valid). Such exceptions are often not tested because implementors do
  not expect a vital service to "disappear" from the processing loop.

* Please add "ACL bypass" as a threat: Systems implementing access
  controls via OPES entities may be incorrectly configured to honor
  bypass and, hence, give unauthorized access to the world.

* Please add "Tap bypass" as a threat: Systems implementing "wiretaps"
  of all sorts via OPES entities may be incorrectly configured to
  honor bypass and, hence, ignore (leave undetected) traffic with
  bypass instructions that should have been tapped/logged.

* Do you already document a threat where one end can disable things
  like virus checkers at the other edge? Please add if not. I am sure
  you cover this in some general statement, but general security
  statements are known to be ignored. We need specific examples to
  get folks attention.

> There are risks for the OPES System by non-OPES entities, whereby,
> these entities can insert bypass instructions into the OPES Flow.

Isn't that usually the case that bypass instructions are inserted by
non-OPES entities (e.g., end-user browsers)?

> The ability to illegally introduce bypass instructions into a data
> flow

Do we define a legal way of introducing bypass instructions?

> [5]  Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD,

Please update the above reference, including the authors list.

> draft-ietf-opes-iab-02.txt, February  2004

What's the price of MS stock in your time zone? :-)

Thank you,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 21 Oct 2003 11:40:42 -0400

Folks,

please follow Alex example and take a very, very careful look at this 
version of the draft (draft-ietf-opes-end-comm-04).

THIS IS THE FINAL DOCUMENT CANDIDATE.

Please post your comments to the mailing list by 11/1, so that Abbie 
can prepare the final document, on which we'll then issue WGLC. I'd 
expect that open issues get resolved beforehand, so please check it 
out NOW!!

Thanks,
   Markus