Subject: [midcom] Requirements in the framework draft

From: Scott Brim <[email-masked]>
Date: Fri, 3 Aug 2001 11:51:09 -0400

Going through the framework draft, I find the following requirements
(implicit or explicit) which have not yet been agreed on by the working
group.  I'm not suggesting any changes to concepts or wording or
anything else in the framework draft here (see other mail), just
summarizing requirements.  

We've decided not to push for last call on the framework draft, which is
a relief.  Progress in each of the framework and requirements drafts
requires progress in the other.  I think the pendulum has swung and we
need to make a lot of progress on requirements before going back to
focus on the framework.  

Specifically, I would like the chair to select just two, maybe three,
requirements each week and push them as far toward resolution as
possible, strictly controlling other discussion.  

I'll try to put together a list of known requirements -- I suspect
others are as well :-) -- but here are the ones in the framework draft
to start with.

> 3.0 Architectural framework for Middleboxes

>    Firewall ACLs, NAT-BINDs, NAT address-maps and 
>    Session-descriptors are a few of the middlebox managed
>    resources. Session-Descriptor above refers to a session denoted
>    by the tuple of (SessionDirection, SourceAddress,
>    DestinationAddress, Protocol, SourcePort, DestinationPort).

Assumed requirement: a "session descriptor" MUST be uniquely identified
by this tuple.  We don't yet know if that's true -- in fact for
extensibility we cannot assume it's true.  We cannot assume how agents
will refer to state information they want to control ... until we finish
the requirements.

> 4. MIDCOM Protocol

>    The MIDCOM protocol between a MIDCOM agent and a middlebox allows
>    the MIDCOM agent to gain access to middlebox resources and
>    allows the middlebox to delegate application specific processing
>    to MIDCOM agent. The protocol will allow MIDCOM agents to signal
>    the middleboxes to let complex applications using dynamic port 
>    based sessions through them (i.e., middleboxes) seamlessly. 

"delegate" assumes a particular control relationship between middlebox
and agent.  So would "relinquish".  Assumed requirement: An agent MUST
accept responsibility for application-specific processing under
direction of a middlebox which is performing a related service for that
agent.

>    The MIDCOM protocol will consist of a connection setup phase, 
>    run-time connection phase and a connection termination phase. 

Assumed requirement: there MUST be some activity between agent and
middlebox which maintains a "connected" state.  It may be that some kind
of probe to see if the other function is still there is all that is
intended -- the question still remains.  What kind of interaction do we
*require* between agent and middlebox, beyond registration and
deregistration?

>    MIDCOM is a
>    peer-to-peer protocol. As such, either the agent or the
>    middlebox may choose to initiate the connection.

Assumed requirement: either the agent or the middlebox may initiate the
connection.  Do we require that of the protocol?  If not, what do we
require?  Why?

> 5.0. MIDCOM Agents

>    A 
>    MIDCOM agent may communicate with one or more middleboxes.

Assumed requirement: The midcom protocol MUST allow for agents to
communicate with one or more middleboxes, and for middleboxes to
communicate with one or more agents.  (I think this is a fine
requirement, but let's get explicit consensus.)

>    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), independent of their MIDCOM function.

What does "with prior knowledge" mean?  If it means what I think it does
.. assumed requirement: agents MUST be known to end system
applications.

> 6.1. Authentication, Integrity and Confidentiality

>    Security shall be
>    specified to minimize the impact on connections that do not use the
>    security option.

The above text is a requirement for the midcom protocol.

>    Security should be designed to avoid introducing
>    and to minimize the impact of denial of service attacks.

Another.

> 6.2. Registration and deregistration with a middlebox

>    Profile of a MIDCOM agent includes agent authorization policy (i.e, 
>    session tuples for which the agent is authorized to act as ALG),
>    agent-hosting-entity (e.g., Proxy, Gateway or end-host which hosts
>    the agent),

What does this mean?  An expected IP address?  Assumed requirement:
Agent hosting entity (whatever that is) MUST be identified in the midcom
protocol. 

>    Coupling MIDCOM agents with the middlebox resources requires
>    a means of reflecting that into the resource description table
>    of the middlebox. 

Requirement: a middlebox MUST couple middlebox resources with midcom
agents.

>    Once a connection is established between a middlebox
>    and a MIDCOM agent, that connection should be usable with multiple
>    instances of the application(s), as appropriate.

That's a requirement.

> 8.1. Multiple MIDCOM connections between agents and middlebox 
> 
>    A middlebox cannot be assumed to be a simple device
>    implementing just one middlebox function and no more than a 
>    couple of interfaces. Middleboxes often combine multiple 
>    intermediate functions into the same device and have the 
>    ability to provision individual interfaces of the same device
>    with different sets of functions and varied provisioning for
>    the same function across the interfaces. 
> 
>    As such, a MIDCOM agent ought to be able to have a single 
>    MIDCOM connection with a middlebox and use the MIDCOM
>    interface on the middlebox to interface with different
>    services on the same middlebox interface.

It sounds good but what is a "connection"?  If you are assuming some
kind of reliable transport, this is an assumed requirement.

> 8.3. Asynchronous notification to MIDCOM agents
> 
>    Asynchronous notification by the middlebox to a MIDCOM agent
>    can be useful for events such as Session creation, Session 
>    termination, MIDCOM protocol failure, Middlebox function 
>    failure or any other significant event. Independently, ICMP
>    error codes can also be useful to notify transport layer
>    failures to the agents. 

Assumed requirement: a middlebox MUST be able to notify one or more
agents of all these events.

>    In addition, periodic notification of various forms of data 
>    such as statistics update would also be a useful function
>    that would be beneficial to certain types of agents.

Is this a requirement or not?

> 8.4. Timers on Middlebox considered useful

>    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. Associating a lifetime for these
>    dynamic resources and using a timer to track the lifetime can
>    be a good way to accomplish this.

Requirement: A middlebox MUST be able to associate a timer with session
elements.  

> 9. Applicability Statement
> 
>    Middleboxes may be stationed in a number of topologies. However,
>    the
>    signaling framework outlined in this document may be limited to
>    only
>    those middleboxes that are located in a DMZ (De-Militarized Zone)
>    at 
>    the edge of a private domain, connecting to the Internet. 
>    Specifically, the assumption is that you have a single middlebox 
>    (running NAT or firewall) along the application route. Discovery of
>    middlebox along application route is outside the scope of this 
>    document. It is conceivable to have middleboxes located between
>    departments within the same domain or inside service provider's
>    domain and so forth. However, care must be taken to review each
>    individual scenario and determine the applicability on a
>    case-by-case basis.

I think there's a requirement in here but I'm not sure what it is.

..Scott

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