Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt

From: "Cedric Aoun" <[email-masked]>
Date: Mon, 25 Jun 2001 16:02:01 +0100

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

This has to be limked with agents policy attributes such as who is the
backup agent to whom. This needs to be considered in our overall
requirements for fail over.

This implies that the backup agent needs to have the status of already
established
sessions between the middle box and the active agent. 

Cedric

-----Original Message-----
From: Andrew Molitor [mailto:[email-masked]]
Sent: Friday, June 22, 2001 5:19 PM
To: Scott Brim
Cc: [email-masked]
Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt

On Fri, 22 Jun 2001, Scott Brim wrote:

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

	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.

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

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

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

	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

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