Subject: [midcom] I-D ACTION:draft-ietf-midcom-requirements-01.txt,.ps

From: [email-masked]
Date: Thu, 21 Jun 2001 06:59:49 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Middlebox Communication Working Group of the IETF.

	Title		: Middlebox Control (MIDCOM) Protocol Architecture and 
                          Requirements
	Author(s)	: R. Swale, P. Mart, P. Sijben
	Filename	: draft-ietf-midcom-requirements-01.txt,.ps
	Pages		: 19
	Date		: 20-Jun-01
	
Networks connecting to and forming part of the Internet are 
increasingly deploying specialised network functions to address 
security, quality of service and other administrative policy 
requirements. These devices are a subset of what can be referred to 
as 'Middleboxes'.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-midcom-requirements-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-midcom-requirements-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 22 Jun 2001 10:45:42 -0400

All in all a very good start.  There will be lots more requirements, and
I believe some of the ones you list will need clarification once we get
a more complete list.  I have a few issues ... 

> requested by a MIDCOM Agent. However the Middlebox must not alter
> packet information unless it appears in the packet header. This is to
> ensure that there is an appropriate separation of concerns between the
> MIDCOM Agent and the Middlebox.

If I understand what you mean I disagree.  Consider the case of FTP
through NAT.  Are you saying the middlebox must never modify IP
addresses in packet payloads?

> 4.3.   Policy Server functions

I see no requirements in this section.

> The MIDCOM Protocol should allow the aggregation of commands, requests
> and responses.

Could you be more specific?  What is the requirement which leads to this
conclusion?

> In conjunction with an appropriate MIDCOM Agent, an application shall
> be able to request a pin-hole through a Middlebox. To achieve this,

I believe the model is that the application and the agent are separate,
and that if the application is making such a request, it is because the
agent function is at least apparently co-resident with the application.
That is, we are not defining any kind of protocol between application
and agent to allow them to work "in conjunction".  All of that is beyond
our scope.

> A given Middlebox may support multiple concurrent trust relationships
> with a number of MIDCOM Agents. Resources, such as a Pinhole-
> Descriptor, may be shared across MIDCOM Agents and a Middlebox.

I don't understand what it means for something to be shared "across
agents and a middlebox".  What is the base requirement which leads you
to suggest this?

> As part of the de-registration process, any pin-holes or other
> Middlebox resources requested by the MIDCOM Agent must be immediately
> released by the Middlebox.

This is currently under debate :=)

> 7.     Application Control Flow Services  
> 
> Application Control flows constitute the control aspect of an 
> application. To enable a Middlebox to correctly handle such flows, 
> they will need to be routed to a specific MIDCOM Agent that is able 
> to handle the given application. These flows may be routed between a 
> physical port on a Middlebox and a specific a MIDCOM Agent. The 
> establishment of this association will requested via the MIDCOM 
> protocol or may be determined by policy otherwise applied to the 
> Middlebox. 

This is the diversion issue, also under debate.  We have the "in-path"
model where somehow, in a way we don't know anything about, agents see
application control traffic.  The model you have here, where agents ask
middleboxes to divert packets to them, is going to be put on the shelf
for now.  I would take this out and simply say (here and in 7.1.1) that
the method by which agents get to see application control packets is out
of scope for now.

> A MIDCOM Agent may be notified when a pin-hole previously granted has
> become invalid, such as through a system restart.

In this series of statements, when you say "may be", do you mean (1)
"might", i.e. this event might happen and the agent must be prepared to
deal with it, or (2) "is allowed to", i.e. the agent is allowed to ask
to be notified and the middlebox must be able to grant that request if
it is made?  Or something else?  Also, I hope the use is consistent
between statements, but it looks like it might vary.  For example I
believe you mean a midcom agent might hear that a pinhole has become
invalid and needs to be prepared to deal with it, but that an agent is
allowed to refresh a pinhole grant and a middlebox must be prepared to
deal with it.

> The MIDCOM communication protocol needs to allow for selective
> communication between a specific MIDCOM agent and one or more
> Middlebox functions on the interface to which it is connected.

Are you saying the protocol must not require multicast?  Are you saying
protocol messages should contain middlebox identifiers?  Or do I not
understand at all?

> An operation is needed to permit a flow, with a given flow
> specification and address translation, across the Middlebox. It shall
> be possible to indicate whether packets should be carried or discarded
> when a given flow specification is exceeded.

Traffic policer/marker/conditioner is a different class of
middlefunction than those we've been discussing up to now, and I'm glad
to see you want to keep the midcom protocol general enough to support
it.

> Other than the communication of control information between Middlebox 
> and an associated MIDCOM Agent, no packets will be allowed to flow 
> across the Middlebox unless requests by a MIDCOM Agent. i.e. the 
> default operation is that "no packets should be allowed to cross the 
> Middlebox". 

In fact, communication between an agent and a particular mdidlebox won't
flow through that middlebox either, so you can leave out "other than
...".  Also s/requests/requested/.

> The MIDCOM Protocol must allow communications between Middleboxes and
> MIDCOM Agents to be authenticated.

s/allow/require/

> Since Middleboxes and MIDCOM Agent(s) are likely to operate
> asynchronously, the protocol needs to permit the synchronisation of
> state machines between peer entities by adding state information to
> messages in normal operations or by the use of explicit query
> messages.

What do you have in mind by synchronization of state machines in this
particular case?  That is, what specific functions do you think are
required for it?

> 11.2.  Application protocol transport 
> 
> To enable the MIDCOM Agent to implement the desired application level
> functionality, it may be necessary for the Middlebox to forward IP
> packets received on specific IP addresses and/or ports directly to the
> MIDCOM Agent.

The "diversion" issue again (see above)

> h. Define mechanisms to mitigate replay attacks on the control 
> messages. 

This is the only security requirement that gives me pause.  So far we
haven't had a requirement to keep a connection open between agent and
middlebox -- just security state at each end.  Replay protection would
require a lot more lower-level, protocol-related state.  Essentially,
what do you mean by "mitigate", in concrete terms?

Thanks ... Scott

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

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 22 Jun 2001 11:10:06 -0400

> This is currently under debate :=)

Something like it, but not this.  We were talking
(I think) about what to do when the agent disappears
without deregistering, which is different from an
intentional deregistration.  I think.

> > MIDCOM Agents to be authenticated.

Well, we don't really know what "authenticated" means here.
For example, in a so-called "trusted network" we might consider
any endpoint that's on it implicitly authenticated.  I think
we need to allow for the possibility of operating in an
environment without explicit authentication.

> This is the only security requirement that gives me pause. 

We should probably discuss the non-repudiation requirement,
too.  

> So far we

It may not be necessary, actually, depending on how we define
the format of the information being passed.  A "give me a pinhole
for 10 minutes" request is a lot more vulnerable to replay than
a "give me a pinhole from Fri Jun 22 11:07:10 to Fri Jun 22 11:17:10".
In the former case you need to retain longitudinal state; in
the latter case you might need to compare current state.

Melinda

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 22 Jun 2001 10:18:32 -0500 (CDT)

> addresses in packet payloads?

	I think the point is that the middlebox wouldn't mess with the
control stream -- that's the 'FTP-aware MIDCOM Agent's job. If a middlebox
DOES alter the PORT commands, we should consider that to be an agent
contained inside the middlebox.

	The point, I suspect, is that the middlebox proper CANNOT
alter the payloads -- in this case the PORT commands -- because
the middlebox proper BY DEFINITION does not know enough (anything)
about the FTP control protocol to do that work. A thing which knows
enough to do that work is an Agent.

> agents and a middlebox".  What is the base requirement which leads you

	I read this as allowing one Agent to, for example, remove
a pinhole created by another. This is obviously necessary for fault
tolerant configurations.

> what do you mean by "mitigate", in concrete terms?

	Replay attacks are the single most dangerous type of attack
in this context. If I can re-open a specific pinhole at will, you are
COMPLETELY sunk. If MIDCOM doesn't support enough crypto juice to
make replay attacks crypto-hard to mount, it's a useless toy.

	Having worked on the design, implementation, and deployment of
one of these things I see no way around maintaining some type of
connection state between Agent and Middlebox. It doesn't have to be
heavy state, but it needs to do enough stuff with connect/authenticate
and then sequence numbering and crypto stuff to make it work securely.

	If someone can show me how to do it statelessly, securely, and
efficiently, it'll make the happiest boy in town!

		Andrew

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 22 Jun 2001 11:18:45 -0400

> intentional deregistration.  I think.

Good point.

> environment without explicit authentication.

Hmm, yup, and the draft says so later.

> We should probably discuss the non-repudiation requirement,

They have limited the non-repudiation requirement to where the
agent-middlebox relationship also crosses administration (money)
boundaries.  Also the requirement is that the protocol "support" it,
which at this point could simply mean leave room for it.  I thought the
non-repudiation requirement was pretty well phrased.

> the latter case you might need to compare current state.

That would be excellent.

Thanks ... Scott

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 22 Jun 2001 11:29:50 -0400

> contained inside the middlebox.

I agree with that, and that may be what the authors intended but if so
then could it be reworded?  This is the first paragraph of 4.1 on
Middlebox Functions.  It looks like a fundamental statement that
middleboxes manipulate headers but not payload.

> a pinhole created by another. This is obviously necessary for fault

OK

> efficiently, it'll make the happiest boy in town!

(swb looks to the security wizards for a great answer)