Subject: [midcom] policy & duration

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Aug 2001 08:42:42 -0700

In our bar-fob we had a number of issues with policy.  i have promised to
provide some words to help improve the situation.  I hope this does. 
Please note that there is a trivial case hidden in these requirements,
obviating the need for a policy server in many instances.  Thus the
wording allows for a fairly flexible architecture.  Don't understand the
policy conditions?  Go ask the policy server.

This information supersedes section 4.3 of the requirements document and
augments (and will need to be reconciled with) sections 2.9 and 6 of the
framework document.  The wording here will need to be further reconciled
with the policy documents.

Please note that I have not addressed what information is returned to the
midcom agent.  That is an important topic and it needs to be better
understood.

I've also taken a stab at rewriting the duration discussion.  There may be
lots of text we can borrow from the policy people on this subject.

--

4.3  Policy

Each middlebox decision is made based on either configured policy or by
querying a policy server.  While it is not within the midcom rubric to
specify policy configuration methods, the actual policy configuration
itself is important to discuss.

A policy statement consists of one or more policy conditions and a policy
action.[policy]

4.3.1 Policy conditions

Some policy decisions, such as those based on 5-tuple simple access lists
are likely to be made by a middle box.  Other decisions, however, are
likely to be more complex.  Hence we propose a nuanced approach that
allows the policy function to be split.

The midcom agent MUST be able to satisfy informational requirements of the
policy conditions in a policy statement in order for the policy server to
make a decision.  Therefore, a structured exchange that contains those
components MUST occur between the midcom agent and the middlebox, both
query and response.  In as much as a policy server is required to resolve
the policy conditions, a structured exchange MUST also occur between the
middle box and the policy server.

If a middle box acts as its own policy server, it MUST understand any
policy information needed to execute a policy statement.  Put another way,
it MAY discard any policy information that it doesn't understand so long
as that information is not required to make a policy decision.

If the middle box does not understand all of the policy conditions, it
MUST refer the request to a policy server.  It is a configuration error to
have a policy condition that neither the middle box nor the policy agent
can evaluate.

A middle box SHOULD understand, at a minimum, policy conditions that
contain the interfaces involved, protocol, source address and port,
destination address and port, all of which with the exception of protocol
and interfaces MUST be capable of being expressed as a range of values. 
This is the trivial case, necessary to deploy a middlebox without the
assistance of a policy server.

One should expect a middle box that understands a given policy condition
to police it.  However, we do not require it.

4.3.2 Policy actions

Policy actions are those actions associated with a set of policy
conditions in a policy statement.  Examples might be "open a pinhole" or
"return NAT bindings for a given system".

The middle box MUST understand the policy action it is to take.  The
semantics and syntax of each of those policy actions MUST be documented in
a standard.

Hence, policy information SHOULD be encoded in a standard form that is
possible for a middle box to decode, even if it cannot evaluate each
policy condition.

Examples of policy statements can be found in [POLICY].

X Duration

Decisions made by middle boxes MUST have a specific duration.  That
duration MUST include a time interval or a set of actual dates and times,
and MAY include additional termination conditions.  Examples of
termination conditions include an exchange of TCP FINs, the excessive use
of bandwidth, or the exchange of unauthorized content.  A midcom agent MAY
request a change in duration, but the decision of the middle box, like
every other decision will be bound by policy.
--
Eliot Lear
[email-masked]

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

---

From: "Michael W. Condry" <[email-masked]>
Date: Wed, 08 Aug 2001 00:12:02 -0700

Do you think that alignment between OPES policy and MidCom policy
concepts should be applied where appropriate?  If so, should the document
not reflect this?

>lots of text we can borrow from the policy people on this subject.

Michael W. Condry
Director,  Network Edge Technology

---

From: Eliot Lear <[email-masked]>
Date: Wed, 08 Aug 2001 01:05:22 -0700

> concepts should be applied where appropriate?  If so, should the document

In as much as it doesn't could you be more specific?  I don't  understand
the OPES space as well as the middle box space.
--
Eliot Lear
[email-masked]

---

From: "Melinda Shore" <[email-masked]>
Date: Wed, 8 Aug 2001 04:20:29 -0400

> provide some words to help improve the situation.  I hope this does. 

It does, but on ething that concerns me is that you're
now describing "open a pinhole" as a policy action, which
is a major change in how we've been talking about the
middlebox and middlebox commands.  

Melinda

---

From: "Melinda Shore" <[email-masked]>
Date: Wed, 8 Aug 2001 04:24:51 -0400

> From: "Michael W. Condry" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, August 08, 2001 3:12 AM
> Subject: Re: [midcom] policy & duration

> concepts should be applied where appropriate?  If so, should the document

I do think that there's value in trying to keep these aligned,
and it would probably be useful to get some feedback on our 
documents from OPES.  In the interests of keeping our work
moving forward, it would probably be best to regard midcom
and OPES as dating rather than married.

Melinda

---

From: Eliot Lear <[email-masked]>
Date: Wed, 08 Aug 2001 02:14:53 -0700

Melinda,

A firewall is all about policy actions.  A NAT is similar. 
--
Eliot Lear
[email-masked]

---

From: Paul Sijben <[email-masked]>
Date: Wed, 08 Aug 2001 11:47:27 +0200

I agree with Melinda on this one.

The way I see it:
- Policies should be the genric rules of engagement.
- The pinholes are *on demand* things requested by the MIDCOM agents
subject to the policies.

Paul

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

---

From: Scott Brim <[email-masked]>
Date: Wed, 8 Aug 2001 10:57:12 +0100

Nice.  Naturally I have comments.

> querying a policy server.  While it is not within the midcom rubric to

By implication this leaves out the possibility of a middlebox receiving
all policy regarding a particular agent at the time that agent is
authenticated.  That is, the possibility that the middlebox does not
need to refer to the policy server for decisions on individual
transactions at the times of the transactions.  I suggest simply
changing "querying" to "policy received from".

Also change rubric to scope?  Never use a correct word when a
well-understood word will do? :-)

> A policy statement consists of one or more policy conditions and a policy

Is this a new document?

> assistance of a policy server.

There's a hint of directionality in here, which we're still debating.

> to police it.  However, we do not require it.

I don't know what it means, to police it.

> "return NAT bindings for a given system".

Wouldn't the policy action be to *install* such a rule(set), not the
rule(set) itself?

> duration MUST include a time interval or a set of actual dates and times,

Time intervals are under debate (and I hope they lose).

> every other decision will be bound by policy.

Thanks for doing this!

..Scott

---

From: Scott Brim <[email-masked]>
Date: Wed, 8 Aug 2001 11:20:21 +0100

> - The pinholes are *on demand* things requested by the MIDCOM agents

Pinholes are rulesets functionally.  Rulesets are the reification of
policy.

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 8 Aug 2001 07:14:38 -0400

----- Original Message -----
From: "Paul Sijben" <[email-masked]>
To: <[email-masked]>
Cc: "Melinda Shore" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 08, 2001 5:47 AM
Subject: Re: [midcom] policy & duration

> - The pinholes are *on demand* things requested by the MIDCOM agents

However, we should not exclude the possiblity that the middlebox may want to
consult the policy server when the "demand" occurs.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 08 Aug 2001 05:06:40 -0700

Paul,

I seem to have introduced some confusion.  The MIDCOM protocol ought not
require the exchange of policy.  It MUST facilitate the exchange of that
information needed to satisfy policy conditions.
--
Eliot Lear
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 08 Aug 2001 05:35:32 -0700

> changing "querying" to "policy received from".

That's fine.

> > A policy statement consists of one or more policy conditions and a policy

No, I'll send some pointers.

> [...]

First, very basic packet firewalls understand packets and not connections
or conversations.  I don't know that we want to require much more than
that.

Also, I think we remove directionality at our peril.  In an
internal/external communication, the reversing of directional rules on
interfaces would lead to a weakening of enterprise security.

> I don't know what it means, to police it.

as in, ensure the communication proceeds as specified in the request.

> Wouldn't the policy action be to *install* such a rule(set), not the

IMHO Policy is declarative.

--
Eliot Lear
[email-masked]

---

From: Paul Sijben <[email-masked]>
Date: Wed, 08 Aug 2001 14:42:31 +0200

I beg to differ. Pinholes MAY be *described* by rulesets. Policies MAY
ALSO be *described* by rulesets. 

Functionally they are different things.

Paul

---

From: Mark Duffy <[email-masked]>
Date: Wed, 08 Aug 2001 10:21:42 -0400

>Scott Brim wrote:
...
>interfaces would lead to a weakening of enterprise security.

Not only that, but the directionality is already an aspect of the existing
firewall functionality we are providing control over.  I too believe
directionality should be included.

---

From: Scott Brim <[email-masked]>
Date: Wed, 8 Aug 2001 17:09:26 +0100

On Wed, Aug 08, 2001 at 02:42:31PM +0200, Paul Sijben apparently wrote:
> I beg to differ. Pinholes MAY be *described* by rulesets. 

What is a pinhole?  How do you differentiate one pinhole from another,
functionally?  What thing of substance do you deal with to create a
pinhole?  I'm looking for your word for that thing.

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 8 Aug 2001 19:34:24 -0400

----- Original Message -----
From: "Mark Duffy" <[email-masked]>
To: <[email-masked]>; "Scott Brim" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 08, 2001 10:21 AM
Subject: Re: [midcom] policy & duration

> directionality should be included.
I just want to chime in a say expression of direction without a notion of
which side is in or out is not of much use. I think is would be more useful
to define the ingress and egress realms. As I have said before, I believe
assuming all middleboxes will be connected to exactly two realms would be
unwise.

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 9 Aug 2001 05:56:10 -0400

> Mark Duffy:

I think that functionality will be very, very hard to
replicate (i.e. "impossible to do") without introducing
network layer topological and routing information into the
midcom agent.  This is particularly a headache when the
middlebox has more than two interfaces.  Directionality is
implicit in the source and destination addresses in the packet
header and a middlebox with more than one interface already
knows how to route.

Melinda

---

From: Paul Sijben <[email-masked]>
Date: Thu, 09 Aug 2001 15:14:00 +0200

Melinda,

you write:
> midcom agent. 

I am not trying to be cheeky (as they might say here) but that is
*exactly* the can of worms that we opened by starting to work on this. 
I am truly sorfry if you did not realise this before.

If a midcom agent takes charge of a packet flow through a *certain*
middlebox it *must* know the topology of the network (or at least a
sufficiently complete view on it).
  
I know we are getting into a mess but it seems to be the only way to solve
the issues we want to solve.

Paul

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 9 Aug 2001 09:23:19 -0400

> sufficiently complete view on it).

People keep saying "must" in regard to directionality
and exporting topology to the application (beyond 
the location of the middlebox), but they haven't made
a particularly strong case.  What would be helpful would
be a realistic example of a problem that can be solved
no other way along with an indication that the people
advocating this fully understand the implications of
interfacing with the routing system.  The advocacy
of this has been adamant in tone and casual in content,
and given how profoundly this proposal violates basic
IP network architecture principles I believe that it 
needs a bit more respect.

Melinda

---

From: Paul Sijben <[email-masked]>
Date: Thu, 09 Aug 2001 15:44:43 +0200

Melinda,

the issue is clearer when you also address the point that is outside the
scope of MIDCOM, namely discovery of middleboxes. 

If you do not address that problem you have *no* idea where the flows are
going to end up and you can only push a generic policy to *all*
middleboxes in your network rather than send clear commands to *one* box.
Obviously, this does not scale. 

So assuming sufficuently large networks that make midcom deployment
interesting (rather than stuffing all application intelligence in the
firewall), you need to know where the flow is going to hit a middlebox and
(assuming middleboxes with more than 2 interfaces) you need to know where
the flow needs to go to.

This makes the midcom agent party to the network topology information as
far as it needs to know. 

Now, I am OK that we leave the aspect of getting that kind of information
to the agent out of the discussion but we can hardly ignore the larger
architectural impact.  

Paul

---

From: "Mark Pietras" <[email-masked]>
Date: Thu, 9 Aug 2001 09:05:11 -0500

Can someone clarify for me what we're talking about here:

To me, there are two types of multiple-interfaces:

1) I'll call it the ABC-type, where packets arriving on interface A may exit on interface B or interface C (and all the other combinations or a subset thereof)

2) I'll call it the NxAB-type, where packets arriving on the interface A of a pair exit on the corresponding interface B of the pair (and visa-versa).

ABC is a much harder problem to solve than NxAB.  Which multiple-interface type are we discussing?

Mark.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Paul Sijben
Sent: Thursday, August 09, 2001 8:45 AM
To: Melinda Shore
Cc: [email-masked]
Subject: Re: [midcom] policy & duration

Melinda,

Paul

---

From: Mark Duffy <[email-masked]>
Date: Thu, 09 Aug 2001 09:20:43 -0400

At 07:34 PM 8/8/01 -0400, Bob Penfield wrote:
...
>assuming all middleboxes will be connected to exactly two realms would be

Yes, direction alone is not useful.
At a minimum, <interface> is needed along with it.  <Realm> would be even
better (although I don't know that we have a way to name realms).

---

From: Eliot Lear <[email-masked]>
Date: Thu, 09 Aug 2001 07:27:28 -0700

> sufficiently complete view on it).

This statement is not necessarily true.  It really depends as much on
discovery or configuration as anything else.  This is why discovery is an
important topic (albeit perhaps one for another venue).
--
Eliot Lear
[email-masked]

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 09 Aug 2001 17:37:56 +0200

How does a, say SIP proxy, know what the direction of a media stream
belonging to a SIP session will be?

-Jiri

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 9 Aug 2001 14:18:27 -0400

> scope of MIDCOM, namely discovery of middleboxes. 

No, those issues are largely orthogonal.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Fri, 10 Aug 2001 06:57:23 -0400

In general, a mb has no idea what direction anything *wants* to go in.  All
it does is open pinholes etc at the behest of agents.  If the agent, with
the applic. intelligence, can't determine that, then probably no one can --
maybe in that case the agent should just ask the mb for both directions.
From the point of view of the typical mb, a 5-tuple in one direction is
completely different from the same 5-tuple in the opposite direction.  If
the agent via the midcom protocol cannot express that difference, then the
overall system is essentially dumbed-down to that level.  The result would
be reduced security, if packets matching an n-tuple are permitted in either
direction when in fact they should only be permitted in one.  I believe
that would be an unacceptable reduction in security.

-Mark

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 10 Aug 2001 13:49:48 -0500

Since pinholes are associated with the packet filtering functionality of a
middlebox I think the following paragraph from the Benchmark WG defines the
packet filter function well:

"Packet-filtering devices forward or deny packets based on information in
each packet's header, such as IP address or TCP/UDP port number. A
packet-filtering firewall uses a rule set to determine which traffic should
be forwarded and which should be blocked." [RFC2647]

In my opinion, a pinhole is related to a receiving or transmitting
tcp/udp/icmp port number or type code associated with a specific session,
typically with one pinhole (port) associated with an inbound data stream
and/or outbound data stream, relative to ingress or egress interface(s) of
the middlebox.

