Subject: [midcom] Framework draft review

From: "Melinda Shore" <[email-masked]>
Date: Thu, 14 Jun 2001 09:36:26 -0400

By now you all should have seen the announcement of the
most recent revision of the framework document.  I'm
optimistic that we can get this into last call in time
to meet our deadline, but in order to do that we need
your review and discussion.  Please have a look at it
and post questions, concerns, disagreements, etc. to the
mailing list.

Many thanks,

Melinda

p.s. if you didn't see the announcement, the URL is
http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-02.txt

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

---

From: "Scott Brim" <[email-masked]>
Date: Thu, 14 Jun 2001 14:58:35 -0400

>    detection, security and so forth. Network Address Translator
>    service, on the other hand, provides routing transparency across
>    address realms (within IPv4 routing network or across V4 and V6
>    routing realms). Application Level gateways (ALGs) are used in 

This use of "routing" came up in the NAT WG about 2 years ago, maybe
more.  There was a long discussion and I thought Suresh had conceded.
In any case "routing" is misused here, assuming you mean IP routing.  IP
routing information does not pass transparently through NATs.  I would
change the first instance of "routing" to "forwarding" and delete the
other instances.  

>    The communication between a MIDCOM
>    agent and a middlebox will be transparent to the end-hosts that 
>    take part in the application, unless one of the end-hosts assumes
>    the role of a MIDCOM agent. 

I don't think "transparent" is a good word here.  "Transparent" usually
means communications from the end host are passed through unchanged,
which this framework should not guarantee.  I think you mean "does not
require changes to the end host".  Do you?

>    method performed on a network intermediary that requires application 

For clarity, you should change "on" to "by".

> 2.2. MiddleBox 
> 
>    Middlebox is a network intermediate device that implements one or
>    more of the middlebox services. A NAT middlebox is a middlebox 
>    implementing NAT service. A firewall middlebox is a middlebox
>    implementing firewall service.

At this point, please reiterate that middlefunctions can run on end
systems as well as routers or just about anywhere.

>    Network Address Translation is a method by which IP addresses are
>    mapped from one address realm to another, providing transparent
>    routing to end-hosts. This is achieved by modifying end node 

Same comment as above re "routing".  

>    ALGs are different from proxies. ALGs are transparent to 
>    end-hosts, unlike the proxies which are relay agents terminating
>    sessions with both end-hosts. ALGs do not terminate session with
>    either end-host. Instead, ALGs examine and optionally modify
>    application payload content to facilitate the flow of application
>    traffic through a middlebox. ALGs are middlebox centric, in that

Here you make it clear that ALGs are not "transparent" in the usual
sense.  See suggested fix above.  

>    Policy Server is a management entity that acts in advisory
>    capacity and interfaces with a middlebox to communicate policies

Change "advisory" to "authoritative".  Policy servers don't say "gee, I
don't think you should do that.

>    middlebox. In the case where a MIDCOM agent is not pre-configured,
>    the middlebox will consult Policy Server out-of-band and obtain
>    the agent profile to validate connection setup and authorization
>    of the agent to gain access to middlebox resources. Once an agent
>    is connected to the middlebox, the policy server may at anytime
>    notify the middlebox to terminate authorization for the agent.

First, I'd delete out-of-band.  Out-of-band of what?  The relationship
between middlebox and policy server is purely management.  There is no
other data flow to be out-of-band of.

Second, as discussed on the mailing list, there are two different kinds
of information which can be obtained from a policy server.  You have the
them bundled together.  The first is general authorization and limits
for an agent.  The second is information regarding a particular request
from an agent.  While a middlebox might obtain an agent "profile" either
before or when it first makes contact with that agent, it does not
necessarily obtain complete rules for treatment of requests from that
agent at that time.  The text above requires that (or if it doesn't,
then you don't mention request-specific rules anywhere :-)).  I would
add another sentence, something along the lines of "Policy regarding
treatment of specific agent requests may be obtained when the agent is
first authorized or at any time thereafter."

>    Resources such as a Session-Descriptor may be shared across 
>    middlebox functions. A Session-Descriptor may uniquely identify 
>    a session denoted by the tuple of (SessionDirection, 
>    SourceAddress, DestinationAddress, Protocol, SourcePort, 
>    DestinationPort). An aggregated Session-Descriptor, on the other 
>    hand, may have one of the tuple elements denoted by a regular
>    expression (ex: Any source port). The attributes associated 

There's an unnecessary assumption here about what a "session" might be.
A "session" may be more specific than the exact-match tuple you propose,
as might regular expression descriptors.  You demonstrate this in 5.1,
when you talk about "sub-sessions".  I would leave out everything
between the first sentence and "The attributes associated ...".

>    It is important to note that an agent and a middlebox can be on
>    the same physical device. In such a case, it is not desirable
>    for them to communicate using MIDCOM protocol. They may communicate
>    using a MIDCOM protocol message formats, but using a non-IP based

All true except leave out "it is not desirable for them to communicate
using MIDCOM protocol".  It isn't up to us to judge implementations.  We
do need to note (as you do) that they MAY communicate by any means.

>    A MIDCOM session may be terminated by either of the parties.
>    Alternately, a MIDCOM session termination may be triggered by
>    one of (a) agent going out of service and not being available
>    for further MIDCOM operations, or (b) a policy server notifying
>    the middlebox that a particular MIDCOM agent is no longer
>    authorized for a particular set of sessions any longer.

The policy server telling the middlebox an agent is no longer authorized
does not terminate the midcom protocol.  That's a completely separate
relationship.  Leave this part out.

Do we need to say, now, that the midcom protocol will have reason codes
in it?  I don't think so.

>    (out of band stuff)

I see no scope for an out-of-path agent for JUST control.  As in, the
middlebox says "Hey, Charlie is trying to make such-and-such a
connection, what do I do?", and the oop agent says "do this for him", or
"return this error".  What about, e.g., incoming calls?

>    Agents are pre-registered with a Policy Server for authorization to
>    gain access to a middlebox. 

Well, the middlebox doesn't know or need to know if they are
PRE-registered.  They may be registering moments before they talk to the
middlebox.  Change "are pre-registered" to "are registered".

>    The policy server maintains a list of
>    agents that are authorized to connect to each of the middleboxes the
>    policy server supports. The Policy server has no knowledge of
>    middlebox service and as such cannot help a middlebox with any of
>    the middlebox services and the resource authorization.

No knowledge?  That's an assumption.  We don't know yet what level of
detail will be required by communication between middlebox and policy
server.  

>    The policy server acts in an advisory capacity to a middlebox to

The policy server is the policy authority (again).

>    authorize or terminate authorization for an agent to gain 
>    connectivity to the middlebox. The primary objective of a policy
>    server is to communicate agent authorization information so as to
>    ensure that the security and integrity of a middlebox is not
>    jeopardized. Specifically, the policy server should associate a
>    trust level with each agent attempting to connect to a middlebox
>    and provide a security profile. The policy server should be capable
>    of addressing cases when end-hosts are agents to the middle-box.

See comment way up top about not restricting the policy server to this
limited coarse-grain ability.  If we do, I guarantee that someone will
have to create another kind of policy server.

>    of the key can decipher the message content. Lastly, replay
>    protection is a form of sequence integrity so when an intruder
>    plays back a previously recorded sequence of messages, the
>    receiver of the replay messages will simply drop the replay
>    messages into bit-bucket. Certain applications of the MIDCOM
>    protocol might require support for non-repudiation as an option of
>    the data integrity service. Typically, support for non-repudiation
>    is required for billing, service level agreements, payment orders,
>    and receipts for delivery of service. 

OK, but certain agent communications will need to be idempotent.  We
need to think carefully about our security needs when we get to the
midcom protocol.

>    IPsec AH ([IPSEC-AH]) offers data-origin authentication, data 
>    integrity and protection from message replay. IPsec ESP 
>    ([IPSEC-ESP]) provides data-origin authentication to a lesser
>    degree (same as IPsec AH if the MIDCOM transport protocol turns out
>    to be TCP or UDP), message confidentiality, data integrity and
>    protection from replay. Besides the IPsec based protocols, there
>    are other security options as well. TLS based transport layer
>    security is one option. There are also many application-layer 
>    security mechanisms available. Simple Source-address based 
>    security is the least form of security in a trusted domain and
>    may be permitted to trusted hosts. 

Leave this entire paragraph out.  We're not at the point where we should
be discussing which security mechanisms to use at all.

>    The premise of middlebox operation fundamentally requires
>    stateful inspection of data in the clear. This compromises the 
...
>    However, the MIDCOM protocol removes the need for a middlebox
>    to inspect or manipulate data. This in turn allows applications

Thus, I hope you mean, in the first excerpt, that *current* middlebox
operation requires stateful inspection.

...Scott

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 15 Jun 2001 13:31:00 -0700 (PDT)

> change the first instance of "routing" to "forwarding" and delete the

My use of the term "transparent routing" is consistent with what was 
agreed upon two years ago. You might refer section 2.2 of RFC 2663
for the term and its definition.
 
> require changes to the end host".  Do you?

I believe, the word "transparent" means "not noticeable". Transparency
does  not imply "unchanged". I believe, the usage of the term is 
appropriate.

> For clarity, you should change "on" to "by".

OK. 

> systems as well as routers or just about anywhere.
That is not correct. A middlebox is a netwrok intermediate device
that transits an application - not one that terminates it. As such,
an end-system will not be considered a middlebox.

> Same comment as above re "routing".  
See my comments above. Refer RFC 2663.

> sense.  See suggested fix above.  
Not really. The sentence reads... "The ALGS are transparent to 
end-hosts..."
 
> don't think you should do that.

We had this thread before. "Advisory"  was the term folks on the list
wanted to see happen. 
You might also check with Melinda on this. She was one of the people 
who suggested this. I happen to agree with the usage as well.

> First, I'd delete out-of-band.  Out-of-band of what?  The relationship

The "out-of-Band" here refers to Out-of-band of the MIDCOM protocol. 

> first authorized or at any time thereafter."
What sort of agent requests would require the middlebox to consult
the Policy Server at run time? DO you have a specific example?

We had a discussion on this thread. Somewhat inconclusive.
SO, I didnt add any text that is suggestive or not-suggestive of
the use of Policy Server at run-time by the middlebox.

> between the first sentence and "The attributes associated ...".

I did use different words - "session-descriptors" and "Aggregate session
descriptors". Are you refering to sessions from an application point of 
view (parent sessions, sub-sessions) vs session as an independent tuple
from middlebox view point. My use of the terms above was within the
context of middlebox.

> do need to note (as you do) that they MAY communicate by any means.
OK.

> relationship.  Leave this part out.
I am loosing you. Why do you expect that a MIDCOM session should not be 
terminated when the middlebox is notified by the Policy Server that the
agent is no longer authorized?

> "return this error".  What about, e.g., incoming calls?

The framework allows for Out-of-Path MIDCOM agents. However, the diversion
function and its implmentation is out of scope for the MIDCOM protocol and
this document. The specification and implmentation of diversion function
can be proprietary for the middlebox vendor. The document says this.

> middlebox.  Change "are pre-registered" to "are registered".
OK.

> detail will be required by communication between middlebox and policy

OK. I will remove the following text:
          "has no Knowledge of middlebox Service".

> The policy server is the policy authority (again).

See my comment earlier.

> have to create another kind of policy server.

Again, we had this discussion. I believe, the document reflects it.

> be discussing which security mechanisms to use at all.
Right. But, this makes no recommendations. Just lists some of the known
mechanisms.

> operation requires stateful inspection.

Let me redo the first excerpt as follows.
   The premise of middlebox operation fundamentally requires the
   data to be in the clear as the middlebox needs the ability to
   inspect and/or modify packet headers and payload. 

> ...Scott

Thanks.

cheers,
suresh

=====

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 15 Jun 2001 18:29:55 -0400

> for the term and its definition.

Yes, I know.  I recall there was never agreement, we just stopped
arguing.  The usual IETF story.  But we can do better now.

In everything I said in my mail, I'm trying to get to technical clarity,
with the assumption that this draft *will* become a useful RFC and
therefore had better not confuse anyone.  That's where this comment on
"routing" comes from.

Do you agree that there is a difference between (IP layer) routing and
forwarding?  If not, you should take a look at the specifications and
implemented products over the years which have separated them.  GSMP
comes to mind as a current activity.  "GSMP provides an interface that
can be used to separate the data forwarder from the routing and other
control plane protocols such as LDP." (from
http://www.ietf.org/internet-drafts/draft-ietf-gsmp-applicability-01.txt).
"Routing" refers to the use of routing protocols to do path discovery
and selection.  When you say transparent "routing" you are not being
clear.  As I said, 2663 is not right in its use of the word, and it's
only in there because we gave up arguing.

> does  not imply "unchanged". I believe, the usage of the term is 

NAT is not noticeable.  Would you dare to claim in front of an IETF
Plenary that NAT is transparent? :-) Again, just like "routing" above,
when you use this word you are opening up the possibility of
misinterpretation, which you really don't want to do in a significant
RFC.  Don't use words which other people already use to mean something
different, or if you do, make it clear what you mean (and that you are
right).

> an end-system will not be considered a middlebox.

Yes, sorry, I was thinking about agents and middleboxes (or
middlefunctions) simultaneously when I typed that.  I think it would be
good to reiterate that middlefunctions can run on routers.

> Not really. The sentence reads... "The ALGS are transparent to 

The other sentence says "optionally modify application payload
content".  Let's see what other people in the group think about calling
this transparent.  I know what the purists will say.  Why goad them?

> who suggested this. I happen to agree with the usage as well.

I look forward to hearing what people think.  Discussion on the list
often does not lead to conclusion, until we get to this stage.

I for one can't imagine what "advisory" might mean in practice.  When I
"advise" my children, it means they have the option to discard what I
say.  What's a policy server for?  Communicating policy-based
information to parts of the infrastructure that don't have it.  There
may be other sources of policy which have more authority, but any policy
server is certainly authoritative.  Everyone?

> The "out-of-Band" here refers to Out-of-band of the MIDCOM protocol. 

Out-of-band refers to communication between two entities which are
normally communicating by some other means.  For example, you dial up a
modem connected to your router when you can't reach it otherwise.  But
the midcom protocol is not between the policy server and the middlebox,
it's between the agent and the middlebox.  First you have two different
sets of endpoints (so calling one of the communications flows out of
band makes no sense).  Second, the communication flow you're talking
about is the only one between middlebox and policy server, so again it
can't be out of band of anything.

I believe what you have in mind is that it's not in the main flow of
packets from the endpoint through the middlebox.  There's no need to say
this.  It's clear everywhere that the relation with the policy server is
a network management one, orthogonal to any user session.

> the use of Policy Server at run-time by the middlebox.

As I said, many conversations are inconclusive until we get this close
to last call.  Now's the time we work things out.

OK, here's an example: I have a middlebox which handles communications
for potentially millions of clients, although only a small number
(hundreds?) will be active at any one time.  Each customer is
potentially different enough in enough ways that it would take
significant effort to create aggregate rules for them. I don't want to
store rules for all the millions of them in the middlebox since that
would cost me more in hardware and in any case the initialization time
would ruin my availability numbers.  So I feed the middlebox some
general policy to start with -- such as which agents are authorized for
what, in general terms -- and when it gets a specific connection
request, it queries the policy server which generates the
customer-specific policy on the fly (from info in a database) and
returns it.  See?  Agent-related policy comes first, then
customer-related policy later.  They don't have to, but I want to allow
this possibility for the service providers.

My concern here is that your language explicitly mentions the agent
profile and stops as if that's all there is.  Perhaps you could say
something like ... "gain access to middlebox resources.  A middlebox and
a policy server may communicate further if the policy server's policy
changes or if a middlebox needs further information."

Also, I just noticed that in the last sentence of the paragraph you say
"Once an agent is connected to the middlebox, the policy server may at
anytime notify the middlebox to terminate authorization for the agent."
First, the policy server can terminate authorization for that agent even
before it connects to the middlebox :-).  Second, if you use something
like my proposed sentence above, this sentence is unnecessary because
mine is a superset.

> from middlebox view point. My use of the terms above was within the

From your response I think I failed to communicate, so I'll try again.
I am talking about a "session" in the sense of what a middlebox might
receive requests/instructions regarding, and which the middlebox might
need to maintain state for.  I think it's wrong to presuppose that a
"session" is defined by the tuple you give.  This is a framework.  Let's
wait and see what requirements there are, and what we want to do with
the midcom protocol.

> agent is no longer authorized?

They are two different events.  (1) a policy server tells the middlebox
an agent is not authorized.  (2) the middlebox terminates the session
with the agent.  Event 2 is the real termination, and you've already
covered it in the first sentence -- where you say either end can
terminate the session.  The second sentence, saying the session would be
terminated if one of the parties might stop functioning, is also needed.
But then adding reasons for the first sentence (the middlebox
terminating the session) and putting "Alternately" in front, as if they
were different, is not logically consistent.

Another way to fix it would be just to delete "Alternately".

> can be proprietary for the middlebox vendor. The document says this.

The diversion function is for packets from endpoints, right?  I'm asking
about a relationship where no packets are diverted to the agent.

Let's start with a simpler situation and draw parallels.  If this
doesn't work I'll get more detailed later.  Suppose you're a middlebox.
You get a request from an agent to open a pinhole.  You do so.  Traffic
from the endpoint flows through you.  Endpoint traffic may flow through
the agent but it need not.  If it does not, then the relationship
between agent and middlebox is control only.

OK, now take your out-of-path case.  Suppose traffic comes in and you
signal an out-of-path agent that you want assistance.  According to your
text you then start diverting that traffic to it.  However, you could
just ask for assistance and get information back that you don't need to
divert packets, you can do what you have to for them yourself.  That's
the case I'm asking about, which you have left out entirely, the
parallel with the control-only agent in the previous paragraph.

> > The policy server is the policy authority (again).

Right.  Looking for more list discussion.

> Right. But, this makes no recommendations. Just lists some of the known

OK

>    inspect and/or modify packet headers and payload. 

Some middlefunctions do, some don't.  I'm going to have to think about
whether there's anything in the set we're restricting midcom to which
does not require packets in the clear.  Anybody else?

Thanks ... Scott

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 18 Jun 2001 07:44:19 -0700 (PDT)

> arguing.  The usual IETF story.  But we can do better now.

Well, your recollection is wrong.
The dicussion was conclusive. The definition and subsequent use of the
term were a direct result of the discussion. Check with the IESG and
others that were party to the conversation at the time.

<... stuff deleted>

> different, or if you do, make it clear what you mean (and that you are
Scott - I suggest, you read the draft carefully before you jump into 
innuendo. I will not have a problem reiterating what I said in front
of a plenary, if necessary.  

NAT performs transparent routing. The document does not state that 
NAT performs end-to-end application transparency.

Your refering to this (MIDCOM framework) as a significant RFC implies 
that RFC 2663 and all other RFCs that refered the term are insignificant.
That was uncalled for. I expected better than that from you. 

<... stuff deleted>

> often does not lead to conclusion, until we get to this stage.

Have you looked at the thread? Did the thread seem like it was 
inconclusive to you? (or) Do you consider a discussion conclusive,
only when you initiate the thread?

From your blanket comments, it sounds like you havent looked at the 
thread.

> server is certainly authoritative.  Everyone?

The policy server is not the enforcing entity and hence is not
authoritative.

> a network management one, orthogonal to any user session.

OK. I will delete 'out-of-band'. Thanks.
 
OK.

> like my proposed sentence above, this sentence is unnecessary because
You are right. However, I would still like to keep the sentence, without
the precondition. I.e.,

    The policy server may at anytime notify the middlebox to terminate
    authorization for an agent.   

> were different, is not logically consistent.

I dont see this as altering the meaning.

> Another way to fix it would be just to delete "Alternately".

OK, if that makes it a better read.

> text you then start diverting that traffic to it.  However, you could

During connection establishment, an agent would identify itself as
Out-Of-Path(OOP) to the middlebox. The middlebox does not know that
it wants assistance when it sees some traffic. The middlebox merely
looks to see if there is an OOP agent that controls the session. 
And if there is, the packet is diverted to OOP agent.

> divert packets, you can do what you have to for them yourself.  That's

Presumably, MIDCOM agents monitor only those application sessions that
require the agent to examine the packet payload.

If there is no need for a session to be monitored by an agent, either
an agent is not associated with the session (or) if there was an agent
to satrt with. the agent may simply choose to disassociate itself from
the session.
 
For example, an OOP FTP agent doesnt care to monitor FTP data sessions. 
so, it doesnt insert itself as the controlling agent for the data 
sessions.
 
> parallel with the control-only agent in the previous paragraph.

See my comments above.
 
<... stuff deleted>

cheers,
suresh

=====