Subject: [midcom] middle-boxes and a historical precedence

From: Sean Doran <[email-masked]>
Date: 26 Jan 2001 15:33:27 +0100

One of the obvious slants one can take on the posted WG
description is that "existing IETF protocols" end up being
a language used to communicate with a middle-box, which
translates that language into something another host or
middle-box elsewhere in the network can process.   

In essence, IPv4 can be seen as a host-to-router protocol,
and the router-to-router protocol can be IPv4-with-different-addresses,
IPv6, MPLS, OSI CLNP/X.25 PLP(IS8208 "CONP")/IONL, you-name-it.
The major difference between a middle-box and a
traditional router is that the adjustments done to packets
may go beyond simple bookkeeping adjustments in the network 
layer header.  In other words: a traditional router
adjusts the likes of TTL, does fragmentation, sends back
error messages, and so forth; a middle-box router does all
this and _also_ may rewrite network-layer addresses, may
rewrite the network-layer header information into a
completely different protocol's analogue, may make
adjustments to the payload of the network-layer, and may
even act as an ALG.

In my opinion, there shouldn't be an assumption about
_where_ the middle-box sits; it could be on a LAN with a
bunch of hosts, it could be on either side of a
provider/customer network boundary, it could be on a
provider/provider boundary, or going the other way, it
could be integrated directly with a single host.

If this is a reasonable point of view, then an obvious
goal of the WG would be to attempt to keep the possible
output of a middle-box as general as possible when the
input is an IPv4 packet from a host (and of course the
complementary maximally-general->IPv4 for packets destined
to the same host).  At the same time, the host should be
as close to unaware as possible that this whole process is
occurring.  The output of the IRTF's NSRG (when it comes)
likely would be useful to the WG.  See http://www.irtf.org/charters/namespace.html

Ad blurb.  Padlipsky's book, _The Elements of Networking
Style_, is available once again, thanks to
backinprint.com; it's apparently available in the usual
book-buying places.

An interesting MIDCOM-relevant excerpt:

[writing in ca. 1984 about INFOCOM 83's "Futures" panel,
 which was thinking about what things would be like when
 hardwar was cheap enough that "everybody" had enough
 "computer power" at home, Padlipsky developed a Vision,
 which he shared with the audience]

  Given enough "compute power," what will happen is that
  the technotheology can and will become moot: Nobody will
  have to give up his or her favorite approach to
  Intercomputer networking, nor will anybody have to give
  up on the sunken investment in current networking
  software, nor will somebody have to come up with
  something that really does border on the magical by way
  of Translating / Mapping Gateways.  No, what will happen
  is that when you want to get at a particular resource
  you'll just go off to it in _its "own" protocol suite_...
  because you'll have an Outboard Processing Environment
  (see Chapter 6) available to you, on that cheap and
  plentiful enough hardware, which is capable of
  interpreting all reasonable (and some unreasonable)
  suites "in parallel," so it doesn't really mattter much
  -- except to technoaestheticians -- which suite is
  "best".

  I'd like to think that's the way it will be, actually;
  it's so attractively Ecumenical.

  [Though I must confess to a lingering fear that the
  suites which do assume end-to-endness of the Network
  level c0ould still foul things up...]

The Outboard Processing Environment is basically a
middle-box as above, only the hosts may talk not just
IPv4, but also IPv6, MPLS, Appletalk, IPX, DECNET, bla bla bla.
This "OPE" middle-box would then convert to something that
some set of routers could actually deliver to some other
middle-box, or host, in such a way that the ultimate host
can use the data as intended (including replying to it).

        Sean.

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 26 Jan 2001 09:52:52 -0500

> could be integrated directly with a single host.

This is the ideal, I think, but we should remember
that it's at the cost of additional complexity in
the security mechanisms.

> At the same time, the host should be
> occurring.

I'm not sure exactly what you mean, here, but inasmuch
as the intention is to offload application processing
from the middlebox and move it back to a host or something
like a call-control server, I'd probably disagree.  It
may be possible to do something similar to the auto-SOCKS-
ification DLLs and shared libraries, but those really aren't 
*that* transparent.

Melinda