Subject: [midcom] Fw: I-D ACTION:draft-shore-midcom-apps-00.txt

From: "Melinda Shore" <[email-masked]>
Date: Mon, 14 May 2001 08:18:51 -0400

FYI.

Melinda

----- Original Message ----- 
From: <[email-masked]>
To: <IETF-Announce: ;>
Sent: Monday, May 14, 2001 7:35 AM
Subject: I-D ACTION:draft-shore-midcom-apps-00.txt

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> Title : Application Considerations for Midcom Middleboxes
> Author(s) : M. Shore
> Filename : draft-shore-midcom-apps-00.txt
> Pages : 8
> Date : 11-May-01
> 
> As an architecture is evolving around an interface
> between middleboxes in the transport plane [Srisuresh]
> and the applications which must traverse them, we need
> to document the implications for applications.  This
> documentation is intended both to provide guidance for
> application designers and to help network architects
> come to a better understanding of sources of complexity
> in our networks.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-shore-midcom-apps-00.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-shore-midcom-apps-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-shore-midcom-apps-00.txt".
> 
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 May 2001 11:36:33 -0400

Melinda,

I strongly object to the notion that middleboxes are part of any kind
of 'architecture'.  They are a hack, nothing more.  An architecture
implies some aspect of overall design, making compromises between the
needs of different facets of the design for the overall good.
Such terminology does not apply to workarounds for the problems 
with NATs.

Before this group was formed I tried to get it to work on a sound
architecture for firewalls.  That approach was soundly rejected in
favor of the group working on short-term workarounds.  It's disingenious
and misleading to call this group's work any kind of architecture. 

Keith

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

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 15 May 2001 12:11:01 -0700

>Such terminology does not apply to workarounds for the problems

Real networks architectures that make compromises between the needs of 
different facets of the design for the overall good, use middleboxes. The 
definition of good is a variable.

We need to address such designs and that's what this WG is about. In any 
case, a bad architecture is still an architecture.

---

From: Keith Moore <[email-masked]>
Date: Tue, 15 May 2001 15:47:26 -0400

> case, a bad architecture is still an architecture.

Let me try to state this in different words:

(note: the word middlebox is so overloaded as to make nearly every use of 
the word ambiguous at best and misleading at worst.  so I try not to use 
that word.)

weasel-words in the charter notwithstanding, this working group exists 
primarily to work around some of the problems caused by NATs to a 
fairly narrow class of applications.  that much was clear from the
arguments preceding formation of the group in which any attempt to
get the group to develop a reasonable architecture were quite loudly 
(and occasionally abusively) shouted down.

yes, this group is also trying to accomodate firewalls, but this is due 
to a confusion that firewalls and NATs are similar in function.  if this 
group were concentrating on firewalls rather than trying to justify and 
prolong NAT's existence it would be quite reasonable for it to develop 
an architecture for firewalls.  

the word architecture implies a compromise made in view of the needs of 
various parties.  this does not describe even the typical use of NATs, 
which are NOT a compromise made in view of application developers.
and the word 'architecture' quite emphatically does not describe the 
problems with NAT which motivated creation of this group.

as I said in an earlier message, when a building is destroyed by explosives,
you don't use the word 'architecture' to describe the rubble.  this group 
is trying to salvage something of the rubble created by NATs.  calling it 
'architecture' is misleading and dishonest.

if you want to develop an architecture, you start not by assuming the 
existence of NATs, but by determining what functional layers you need.  
then you can think about what name spaces are needed by those layers
and how those names are going to be mapped to one another, and then
you can start making compromises regarding how many namespaces you
have and the efficiency and currency of the mappings, etc.   if you 
find that the result accomodates NATs, then NATs might end up being 
part of the architecture.  but in order to reach that conclusion you'd 
have to find a reason to discount many years of experience that 
demonstrate that translation of endpoint identifiers creates a royal 
mess.  in fact, no such reason has been found, and the most recent 
experience with NATs (which in fact led to creation of this group)
only serves to reinforce the earlier experience.

the fact that NATs exist is not evidence of architectural soundness,
any more than the fact that drunk driving exists is evidence of
wisdom on the part of the drivers.  both are examples of optimizing for 
short-term gain and ignoring the tragic result that is likely to happen 
in the long term if the practice is continued.  

which is not to say that NATs are as tragic as loss of life.  but we
are trying to build the world's first global general-purpose communications
system.  our work really does have profound effects that extend for 
decades beyond the next RFC or product release cycle.  we have an 
obligation to try to do this work rationally and with some attempt
at foresight.

