Subject: [midcom] Framework last call

From: Melinda Shore <[email-masked]>
Date: Fri, 20 Jul 2001 13:19:29 -0400

The midcom framework document (available as 
http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-03.txt 
is ready for working group last call.  Last call closes Friday, 3 
August 2001.  Please send all comments to the midcom mailing list.

Thanks,

Melinda

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

---

From: Mark Duffy <[email-masked]>
Date: Fri, 20 Jul 2001 15:33:41 -0400

Hi, I have some comments and suggestions on
draft-ietf-midcom-framework-03.txt.

.  The document should make a clear statement on what in a packet the
middlebox is expected to understand and be able to classify on.  I hope
this is only IP header fields and TCP/UDP port numbers.  (Thus the
middlebox would be "IP-aware" and "TCP/UDP-aware" but not
"application-aware".)  There was the long discussion on the maiiling list
about being BEEP-aware but I'm not sure what the consensus was (if any).

.  The document should make a clear statement on what in a packet the
middlebox may modify.  My understanding is this should be only the IP
header and TCP/UDP port numbers (and associated checksums).  The
requirements draft states this in section 4.1 although it is vague about
what constitutes the "packet header".  My understanding is only the Midcom
Agent should modify any higher layer information.

.  In section 1. Introduction, 1st paragraph, it says "The discussion scope
of this document is however limited to middleboxes implementing Firewall
and NAT services only."   This improperly (I believe) excludes middleboxes
implementing other services but doing so outside of the midcom framework.
I suggest rewording this as "The discussion scope of this document is
however limited to firewall and NAT middlebox services."

.  In 2.1 it says "A middlebox function or a middlebox service is an
operation or method performed by a network intermediary that requires
application specific intelligence for its operation."   I propose replacing
"requires application specific intelligence" with "may require application
specific intelligence".  For example, if a firewall device were set up to
pass all TCP packets but drop all non-TCP packets, that would not require
application specific intelligence.  Would it not however still be
considered a middlebox function?

.  2.4 -- NAT.  "Network Address Translation is a method by which IP
addresses are mapped from one address realm ..."   I suggest this should
mention port numbers as well i.e. "Network Address Translation is a method
by which IP addresses and TCP/UDP port numbers are mapped ..." 

.  In 3.0 beneath the figure it introduces the concept of SessionDirection.
 The implication I get is that this identifies either "outbound" or
"inbound".  This may become limiting.  For example, in a service provider
based middlebox there may be "in" sides associated with each customer of
the provider.  While this could be modeled as many logical middleboxes each
with an inside and outside, it would be much more flexible for the midcom
architecture to provide for this.  One way to do this would be to enlarge
the Session-Descriptor tuple to also specify the applicable interface.
Another way would be to allow for specifying in the tuple which realms the
packet is moving from and to (although I don't know of any existing way to
name and refer to these realms).  (Section 8.1 relates to this somewhat.)

.  In 3.0 below the figure it states "The attributes associated with a
Session-Descriptor may be specific to the individual middlebox function."
Can you please clarify the meaning of this?  What *are* the "attributes"?
Are they the what-to-do-when-a-packet-matches-this-session-descriptor stuff?

.  In 5.0 it states "In-Path MIDCOM agents are entities that have a native
role in the path of the application traversal ... idependent of their
MIDCOM function."   Why must they have a native role?  This would pretty
much eliminate using midcom for any applications that don't already employ
such devices.  I don't see any reason to exclude agent devices placed there
solely for the purpose of being an in-path Midcom Agent.  I propose we
revise that sentence to read: "In-Path MIDCOM agents are MIDCOM agents that
are located naturally within the message path of the application they are
associated with."  Or strike the sentence entirely since this is just
repeating the definition presented in section 2.8.

.  In the last paragraph on Page 10 (section 5.0) it uses the words
interjecting/interjected.  Those should be replaced by
intercepting/intercepted.  (It is talking here about the agent receiving
and manipulating packets already in-flight, not about introducing new
packets.)

.  In section 6.1: "Simple Source-address based security is the least form
of security in a trusted domain and may be permitted to trusted hosts."  It
doesn't matter how trusted the hosts are if someone can spoof them!  I
propose changing the wording to "Simple Source-address based security is a
minimal form of security and should be relied on only in the most trusted
environments where those hosts won't be spoofed."

.  Section 6.2 -- registration.  It is not clear what "registration" means
in the midcom context and I think this should be clarified in the document.
 By my read it refers to configuring information about the agent into the
middlebox or entering similar information into the policy server(s).  If
this is what it means than this is probably something done *on behalf of
the agent* by some operator, rather than *by the agent itself*.  If this is
the case it doesn't make sense to me that the agent would "deregister"
itself as described in the last paragraph of 6.2 -- that seems to relate to
breaking the current session.  

We need to define "registration" and how it relates to one or the other of
 - provisioning of authorization information, or
 - establishment of an authenticated session between an authorized agent
and a middlebox.

Section 6.2, "Coupling MIDCOM agents with the middlebox resources requires
a means of reflecting that into the resource description table of the
middlebox. In the case of a firewall, for example, the ACL tuple may be
altered to reflect the optional ALG presence.  The revised ACL may look
something like the following.
   (<Session-Direction>, <Source-Address>, <Destination-Address>, 
   <IP-Protocol>, <Source-Port>, <Destination-Port>, <ALG>)
Can you please clarify this?  Aside from the <ALG> that tuple appears to be
a specification for identifying a set of packets.  I don't see what an ALG
has to do with that.  Besides, isn't it a fundamental concept of midcom
that the ALG belongs in the agent, not in the middlebox?

.  Section 8.4 -- timers: "However, the middlebox should be able to recover
the dynamically allocated resources even as the agent that was responsible
for the allocation is not alive."   Does that mean "recover even while
still alive" or "recover when not alive"?

.  Separate from any timers on individual resources, there should be a way
to detect disappearance of the agent.  That disappearance should perhaps
free all the related resources as stated in
draft-ietf-midcom-requirements-01 section 5.3.2.   (Or was there a decision
on the mailing list that disappearance of the Agent not cause all its
allocated resources to be immediately freed?)  Why should the middlebox
time out allocated resources while the session with the agent is still
alive?  But if it does so, it should notify the agent!

.  Section 8.5: " In the case of a middlebox implementing NAT and firewall
services, it is safe to state that the NAT operation will precede firewall
on the egress and will  follow firewall on the ingress."    From what frame
of reference are we defining egress and ingress?  Please clarify.  If this
is egress from and ingress to the private domain, then I disagree with this
statement.  I believe the firewall rules must be based on the private
addresses etc. (which are fixed and known), not on the public addresses
(which are dynamically assigned).  In fact I believe this is what the next
sentence in 8.5 means:  "Further, firewall access control lists used by a
firewall are assumed to be based on session parameters as seen on the
interface supporting firewall service."

.  There is no section between 9 and 11.

.  Section 12 -- security considerations: "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."   I believe what you are referring to here is a pre-midcom world,
as contrasted by the next paragraph.  It would help to state here
explicitly that this refers to the world without midcom.

.  Section 12, last paragraph on Page 32: " A middlebox service may be
abruptly disrupted due to malicious manipulation or incorrect
implementation of the middlebox or its agents of a certain shared resource
by an agent purporting to offer ALG service for a different middlebox
function."   This is very hard to understand.  For me anyway :-)  Here is a
suggested rewording: "A middlebox service may be disrupted due to
conflicting directives from multiple agents associated with different
middlebox functions but applied to the same application session."

-- Thanks, Mark

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 22 Jul 2001 12:21:29 -0700 (PDT)

Thanks, Mark, for your detailed comments. I appreciate the feedback.
Please see my responses below.

regards,
suresh

> about being BEEP-aware but I'm not sure what the consensus was (if any).

Application intelligence goes beyond just the TCP/UDP payload. It includes
correlation between sessions, session orientations, port usage and so
forth. The document states in no uncertain terms that the MIDCOM protocol
allows the middlebox to move application intelligence to agents (Ex: refer
the text in sections 2.10 and 4). I dont believe it is necessary to 
single out TCP/UDP payload.
 
> Agent should modify any higher layer information.
Same as above.

> however limited to firewall and NAT middlebox services."
OK.

> considered a middlebox function?

I guess, you are saying that you cannot call something "a middlebox"
by the way it is configured at a given time. Good point. I will fix
the definition as you suggest.

> by which IP addresses and TCP/UDP port numbers are mapped ..." 
No problem. I will add the following at the end of first pragraph.

   Two types of NAT are most common. Basic-NAT, where only an
   IP address (and the related IP, TCP/UDP checksums) of packets is
   altered and NAPT (Network Address Port Translation), where both an
   IP address and a transport layer identifier, such as a TCP/UDP port 
   (and the related IP, TCP/UDP checksums) are altered.

> name and refer to these realms).  (Section 8.1 relates to this somewhat.)
All parameters of the tuple, including SessionDirection, are with reference
to an interface on the middlebox. I will state this explicitly. Thanks.

> Are they the what-to-do-when-a-packet-matches-this-session-descriptor stuff?
Yes - a variety of Timers, NAT translation parameters etc. Will inlude the
examples.

> repeating the definition presented in section 2.8.
You are right about the interpretation of the definition. That was the
intention. What non-native kind did you have in mind?

> and manipulating packets already in-flight, not about introducing new
Interception refers to processing packets in-flight not targeted to itself.
That is not the case with proxies. The packets are targeted to/from the
proxy server. So, I believe, the existing wording is the right choice.
 
> environments where those hosts won't be spoofed."
OK.

> the agent* by some operator, rather than *by the agent itself*. 

Yes, this is what is meant. I will reword the text to get this message
across.
 
>                                                                 If this is
Oops.. wrong choice of word. Will replace the word "deregister" with
"disconnect". Thanks for pointing out.

>  - establishment of an authenticated session between an authorized agent
It is the former. I believe, the following rewording in the first paragraph
of section 6.2 would make this clear.

   Prior to giving MIDCOM agents access to the middlebox resources,
   a registration process MUST take place. Registration is a
   different process than establishing a transport connection.
   The former requires exchanging agent profile information with
   the middlebox or a policy server(s). Agent registration is often
   a manual operation performed by an opertor rather than the agent
   itself. The latter refers to establishing a MIDCOM transport
   connection and exchanging security credentials between an agent
   and a middlebox. The latter uses the information from the former
   for connection establishment.

> that the ALG belongs in the agent, not in the middlebox?
This is what registration of an agent/ALG with the middlebox looks like.

> still alive" or "recover when not alive"?
Recovering when the agent is alive happens by design, when the dynamically
allocated resources are no longer required.

> alive?  But if it does so, it should notify the agent!
This is so the middlebox is not exhausted of its resources when an
agent dies on it.

> of reference are we defining egress and ingress?  Please clarify. 

OK. Hope the following replacement will work for you. Ingress and egress
are with reference to an interface.

   In the case of a middlebox implementing NAT and firewall
   services, it is safe to state that the NAT operation on an
   interface will precede firewall on the egress and will follow
   firewall on the ingress. 
>                                                                   If this
Hope the above replacement text clarifies this.

> .  There is no section between 9 and 11.
Got it. Will renumber. thanks.

> explicitly that this refers to the world without midcom.
OK.

> middlebox functions but applied to the same application session."
You are right. I do like your wording better. Thanks.

> -- Thanks, Mark

=====

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---

From: "Scott Brim" <[email-masked]>
Date: Mon, 23 Jul 2001 09:07:19 -0400

Paul, could you list (at least some of) the implicit requirements you
see in the framework document, so we know what to clean up?

---

From: Paul Sijben <[email-masked]>
Date: Mon, 23 Jul 2001 14:59:10 +0200

I am sorry but I do not believe that the framework doc is ready for last
call. Just as people have (rightly) criticized that the requirements doc
overlaps with the framework doc and hence needs some stuff removed, the
same is true the other way around. 

The framework document contains a lot of explicit and implicit protocol
requirements that need to be removed from that draft and considered if
they are present in the requirements document. If they are not there, they
need to be discussed.

Also the document seems to be so verbose that I find it difficult to read
(as in; find the midcom specific material amidst the generic tutorial). 

I would propose we bring both the output documents of this WG in better
shape and approve them together so they are in alignment.

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: Melinda Shore <[email-masked]>
Date: Mon, 23 Jul 2001 09:20:40 -0400

>they are present in the requirements document. If they are not there, they

It would be a huge help in knowing how to proceed if you
could be more specific in what you'd like to see changed/
removed.  Last call is a time for specific, substantive
objections.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Mon, 23 Jul 2001 14:53:27 -0400

Hi Suresh and thanks for your response!  I have another round of questions
on a few of the issues.  I'll put them into separate emails.  Here's the
first.

>> [Mark wrote]

> [Suresh replied]

I think I did not state my point clearly enough.  Let me try again.

Yes, the document is quite clear that the application intelligence is to be
in the agents.  What I would like to get clarified is exactly how much
"intelligence" needs to remain in the middlebox after that "application"
intelligence is moved out.  This is fundamentally about where we are
drawing the line between the application and the network.  It seems clear
that the middlebox must be aware of TCP and UDP ports, so that the agent
may direct it to give particular treatment (pinholes, NAT translations,
etc.) for traffic on particular TCP/UDP ports.  For example, the
Session-descriptor is described as consisting of direction,
source/destination addresses, IP protocol, and source/destination ports.
And in section 4 it mentions "port based sessions".

Yet there has been discussion on the list (e.g. the recent thread about
BEEP) that the middlebox might be expected to look deeper into the packet
and give separate treatment to separate threads multiplexed into one port.
I am not sure what the consensus was on that.  My personal opinion is that
the midcom protocol should not ask of the middlebox to look into anything
other than the IP, tcp, and udp headers.  But in any event we should all
come to some agreement on this and place text in the framework document
that clearly states the agreed direction.

>> [Mark wrote]

> [Suresh replied]

This is closely related to the issue above.  While the above discussion is
about what fields the middlebox should be *looking at* to make its decision
about a packet, this part of the question is about what fields the
middlebox might be expected to modify in processing the packet.  Again my
personal opinion is that this should be limited to fields within the IP,
TCP, and UDP headers but in any event the WG consensus on this should be
clearly stated in the framework.

-- Thanks, Mark

---

From: "Scott Brim" <[email-masked]>
Date: Mon, 23 Jul 2001 15:20:25 -0400

On 23 Jul 2001 at 14:53 -0400, Mark Duffy apparently wrote:
> intelligence is moved out.

What are your requirements?  Why?

---

From: Mark Duffy <[email-masked]>
Date: Mon, 23 Jul 2001 15:25:22 -0400

Hi Suresh and all,

>> [Mark]
> [Suresh]

>> [Mark]
> [Suresh]

Let me test my understanding of this.

The middlebox maintains a number of "session-descriptors" each of which
describes a set of packets that are to be treated in a particular way.  The
session-descriptor is a tuple roughly of the form (Interface,
SessionDirection, SourceAddress, DestinationAddress, Protocol, SourcePort,
DestinationPort).

Each session descriptor has associated with it some number of actions to be
performed by the middlebox.  So far there doesn't seem to be a midcom term
for these.  Let me call them session-actions.  I would suppose these
actions are things like "open a firewall pinhole", "apply NAT translation
y", and perhaps in the future "mark Diffserv codepoint value z".

I would further suppose that each session-action has associated with it a
timer (possibly) and an identifier of the particular Agent that requested
that action.

If this view of the world is consistent with that of others in the wg, I
would suggest that describing the middlebox function in terms of an
abstract data model like that would help to clarify the framework.  I'd be
willing to propose some text if there is interest in this.

--Mark

---

From: Mark Duffy <[email-masked]>
Date: Mon, 23 Jul 2001 16:53:06 -0400

>What are your requirements?  Why?

Scott, I'm not sure I understand your question.
My message was not about adding any requirements on midcom, if perchance
that's what you are asking.

The agents will use the midcom protocol to tell middleboxes to do
particular things to/for particular packets.  As asked in detail in the
rest of my posting of which you quote a part, I am looking for
clarification (in the framework document) as to how deep in the packet the
middlebox is expected to examine and what protocol headers the middlebox is
expected to understand.

Why am I looking for this?  Because without stating this we in fact have
very little.  It doesn't mean much to say midcom allows moving the
"application" intelligence from the middlebox to the midcom agent if one
does not define where the "applications" begin.  No?

-Mark

---

From: Mark Duffy <[email-masked]>
Date: Mon, 23 Jul 2001 17:19:51 -0400

Suresh, see below...

> {Suresh]

I don't have any specific kind in mind but let's use ftp as an example.
For the sake of the example suppose that ftp proxies will not be used.  

Passing ftp through a NAT box requires an ftp-aware ALG function to modify
data on the ftp control session.  Today this ALG would perhaps be a
component of the NAT middlebox.  In the spirit of midcom, I would like to
leave open the possibility to remove the ftp application intelligence from
the middlebox and deploy it instead in a Midcom Agent.  

Since there is not necessarily any ftp-aware box already in the network
(excepting the end points) we might want to deploy an ftp-aware midcom
agent device expressly for the purpose of controlling the non-ftp-aware
middlebox.  This device would not have a native role in the path of the
application traversal idependent of the MIDCOM function, but I don't see
why it should therefore be excluded by the midcom framework.  In other
words, why should midcom care what (if anything) else the agent device does
outside of its midcom role?

--Mark

---

From: "Scott Brim" <[email-masked]>
Date: Mon, 23 Jul 2001 17:09:22 -0400

Hi Mark.  More detail ... That's exactly my point.  You're asking "how
deep in the packet should a middlebox look", and my answer is "as deep
as it has to".  How deep is that?  That depends on what the requirements
are.  If nobody has a need for a middlebox to look deeper than the IP
header, then we can stop there.  So, what needs do you personally see?
Do you see any reason to go deeper?  If so, we can include your
requirements, and justifications for them, in the requirements draft.
"What are your requirements" was meant to be shorthand for all that.

...Scott

---

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Jul 2001 18:49:18 -0400

>does not define where the "applications" begin.  No?

That's an excellent point.  We (the collective "we" - there's
certainly been some disagreement, however) have been assuming 
that we're dealing with transport-layer middleboxes and there
seems to be some consensus around having us not skip past the
transport (TCP, UDP, SCTP) headers.  We must stay mindful, 
however, of the possibility that either future iterations or
vendor-proprietary extensions will want to go deeper into the
packet, and must therefore require that the protocol be
sufficiently expressive to allow something beyond {address,
port, proto}.

Melinda

---

From: "Ken Rong" <[email-masked]>
Date: Mon, 23 Jul 2001 18:07:21 -0500

Can the protocol specification be open/flexible enough to accomodate deeper
look up?  I understand that beyond 5 tuples, scenarios can be very
different.  But most application intelligence are really in the payload of
packets.

Thanks,

Ken Rong
Netrake Corp
Richardson, Texas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Melinda Shore
Sent: Monday, July 23, 2001 5:49 PM
To: Mark Duffy; [email-masked]
Subject: Re: [midcom] Framework last call -- level of middlebox
intelligence

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Mon, 23 Jul 2001 18:21:54 -0400

Suresh, last of my 4 followup questions.  Thanks and sorry about the volume
of all this!

>allocated resources are no longer required.

I agree with your statement immediately above.  However, I'm not sure
whether the text (quoted above) from the 2nd paragraph  of 8.4 refers to
the case where the agent is no longer alive, or to a case where is is still
alive and in contact.  If it is about the the former, it might be clarified
by changing "even as" to "even when".  (This is just a trivial question on
the wording.)

On a more substantive note, I would like to ask about the following.  The
draft discusses middlebox resources allocated by an agent and then being
freed:
 - by explicit direction from the Agent
 - by expiration of a timer
 - by loss of the session with the agent (for various reasons)

I would suggest that in some cases not all of those would be desired and
therefore it could be selected when the resource is assigned, and typically
controlled by the agent, which way(s) the resource would be freed.

For example, an agent opening a firewall pinhole might ask the middlebox to
keep the pinhole open even if the midcom session is lost (presumably the
middlebox would require a non-infinite timeout in this case).  Another
agent might request the pinhole remain open until the midcom session is
broken or the agent explitly requests its removal.   Yet another agent may
request a pinhole be closed on expiration of a timer or when the midcom
sesion is lost, whichever comes first.

Is there interest in this?  Is this too detailed for the framework document?

Currently, many firewalls will automatically close tcp pinholes when they
see the close of a tcp session.  I suggest that might also be a trigger the
middlebox could be instructed to watch for.

--Regards, Mark

---

From: Mark Duffy <[email-masked]>
Date: Mon, 23 Jul 2001 19:00:58 -0400

Hi Scott,

My personal "requirements" would be mostly along the lines of keeping the
amount of application intelligence required in the middlebox as low as
possible.  I guess I spoke a little loosely about "how deep in the packet".
 I wasn't talking literally about how many bytes into the packet, but
rather how many protocols the middlebox would need to understand and parse
to classify the packet. 

It seems to be a given at this point that middleboxes will need to be told
to look for certain values of source/destination addresses, protocol, and
source/destination ports.  The implication is that the middlebox needs to
be able to find the IP, TCP, and UDP headers and examine those fields.
Well that is just fine with me.  

What I am trying to tease out here is whether participating in a midcom
environment will require the middlebox to be able to understand and/or
examine headers aside from IP, UDP, TCP.  I suppose extension beyond those
could take the form of either specific protocols/headers to understand, or
the ability to be told to blindly look at certain offsets for certain
values, without really understanding what the headers are (would work for
some protocols).  Personally, I'm not too keen on going beyond tcp/udp.  I
suppose going beyond there will be based on the intersection of what is
needed to do middlebox functions for a particular application of interest,
how expressive the midcom protocol is, and what various middlebox products
are capable of.  BTW, I was really trying to understand what the consensus
of the group was in this area, not to propose changes.

-- Mark

---

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Jul 2001 19:42:02 -0400

>different.  But most application intelligence are really in the payload of

I'd actually say that some not-insignificant portion of the application's
intelligence resides in application state and transaction state and not in 
the packet at all.  I think the question that we need to answer is what
information the application needs to convey to a firewall or NAT in order
for the middlebox to be able to correctly identify application packets
for traversal purposes, translation, etc.

Melinda

---

From: "Ken Rong" <[email-masked]>
Date: Mon, 23 Jul 2001 19:23:05 -0500

"Application State" and "Transcation State" may cover lots of stuff.  For
the SIP example used in the draft, I do need to get the RTP port number from
the packet payload in order to apply specific logic to the real call
traffic.  Without getting into the payload, how can I do that?

Ken

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Monday, July 23, 2001 6:42 PM
To: Ken Rong; [email-masked]
Subject: RE: [midcom] Framework last call -- level of middlebox
intelligence

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Jul 2001 20:46:04 -0400

>traffic.  Without getting into the payload, how can I do that?

That (having the middlebox snag the port number from the
signaling payload) is precisely the situation we're trying to
rectify.  An endpoint/ALG/proxy will have knowledge of the 
port number and would be able to convey it to the middlebox.

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 25 Jul 2001 07:52:15 -0700 (PDT)

> the middlebox and deploy it instead in a Midcom Agent.  
Sounds good.

> outside of its midcom role?

If the device is not natively in the path (i.e, terminating a session 
along the way and visible to end-hosts), that would be an intermediate 
device forwarding packets along the route (such as a switch, a router or
a VPN device etc.) that would be hosting the MIDCOM agent function. 
Yes, that does make sense.

I will reword as you suggest. Thanks.

regards,
suresh

---

From: Mark Duffy <[email-masked]>
Date: Thu, 26 Jul 2001 22:42:02 -0400

-- Thanks, Mark

---

From: Mark Duffy <[email-masked]>
Date: Thu, 26 Jul 2001 22:55:43 -0400

Hi Suresh and all,

The middlebox maintains a number of "session-descriptors" each of which
describes a set of packets that are to be treated in a particular way. 
The session-descriptor is a tuple roughly of the form (Interface,
SessionDirection, SourceAddress, DestinationAddress, Protocol,
SourcePort, DestinationPort).

Each session descriptor has associated with it some number of actions to
be performed by the middlebox.  So far there doesn't seem to be a midcom
term for these.  Let me call them session-actions.  I would suppose these
actions are things like "open a firewall pinhole", "apply NAT translation
y", and perhaps in the future "mark Diffserv codepoint value z".

If this view of the world is consistent with that of others in the wg, I
would suggest that describing the middlebox function in terms of an
abstract data model like that would help to clarify the framework.  I'd
be willing to propose some text if there is interest in this.

--Mark

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 30 Jul 2001 10:24:10 -0400

I have several comments on the framework document, mostly minor issues.

Section 2.6 states that "ALGs are not visible to end-hosts". I don't think
that this is necessarily true. If fact, since OOP agents are out for now,
the MIDCOM framework requires that the ALG functionality be embedded either
in a proxy or an end-host (or other entity that is in-path) instead of in
the middlebox as it is today. Based on this definition, an ALG cannot be a
MIDCOM agent since it is not "naturally in the message path". I suggest the
following wording:

   Traditional ALGs are embedded in a middlebox and are not visible to
   end-hosts, unlike the proxies which are relay agents terminating
   sessions with both end-hosts. Most ALGs do not terminate session with
   either end-host. ALGs examine and optionally modify
   application payload content to facilitate the flow of application
   traffic through a middlebox. ALGs are middlebox centric, in that
   they assist the middleboxes in carrying out their function.
   Whereas, the proxies act as focal point for application servers,
   relaying traffic between application clients and servers. The MIDCOM
   framework will allow for ALG functionality to be embedded in proxies
   and end-points external to the middlebox and closer to the application
   intelligence.

The last paragraph in 2.6 can be eliminated.

In section 2.8, I suggest the following wording to clarify the difference
between an in-path and out-of-path agent.

   The MIDCOM framework is specifically designed for applications
   that consist of signaling/control sessions and media/data
   sessions. These control and data flows may traverse
   different paths through the network. In order to perform the
   ALG function, MIDCOM agents must access the control messages.
   This document considers only MIDCOM agents co-resident on
   devices that are naturally in the control message path
   of an application. These are also referred to as "In-Path MIDCOM agents".
   This may be an application proxy, gateway, or in the extreme case,
   one of the end-hosts, that is party to the application.

   Agents not resident on entities that are natively in the path of
   application flows are referred to as Out-of-Path (OOP) agents. These
   require that control messages be diverted from their natural path to
   the agents and then reinjected into the path. OOP agents will be
   considered out of scope for this document. As such, there will
   be no further discussion on OOP agents in the reminder of this
   document.

In section 5.0, it says:

   In-Path MIDCOM agents are entities that have a native role in the
   path of the application traversal (with prior knowledge to one of
   the application end-hosts) ...

The application end-hosts do not necessarily have "prior knowledge" of all
the proxies in the path of application traversal. When there is more than
one proxy in the path, the application end-hosts will have prior knowledge
of their adjacent proxy, but not of the other intervening proxies, one of
which may be a MIDCOM agent. I suggest removing the comment inside the
parenthesis.

In Figure 2, the control paths for the RTSP and SIP are missing from the
right side of the firewall.

In section 6.0, it says:

                               The Policy server does not assist a
   middlebox in the implementation of the services it provides or
   with resource authorization on the middlebox

Why not? Why should MIDCOM impose a restriction what a middlebox and its
policy server can do? What role a policy server plays beyond the
registration and authorization of agents is beyond the scope of MIDCOM and
we should not attempt to describe what is does or does not do. This sentence
should be removed.

In the last paragraph of 6.2, change "deregister" to "disconnect" in the
first sentence.

The labeling in Figure 3 is not correct. It should look like this:

                         _________
                     --->|   SIP   |<-----\
                    /    |  Proxy  |       \
                   |     |_________|       |
                  1|       | ^  ^ |       4|
                   |       | | 7| |6       |
                   |8     2| |3 | |        |5
   ______________  |       | |  | |        |    _____________
   |            |<-/      _v_|__|_v__       \->|            |
   | External   |    Na   |           |   Nc   | SIP Phone  |
   | SIP phone  |>------->| MiddleBox |>------>| within     |
   |            |<-------<|___________|<------<| Pvt. domain|
   |____________|    Nb                   Nd   |____________|

Where 1&4 are the INVITE message. 5&8 are the 200-OK response. 2&3 are the
setup of the flow Nd+Nb and 6&7 are the setup for the flow Na+Nc.

In the timeline flows in 7.1, 7.2, and 7.3, the 100Trying should be
immediately after the INVITE is received by the proxy. It tells the client
that the request has been received and prevents the client from
retransmitting the INVITE. There is no need to wait for the results of the
first NAT/Firewall setup.

In the timeline flow in 7.2, modification of IP addresses in the SIP headers
needs to occur for the INVITE in the same manner as the ACK and the BYE.
This would also have to be done for the responses coming back from the
private phone. Also, I believe the source address needs to be NATd in the
180Ringing and 200-OK responses from the private phone.

The timeline flow in 7.3 indicates the BYE and its response have SDP payload
which they do not. For each request and response, the proxy needs to modify
IP addresses in the SIP headers (same as in 7.2).

(-:bob

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 30 Jul 2001 08:15:17 -0700 (PDT)

Mark,

It has been a non-goal of the Work group to describe data models 
within middlebox. As such, the FW draft had purposely stayed away
from going into guts of the middlebox. Hope you understand. Thanks.

cheers,
suresh

=====

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 30 Jul 2001 08:21:30 -0700 (PDT)

As such, middleboxes that understand the transporty headers
(ex: TCP, UDP and SCTP?) has been the focus of this WG. 
I can certainly state this in the document. Anything beyond
the transport headers will be assumed to require 
application-specific intelligence. Thanks.

cheers,
suresh

=====

---

From: Mark Duffy <[email-masked]>
Date: Mon, 30 Jul 2001 13:01:12 -0400

Suresh, that it fine.  I am not hung up on a data model.  What I was really
looking for was more specific description around the concept of the agent
using the midcom protocol to convey to the middlebox WHICH packets to do
something with, and WHAT to do with them.

I think the WHICH is pretty much covered by the session-descriptor concept
introduced in section 3.0.  But there is really not much specific in the
document about the WHAT, that is, what actions does the midcom protocol
allow for specifying.  (What I have called session-actions in the message
below.)  Associated with that may be other miscellaneous directives such as
HOW LONG to do the action for.

I believe you indicated in an earlier email you would add more examples of
the WHAT.  I was thinking in terms of something more definitive than
examples, but perhaps this is really an issue for the protocol requirements
draft.

-Mark

>--- Mark Duffy <[email-masked]> wrote:
[snip]

---

From: Scott Brim <[email-masked]>
Date: Mon, 30 Jul 2001 13:18:16 -0400

> examples, but perhaps this is really an issue for the protocol requirements

Mark, I think the strategy for this WG is that the framework says HOW,
while the requirements draft says how to say WHICH and WHAT, and by
implication which whiches and whats you can say.  So you're looking in
the wrong draft.  If you want anything besides HOW, get it in the
requirements draft.

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 30 Jul 2001 21:22:22 -0700 (PDT)

> MIDCOM agent since it is not "naturally in the message path". I suggest the

Just because an ALG is in the natural path of an application, that 
does not mean that the agent should be visible to end-hosts.

I dont see how the ALG definition conflicts with the In-Path MIDCOM agent.

>    be no further discussion on OOP agents in the reminder of this
Bob - this portion of the text went through multiple edits.
I really dont want to change the text unless absolutely necessary.
Why go into the details of diversion function for OOP agents, when
the WG does not want to pursue that discussion. That will simply
raise additional questions - all in an area the WG is queasy about.
So, my druthers is to leave the text as is. Hope you understand.
Thanks.

> which may be a MIDCOM agent. I suggest removing the comment inside the
Done. 

> right side of the firewall.
OK. I will add 2 lines.

> we should not attempt to describe what is does or does not do. This sentence
The sentence is there to state what the policy server cannot be 
expected to do. Hope the following rewording will work for you.

   The Policy server is not intended to assist middlebox in the
   implementation of the services it provides or with resource 
   authorization on the middlebox.

> In the last paragraph of 6.2, change "deregister" to "disconnect" in the
Done.

> The labeling in Figure 3 is not correct. It should look like this:
I will respond to this on a different thread. Thanks.

regards,
suresh

=====

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 31 Jul 2001 08:52:37 -0400

> I dont see how the ALG definition conflicts with the In-Path MIDCOM agent.
OK, I'm a bit confused. The paragraph implies that proxies are visible to
end-hosts, yet if the "path" goes from one end through 3 proxies and to the
other end, the middle proxy is not necessarily "visible" to the end hosts.
Are you implying the same thing for ALGs? I don't see how an ALG can be in
the natural path of the application without be known or visible to either an
end host or proxy along the way. Today, with the ALG embedded in the
middlebox, it can be invisible to the application elements (proxies & end
hosts). But in order to put the ALG in an agent external to the middlebox,
the application must specifically send at least control traffic to the agent
(i.e. the application element co-resident with the agent). If the ALG in the
agent is not visible to an application element then some sort of diversion
is required to get the packets to the agent which makes it an OOP agent.
What am I missing here?

> So, my druthers is to leave the text as is. Hope you understand.

I know this has been a contentious issue, but I believe that confusion over
what is in-path vs. out-of-path persists (including my own above). Unless we
clearly differentiate these two, I believe this confusion will continue.

I guess the most important idea that I think is needed in the definition of
the in-path agent is that the control messages and not necessarily the data
messages have to traverse the box that included the MIDCOM agent.

thanks,
(-:bob

---

From: Scott Brim <[email-masked]>
Date: Tue, 31 Jul 2001 09:41:00 -0400

>    authorization on the middlebox.

I think Bob's concern stems from mixing boxes and functions again.  The
policy server *function* is strictly a policy server.  It may be bundled
with other functions which support services, and doing so is beyond what
we care about.  I think the sentence that was already there is clearer.
While the new sentence is tolerable, it hints at other unspecified
issues -- that's its intention, but doing so reduces clarity.

..Scott

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 31 Jul 2001 11:12:58 -0400 (EDT)

The original sentence is clear and up to the point. It 
specifies what the middlebox not to expect from the policy 
server in the context of the MIDCOM framework. The main 
reason of it is to focus the attention on the agent/middlebox
interaction implementing the MIDCOM distributed architecture. 
If it is necessary to address the policy server/middlebox 
issues, I would propose the following text, 

  "In the context of the MIDCOM Framework, the policy 
   server does not assist a middlebox in the implementation 
   of the services it provides or with resource authorization 
   on the middlebox."

and the policy server outside of the MIDCOM framework is 
out of scope.

regards
Abdallah

> issues -- that's its intention, but doing so reduces clarity.

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 31 Jul 2001 10:40:41 -0500 (CDT)

> clearly differentiate these two, I believe this confusion will continue.

	In the first place, it's out of scope ;)

	In the second place, the distinction is, as I understand it,
this:

	In-path agents use information from IP packets IP
		addressed to the agent host.
	Out-of-path agents use information from IP packets
		IP addressed to some other host.

	You could get all pedantic about how you COULD have a "sniffing"
widget that behaves like an out-of-path agent but co-resides on the
same box as the endpoint, and then you have to get fussy about transport
layer addressing and to which application the packets were addressed
and so on. I think my definition captures the essence conveniently,
though.

	The point about OOP agents is that someone needs to get the
packets TO or at least NEAR (for sniffing) the agent. At one point,
it seemed natural to allow MIDCOM to support requests for such.
Shoot, it still sounds natural. I don't think it was ever a requirement
that an OOP Agent SHALL get its access to data via a middlebox, it
could get it by mental telepathy for all I care.

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 31 Jul 2001 12:32:16 -0400

----- Original Message ----- 
From: "Abdallah Rayhan" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 31, 2001 11:12 AM
Subject: Re: [midcom] Framework comments & suggestions

>    of the services it provides or with resource authorization 

I like this wording the best.

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 31 Jul 2001 19:42:55 -0700 (PDT)

> I like this wording the best.
I like it as well. Let's go with it. Thanks.

regards,
suresh

---

From: Mark Duffy <[email-masked]>
Date: Tue, 31 Jul 2001 23:53:21 -0400

At 10:40 AM 7/31/01 -0500, Andrew Molitor wrote:
...
>		IP addressed to some other host.

This was not my understanding.  I am surprised in fact not to see any
responses to the above post (so far).  Does the silence mean everyone
agrees with the above statement?  I guess we can at least conclude that the
definition of in-path agent "...devices that are naturally within the
message path of the application" is too vague!

Andrew's definition strikes me as unnecessarily restrictive of what can be
an in-path agent (and therefore an in-scope agent :-)  

Consider the pre-midcom case where a middlebox, say a firewall, embeds
application intelligence in order to do its job.  None of the application
packets would be IP-addressed to the firewall.  Now consider the
midcom-ized evolution of that picture.  We can shift the application
intelligence out of that firewall and into a midcom agent that is within
the path traversed by the packets.  Why should it be a precondition to
doing so that the application now address its packets to the agent?  All
this serves to do is to prevent (as a side effect) the use of midcom for
any application that is not using some sort of proxy.

-Mark