Subject: Re: [midcom] Protocol Requirements -

From: Scott Bradner <[email-masked]>
Date: Tue, 27 Mar 2001 11:45:27 -0500 (EST)

> Is it fair to devise a maze of constraints 
> which rule out everything except 'UDP,

no

if UDP is the answer based on realistic requirements then that is OK
but please concentrate on real requirements not a devised maze of
artificial ones

and note that any UDP-based option has to deal with retries and congestion
and must be conformant with RFC 2914

Scott

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

---

From: Randy Turner <[email-masked]>
Date: Tue, 27 Mar 2001 08:26:59 -0800

Regarding the need for acknoledged receipt of asynchronous update messages
from a middlebox to a client, I think this requirement depends upon how
important it is for the client to absolutely know the current state of the
middlebox. I wouldn't dismiss the requirement out of hand. SNMPv3 "fixed"
the problem of reliable notifications, in part because there was a class of
network management entities that did not want constant polling, but still
wanted to make sure that notifications were reliable. I think we should wait
until we have a complete set of required scenarios before we dismiss this as
a possible requirement.

Also, I'm assuming that the "mirroring" capability is not to suggest that
"failover" is in scope, but instead to allow some "enabling" technology by
which a client "could" construct some type of failover. This would really
only need to be supported if the functionality naturally overlapped one or
more other requirements. 

Randy

-----Original Message-----
From: Andrew Molitor
To: [email-masked]
Sent: 3/27/01 6:44 AM
Subject: Re: [midcom] Protocol Requirements -

On Tue, 27 Mar 2001, Melinda Shore wrote:

> Quick notes:
> > - must operate over standard IP transports, UDP required, TCP
> >   optional.
> 
> Transport specification is an answer, not a question.  i.e.
> we need to describe transport requirement characteristics.

	Point taken. Is it fair to devise a maze of constraints
which rule out everything except 'UDP, with a TCP option'? For
a large number of fairly vague reasons which I would, if necessary,
take the time to refine and write down, I think that any other
transport description would be lunacy.

	I am, nontheless, happy to phrase the answer in the form
of a requirement!

> > - should support one or more privacy models (I am weak on this
> >   because, in general, not much you are saying is a big
> >   secret -- traffic flows will pretty much reveal the state
> >   of the box anyways)
> 
> To varying degrees.  It's pretty common to do VPN termination
> on firewalls, and while you can infer a lot from tunnelled
> traffic characteristics at least the actual destination
> address itself is protected in the case where the VPN is
> encrypted.

	What I meant was this:

	If I open a pinhole allowing traffic from A to B, the fact
that I have will be obvious pretty soon, when A starts sending traffic
to B. This is somewhat more trivial than VPN traffic analysis. Of
course,
I conveniently forgot NAT and the fact that people like to hide their
private addresses when I wrote that.

	Again, point taken, and thanks.

> > - must support server-to-client informational messages (or
> >   transactions?)
> 
> "Transaction" implies that a response would be expected.
> We had talked about asynchronous alerts from the middlebox
> to the midcom client and agreed that it's necessary - can
> you describe a scenario in which you'd like a response
> back to the middlebox?

	I cannot. As a potential server-end MIDCOM implementor, I
REALLY like the plan to send alerts optimistically into the void
and hope for the best.

> > - must support a method for mirroring an existing NAT
> >   binding allocated by one middlebox into another middlebox,
> >   for redundancy. There are a few ways to build this,
> >   I don't know or care how the protocol does it, but
> >   this capability must be supported.
> 
> I'm actually not convinced about that, but even so,
> a mechanism to do this that required communication
> among middleboxes is out of scope.  A mechanism that
> made the client responsible for requesting a particular
> binding is not.  Either way, how the address of the
> NAT itself is failed over is absolutely not our concern,
> yet if that's not done the question of transferring
> existing bindings is pretty much moot.

	I actually meant to indicate a mechanism whereby a client
can do the heavy lifting. The point was that the MIDCOM protocol
should support:

	- returning enough information to the client to allow a
	  NAT binding to be installed on a parallel middlebox
	- a way to install said information on same

	The difficulty is that the Middlebox-NAT really needs to
be allocating stuff (port numbers and whatnot) in the normal case.
Otherwise the multiple-client case breaks entirely, and the
clients have to do way too much computation and address/port space
management.

	However, in the redundant middlebox case, the "spare" middlebox
has to simply told what the other one did. Then, if all the clients
agree which one is the primary and which one is the spare, we
don't have Middlebox A and Middlebox B allocating the same
IP address/port to two different things.

	This is actually a solution too. What is needed is a way,
any way, to allow a bunch of clients to collectively keep a bunch
of middleboxes all configured the same.

	The idea of middlebox-middlebox communications a) gives me
the willies and b) doesn't solve the problem. You really need
a single logical allocator of IP addresses and ports to avoid
problems.

	Thanks much for your comments!