Subject: Re: interception proxies

From: Vernon Schryver <[email-masked]>
Date: Tue, 11 Apr 2000 16:47:04 -0600 (MDT)

> From: Joe Touch <[email-masked]>

> ...
> > The problems draft is interesting and depressing.  All of the problems
> > listed are technical nits.  
>
> This was a choice - in some larger sense, if sourcing other-owned IP
> addresses or TCP connections is considered an architectural problem,
> needs to come down from above, rather than up from WREC. f

Call me a non-team playing scab, but I refuse to the honor the old guild
work rule that limits the questions I can consider.  If sourcing
other-owned etc. or anything else is an architectural or other problem,
then professional pride ought to force one to raise the issue insetad of
waiting for the AD, IESG, IAB, or a plenary to redirect things.  But I
realize that's a minority view, and not just in IETF working groups or
even the IETF.
If only I could have had one pre-IPO share for every time I've been told
"we can't think about that; we'll have to ask to marketing" ...  on the
other hand, most of those shares would be merely expensive wallpaper.

> >                    ... That there is no mention of the problems that IP
> > fragmentation can cause interception proxies is depressing.
>
> The problems of IP fragmentation are not unique to web caching or
> replication proxies. They affect all interception proxies. The issue of
> inteception proxies was around long before WREC, and is more than just a
> caching or replication issue. 

Which is why it was depressing.  Oh, well, perhaps a future version of
the Problems draft will consider that issue and say as others wrote, it's
not a problem and can be fixed with big buffers watching IP ID's, avoiding
UDP, assuming good MSS's or discovery prevent TCP/IP fragmentation, or
whatever.

> ...
> That's the property of WGs in general, by construction. These questions
> sometimes get addressed in BOFs, but there is also often too much
> momentum or political interest in establishing a 'standardizing
> presence' in an area. By the time a WG is formed, the time for 'whether'
> has often passed in favor of 'which'.

Which was exactly the lament the other day.  By the time a Last Call rolls
around, it's months and $B of market cap late to worry about "whether?"
There are always screams about the unfairness of raising "whether" at such
a late date and vague reference to nearly completed implementations that
will have billions of installations by the end of the quarter, or when
IPv8 replaces IPv4 at the latest, exactly as we heard in response to the
initial comments about draft-cerpa-necp-02.txt.

I don't have a fix for the problem, except to steadfastly refuse to heed
cries from partisans that "whether?" is out of order until it really is.

 ...

] From: "BookIII, Robert" <[email-masked]>

] Joe,
]        Am I to presume by your statement that you are of the mind that the
] time for considering whether vs. which has already come and gone? Is there
] anyone on this list who thinks that?

I don't speak for Joe, but it's clearly over.  Unlike the wiretapping
question, interception proxies are too near to the technical interests
(and pocketbooks) of too many IETF participants.  You must admit that they
sound like cool hacks, unlike merely forwarding copies of bits.

Vernon Schryver    [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Apr 2000 20:02:31 -0400

> waiting for the AD, IESG, IAB, or a plenary to redirect things.

agree entirely.  but for this to work there have to be folks within
the WG who are willing to raise a fuss.  

Keith

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 11 Apr 2000 23:37:24 -0400

Date: Tue, 11 Apr 2000 16:47:04 -0600 (MDT)
   From: Vernon Schryver <[email-masked]>

And the latest kludge which has been called to my attention is ISP's
that tamper with the MSS values in TCP SYN packets in flight.  This is
done to work around smaller MTU's caused by PPP over Ethernet (and other
tunnelling mechanisms) interacting badly with Path MTU discovery
failures, which in turn are caused by firewalls that filter out the
wrong sorts of ICMP packets.

Hmmm, yet another thing which IPSEC will break.....

							- Ted

---

From: Vijay Gill <[email-masked]>
Date: Wed, 12 Apr 2000 00:03:08 -0400 (EDT)

