W3C home > Mailing lists > Public > ietf-discuss@w3.org > March 1999

Re: need a reviewer (or three) for draft-cai-ssdp-v1-00.txt

From: Martin Hamilton <martin@net.lut.ac.uk>
Date: Wed, 17 Mar 1999 14:14:43 +0000
To: Harald Alvestrand <Harald@alvestrand.no>
Cc: Koen Holtman <Koen.Holtman@cern.ch>, Larry Masinter <masinter@parc.xerox.com>, Keith Moore <moore@cs.utk.edu>, web@apps.ietf.org, discuss@apps.ietf.org
Message-Id: <E10NH66-00037p-00@gizmo.lut.ac.uk>
-----BEGIN PGP SIGNED MESSAGE-----


Harald Alvestrand writes:

| At one time at least, the ICP protocol of SQUID would ship small documents
| in UDP datagrams on the ICP response.
| That community is probably able to give practical, recent experience.

The main one is probably that ICP is gradually being abandoned in 
favour of the new Cache Digest protocol.  For more info, check out:
<URL:http://squid.nlanr.net/Squid/CacheDigest/cache-digest-v5.txt>

For problems with ICP returning object contents, see RFC 2186 ...

      CAVEAT: ICP_OP_HIT_OBJ has some negative side effects which make
      its use undesirable.  It transfers object data without HTTP and
      therefore bypasses the standard HTTP processing, including
      authorization and age validation.  Another negative side effect is
      that ICP_OP_HIT_OBJ messages will often be much larger than the
      path MTU, thereby causing fragmentation to occur on the UDP
      packet.  For these reasons, use of ICP_OP_HIT_OBJ is NOT
      recommended.

 ... and RFC 2187 ...

   o    ICP_OP_HIT_OBJ is particularly vulnerable to security problems
        because it includes object data.  For this, and other reasons,
        its use is discouraged.

   o    Falsifying, altering, inserting, or blocking ICP messages can
        cause an HTTP request to fail only in two situations:

        -    If the cache is behind a firewall and cannot directly
             connect to the origin server.

        -    If a false ICP_OP_HIT reply causes the HTTP request to be
             forwarded to a sibling, where the request is a cache miss
             and the sibling refuses to continue forwarding the request
             on behalf of the originating cache.

Sayonara!

Martin



-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBNu+40NZdpXZXTSjhAQG16wQApJXctu2XI1tTDigKP/NGsbSS3G+98gp5
6vlgJ23+cJmtNjp9dB/GR6VR2csgDl8Jccp3Y8JJPGPGh4hEafMGcrsiWbdt3tKE
2fMROqGMrg02qwHU2KVGMnM3Lhd3B1lsAHWdjXfj6xmCOYSudobLv/zfjJxm9m0y
u2ucUaYg5Sw=
=ng4U
-----END PGP SIGNATURE-----
Received on Wednesday, 17 March 1999 10:27:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:00 UTC