I think the security section is a little confused. SSL doesn't use digital
signatures to validate content. Instead, SSL uses public key methods
to establish a symmetric key that can be used to generate a message
authentication code for data carried over TCP. Maybe that's what was
meant by "unicast can use SSL" after option 2, but it's not clear.
You might use an XML signature for messages
that were multicast, or you might establish a symmetric key for
use by a group. It's unlikely that you'd want to use digital
signatures because of the computational cost and induced
latency in processing the messages, but that's an engineering
tradeoff decision.
Basically, you need to decide if the security is done at the
transport or application level, what the trust relationships are,
and what the crypto encoding framework is.
There's a need for a generic cache communication protocol that
will support cache functionality extensions without requiring a lot
of new protocols over http. Sessions, security, robustness,
multicast, encodings, etc., these keep being reinvented.
If BXXP+XML can cover the space, then this is probably the
time to adopt them.
XML for bulk data seems worrisome because of the processing
latency and space inefficiency.
Hilarie
>>> Dan Li <lidan@cisco.com> 11/15/00 01:57PM >>>
Hi, please take a look of the WCIP draft before the IETF meeting, as we'd
spend time on issue discussions and won't cover the draft in detail. This
draft is a strawman, at least the following things need more work:
- clearly define the relationship of wcip with normal cache-control directives.
- specify in more detail the role of relay point, especially for channel
aggregation. Can we or can we not aggregate heartbeats, possibly but
cutting freshness guarantee.
- pick a security model. Use SSL, or PGP signature, or both, and also the
security of the channel info.
- do we need a default port number? pros and cons wrt. to port 80.
- are people happy with persistent TCP connection? are people happy with
"delta consistency" (vs. eventual consistency, strong consistency, or
anything else).
- in the absence of a off-the-shelf realtime reliable multicast protocol,
can we still run wcip on multicast UDP for scalability. See section 3.2.3.
- preloading, log reporting, advanced event notification, programability,
.. future stuff on vertical peering and dynamic content
What do people think?
Dan
At 08:12 AM 11/15/00 -0800, Ian Cooper wrote:
>>To: IETF-Announce: ;
>>From: Internet-Drafts@ietf.org
>>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt
>>Date: Wed, 15 Nov 2000 06:41:12 -0500
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>>
>>
>> Title : WCIP: Web Cache Invalidation Protocol
>> Author(s) : D. Li, P. Cao, M. Dahlin
>> Filename : draft-danli-wrec-wcip-00.txt
>> Pages : 26
>> Date : 14-Nov-00
>>
>>Cache consistency is a major impediment to scalable content
>>delivery. This document describes the Web Cache Invalidation
>>Protocol (WCIP) which uses invalidations and updates to keep
>>changing objects up to date in web caches. Moreover, it allows
>>automatic one-to-may relay and many-to-one aggregation in a CDN
>>(content delivery network) environment.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt
>>
>>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-danli-wrec-wcip-00.txt".
>>
>>A list of Internet-Drafts directories can be found in
>>http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>> mailserv@ietf.org.
>>In the body type:
>> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt".
>>
>>NOTE: The mail server at ietf.org can return the document in
>> MIME-encoded form by using the "mpack" utility. To use this
>> feature, insert the command "ENCODING mime" before the "FILE"
>> command. To decode the response(s), you will need "munpack" or
>> a MIME-compliant mail reader. Different MIME-compliant mail readers
>> exhibit different behavior, especially when dealing with
>> "multipart" MIME messages (i.e. documents which have been split
>> up into multiple messages), so check your local documentation on
>> how to manipulate these messages.
>>
>>
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>>
>>Content-Type: text/plain
>>Content-ID: <20001114131241.I-D@ietf.org>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt
>>
>><ftp://ftp.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt>
>
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST