Re: [midcom] Framework draft review

On 15 Jun 2001 at 13:31 -0700, Pyda Srisuresh apparently wrote:
> --- Scott Brim <sbrim@cisco.com> wrote:
> > >    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.  
> >
> 
> 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.

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.

> > >    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?
> > 
> 
> I believe, the word "transparent" means "not noticeable". Transparency
> does  not imply "unchanged". I believe, the usage of the term is 
> appropriate.

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).

> > > 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.
> > 
> 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.

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.

> > >    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.  
> >
> Not really. The sentence reads... "The ALGS are transparent to 
> end-hosts..."

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?

> > >    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.
> > 
> 
> 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.

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?

> > >    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
> 
> 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.

> > 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."
> >
> 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.

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.

> > >    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 ...".
> > 
> 
> 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.

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.

> > >    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.
> > 
> 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?

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".

> > 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?
> > 
> 
> 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.

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 acts in an advisory capacity to a middlebox to
> > 
> > The policy server is the policy authority (again).
> > 
> 
> See my comment earlier.

Right.  Looking for more list discussion.

> > >    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.
> > 
> Right. But, this makes no recommendations. Just lists some of the known
> mechanisms.

OK

> > >    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.
> > 
> 
> 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. 

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

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom