Subject: Re: interception proxies

From: Vernon Schryver <[email-masked]>
Date: Mon, 17 Apr 2000 17:05:01 -0600 (MDT)

> From: Joe Touch <[email-masked]>
> To: Erik Nordmark <[email-masked]>

> > This doesn't list what I thought was an obvious issue.
> > If multiple nodes are originating packets with the same source
> > IP address it will be rather hard for them to ensure the required
> > uniqueness on the IP ID field (unique for the combination
> > of source IP, destination IP and protocol).
> > 
> > I suspect that most of boxes that play these games don't worry about
> > IP ID which might cause garbage reassembly should the same
> > IP ID be used when multiple such boxes are sending to the same IP address.
>
>
> Good point.
>
> I suspect they ignore the issue because of how they demux to multiple
> boxes;
> if the demux is by a hash of source IP address, then there's no need for
> coordination thereafter.

That's ok for the redirected ISP customers and the box itself, but
what about the distant server that is getting less than half of the
(addr, port, addr, port) 4-tuple?  I thought the point was that
the distant SMTP or HTTP server would be getting second or later
IP fragments with colliding IP ID's, identical source (proxy's)
and destination (server's) IP addresses, and so with no clue which
IP fragments belong to which stream.

> I'll certainly add that to the list. There's a corrolary at the TCP
> level, of port reuse, etc.

Is that a sign of good things happening to the document?  
I've been hoping to see some activity in the WREC list about either
hijacking--uh--redirecting proxy hazards documement or the document
NECP Is something happening behind the scenes?  If so, please forget
I asked.

Vernon Schryver    [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2000 16:14:55 -0700

> IP fragments belong to which stream.

I was describing a (easy) case where the demux is by source IP only; in
that case, IP IDs can be reused by the different servers, because there
is no potential collision of the tuples.

There are certainly cases where the demux is not by source IP, in which
case the different servers (or clients) sharing an IP address need to
coordinate IP IDs.

> NECP Is something happening behind the scenes?  If so, please forget

Thus far I haven't seen enough feedback to determine.

I'm looking for direction:

	- (preferred) separate hazards ID
	- roll into known problems
		(I've discussed with others why I think this
		is outside 'known probs' - in the sense that
		I feel KP is about unintended non-compliance,
		not deliberate extension/augmentation with new
		mechanism)

I don't know what 'hijacking' would mean - I'm in WREC, so I'd be glad
to have it run through that group (that's what I was expecting, in
fact).

I would assume it would be cited/referred by an update to NECP, but not
rolled-in per se.

Any other thoughts?

Joe

---

From: John Martin <[email-masked]>
Date: Tue, 18 Apr 2000 10:09:25 +0200

>NECP Is something happening behind the scenes?  If so, please forget

NECP is not within the scope of WREC's current charter. NECP is being 
revised, however, and we can expect a new version within the next few weeks 
or so.

With respect to interception proxies, I would very much like to see these 
discussed further on WREC. Our issues document could probably do with wider 
review than just WREC.

But one very common mis-conception I have noticed is about the point at 
which redirection occurs. In my experience, the redirection takes place 
only at either source or destination, or more specifically, at a point 
which is under the same administrative control as the end-user or (e.g.) 
the web server itself.

A lot of the recent discussion on the IETF list seemed to assume that this 
happened "somewhere in the middle". I'm not saying this is not possible, 
just that it is not happening today (to my knowledge). In the future, I 
think that it will get more, not less difficult to do this too - e.g. when 
traffic is already tagged / labelled it will be more difficult to intercept 
in the middle of its path.

In the meantime, there are many other ways to redirect clients to the 
closest proxy. One common way is to simply use the DNS to give a response 
dependant on the client's source IP address (for either the proxy or the 
destination web server); many corporates do this today already - Akamai 
have built a whole business out of it.

John
---------------------------------------------------------------
Network Appliance           Direct / Voicemail: +31 23 567 9615
Kruisweg 799                               Fax: +31 23 567 9699
NL-2132 NG Hoofddorp               Main Office: +31 23 567 9600
---------------------------------------------------------------