Subject: Re: recommendation against publication of draft-cerpa-necp-02.txt

From: Vernon Schryver <[email-masked]>
Date: Mon, 10 Apr 2000 09:07:58 -0600 (MDT)

> From: Keith Moore <[email-masked]>

> ...
> But IP-layer interception has some fairly significant limitations
> for this application. ...

There's a technical problem with IP intercepting that I've not seen
mentioned, including in the draft.  Any intercepting based on TCP or UDP
port numbers or that makes any assumptions about TCP or UDP port numbers
will have problems, because of IPv4 fragmentation.  It seems plausible
that intercepting done by/for the server(s) would want to redirect all
traffic for a given IP address, and so not be affected by port numbers.
(Thus, it may make sense for the draft to not mention the issue.)

However, "transparent" HTTP proxy and email filtering and rewriting schemes
such as AOL's that need to intercept only traffic to a particular port
cannot do the right thing if the client has a private FDDI or 802.5 network
(e.g.  behind a NAT box) or has an ordinary 802.3 network but follows the
widespread, bogus advice to use a small PPP MTU.

Yes, I realize IPv6 doesn't have fragmentation, but most if not all of
the distant-from-server IP interception schemes sound unlikely to work
with IPv6 for other reasons.

> Bottom line is that IP-layer interception - even when done "right" - 
> has fairly limited applicability for location of nearby content.
> Though the technique is so widely mis-applied that it might still be 
> useful to define what "right" means.

That sounds overly optimistic.

Vernon Schryver    [email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Apr 2000 17:42:16 +0200

=> the first fragment has 8 bytes or more of payload, then the port numbers.
And other fragments share the same ID then it is possible to apply
the same action on all the fragments if they follow the same path at
the interception point.
 This can be hairy if fragments are not in the usual order, for instance
if someone sends the last one first (this is not as stupid as it seems
because the last fragment provides the whole length of the packet).

=> but fragmentation is not the best way to fight against "transparent"
proxies (:-)...

   Yes, I realize IPv6 doesn't have fragmentation
   
=> IPv6 has fragmentation, but only from end to end (no fragmentation
en route). Packet IDs are used by IPv6 only with fragmentation (they
are in fragmentation headers) too...

   but most if not all of the distant-from-server IP interception
   schemes sound unlikely to work with IPv6 for other reasons.

=> I'd like that this is true (another reason to switch to IPv6 :-)
but the only thing which is broken by interception is authentication
(IPSec is mandatory to implement, not (yet) to use with IPv6).
Encryption isn't really "transparent" proxies friendly too (:-).

Regards

[email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 10 Apr 2000 16:59:58 +0100

>>That sounds overly optimistic.

user experience/expectation& context is verything

TCP end2end ness?
if you access a web page from our server, chances are its fectehc by one
of several httpds from one of a LOT of NFS or samba servers, which,
depending on local conditions.....

if you send audio on the net, its quite possible it goes through several
a2d and d2a conversions (.. thru a PSTN/SIP or 323 gateway) - in fact,

if you speak on an apparently end2end PSTN
transatlantic phone call, chances are your voice 
is digitzed and re-digitzed several times by transcoder/compressers....

its the 21st century:
f you dont use end2end crypto, then you  gotta expect people to optimize
their resources to give you the best service money can buy for the least
they have to spend.

hey, when you buy a book written by the author, it was usually typeset,
proofread, and re-edited by several other people....

even this email may not be from me...

 cheers

   jon
"every decoding is an encoding"
maurice zapp from the Euphoric State University, in small world, by david lodge