Subject: Re: interception proxies

From: "Dick St.Peters" <[email-masked]>
Date: Wed, 12 Apr 2000 14:01:37 -0400 (EDT)

Charles Lynn writes:

> You have misread the specification.  That "source" is not (IP Header)
> "Source Address" that you imply, but the "source" mentioned earlier in
> the sentence, i.e., "address in the source route" (option).

Apparently so - though given that the part I emphasized immediately
follows mention of rewriting the destination address, this isn't
obvious.

> [If you think about it, the interpretation you emphasized above will
> not result in a capability for bi-directional communication.]

Actually, I've always thought that the first recorded-route address
was the original source address so the route would indeed be
reversible, but I'll admit to never having actually seen a recorded
route.

J. Noel Chiappa writes:

> Pardon me if I emit a "balderdash".
 ...
> They had great foresight, huh? The foresight to see the need for more
> address bits (funnily enough, IP2.5 *had* this, and they *ripped it out* -
> great vision there), traffic flows, etc (I could go on but what's the
> point).

Yes, just what was your point?

> However, let's not mythologize anything, OK? It gets in the way of
> objective analysis.

Actually, the view that everything about IP was cast in stone forever
in the IP spec is exactly the view that is being argued about.

Would you settle for "The IP spec authors didn't have enough foresight
to foresee a need to rewrite source addresses" ? :)

Whatever anyone thinks of it, people are doing it.  On the right are
people saying it is immoral, evil, and dangerous, not to mention
prohibited by the gods, and they refuse to talk about it.  On the left
are people doing it, each their own way because there is no standard
and not even any public discussion.

Only a few months after I first used the net, IP replaced NCP, giving
me an instant impression that network protocols are ephemeral things,
replaceable if they don't measure up.  Presumably if they can be
replaced, they can be adapted when necessary.

--
Dick St.Peters, [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Apr 2000 15:12:00 -0400

> in the IP spec is exactly the view that is being argued about.

nobody has said anything about IP being cast in stone forever.

Keith

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Apr 2000 13:51:28 -0700

> and not even any public discussion.

Intercepting connections and sourcing packets with addresses not owned
by you (or within your stub subnet) violates one of the few standards we
have (STD003 - the combination of RFCs 1122 and 1123).

Intercepting connections by rewriting IP headers in a gateway violates a
proposed staandard (RFC 1812).

It is not immoral, evil or dangerous; there are standards (existing and
proposed), and they are being violated.

Joe

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 12 Apr 2000 23:21:18 +0200

>to foresee a need to rewrite source addresses" ? :)
My standard architectural wish-it-could-be-changed:

The source address of a datagram was an architectural mistake, and should 
never have been in the mandatory packet format.

                   Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 12 Apr 2000 17:07:50 -0500

> never have been in the mandatory packet format.

Nahh, the mistake was ignoring the source address when routing & forwarding.

---

From: [email-masked]
Date: Thu, 13 Apr 2000 00:04:14 -0400

> > never have been in the mandatory packet format.
OK, I'll bite - either I'm missing something, or it's 11 days past the
traditional time for such statements.  If the source address wasn't
in the mandatory packet, what would we use for the 4-tuple identifying
a connection?

> Nahh, the mistake was ignoring the source address when routing & forwarding.
I may be dense, but I don't remember seeing an absolute prohibition
against checking the source address.  Otherwise, RFC2267 on Network
Ingress Filtering would be in violation all over the place....

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 13 Apr 2000 07:57:00 +0200

>in the mandatory packet, what would we use for the 4-tuple identifying

ok :-)

that statement illustrates the reason I think so.
The source address fulfils about 4 purposes:

- the address to which a response should be sent.
   For connection oriented stuff, this is part of connection establishment.
   For connectionless stuff, it needs to be only in an initial fragment.
   In one-way transport ("broadcast") it's not needed.
   In transports with feedback on a different channel (RTP/RTSP), it's
   simply the wrong address for this purpose.
   In all cases, it's an application layer thing, thus placing it at the
   network level is a layering violation.

- the address to which network layer error reports (ICMP) should be sent.
   This is not clearly the same as the above one.

- the address of the entity which authorizes the transmission of the message
   (as in "ingress filtering").
   Being unprotected and guessable means that it's not a particularly well
   suited identifier for this. DDOS attacks and SYN spoofs, anyone?

- a simple debugging aid for making trace logs easier to read.
   This is worth 4% of our network traffic volume??????
   (based on 100-byte average packet size, that's what 4 bytes amounts to)

I don't want to change it (as if I could!), my purpose was to point out 
that our current network is the sum of our mistakes, not the network 
equivalent of the Mount Sinai tablets.

                    Harald

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Apr 2000 08:07:02 -0400

> equivalent of the Mount Sinai tablets.

no disagreement there.  but the original mistakes in TCP/IP were more-or-less
designed to work together.  when people start deploying their own mistakes
in an ad hoc fashion, and when multiple mistakes get added concurrently,
not only do they break things that assumed that the only mistakes in the 
network were those originally designed-in, the combined effect of those 
new mistakes is far worse than the effect of any of them taken individually.

Keith

p.s. I will also argue that the complexities of adding a separate 
application-level identifer and doing without the source address,
are such that had this been done in the original TCP/IP design, 
it would have had a much more difficult time getting deployed 
in the first place.

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 13 Apr 2000 13:33:27 +0100

>>Nahh, the mistake was ignoring the source address when routing & forwarding.

thats an implementation detail not a design mistake.

there's plenty of fast classifier algorithms and data structures now
for the 5-tuple which reender  this debate academic - in fact, i think
the lack of a idee fixe about flow id, versus src or dst or src+dst
based routing, versus route hint +eid and so on is the _strength_ of
the tcp/.ip model-  the very lack lack of strong noel complains about
 foresight led to diversity and design freedom....

 cheers

   jon