Keith

p.s. for those who are tempted to dismiss this as a rant - it's not.
it's a serious attempt at a wakeup call.

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 15 May 2001 15:27:05 -0500 (CDT)

On Tue, 15 May 2001, Keith Moore wrote:

> to a confusion that firewalls and NATs are similar in function.

	Here's your first problem. NATs and Firewalls are lumped
together not because they're similar but because they're the two types
of widgets in the way of making a whole lot of stuff work.

	It might be courteous to assume that we're not idiots, Keith.
I shall try to do the same for you, and I apologize if I have not
been scrupulous in that regard up to now.

> 'architecture' is misleading and dishonest.

	This is pure opinion and sloppy rhetoric, and you know it.
You start from the premise that NATs are "like rubble" and then
declare "look! they're like rubble!"

	Such circular reasoning is beneath you.

> in the long term if the practice is continued.  

	Ditto. "NATs are like drunk drivers!"

> it's a serious attempt at a wakeup call.

	I appreciate the effort, but with such inflammatory rhetoric,
you're unlikely to make headway. After reading your postscript, I
deliberately took the time to re-read your essay in detail, and found
very little beyond random shouting. Perhaps I missed something, but
I really did try.

	By the way, the E.164 network is rife with NATs, and seems to
have scaled quite well. Of course, we don't call them NATs, but they're
there, and you use at least one every time you dial an 800 number
or call someone's office using a direct-inward-dial number. I venture
to suggest that the lads at Bellcore (oops, Telcordia, oops SAIC)
think they might just have done a little architecture there.

	Just by way of a counter example.

---

From: Keith Moore <[email-masked]>
Date: Tue, 15 May 2001 22:14:29 -0400

> NATs and Firewalls are lumped

yes, but there's a huge difference:

- NATs are "in the way" because they violate the Internet Protocol
  in some fairly fundamental ways, that (due to IPv4 address space
  shortage) cannot be fixed without moving to another address space.

- firewalls are "in the way" because the site administrator has decided
  (for better or worse) that whatever you're trying to do is not
  compatible with the security policy.  

yes, there is a small conceptual similarity between the problem of
opening up a hole in a firewall and allocating translation state in
a NAT.  and if this group mostly limits itself to defining a way to 
do that one thing, then it probably won't do too much harm.
the problem is when people start assuming that this part of the 
future direction of the Internet, and that it needs an 'architecture'  

this is a short-term hack.  it needs to be kept simple so that it
can be deployed soon enough to be of use.

>         It might be courteous to assume that we're not idiots, Keith.

I don't.  Indeed, the paradox is that so many very intelligent people are, 
acting together, are capable of investing large amounts of effort in 
unproductive directions.

> declare "look! they're like rubble!"

it's an analogy, not a logical argument.   it's intended to persuade
folks who are capable of a bit of intiution and can see the similarity
between NAT-damage and rubble.  it's not intended to persuade folks who 
prefer to establish values and analyze the logical consequences of a 
particular approach with respect to those values.  it's possible to 
demostrate that NATs are a bad idea via that method also, and this 
has been done.  but it takes longer, and anyway logical arguments are 
lost on folks who assume that because NATs exist, they therefore must 
continue to exist.

>         Ditto. "NATs are like drunk drivers!"

that's it.  repeat the hook line, and ignore the explanation contained
in the same paragraph.

> you're unlikely to make headway. 

Indeed, I'm afraid that you're right.  But I suspect there are plenty of 
intelligent people here who do not accept the "NATs are the future of the 
Internet" mantra without question, but who (for whatever reason) do not 
speak up when the group seems to go in that direction.  I'm hoping that 
my speaking up will encourage others to do so also, and that this in 
turn will encourage the group to direct its energies more usefully.

> After reading your postscript, I
> have scaled quite well. 

well, until recently the telephone network didn't have anything like a
source endpoint identifier that was visible to the destination.  and of
course it was designed for a fairly narrow application space compared 
to the Internet.  if all of the applications in the Internet were
client-server, NATs wouldn't be as much of a problem - but in fact an 
Internet that can only do client-server applications is crippled compared 
to one that supports IP.  I'll note that these days, caller line 
identification does tend to preserve addresses end-to-end, and the
caller's source address has long been available at the destination
for 800 number calls.  so I don't think your argument holds.

Keith

p.s. it's not my intent to try to disrupt the group by consuming bandwidth,
and I don't think that I'll persuade many more people by continuing this
line of persuasion.  so I'll probably drop it for now unless I see some
significant point that I can make that hasn't been made recently.