Subject: [midcom] Framework draft -01 comments

From: "Russell Daigle" <[email-masked]>
Date: Mon, 18 Jun 2001 16:33:25 -0700

Here are the main comments I have on the arch/framework document.  

Some of these comments are not architectural,  but are more protocol
issues....  but I've included them anyways since they may be helpful.

1) Section 2.8:  "MIDCOM agents possess a combination of application
awareness and knowledge of the middlebox function."  It shouldn't be
necessary that the agent knows the middlebox function.  While there are
situations where it is advantageous (ie,  when the agent itself will perform
the NAT manipulations of the stream),  it definitely should not be a
requirement.   I'd like to see some generic APIs that can abstract this
away;  for example the midbox may just want to know about dynamic ports
associated with the conversation.   I presume this was intended,  but it's
not clear from the text,  and it is important enough to be mentioned
explicitly.   In general,  this helps achieve extensibility in what I expect
will be a common situation where the midbox wants to maintain the "middlebox
function" without explicit knowledge of lots of applications.

2) Section 5.2, Page 12, point #3:  "Note the middlebox will not subject the
datagram to any of the middlebox services this time around."  This statement
indicates that when the out-of-path agent forwards the processed packet back
to the middlebox,  the middlebox won't pass this packet through any more
services.   This is completely untrue:  there are situations where
additional services are required after the packet has been processed by the
middlebox.  This has many implications....  but the salient point here is
that the architecture/protocol must not preclude this from happening.  This
should be mentioned explicitly.

One implication is that such situations that have this requirement will not
be able to use in-path agents since the packet must be forwarded back to the
middlebox.

I know the remaining implications are protocol-related,  so don't flame me.
:)  Just ignore them if you want.  I thought they were interesting enough to
note.... and I'll be mentioning them again later if the protocol-spec
doesn't have provisions for them.

Another implication is that there needs to be some sort of mechanism where
an out-of-path agent can be configured to return [on a per-connection
basis?] packets to the middlebox for further processing.  Presumably,  this
would be upon establishing the midcom protocol between a midbox and agent.
(This statement is also related to section 9.4:  "The agents should be
capable of returning the processed traffic to the middlebox point of
origin...";  this requirement should be configurable.)

Then there are strict ordering requirements between messages exchanged via
the midcom protocol and packets forwarded back to the midbox from the agent.
This may be particularly cumbersome if the midcom protocol messages and
actual user data-packets are sent via distinct virtual channels (ie,
different L4/7 connections).  This point may argue for having the user
data-packets tunnelled in the same connection as midcom protocol message are
sent via.  There are also  additional reasons for tunnelling of user
data-packets which will be described later.

In addition, there should be some sort of "cookie" (ie, 32-bit entity) that
the midbox can associate with each packet forwarded to an agent.  When the
agent forwards this packet back to the midbox,  the cookie should be copied
back.  One important use of this cookie would be to tell the midbox where
the processing for this packet needs to resume.  Note that this requirement
also seems to imply the need for tunnelling of user data-packets between
midbox and agent.

3) Section 9.1, 2nd para:  "A MIDCOM agent ought to be able to have a single
MIDCOM connection with a middlebox...".   In addition,  a MIDCOM agent must
be able to support multiple connections from the same middlebox.    The
perspective from which I'm looking at this is purely a matter of scale.  For
large scale midboxes with lots of processors,  I would like it to be
possible for each processor to be able to maintain their own connection(s)
to the agent such that packets can be sent/received from/to a processor
directly without having to hop through another one first.  In this scenario,
the middlebox L3 end-point of each of these connections will be the same;
however the L4 end-point (ie, TCP/UDP port number) would be different.  In
addition,  I highly recommend there be some sort of session-ID which is
included in every packet (control and data);  there could be a mapping of
session-id to processor for large scale boxes .....  again, this enforces
the requirement for tunnelling user-data-packets.

4) Redundancy and failure issues.   There probably needs to be more
discussion on this topic.  The first things that pop into my mind are:

(a) The need to be able to determine when the peer has gone down.  One of
the traditional techniques used for this is some sort of "heartbeat"
protocol.

(b) User-data packets being forwarded between midbox and agent should be
dropped in network if the destined peer is down/unreachable.  Tunnelling
would accomplish this since the midbox/agent peers are the src/dest of the
packet.  The concern here is that when the data-stream is modified (such as
with NAT),  some problems can be encountered if the two user-endpoints have
some data modified appropriately and some not (due to failure);  it would be
preferred that the latter packets not reach the end-node since one possible
outcome of this sort of scenario is data-corruption.  One of the problems
that arise in this situation is that seqno-delta operations performed by NAT
may not be done upon all packets of a conversation.  Of course,  one could
claim this is a more general problem that transcends the midbox architecture
(ie, any intermediate networking node that performs such stream
modifications opens this vulnerability),  which is true to some extent;
however,  I think that if this problem can be easily avoided by the midcom
arch it should be.

(c) Failover support.  I imagine this may be considered to be out of scope
since this is difficult (and potentially computationally expensive) for this
class of problem.

5) This is more of a protocol than architectural issue...  have some
mechanism in the protocol where a midbox can tell the agent to drop the
packet after fully processing it.  This can lead to performance gains in
situations where the user data-stream doesn't need to be modified at all,
but rather watched for dynamic connection information.  The midbox could
simply duplicate the packet, sending one to the agent and one on it's normal
way. Yes,  this can lead to some race-conditions where the dynamic
connection is attempted to be opened before the agent has the chance to tell
the midbox about it.   Assuming a tunnelling mechanism is used, a simple way
to implement this would be to have a bit indicating what to do with the
packet after the agent processes it.   (There can be another bit indicating
whether the agent must forward the packet back to the midbox after
processing,  or if the agent to route the packet onto the destination
however it sees fit.   The power of tunnelling..... have I convinced you
yet? :)

-Russ Daigle

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 19 Jun 2001 10:30:26 -0700 (PDT)

Hi Russell,

Would appreciate, in the future, if you sent your comments on the 
latest rev. of the draft. It is likely the previous rev went 
through multiple changes. Thanks. My comments below. Also, I didnot
respond to suggestions on specific protocol mechanisms and 
implementation issues. We could revisit these later at an appropriate
time. Hope you understand. 

cheers,
suresh

> function" without explicit knowledge of lots of applications.
You may be able to generate some generic APIs once the protocol is
designed. But, that cannot be mandated at the framework time.
Not all middleboxes are alike. An agent designed for a specific 
middlebox function or a specific application cannot be assumed to 
magically work with any middlebox function and/or application.

> be able to use in-path agents since the packet must be forwarded back to the

The intent is for the OOP agent to have the same priveleges to application
datagrams as that of an In-Path agent, in order for the OOP agent 
to behave exactly like the in-path agent.

The only difference would be a requirement for diversion function on the 
middlebox to support OOP agents. Otherwise, both agents have identical 
MIDCOM sessions.

Anything outside of this, I believe, would be out of bounds for this
work group.

> doesn't have provisions for them.
I am going to have to defer on the protocol related comments.

<... stuff deleted> 
> the midcom protocol and packets forwarded back to the midbox from the agent.

Yes. That is a requirement in general on all intermediate devices. 

> data-packets which will be described later.
Not necessarily. Besides, the exact diversion function implemenation
mechanism is considered proprietaty to the middlebox and is out of
bounds for the FW document.

<... Comments on specific protocol mechanisms & implementations deleted>

> -Russ Daigle
Thanks.

regards,
suresh

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

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

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 20 Jun 2001 10:46:16 -0400

> function" without explicit knowledge of lots of applications.

I believe this is exactly what was intended, and that if there's a
problem it's just wording.  I suspect (Suresh?) that "knowledge of the
middlebox function" does not mean that agents are able to function as
middleboxes, but rather that agents are designed with explicit awareness
that middleboxes exist, and how to talk to them.

We are working on an API, it's called the midcom protocol.