Subject: [midcom] Topology considerations documents

From: Melinda Shore <[email-masked]>
Date: Wed, 05 Sep 2001 10:26:57 -0400

Now available at:
http://www.ietf.org/internet-drafts/draft-molitor-midbox-telephony-topology-00.txt
http://www.ietf.org/internet-drafts/draft-aoun-midcom-agent-information-00.txt
http://www.acmepacket.com/internetdrafts/draft-penfield-midcom-realms-00.txt

Melinda

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

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 5 Sep 2001 11:09:55 -0400

The third one should be:

http://www.ietf.org/internet-drafts/draft-penfield-midcom-realms-00.txt

(-:bob

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 05, 2001 10:26 AM
Subject: [midcom] Topology considerations documents

> Now available at:
http://www.ietf.org/internet-drafts/draft-molitor-midbox-telephony-topology-
00.txt
http://www.ietf.org/internet-drafts/draft-aoun-midcom-agent-information-00.t
xt

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 5 Sep 2001 23:29:52 -0500 (CDT)

> http://www.acmepacket.com/internetdrafts/draft-penfield-midcom-realms-00.txt

	I have quickly perused the two of these I did NOT write, and I
think the three authors are essentially in agreement.

	1) some notion of 'realm' is needed which is roughly a set of
	   IP addresses, except that some additional information is
	   needed since privately addressed realms can easily have
	   overlapping addresses.

	2) The MIDCOM agent needs to figure out which realms are
	   involved in any given session (whatever "session" means).
	   How it figures this out is Out Of Scope.

	3) By implication, the MIDCOM agent can deduce which middleboxes
	   need to be configured and which interfaces (or equivalent)
	   are involved.

	4) It is therefore possible -- and also for security reasons
	   necessary -- to add to a pure 5-tuple some information about
	   interfaces expected to receive and transmit traffic belonging
	   to the session.

	How this additional "interface" information is managed is
up for grabs. You can apply a 5-tuple/NAT-binding/etc TO and interface,
or you can specify interface information IN the 5-tuple/NAT bind/etc.
There are probably more ways to do it.

	The terminology is all variable at this point, though I think
Bob Penfield and I used the word "realm" in essentially the same way.

	Does this agree with what other people see in these documents?
(in particular, of course, the authors!)

		Andrew

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 6 Sep 2001 08:47:53 -0400

I agree that we four gladiators are in agreement. I think Cedric & Sanjoy's
usage of the term "realm" is consistent with mine and Andrew's. Realm is the
right term to use. The term "interface" can be too specific or not specific
enough depending on the configuration of the middlebox, and it falls into
the category of "too much information" as far as exposing topology to MIDCOM
agents. The realm concept should be incorporated into the MIDCOM framework.
I think it is already a part of the framework, it is just not explicitly
called realm.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Scott Brim <[email-masked]>
Date: Thu, 6 Sep 2001 13:30:31 -0400

Realms as a concept are useful.  We speak of addressing realms (which
have address spaces), and so on.  The idea of instantiating these kinds
of realms in any protocol disturbs me greatly.

Bob proposes adding a realm ID to the midcom protocol.  The realm ID
would be for a "natural" space delineated by NATs/Firewalls.  It would
be unique among all the different realms a particular realm spoke to.
If I understand correctly, it would not be carried in any particular
application protocol, but would be derived from the e.g. TLS connection
over which an invitation or whatever arrived.  

The other proposals seem to assume a realm identifier gets determined
somehow.  Whether it does or not, if you instantiate the *concept* of
realms like this ...

You need a universal namespace.  Why universal?  You only need to be
distinct from those you communicate with, right?  Well, it would be
difficult to be sure that your realm ID was unique among every one you
would have an association with, especially because a lot of SIP proxies
will be in casually run organizations.  Difficult enough that global
uniqueness would be required to avoid overall pain.  This isn't like
routing, where you only communicate with your contiguous peers, so you
can use "localized" and/or "temporary" realm identifiers.  You never
know when you're going to want to establish an association across half
the Internet.

There is no other universal namespace at this level that I can think.
Even AS numbers are not unique, since some are temporary/local.  Some
people with NATs/firewalls don't even have temporary AS numbers.  So AS
numbers are out.  Domain names are not topologically indicative, so
they're out.  This kind of namespace is completely new.  Well, we used
to try to have globally unique ASs and don't try anymore because we
don't need them to be. 

What happens when realms split and merge?  How will an agent know when
two endpoints are inside and outside during splits and mergers?  There's
a strong chance for misconfiguration here, and you're betting the
security of your network -- or your customers' networks -- on
configuration to a greater extent than before, since errors won't become
obvious until they are a security problem.  

Someone has to administer the namespace, as organizations do for domain
names, and that will cost money.  And politics!  Man, the politics alone
scare me.

"Realms" for different applications cannot be depended on to be
congruent.  What do you do when you have different kinds of middleboxes
with some intermediate nodes like web servers?  So, if realms for
different applications turn out not to be congruent, or if we want some
more flexibility in the unknown future, you would need not just one
globally unique identifier, but one for every class of agent!  Setting
up even the possibility of that happening is not good architecture.

If you do carry realm IDs in application signaling, then you're going to
have to change every existing application signaling protocol for which
an agent might want to speak Midcom.

OK, suppose you avoid globally unique identifiers by saying you'll just
configure every agent with every possible peer that it should consider
"inside".  First you have to be sure that you'll always be able to
determine whether a peer is inside or outside.  That puts a lot of
restrictions on how we develop our application signaling in the future
(and I'm not even sure we could make that claim today).  Second, you
still have a serious synchronization problem, a serious maintenance
problem for service providers, and the possibility of opening up
unnoticed security holes.  

So globally unique identifiers feels like it has all sorts of problems,
and implicit classification of peers is also painful.

If I've understood how you all want to use realm identifiers, then --
I'm sorry to say, really -- I don't think this is a path we or the rest
of the IETF will want to progress down -- it's just not good scalable
engineering.

I have some ideas which I wasn't able to get written up before the
deadline, but I will ASAP.  The WG established the deadline as a tool
for making progress.  I don't like saying it but I don't call this
progress yet.  If we say the working group has no choice but to accept
what came in before the deadline, we're treating procedure as sacred and
forgetting that utility of the outcome is the only useful measure of
success.  Anyway, I'm writing now.

..Scott

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 6 Sep 2001 14:36:27 -0400

I see a realm names/identifiers as belonging to a particular middlebox or
group of middleboxes. Relationships between MIDCOM agents and middleboxes
will be based on business and/or contractual relationships and will not be
established willy nilly half way across the Internet. Middleboxes that do
firewall and NAT live at the borders of networks. A midcom agents that
control those middleboxes will live in the networks that the middleboxes are
the at the border of.

The realm naming scheme, if they need realms at all, will be worked out
between the parties that own the networks. There is no need for a universal
namespace for realms.

How the midcom agents learn the realm names is not a midcom problem. It
could be through static configuration or some discovery protocol between the
entities sharing that realm naming scheme and namespace.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 6 Sep 2001 15:39:52 -0500 (CDT)

For my money, "realm" is a useful construct to think about,
but it is not a MIDCOM construct. My way of thinking of this is
that Agents will have "some notion of realms" which the Agent will
use to compute some notion of or similar to interfaces. It is this
notion of interfaces that appears in MIDCOM messaging.

	It is, in my opinion, ludicrous to propose that a middlebox
should possess anything resembling global knowledge. The whole
point is to make a DUMB middlebox, that could easily know nothing
more than what physical interfaces it has, and internal policy/NAT
state.

	In particular it might very well not have any concept of
IP routing. Also, by implication, it knows nothing of realms. If
you equate a realm to "the stuff off that interface" why not call
a spade a spade and admit that we're talking about interfaces, not
realms!

	In summary:

	realms are, roughly, the coarse notion of network topology
	used by the AGENT to compute interface information. This
	interface information is communicated via MIDCOM to the
	MIDDLEBOX, which itself may well have not concept of realm.

		Andrew

---

From: Mark Duffy <[email-masked]>
Date: Thu, 06 Sep 2001 17:16:50 -0400

My understanding is similar to what Bob has stated.  The realm identifiers
only need to be unique within the middlebox that the midcom request is
directed to.   The point of all the gladiators' drafts is (I think) that
the agent must know which middlebox it needs to send a particular request
to, and must know which of the realms connected to that middlebox to tell
the middlebox each pinhole/etc. request relates to.

-Mark

---

From: Mark Duffy <[email-masked]>
Date: Thu, 06 Sep 2001 17:34:42 -0400

Andrew, yes there are middleboxes that want to be told what interface a
pinhole/etc should be applied to.  A traditional 2-interface firewall comes
to mind.  But there are other middleboxes that have more complex models --
for example, multiple interfaces into each administrative realm, or
multiple realms reached via the same interface.  By using the more abstract
concept of realm rather than interface, one has a model powerful enough to
manage both these types of devices, not just the simpler one.  --Mark

---

From: Scott Brim <[email-masked]>
Date: Thu, 6 Sep 2001 17:45:05 -0400

> the middlebox each pinhole/etc. request relates to.

How will a particular agent find out what realm identifiers a middlebox
is using to name its attached realms, and whether those realms are
inside or outside the trust/addressing boundaries?  Configuration?
Again you have management problems and potential security problems (as
already discussed -- I'd rather not repeat it).  Remember there are
users out there, and we must not, in any way, insist on their getting
configuration right.  How about ... a global namespace and modification
of all application signaling?

Do you have any other alternatives?

Pardon me for being short, it's late.  I'm hoping you see what I'm
saying without my having to elaborate.

---

From: Scott Brim <[email-masked]>
Date: Thu, 6 Sep 2001 17:52:24 -0400

> notion of interfaces that appears in MIDCOM messaging.

Just so you notice, this is different from what Mark just said, which is
that the notion of realms is local to the middlebox (not the agent).

Right, I saw that you said that.  So, how does the agent classify an
interaction into a realm?  Well, I hesitate to repeat what I sent before
but I don't see any scalable *and* manageable way to do it.  I'll repeat
myself tomorrow :-).

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 6 Sep 2001 17:04:53 -0500 (CDT)

> but I don't see any scalable *and* manageable way to do it.  I'll repeat

	Oh, I concur completely. This is a hard problem to solve.

	Luckily, it's totally out of scope for MIDCOM so we don't
have to worry about it, at least not directly. At any rate, this
is how I see the scope. I certainly remember nothing about being
chartered to invent either a global realm namespace or a (local)
realm naming convention.

	I maintain that the MIDCOM protocol needs to adorn 5-tuples
with interface identifiers or equivalent, and that the realm discussion
and toplogy discussion serves to prove that (in addition to providing
useful context). At the end of the day, though, the only in-scope
result is 'hey, interfaces!'

	If you REALLY want to use realm names instead of interface
names in MIDCOM messages, please provide a real, useful example
where this would be

	a) useful
	b) not isomorphic to interface names

		Andrew

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 6 Sep 2001 17:55:37 -0400

For any given implementation, realm ID and interface ID could be the same
thing. To the agent it is just a handle representing the realm. The
middlebox knows exactly what that handle means. It might mean a specific
interface, a group of interfaces, or one of several VLANs on a specific
interface.

(-:bob

---

From: Mark Duffy <[email-masked]>
Date: Thu, 06 Sep 2001 18:29:01 -0400

At 05:04 PM 9/6/01 -0500, Andrew Molitor wrote:
...
>	b) not isomorphic to interface names

I will argue that "interface identifiers" are going in the right direction
but are not general enough.  Here is one counterexample that actually
exists, it is not just something I have invented to argue this point.

Picture a carrier-based middlebox that can provide a firewall service
independently to multiple enterprises.  Assume that it is possible that
multiple enterprises A, B, and C may be connected to this middlebox *via
the same interface* of the middlebox.  A certain pinhole is to be opened
for packets being sent to enterprise A, but not for those forwarded to B or
C.  To control this via midcom, "interface" is not a powerful enough
criterion.  "Realm", which is more general, is.

>	a) useful
    Yes, since it allows midcom to control this firewall

>	b) not isomorphic to interface names
    Yes, because in this case realm::interface  is many::one

-Mark

---

From: Mark Duffy <[email-masked]>
Date: Thu, 06 Sep 2001 18:45:45 -0400

Hi Scott, see comments interspersed below...

At 05:45 PM 9/6/01 -0400, Scott Brim wrote:
>is using to name its attached realms, 

MD-> I don't know for sure.  Probably by configuration.  The question
doesn't bother me too much because I think the *same* question would need
to be asked if using interface identifiers rather than realm identifiers.
I.e. How does the agent know how the middlebox names its interfaces, and
which ones are connected to where?

>                                      and whether those realms are

MD-> Again, the agent needs to know whether the 'sides' of the middlebox
are in/out of a given trust boundary, whether those 'sides' are denominated
as "interfaces" or "realms".  And the agent needs to communicate that to
the middlebox through midcom.  It's just a matter of the granularity with
which the world is broken into realms by the middlebox.  I don't think the
agent should care what that granularity is, other than using the
appropriate syntax to name the realms over the wire in the midcom protocol.

>of all application signaling?

MD-> Obviously, global namespace and modification of all application
signaling is out of the question.  I do think the agent needs to know the
names of *something* (interfaces/realms/sides/domains/whatever) that the
middlebox works against, and be able to specify them to the middlebox.  I'm
just trying to prevent midcom from embodying an assumption that for all
middleboxes, domain==interface.

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 6 Sep 2001 17:43:54 -0500 (CDT)

>     Yes, because in this case realm::interface  is many::one

	What an excellent example!

	How would a middlebox identify the source and target realms
of a specific packet? I can think of some schemes using IP addresses
or the various and sundry Tags which can be shoved in packets. I
am happy to stipulate that this is a middlebox specific problem,
and we may assume that every packet is Somehow classified, and
has a Source Realm and a Target Realm attached to it before policy
is applied.

	One COULD make the case that this is just a fancied-up
interface, but I think it's fair to abstract it and call it something
else.

	I tend to think of realms as bigger, less local objects.
E.G.

   Realm A -middlebox-+
                      |
             [ big network ]-- middlebox --[ big network ]-- Many Realms
                      |
   Realm B -middlebox-+

	In this case, the middlebox in the center doesn't care
about Realm A versus Realm B, though an Agent trying to manage all
the middleboxes for a SIP call might.

	The middlebox in the center only cares about "Realm Everything
to the Left" and "Realm Everything to the Right" and THESE are the
indications that need to get sent to it over MIDCOM. These are
also the "Realm" names that get attached to packets as they
pass through that middlebox.

	Would it be just too awful to use phrase "Global Realm" and
"Local Realm" where this distinction is needed?

		Andrew

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Sep 2001 09:41:55 -0400

> should possess anything resembling global knowledge.

It is, in my opinion, ludicrous to propose that you can fix the problems
with NATs without creating a global name space with a unique name for 
each realm
   
This doesn't mean that the NAT needs to have anything like global 
knowledge, just that it knows the names of each of the address realms 
to which it connects.

Keith

p.s. the term "middlebox" is confusing here since it's only those 
middleboxes that do NAT that are causing this problem.

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Sep 2001 09:44:58 -0400

> directed to.   

True.  But since you cannot anticipate the names of each of the realms 
to which you might someday want to connect, it seems wise to design a
naming scheme which avoids conflicts.  Global assignment is one way to
do this; generating random names from a large name space is another.

Keith

p.s. I'm tempted to suggest that realm names should be IPv6 prefixes.

---

From: Mark Duffy <[email-masked]>
Date: Fri, 07 Sep 2001 09:53:00 -0400

Hi Andrew, see below...

>has a Source Realm and a Target Realm attached to it before policy

Agreed that how the middlebox idientifies the source and target realms (and
hence which policy to apply) for each packet is a MB issue, out of the
scope of midcom.

>interface, but I think it's fair to abstract it and call it something

I'm not sure whether to interpret the above as agreement that the midcom
protocol should support specifying to the mb the more general concept of
realm rather than only that of interface?

>the middleboxes for a SIP call might.