> Scott Brim
> Sent: Wednesday, August 08, 2001 11:09 AM
> To: [email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Mon, 13 Aug 2001 07:08:29 -0400

>the applic. intelligence, can't determine that, then probably no one can --

That's not really true.

*Clearly* the semantics of a filtering rule are going to be different
when applied to one interface from what they'll be when applied to
another.  The problem is how/whether to bring that information out to an 
application.  I think it's a mistake to assume that software can be
as smart as the network administrator who sits down to manually configure
the box, or that somehow having the agent know the network topology and
the contents of the routing table is equivalent to having a human scribble
the same information on a piece of paper.

It seems to me that the problem here is how to convey the necessary
information to the middlebox that will allow the middlebox to apply
the rules to the correct interface without forcing the agent to become
a participant in the routing system.

Melinda

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 13 Aug 2001 17:26:16 +0200

Mark,

I am still sceptic about agent's ability to figure out the direction.
In the example I gave before agents actually do not know. The only thing
a SIP proxy surely knows is destination address and port number of media. 
(It also might try to guess source IP address, though guessing might fail). 
So it might try to infer direction from the 5-tuple. Doing so is 
however not app-specific and might be done in middleboxes as well.

Consider the following example: two SIP phones which are registered with a company's
SIP server are temporarily in an external network. Which means there is no need
for pinholes at all if they want to speak to each other! Who will figure it out?
I doubt there is something useful for determining the direction what a SIP proxy knows 
a middlebox does not. A middlebox can be configured to guess which IP
addresses is external and which not. Doing the same in every agent 
is lot of work which is perhaps not needed.

This is where my doubts for use of interfaces come from. 

-Jiri

--
Jiri Kuthan            http://iptel.org/~jiri

---

From: Mark Duffy <[email-masked]>
Date: Mon, 13 Aug 2001 13:13:15 -0400

Hi Melinda,

Let me see if I understand what you have said.

I think we are in agreement that "interface" is an important component of
the classifier n-tuple.

I think you are saying that the humans running the show will know which
interface/direction but that it may be hard to get this knowledge into the
midcom agent and/or the mb.

I don't disgree with that, but I suggest the way to deal with it is to have
the operator provision the required information into the agent.  Presumably
the agent must somehow determine which middlebox it needs to talk to about
particular application flows.  This must be determined by some sort of
discovery (out of scope) or by provisioning the agent.  (In fact, how the
agent actually gets the knowledge should not be any concern of midcom!)

It seems to me that for the agent to know that a pinhole needs to be opened
up on a particular interface of a multi-port mb, is not materially
different than just knowing which 2-port mb to use.

-Mark

P.S. I also believe that "interface" should actually be generalized to
"realm" and that direction should also be included, but those points are
somewhat unimportant to the discussion at hand.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 13 Aug 2001 13:41:20 -0400

>I think we are in agreement that "interface" is an important component of

I don't think that I'd agree with that.  I agree that "interface"
is an important (indeed, necessary) component of the routing/filtering 
rules on the middlebox, which isn't the same thing.

This is a difficult problem and there's great potential here for us to
do something very, very wrong.  I don't see any easy answers, myself,
and I'm looking forward to seeing what people come up with in their
various proposals to address this problem.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Mon, 13 Aug 2001 13:49:26 -0400

Hi Jiri,

I would refer you to my response sent  just a few minutes ago to Melinda's
question on this same thread.  I believe that knowing the
realm/interface/direction for the pinhole is just a minor detail of the
larger problem of knowing which middlebox to go to.  I guess the whole
topology thing is a bit of an open issue at the moment.  But it seems clear
to me that the agent must somehow determine which mb to go to.  Whether it
is through discovery, provisioning, or default (only having 1 mb to deal
with), I would venture it is the problem of the agent.

Middleboxes dealing with NAT and/or VPNs are typically dealing with
overlapping (non unique) address spaces and therefore cannot necessarily
determine 'where' particular IP addresses lie.

-Mark

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 13 Aug 2001 14:11:51 -0500 (CDT)

> is lot of work which is perhaps not needed.

	A SIP proxy is as well positioned as anything to figure out
which phone is where. In the simple case, an enterprise (think IP PBX)
SIP proxy can determine with relative ease that:

	- phone A is inside the enterprise
	- phone B is not
	- therefore pinholes from the outside to the inside so and so
	  are needed, and pinholes from the inside to the outside thus
	  and such are needed.

	There are also techniques which allow a SIP proxy, in conjunction
with a set of middleboxes, to steer traffic along desired paths.

	A SIP proxy by its very nature is capable of understanding, at
some coarse level, 'where endpoints live.' With a little additional
configuration information, and corresponding restrictions in network
topology, the SIP proxy may accurately determine which middleboxes
need to be managed, and what directions through them the traffic will
take.

	At the end of the day, figuring out which direction traffic will
take through a middlebox will fall out of the task of determining which
middleboxes need to be managed for a particular call. The Agent, in
general, MUST solve this latter problem, so the former problem is
sort of a non-issue.

	Just to drive home the point: a MIDCOM Agent MUST know something
about network topology to function at all. In many cases, it need not know
more than 'these addresses are inside, everything else is outside' but
it MUST know something. Even a standard firewall needs to know as much,
and for essentially the same reasons.

---

From: [email-masked]
Date: Mon, 13 Aug 2001 14:07:57 -0700 (PDT)

> and for essentially the same reasons.

	I don't think this is quite right, and I think it is important
to get it right.  I'm also still a bit muddle-headed from my flights
back from London, so please understand that this is probably the first
of a series of efforts to get it right, rather than a correct formulation.

NATs manage the exchange of traffic between address realms.

Firewalls manage the exchange of traffic between trust realms.

Historically, realms map onto a network topology, but this is a
function of how they have been implemented and deployed and is not
their essential function.
	
	I think we need to describe the MIDCOM Agent's behavior in
terms of the address and trust realms, rather than in terms of the
network topology onto which those map.  That seem to me to get us
moving to a protocol that will leave routing to the routing systems,
because it won't have built in assumptions about the mapping between
topology and realm.

	I understand that this leaves out the question of how the
mapping between topology and realm occurs, but I think that (very
hard) problem has been ruled out of scope for the group.  I also
suspect that if we discipline ourselves to talk in terms of realm
rather than topology that we are more likely to less to further
hinder the discover problem with assumptions built into the MIDCOM
agents.

			regards,
				Ted Hardie

---

From: Keith Moore <[email-masked]>
Date: Mon, 13 Aug 2001 17:31:25 -0400

> network topology onto which those map. 

I'm very much in agreement with Ted on this.  

Keith

---

From: "Ram Dantu" <[email-masked]>
Date: Mon, 13 Aug 2001 17:08:51 -0500

I understand you do not like the MIDCOM Agent
knowing the network topology. If we do not want
to embed the application-specific knowledge in the
middle box, can you give an example how you think
agent can set the direction ? (using the realm scenario).

For information, I asked the question in the MIDCOM WG meeting
if the discovery is part of the MIDCOM charter,
the answer was NO.

On the other hand, the network topology updates
between Agent and Middlebox may get into more
complex/messy situations.

Ram Dantu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Monday, August 13, 2001 4:08 PM
To: Andrew Molitor
Cc: [email-masked]
Subject: Re: [midcom] policy & duration

			regards,
				Ted Hardie

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 13 Aug 2001 21:26:36 -0500 (CDT)

> I'm very much in agreement with Ted on this.  

	I agree as well, of course. This was made clear when I spoke
of 'inside versus outside' being an example of a perfectly adequate
notion of network topology in some cases, right? The attentive observer
has probably noticed that I am not one to pick nits.

---

From: Mark Duffy <[email-masked]>
Date: Mon, 13 Aug 2001 22:58:38 -0400

This is really interesting.  Wouldn't it be fair to say that realms are
interconnected in a toplology of their own?  (At a higher layer than the IP
network topology.)  And that frequently, middleboxes such as firewalls and
NATs appear at the realm interconnection points?  Not only that but these
middleboxes generally operate on behalf of one of the realms at a
connection point, not both (thus there is an "in"side and an "out"side.
And perhaps the good news about all this is that maybe midcom can get
pretty far without understanding the overall topology of all the realms,
but just the agent statically knowing for each middlebox (or each realm
served by a multipoint mb) which side is in and which is out.

Of course, for agents that are not "near" one specific middlebox this
doesn't help the agent to know which mb a given traffic flow needs to go
through (as function of IP routing)...

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 13 Aug 2001 22:14:59 -0500 (CDT)

> served by a multipoint mb) which side is in and which is out.

	This is all absolutely and 100 percent correct. One winds
up carving the world up into some small set of blobs interconnected
by the middleboxes nearby, and using that as a "sufficiently good"
definition of network topology. This is exactly like firewall
configuration. A "blob" might as well be defined as:

	- an arbitrary set of IP addresses explicitly called out
	- all the IP addresses not in any other set ("the world")

	Well, I agree 100 percent with ALMOST all of the above. It's
actually not very interesting ;) I can't imagine anyone thinks a
middlebox needs to know any more than an "administrative view" of
the network tolopogy.

	Is there anyone who thinks more detailed topology than I
have described above needs to be known by the Agent?

	Is there anyone who thinks that an Agent should not even know
this much?

		Andrew

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 14 Aug 2001 11:31:30 +0200

>        - phone A is inside the enterprise

let me put the question this way: what is the piece of information a SIP
proxy knows and a middlebox does not? (Note that if you infer who is
inside/outside from Contact or SDP you can do it in middlebox too
without having to replicate this logic in every agent you have.)

>with a set of middleboxes, to steer traffic along desired paths.

This is a matter of designer taste, I personally do not desire traffic
to be steered along desired paths. Indeed, I believe that IP model is
a feature, not a bug. Unless I got it wrong, this is not what the WG 
has been charted for.

-Jiri

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Aug 2001 09:39:58 -0400

> determine 'where' particular IP addresses lie.

This is the "Twice NAT" scenario (rfc2663).  When you have overlapping
address spaces, you use a DNS ALG to trap DNS requests and assign a
unique address, which is then used for actual communication with the
remote device.  Therefore, from the point of view of the midcom
protocol, which doesn't care about all that initial setup, an address
always "appears" to be either inside or outside.

(The DNS ALG is interesting, since you could put that in an agent of its
own.)

..Scott

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Aug 2001 09:43:04 -0400

> 	Is there anyone who thinks that an Agent should not even know

Since I don't know what "administrative view" means (it didn't seem to
refer to anything above it) I don't know, but I probably would like
agents to know less than that.  Get out your net and pitchfork and write
your draft :-).

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 14 Aug 2001 10:12:10 -0500 (CDT)

> without having to replicate this logic in every agent you have.)

	The SIP proxy has the contents of the INVITE, which includes
the IP address of the originating phone, and an identifier for the
target phone. The SIP proxy also may have available a database of,
say, all the identifiers of all the local phones and may thereby
deduce that the identifier included in this INVITE refers to a remote
phone.

	The 200 OK contains, in general, similar information but with
"originating" and "target" reversed.

	There are also other header fields which can be useful for
making these determinations, but I am a little hazy on the details of
SIP messages, so I will defer to wiser heads.

> a feature, not a bug. Unless I got it wrong, this is not what the WG 

	Oh, certainly. I didn't intend at all to drag this material in to
the working group. My point is simply:

	- MIDCOM Agents need to know (approximate) topology to
	  function at all
	- MIDCOM Agents may optionally use techniques to steer traffic,
	  thereby to some extent controlling topology
	- with this type of information in hand, a MIDCOM Agent is
	  perfectly clever enough to know (at a high level of
	  abstraction) which way traffic will be entering and
	  leaving a particular middlebox under control.

	Therefore it is probably a good idea to include some notion
of directionality, it is not a pointless exercise and is in fact
quite useful.

	Everything except the conclusion is totally out of scope for
actual working group work.

---

From: "Shai Mohaban" <[email-masked]>
Date: Tue, 14 Aug 2001 08:44:56 -0700

Melinda keeps trying to avoid that topology/direction rat hole - I think
very rightfully so.

I think a direction element is not needed as long is we deal with pure
5-tuple rules: in this case a packet either matches the rule or does not
match the rule and will be forwarded or discarded accordingly no matter what
its direction is and which interface it arrived on.

