Subject: RE: [midcom] London meeting time

From: "Cedric Aoun" <[email-masked]>
Date: Wed, 11 Jul 2001 12:28:20 +0100

I would really want us to discuss during the session how the extensibility
of the Midcom protocol
could be achieved to take into account other Middle Box functions. I'm sure
that some of us (WG members) are
looking for that. I don't think that people want to see another WG being
created to take into account other Middlebox functions.

The only problem is that how can we talk about the tools to achieve the
extensibility
if we didn't even finish the protocol requirements and started look at what
existing protocol (with some extensions) Midcom should be.
The extensibility could be achieved by a package (Megaco, MGCP way) or
policy objects like with RSVP; I think we need to dig a little bit 
on this.

There is another thing that we discussed briefly on the mailing list (emails
between Andrew and Melinda) but didn't seem to move further:
What is our definition of connection setup between the Midcom Agent and the
Middlebox?
Does it include any functions parameters negotiation? or do we rely on the
registration phase to provide the proper settings and error 
notification messages (no I don't support that parameter or you're not
allowed to asked that) will be used.
The last method seems simpler and probably best to use.
Cedric

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Friday, July 06, 2001 5:42 PM
To: [email-masked]
Subject: [midcom] London meeting time

We're tentatively scheduled to meet from 9-1130 on Thursday, 9
August.  Also scheduled at that time are:
APP	trade		Internet Open Trading Protocol WG
OPS	rap-II		Resource Allocation Protocol WG
SEC	sacred		Securely Available Credentials WG
SUB-IP	tewg		Internet Traffic Engineering WG
TSV	avt-II		Audio/Video Transport WG

At the top of the agenda are wrapping up those things which need
to be wrapped in the framework document and the requirements
document.  Please let me know if there's anything you feel *must*
be addressed in the meeting beyond work on the documents.

Note, however, that it would be very, very, very much appreciated
if issues could be raised on the mailing list ahead of time - the
meeting is not *the* place where work is done, but one place
among several.  The bulk of the work is done on mailing lists, and
that's where consensus is developed.

Also, as we prepare to go into last call on the framework document,
do raise issues as soon as you become aware of them rather than
waiting until the last minute and gumming up the process.  Many
thanks.

Melinda

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

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 11 Jul 2001 10:45:37 -0400

> created to take into account other Middlebox functions.

Cedric, first of all, this mailing list is the main session.  The
physical meetings are (imo) mainly to work out details which we fail to
work out in mail.  Bring up issues here.  Type a lot.

> existing protocol (with some extensions) Midcom should be.

Right.  We really need to look at real life requirements.  How
extensible does this protocol actually need to be?  How much will each
level of extensibility cost us in terms of robustness, security, etc.?

> policy objects like with RSVP; I think we need to dig a little bit 

I understand the objects/elements approach.  I don't know what you mean
by using a "package".

> What is our definition of connection setup between the Midcom Agent and the

How does this sound for a summary (inspired by Christian, Suresh and
others)?  The relationship between agent and middlebox should be
stateless.  "Setup" consists merely of authentication & authorization of
the middlebox, and version/parameter negotiations (as you mention) such
as establishment of how transactions will be signed, possible
encryption, etc.  There is no further state necessary or wanted.  In
order to make this possible, all transactions should be in absolute
terms (e.g. absolute expiration times for pinholes).  No particular
agent should "own" a pinhole or any other installed rule -- if an agent
is authorized to manipulate a rule then that agent can do so.  Agent
authorization should be as specific as necessary to support this.
Conflicts and confusion between battling agents should not be resolved
by complex state in the middlebox and notifications, but rather by
interactions between the agents themselves.  This keeps the middlebox
clean.

...Scott

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 11 Jul 2001 18:21:51 -0500 (CDT)

> interactions between the agents themselves.  This keeps the middlebox

	This is pretty good, with a couple of caveats and remarks:

	Obviously some type of agent<->middlebox connection state should
be maintained, (transaction sequence number, or a TCP stream, or
something) to make the authentication work properly without handshaking
or something on every transaction. I assume I'm just being pedantic,
and that this is understood?

	I don't follow why statelessness and non-ownership-of-stuff
implies Absolute timer values? I don't see how 'expire this pinhole
10 minutes from now' is different from 'expire this pinhole
at <absolute time 10 minutes from now>' are sunstantively different,
since they can be trivially converted into one another (with suitable
caveats for clock differences -- which by the by delta times will
work MUCH better in the face of).

		Andrew

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 11 Jul 2001 20:50:12 -0400

> and that this is understood?

Sequence numbers (at the midcom level, not TCP) will probably help with
security.  I hope we won't want to use TCP.  What are the requirements?

> work MUCH better in the face of).

The absolute timer came out of concerns about replays.  It was Eric or
Melinda or both who suggested that if you only allowed messages with
absolute timers about when an event should occur that replays would be
less of an issue so your security could be lighter-weight.

...Scott

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 11 Jul 2001 20:30:54 -0500 (CDT)

> security.  I hope we won't want to use TCP.  What are the requirements?

	My personal feelings are that UDP is the way to go, since
TCP's backoff behavior is just not what you want in a real-time
environment. In a UDP-like environment, the only way I know how to
do client (Agent) authentication is to use sequence numbered
connection-stateful sort of arrangement, which a server (middlebox)
supplied cookie or initial sequence number or similar in each packet.
This allows your digital signatures to be robust against replay
attacks (at least by clients against the server -- it's not
symmetrical -- to the devil with the client's needs ;)

	The only option I am aware of is to do a multi-packet
exchange for each message exchange:

	- client sends a 'hi, can I talk to you?'
	- server replies 'sure, your signature looks good, have a cookie'
	- client says 'here is transaction, and thanks for the cookie'
	- server says 'ACK'

	Obviously if you maintain a little connection state, namely the
cookie, at each end, you can repeat the steps 3 and 4 as often as
you like.

	In TCP-land, you can essentially use the TCP state itself
as a kind of internal cookie, which works pretty well as long as
your TCP stack doesn't reuse initial sequence numbers very often
or predictably. Um, I think.

	I'm no crypto expert, so take all of the above with a good
sized grain of salt.

> less of an issue so your security could be lighter-weight.

	That's not a bad idea. If I was some kind of layering purity
nazi, I'd point out that you are mixing up security considerations in
the minutia of the rest of your protocol. Heck, if I was me I'd point
it out, and since I am me.. I think it's not a bad idea, but it's
not a very good one either -- solve the general problem of security
properly, and let the protocol semantics do the Right thing, and
keep them separate.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Jul 2001 09:31:51 -0400

At 08:30 PM 7/11/01 -0500, Andrew Molitor wrote:
>environment. 

I believe that all IETF protocols are now expected to employ
TCP-compatible congestion response mechanisms.  That's not an
argument against using UDP, but it is something to be aware of.

>properly, and let the protocol semantics do the Right thing, and

I don't agree that it is a layering violation (unless your layers
are more finely-grained than is usual when talking about IP), but 
even so, do note that putting some sort of nonce into the payload 
does the same thing *and* requires maintaining longitudinal state.

Melinda

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 12 Jul 2001 10:58:09 -0500 (CDT)

> argument against using UDP, but it is something to be aware of.

	If I put on my standard hat, I arrive pretty quickly at
the 'should run over UDP or TCP' exactly for these reasons. Obviously
a TCP implementation would do that vis a vis congestion, and
a UDP implementation would let you play games. This seems to be
pretty common, and I'd be surprised if we DON'T get there.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Jul 2001 15:08:28 -0700

We've gotten into protocol selection/design.  Perhaps this discussion is a
bit early, but anyway...

As anyone who followed the RSIP discussion knows, I have a very strong
bias AGAINST having an implementation be both TCP AND UDP.  There are two
and a half closely related reasons for this:

1.  It's more code to write and maintain

2.  Any lesser used code path is a potential security hazard, and
certainly a haven for bugs.

2.5 One of our touted reasons for success over other alternatives has been
our LACK of options.

Since the question is really what form should state remain, I am inclined
to suggest that we decide which we need to guard more carefully- latency
or the resources on the middlebox, while not trading off security, pick
one and run with it.  Let's not have another protocol that is both a floor
wax AND a dessert topping.

Eliot Lear

--
Eliot Lear
[email-masked]