Your picture seems completely valid to me, but here is another picture:

  Enterprise A ---
                  |--- middlebox ---- Internet
  Enterprise B ---

. In this picture the middlebox is serving multiple realms, A and B.
. Assume that the middlebox is also a router.
. A and B may be using overlapping private addresses.
. A and B must have separate security policies, NAT bindings, pinholes, etc.
. Agent sending midcom commands to the mb with only the 5-tuple as the
classifier criteria is insufficient -- it also needs to specify whether
each rule is to be applied for A or for B.
. If the middlebox/router uses one logical IP interface to connect to A and
another to connect to B, then "ip interface" IS sufficient to qualify which
realm a particular midcom command applies to.
. HOWEVER, if the middlebox/router discerns A and B at some other
granularity than the ip interface via which they are attached, a more
general specification of realm is needed.  Examples of different
granularities at which a mb might distinguish its attached realms:
  - everything reached via some set of multiple ip interfaces
  - everything reached via a specific next hop router
  - everything reached via a specific physical port, regardless of logical
interface
  - etc.

>pass through that middlebox.

True.  I think the question at hand though is what constitutes a realm from
the perspective of a generalized middlebox, and how do we specify realms in
the midcom protocol in a way that is generic enough.

>"Local Realm" where this distinction is needed?

Not too awful at all, but in some cases of course the middlebox is
connected to more than 2 realms.  I think we have already agreed that we
need to support that.

---

From: Mark Duffy <[email-masked]>
Date: Fri, 07 Sep 2001 10:38:14 -0400

>p.s. I'm tempted to suggest that realm names should be IPv6 prefixes.

Keith, I do not see why naming conflicts should arise here.  The realm
identifiers we are speaking of here are sent by an agent to a specific
middlebox.   These realm identifiers are interpreted only by the middlebox
to which they are sent.  If we used interfaces rather than realms, the
story would be the same: the interface names would only need to be unique
within the particular middlebox to which they would be sent.

One way of looking at this is that the realm names are in a sense qualified
by the address/name/whatever of the middlebox (which address/name/whatever
is presumably unique over a "sufficient" area).   So the effective realm
names are actually something like
 { <middlebox-ip-address> <locally-significant-realm-name }  

--Mark

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 7 Sep 2001 09:44:35 -0500 (CDT)

> realm rather than only that of interface?

	I agree, I am just unsure of what to NAME the more general thing!

> connected to more than 2 realms.  I think we have already agreed that we

	Oh, absolutely. The point is that, to my way of thinking,
a particular middlebox "sees" potentially fewer realms than an Agent
does. MIDCOM communications need to be in terms of the ones the
middlebox sees, since the middlebox is the Dumb End of the protocol.

	The stuff that appears in MIDCOM messages should therefore
be "Local Realms"

		Agent

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Sep 2001 10:46:08 -0400

> to which they are sent.  

they're shared among the NATs and the agents.  there may be multiple NATs
and multiple agents that need to know about the realm names.

> If we used interfaces rather than realms, the

interface names are slightly less general, particularly across equipment
changes.  

>  { <middlebox-ip-address> <locally-significant-realm-name }

it's not safe to assume that the NAT has a unique IP address, even
within the set of realms which are of interest.

Keith

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 7 Sep 2001 11:37:52 -0400

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Mark Duffy" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; "Bob Penfield"
<[email-masked]>; "Scott Brim" <[email-masked]>;
<[email-masked]>
Sent: Friday, September 07, 2001 10:46 AM
Subject: Re: [midcom] Topology considerations documents

> within the set of realms which are of interest.

If that NAT middlebox can talk MIDCOM, I would think it has to have an IP
address for the MIDCOM agent to send messages to.

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 7 Sep 2001 10:50:58 -0500 (CDT)

None of what I am about to say is MIDCOM related, for which I
apologize in advance.

	I think the idea of globally naming Global Realms is a great
idea. It's also completely out of scope for MIDCOM, and I don't think
it's at all necessary for MIDCOM, which can treat Realms as not
much more than a cookie that the Agent and middlebox agree on.

	If we stipulate that:

	1) IPv4 has scaling problems at a certain point.
	2) An approach to dealing with this would be to devise a
	   way to interconnect IPv4 networks at a higher layer,
	   just as Ethernets are interconnected using IPv4

	Then we can rename NATs "Inter-Realm Routers" and achieve
great happiness.

	Given Realms and a global naming scheme for them, together with

	a) a discovery/mapping service, probably a little like DNS
	   but carting around realm naming and "coarse topology"
	   information.
	b) a protocol like MIDCOM for setting up end-to-end paths
	   by adding net-to-net bindings (i.e. NAT Bindings) to
	   Inter-Realm Routers (i.e. middleboxes)

	we can back into a sort of disney version of Noel Chiappa's
nimrod work that has the advantage of being built ON IPv4 instead
of replacing it, which is wicked cool.

	Nimrod-like solutions have much nicer scaling properties than
IPv4-like solutions like, say, IPv6 (which is arguably no more scalable
than IPv4 -- just BIGGER).

	I'm so glad to see that Keith is finally on board the whole
NAT, err, Inter-Realm Router, thing!

		Andrew

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Sep 2001 11:56:48 -0400

> address for the MIDCOM agent to send messages to.

yes, of course.  but to restate - that IP address might not be 
globally unique, and the same IP address may well be reused within 
the set of realms which are of interest.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Sep 2001 14:16:50 -0400

>         Then we can rename NATs "Inter-Realm Routers" and achieve

ah, no.  either the resulting inter-network has a global address
space (in which case you may as well punt midcom and use IPv6), or 
the resulting inter-network will be overly complex and brittle
and only support a narrow range of applications.

it may be that the latter network has better scaling properties.
but what's the point of a scalable network that doesn't support apps,
or that does so only by requiring apps to understand and explicitly
deal with network topology?

Keith

p.s. I'm glad to see that midcom is realizing that a global address
space is essential :)

---

From: Scott Brim <[email-masked]>
Date: Sun, 9 Sep 2001 18:08:54 -0400

> entities sharing that realm naming scheme and namespace.

This sounds a lot like economics discussions which begin with "First, we
assume a perfect market" :-).  Think about what you're assuming!

Static configuration?  See what I wrote about the management headaches
and the possible security holes (which you wouldn't know about until
after a violation occurred).  Imagine an ISP with thousands of edge
boxes that it needs to manage through these changes.  

Discovery protocol?  For that to work, everyone would need to have
something discoverable.  You would need the world's only globally unique
namespace, would require even casual users to get a name in order to
make a call, and then you would need the discovery protocol itself -- or
you would have to change every application signaling protocol in the
Internet.  More arguments about this later.

..Scott

---

From: Scott Brim <[email-masked]>
Date: Thu, 13 Sep 2001 13:12:34 -0400

> which ones are connected to where?

That's not the point I was making.  Interface IDs and realm IDs are
equally ugly.  At least with interface identifiers it's a purely local
problem.  If you try to use a realm abstraction, it quickly becomes a
non-local problem.  I can go through that again if you like.

> the middlebox through midcom.  

No.  The agent does not need to know those things, as long as the
middlebox knows them.  The agent can (as we proposed in our draft) tell
the middlebox a couple details and let the middlebox use its intelligence
to make the decision.  The middlebox is in the topologically appropriate
place to make the decision, while an agent is potentially nowhere near
it.  In order for the agent to have this kind of intelligence you need
to add complexity to support it.

> It's just a matter of the granularity with

Our draft is about the agent only needing to know just what it already
knows from the existing Internet infrastructure -- IP addresses for
whatever it is already communicating with.  It does not need to know any
names of any new abstractions, nor does it need to know the details of
configuration of the middlebox.

---

From: Scott Brim <[email-masked]>
Date: Thu, 13 Sep 2001 13:12:46 -0400

> chartered to invent either a global realm namespace or a (local)

You cannot propose a solution in a vacuum.  You have to consider the
implications.  We've said, for example, that middleboxes that divert
packets are out of scope, but we are not simultaneously requiring the
existence of such things.  The midcom requirements so far have very
clean, limited implications for the rest of the world.  They don't
assume any kind of infrastructure we don't already have.