The real problem starts as soon as we start dealing with more creative
rules. E.g. maybe we would not like a rule like "let all UDP traffic coming
from source IP X port Y go through" to be applied to traffic arriving on an
"external" interface while we would like it to work for some internal SIP
phones. In that case it seems that the topology/direction data piece does
have a meaning.

Maybe one way to overcome this is to use the notion of roles to abstract the
topology/interface information (like in COPS?). If each interface is
assigned a role (e.g. "Internal", "External") then we can assign
rulesets/pinholes to roles instead of to actual interfaces. Would that be
more acceptable? Isn't that how firewalls are configured anyway?

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Melinda Shore
> Sent: Monday, August 13, 2001 10:41 AM
> To: Mark Duffy; [email-masked]

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 14 Aug 2001 11:21:11 -0500 (CDT)

> its direction is and which interface it arrived on.

	Let us imagine I can persuade your SIP proxy to accept an INVITE
from the outside, giving the IP address and port of your internal NFS
server as 'my' media endpoint. Call this 10.0.0.1 port 5723. The SIP
proxy, acting as a MIDCOM Agent, opens a pinhole that says 'anything at
all can send UDP traffic to 10.0.0.1 5723' assuming that this is OUTBOUND
traffic from some internal phone to the call originator (me). But, alas,
there's no way to specify that in the MIDCOM message. Plus, the Agent
doesn't have any notion of 'inside' versus 'outside' so it doesn't even
know that 10.0.0.1 is inside its network.

	Now I, being part of 'anything at all' can send UDP traffic to
your NFS server. No, validating addresses at the interfaces won't work,
because the packets are actually going the right way. Sure, you could
stick specific rules in to protect your NFS server, and everything else.

	Cool, huh!

	To put it another way, this is functionally identical to opening
all your UDP ports up to the world, since opening any specific one can be
accomplished by forging a suitable INVITE.

	Not to put too fine of a point on it: That dog don't hunt.

P.S. I know perfectly well that 10.0.0.1 isn't public, replace it with
your favorite routable address to get the full effect.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Aug 2001 12:30:31 -0400

>stick specific rules in to protect your NFS server, and everything else.

Anybody who relies on a firewall to protect a particular application -
any particular application - deserves what they get.

In the meantime, I hope that people who do have a particular view
of how this all should work are scribbling (or typing) away,
preparing short documents that they'd like to champion when the
time comes.

Melinda

---

From: [email-masked]
Date: Tue, 14 Aug 2001 09:43:28 -0700 (PDT)

Andrew, Mark,
	Every time I try to write something about this, I find myself
falling into metaphors which use topological terms.  At the risk of
sounding like a pedantic twit, though, I still think we have to think
first in terms of address or trust realm and only afterwards in terms
of topology.  You are both right, of course, that the middleboxes
exist to mediate between the two realms.  And as you both know, there
is also clearly a "from" and a "to" in a packet flow, and mapping that
"from" and "to" onto the address realm or trust realm is a function
which must occur in this process.  The question at hand, though, is
should the MIDCOM agent's signal be focused on the topology or on the
realm?
	Let's assume for a second that we use "managed" and "global"
as the contrasting address realms for a NAT.  Using that terminology,
we can imagine MIDCOM agent statements to a specific NAT taking the
form "Map 'global' address x.x.x.x to 'managed' address y.y.y.y for
all ports until timer value reaches DATE XX:YY UT".  Similarly, we can
use "managed" and "global" for the trust realms associated with a
firewall in statements like "Allow 'global' trust realm member
associated with credential X to participate in 'managed' trust realm
with rights of type Y".
	It is absolutely true that in both cases what will likely
happen is that the NAT or Firewall will allow a specific flow to
travel from one interface to another.  The key is that the MIDCOM agent
need know nothing about which interfaces those are; that knowledge
stays inside the middlebox and can be as simple or as complex as the
circumstances require without any consequential increase in complexity
in the MIDCOM agent.
	Again, my apologies if this sounds nit-picky or pedantic.
				regards,
					Ted Hardie

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 14 Aug 2001 19:05:17 +0200

>deduce that the identifier included in this INVITE refers to a remote

Andrew,

I'm glad you came up with these details. I think they show some frequent
misunderstandings on which we should not build.

SIP user identifiers will not help you as they do not relate to user's current 
location. (Note that SIP has no phone identifiers, it has user identifiers). 
For example, you cannot infer from my address "sip:[email-masked]"
or from my athentication id "jiri" on which side of firewall I am
currently located.

So you might try looking at IP addresses in SDP payloads. My point is, 
however, that a SIP middlebox is not able to infer the expected
direction in this case any better than a middlebox is. If a SIP proxy 
knows from SDP payloads that media will flow from A to B, the middlebox
will know it too. So where do you want to build the direction-guessing 
logic? In one middlebox or in ten different agents?

I still have not said there is no scenario in which an agent knows well
what the expected direction is. I simply want to see it first.

>        - MIDCOM Agents need to know (approximate) topology to

It is likely that a middlebox needs to know that. As said, I still have
not seen a reasoning which explains why the agent knows better then
middlebox does.

>          thereby to some extent controlling topology

Please no.

>actual working group work.

I think that any WG's document which are limited to assertations without
a good justification are useless.

-Jiri

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 14 Aug 2001 12:17:31 -0500 (CDT)

Despite the ongoing thread, I think Jiri and I are in almost
complete agreement ;)

> or from my athentication id "jiri" on which side of firewall I am

	Nontheless, a SIP Proxy may well be able to determine that
there isn't a sip:[email-masked] currently located "inside" and thereby
deduce that you are somewhere else.

> logic? In one middlebox or in ten different agents?

	My point is actually slightly different. The Agent in general
has to sort out which middlebox(es), if any, to talk to. Consider a
simple case of an enterprise, if a call is phone-to-phone inside,
the Agent Must Not do a NAT binding on the middlebox connecting
the Enterprise to the outside world. If it did, the INVITE sent
to the target phone (in the next cubicle) would have been re-written
to use an external address for the media back to the originating
phone. This can be solved through squirrelly routing which
hairpins media out through the middlebox and back in, but it's
exceedingly ugly.

	The process of figuring out which middleboxes to talk to
is, it turns out, a superset of the problem of figuring out
directionality.

	There are other, more complex, scenarios which I expect
I could write up demonstrating the same notion for robustly.

	The point is not that it's easy for the Agent to know this
stuff -- it may be very hard, it may only be possible in limited
scenarios -- but rather that it simply won't work if the Agent
doesn't.

	The middlebox is, in the abstract, far less capable of guessing
direction and location of endpoints since information is lost. In the
land of SIP and RTP, all the middlebox gets is a five-tuple with masks
or wildcards -- which contains NO information about the expected
originator of media! Only one endpoint is known, only one can be
specified, the middlebox cannot reasonably compute a "direction"
based on just one end.

	But more generally, a masked 5-tuple (what the middlebox sees)
has potentially far less information than the Agent has available (in
SIP INVITES, or whatever other messages of whatever other protocol
it's managing).

> not seen a reasoning which explains why the agent knows better then

	Actually, mine doesn't have a clue. It knows that port is
named 'open' and that port is named 'secure' and that's pretty much
it ;) DUMB middleboxes, SMART Agents!

> a good justification are useless.

	I concur entirely. It's certainly worthwhile to think through
usage scenarios, and include summaries of them in documents. However,
these are not part of the work proper, just supporting documentation.

---

From: Mark Duffy <[email-masked]>
Date: Tue, 14 Aug 2001 18:39:34 -0400

Err.. I don't know too much about twice nat but I just had a quick look and
I don't think that is what I was getting at.  It looks like twice NAT is
for when public addresess have been reused in a private realm and so there
is ambiguity when such an address is the destination.

My scenario was about a network based middlebox serving multiple
enterprises.  Say each enterprise is separately using network 10.0.0.0/8
and the middlebox wants to provide each with vanilla NAT.  Assume that the
NATs are logically independent of one another so that from the perspective
of one enterprise and its instance of NAT it doesn't matter that the other
enterprises are using NATs within the same physical box.

Now if an agent comes along and wants to talk to the mb about a nat binding
between 10.1.2.3 and 192.1.2.3, the middlebox cannot tell *just from the
addresses* which realm or interface the request relates to.  What it needs
in addition is either an explicit specification of the realm or interface,
or some some higher-level context that makes it implicit which
realm/interface the request relates to.  Either way, it seems to me this
information needs to come from the agent.  If you consider that this is
really a case of a number of logically independent middleboxes in the same
physical box, you may come to the conclusion that this is really just
another case of the agent needing to know *which* middlebox to talk to.

-- Mark

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Aug 2001 02:42:37 -0700

Andrew,

Having a midcom agent know what's inside is easy.  One doesn't need
protocol support for that.  One needs a few configuration entries.
--
Eliot Lear
[email-masked]

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 15 Aug 2001 15:15:04 +0200

>        Despite the ongoing thread, I think Jiri and I are in almost

I sincerely wish we were but I am not entirely sure. Particularly,
I still do not understand *HOW* the SIP proxy would learn whether
a participant is or is not inside. Can you be please more specific
on that?

(More generally, I do not expect applications to have better knowledge
 of IP topology than a router does. Indeed, I think it is a great design
 feature rather than a bug.)

>hairpins media out through the middlebox and back in, but it's

I'm glad you gave this specific example. It shows the choice of putting
direction-guessing-logic in agent. The protocol conversation could then
look like "A: please, allocate a translation from address A in realm
RA to address B in RB. MB: Yes, sir." The opposite choice is to have the
piece of logic in the middlebox. Fictive conversation example: "A: Please,
allocate a translation from A to B. MB: No translation needed."

Our implementation takes the second way. Why? Because we have limited
manpower and do not want to replicate the same direction-guessing-logic 
in every possible agent. 

[...]

>direction and location of endpoints since information is lost. 

Which specific piece of information that may help you to figure out the
direction gets lost?

-Jiri

---

From: Mark Duffy <[email-masked]>
Date: Wed, 15 Aug 2001 09:25:09 -0400

>manpower and do not want to replicate the same direction-guessing-logic 

Jiri, no matter how smart the middlebox is, doesn't each agent need
sufficient topological information that it can determine which middlebox to
make a request of?  Given that the agent must know that, it seems to me to
be a very small increment in knowledge for the agent to know the direction
of the flow relative to that middlebox.

-Mark

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Aug 2001 09:58:35 -0400

> of the flow relative to that middlebox.

There are alternatives which don't require it to have topology
knowledge.  For example discovery mechanisms such as (1) service
location protocol, and (2) anycast.  The C15N BOF kind of fizzled, it
seems, but it indicated some work on discovery done somewhere else.

---

From: "Ram Dantu" <[email-masked]>
Date: Wed, 15 Aug 2001 09:13:13 -0500

It seems to me that it is really a burden on the agent
if it is required to run a middlebox discovery protocol.

I agree that agent can have
some toplogy related information for
controlling the services in the middlebox
but why should it be part of MIDCOM protocol ?

Ram Dantu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Scott Brim
Sent: Wednesday, August 15, 2001 8:59 AM
To: [email-masked]
Subject: Re: [midcom] policy & duration

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Aug 2001 10:24:20 -0400

> if it is required to run a middlebox discovery protocol.

There's no need, you can configure static information, just as in any
other case.  What would you propose instead of a discovery protocol?

> but why should it be part of MIDCOM protocol ?

I didn't say it should.  I must be missing something.

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 15 Aug 2001 16:43:36 +0200

At 03:25 PM 8/15/2001, Mark Duffy wrote:
>make a request of?  

Mark, 

yes, an agent needs to know where to send its requests. (IP address, port number)

>Given that the agent must know that, it seems to me to

The real question for me is from what we infer the realms. Let us assume
we infer it from IP addresses. In a simple case, a table stating 
"192.168.99.* belongs to an internal realm whereas anything else belongs 
to an outside realm" could work. Alas, such a table might be much more 
complex. You would have to build it in every agent (does a SIP proxy
implementor really want to do that?). You would have to configure
every agent (Does every admin want to do that and update all app-agent
configuration files whenever things change?)

To answer your question: one could certainly put this piece of logic in
agents. However, it seems to me more difficult than the other way around. 
It would sound different to me if an application agent could infer realm 
from its application-layer knowledge. I am currently not aware of such 
a scenario -- if someone knows, please post it.

-Jiri

---

From: "Ram Dantu" <[email-masked]>
Date: Wed, 15 Aug 2001 09:51:35 -0500

> if it is required to run a middlebox discovery protocol.

Scott:

Ram:
I am not proposing anything expect static configuration
for this purpose. So, I strongly agree with your static config. proposal.

> but why should it be part of MIDCOM protocol ?
Scott:

Ram:
OK, we agree on this as well.

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 15 Aug 2001 10:14:52 -0500 (CDT)

> protocol support for that.  One needs a few configuration entries.

	The issue of how the Agent knows what's inside, what's outside
and what's in Timbuktu is out of scope.

	There does need to be protocol support for something a little
more than a pure masked 5-tuple. As I have indicated many times, if
there isn't SOME way for the Agent to indicate to the middlebox which
end of the 5-tuple is expected to be (in the simple example) inside,
the middlebox serves no useful function beyond that of a switch, allowing
all traffic to flow in all directions.

	The only reason topology considerations arise at all is to counter
this argument: The Agent should not have to know enough about topology
to supply the inside/outside component to the middlebox

	The Agent DOES know enough. It won't work at all if it doesn't
know enough. Thus, it's not a problem to for the agent to supply annotated
5-tuples basically of the form:

	Inside Address: <stuff> / <mask>
	Inside Port: <stuff> / <mask>
	Outside Address: <stuff> / <mask>
	Outside Port: <stuff> / <mask>
	Protocol: <number>

	This last bit, that the 5-tuples have inside/outside information,
or more generally port information is all I am asking for. Any other
construct that is at least as semantically expressive would also be fine.

	I'm working on my draft, having it reviewed by some local people
before I inflict it on the world.

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 15 Aug 2001 10:23:55 -0500 (CDT)

> Which specific piece of information that may help you to figure out the

	If I send an INVITE to sip:[email-masked], and the Agent is
a SIP proxy implemented to allow early media to work (that is, it
opens a pinhole immediately), the 5-tuple describing the pinhole
has no information about YOU, since we don't know what IP address
you're at. The pinhole description only has data about my phone,
where my phone will receive media, to be exact. The source end is
wildcarded completely.

	If you don't think early media is an issue, then consider
a NAT binding for my phone.

	The INVITE doesn't have your IP address, but it does have the
text 'sip:[email-masked]' which may well be useful for direction/path
guessing. Indeed, during INVITE processing, this text may be the ONLY
information we have available to figure out where the heck Jiri's
media is likely to be coming from, and surely we're not going to send
'sip:[email-masked]' to the middlebox? It is exactly this piece of
information I consider the Agent to have, but not the middlebox.

	Does that help?

		Andrew

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 15 Aug 2001 18:54:30 +0200

At 05:23 PM 8/15/2001, Andrew Molitor wrote:
[...]

>guessing.

Sorry to repeat myself for so many times, but similarly to email addresses
it is difficult to infer users' location from SIP addresses. In fact, I'm 
traveling and using my address [email-masked] in a network which is
completely outside of the network, where hosts are called xyz.iptel.org.

> Indeed, during INVITE processing, this text may be the ONLY

I agree that telling middlebox about [email-masked] is useless. However, 
the example you  gave does not seem to me to demonstrate the 
application-specific ability to guess the from/to realms.

-Jiri

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 15 Aug 2001 16:08:12 -0500 (CDT)

On Wed, 15 Aug 2001, Jiri Kuthan wrote:

> it is difficult to infer users' location from SIP addresses.

	I never said it was easy. I have said:

	- the Agent must solve the location problem, at least
	  approximately, to work at all.
	- the text 'sip:[email-masked]' is available to the Agent
	  and not to the middlebox, and perhaps could help the
	  Agent out.

	It doesn't matter a whit to me how the Agent figures out
where 'sip:[email-masked]', but a SIP Agent has to come up with an
answer to this question or it WILL NOT WORK.

	The answer doesn't have to be good. Often 'on my network'
or 'not on my network' will do fine, but the question of where
Jiri is MUST be answered at least approximately before the Agent can
proceed. This is not a question of good, better, or bad. This
is not a question of elegance and correct factorization. This IS
a question of WORKS versus DOESN'T WORK.

	My oft repeated corollary, which is the only thing I care
about at all is:

	- therefore, an Agent can specify path/direction information
	  to the middlebox, since it has to solve the problem to function