> Hmmm, yet another thing which IPSEC will break.....

Any specific ISP's that one could care to name?  Coming from an ISP, what
I've seen in general is that most routers have just enough cycles in the
forwarding path to keep up with the offered traffic, much less sit around
watching for SYN's in flight so as to mutate the MSS values.  In fact, I'd
think this would be more of an end system issue rather than a "core" or a
"backbone" issue, where the end system is the box prior to the ISP handoff
and not quite under the ISP's control and not the end system as in the
end2end tcp/ip sense of the word.

/vijay

---

From: Marc Horowitz <[email-masked]>
Date: 13 Apr 2000 04:20:36 -0400

>> end2end tcp/ip sense of the word.

As the person who mentioned this to Ted in the first place, it's
BellAtlantic InfoSpeed DSL:

04:07:18.626618 ppp0 > badsl.1886 > home.finger: S 3981264130:3981264130(0) win 31944 <mss 1452,sackOK,timestamp 57597532 0,nop,wscale 0> (DF)
04:07:18.720702 ppp0 < home.finger > badsl.1886: S 295466136:295466136(0) ack 3981264131 win 16384 <mss 1412,nop,wscale 0,nop,nop,timestamp 7390358 57597532>
04:07:18.720725 ppp0 > badsl.1886 > home.finger: . 1:1(0) ack 1 win 31944 <nop,nop,timestamp 57597542 7390358> (DF)

04:08:17.797647 badsl.1886 > home.79: S 3981264130:3981264130(0) win 31944 <mss 1412,sackOK,timestamp 57597532 0,nop,wscale 0> (DF)
04:08:17.798118 home.79 > badsl.1886: S 295466136:295466136(0) ack 3981264131 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 7390358 57597532>
04:08:17.839552 badsl.1886 > home.79: . ack 1 win 31944 <nop,nop,timestamp 57597542 7390358> (DF)

Of course, it's hard to tell exactly where this is happening.  I
suspect either the DSL modem or the DSLAM.

I've considered bringing up IPsec using AH on the two endpoints, but
I'm sure that will involve far more pain dealing with incompetent
technical "support" droids than I have time to deal with.

On the other side, I can name over a dozen major web sites which
create a black hole by setting DF on outgoing TCP segments, but block
ICMP fragmentation required messages going the other way.

If anybody at Cisco is listening (a rhetorical question to be sure), a
great feature for a future version of IOS would be one which causes
TCP to be blocked completely if ICMP fragmentation required packets
are blocked.  At least then the black hole would be easy to spot :-)

		Marc

---

From: John Martin <[email-masked]>
Date: Thu, 13 Apr 2000 12:07:39 +0200

Vernon,

>realize that's a minority view, and not just in IETF working groups or

When WREC was originally proposed to the IESG, its scope was much 
broader.     Since the area was, at the time, the subject of much 
confusion, our charter was changed by the IESG to begin with a taxonomy and 
a list of known problems with caching and replication as is done today. At 
the time, I disagreed but complied. With hindsight - and given recent 
discussions - I think that their decision was correct. (If for no other 
reason that we now know what to call these "interception proxy" things).

Most of us who started WREC have indeed an interest in caching and 
replication but not necessarily "interceptions proxies". This type of proxy 
is only one way to do caching / replication - and certainly by no means the 
most common. (The most common - by far - are actually standard, 
run-of-the-mill proxies configured explicitly in users' browsers).

Rgds,
John (WREC co-chair)
---------------------------------------------------------------
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
---------------------------------------------------------------

---

From: Vijay Gill <[email-masked]>
Date: Fri, 14 Apr 2000 00:07:52 -0400 (EDT)

> suspect either the DSL modem or the DSLAM.

Ah yes.  Perhaps it would be interesting if the vendor(s) name(s) were
published, so that when they come touting the hardware to other providers,
some hard questions may be asked.

/vijay