Subject: [midcom] more general comments and comments on Requirements

From: "John LaCour" <[email-masked]>
Date: Wed, 27 Jun 2001 18:06:30 -0500

Hello everyone.  I've just caught up on reading the last
few weeks messages and thought it would be a good time to
share my thoughts with the working group.

In a few of my comments I mention what I think Agents
and Middleboxes should do.  I want to be clear - I'm not
advocating that we require agents or middleboxes to implement
things in any particular way outside of the MIDCOM protocol
itself.

I'd also like to mention that I think its very important
that we try to do things in a generic way so that we don't
preclude any particular applications from using MIDCOM.
This means being extensible and not necessarily supporting
every application and topology initially.

My apologies in advance if I've touched on things that have been
resolved prior to my involvement in the working group.

My comments on the recent Protocol Requirements and discussions:

1.  I agree with Bob Penfield and Andrew Molitor that the MIDCOM
    protocol should support the ability to aggregate pin-holes
    and other requests so that they can be addressed as a unit.
    Presumably the Agent would provide some kind of group-id when
    making a request.

    This will also facilitate the objective of keeping the protocol
    less chatty by allowing a group of pin-holes to be closed
    at once (timers to be reset, etc.).

    Middleboxes and Agents aren't required to support this, but the
    protocol must support it.

2.  Regarding Middleboxes redirecting flows to agents, I don't
    want to REQUIRE this.

    I would very much like to include in the MIDCOM protocol a
    request type which essentially accomplishes this.  e.g.
    For traffic from  A -> B now send it from A -> C.  In most
    cases, the middlebox may perform essentially a NAT, but in
    the case of an already established TCP connection, it
    may proxy the connection hence the need for something different.

3.  The whole issues of interfaces, flow direction, and what the agent
    is assumed to know about the network topology, etc. is a key
    decision.

    Fundamentally, an agent is requesting that the middlebox perform
    some function (or NOT perform some function).  Whether the
    interfaces and direction is relevant depends on how the specific
    function is implemented varies by te middlebox.  Before we can
    answer how relevant direction and interfaces are, I think we need
    to answer the question of whether we expect middlebox vendors to
    implement the function, i.e. 'open pin-hole', the same way.

    My position is that the we don't force middlebox vendors to
    implement the functions the same way.  The protocol must support
    the optional delivery of all information from the agent to the
    middlebox.  I believe this will include 'direction'
    and/or 'interface' for most middleboxes.  I agree that including
    discovery of these things is something that we don't want to do in
    the protocol and therefore this will need to be administratively
    configured on the agent and middlebox.

4.  I don't think we should require the middlebox to undo things it
    did on behalf of an agent when the agent deregisters or 'dies'.

    Some applications (bandwidth regulators, profanity sensors,
    anti-virus, intrusion detection systems, honeypots, etc.) may use
    midcom agents to request that the middlebox block network traffic.
    I don't want the middlebox to open this traffic back-up if the agent
    restarts.  This also means we need to support 'close pin-hole' when
    there was never an 'open pin-hole'.

    The middlebox owns its resources and chooses its own implementation
    for garbage collection and (probably by policy) how to handle
    resources that were requested by agents that have disappeared or
    unregistered.  This isn't to say we can't support timers for the
    requests...

5.  The MIDCOM protocol must support time-out values such as those
    suggested by Andrew Molitor.  Specifically, inactivity timeout and
    a hard time out.  The MIDCOM agent is essentially a trusted party
    responsible (in the case of pin-holes) for helping managing security.
    Because the agent is closer to the application, it should help manage
    the length of time that the requested resources are available.

6.  I don't want to preclude the middlebox from altering packet
    information.  If a middlebox performs some function which alters
    packet data to faciliate the operation of an application, it may be
    advantageous for an agent to make smarter decisions about when the
    middlebox should perform that function.

7.  In section 5 of the requirements, "...the MIDCOM protocol need to be
    extensible to allow the requirements of future applications..."

    What about vendor-specific extensions?  I'd like to be able to use
    MIDCOM if I have a middlebox with a function that no other middlebox
    has.

8.  In section 5.1 of Requirements, its mentioned the protocol may
    require NAT.  I'd like get a bit more granular and say that the
    protocol must support the ability to request a NAT with specific
    addresses as well as the ability to request a NAT assignment from
    the middlebox.

9.  Another general concern which needs to be addressed is the case
    where one or more agents request the same or overlapping resources
    from a middlebox.  Each request from an agent will need to include a
    request-id or something similar so that the middlebox can keep track
    of the requests in some sort of state table.  Without this, trying to
    figure out how to handle conflicting requests or multiple requests
    for the same thing gets really messy.

10. I'm not sure that individual message authentication is necessary if a
    lower layer protocol (TLS, SSL, IPSEC, etc.) provides for
    authentication of the data stream.

Should we get all of the various MIDCOM drafts listed on the MIDCOM
home page?

Regards,
-John
--
John LaCour
Technology Strategy
[email-masked]
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

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

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 28 Jun 2001 10:45:32 -0400

Hi John,

I agree with most of your comments. I have a few embellishments detailed
below.

----- Original Message -----
From: "John LaCour" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 27, 2001 7:06 PM
Subject: [midcom] more general comments and comments on Requirements

>     Presumably the Agent would provide some kind of group-id when

The group/session id could be defined by the agent or by the middlebox. If
we decide that the agent defines it, we need to way to make sure the id is
unique such that multiple agents connecting to the middlebox do not use
duplicate ids. I personally would like the protocol to support a middlebox
which gives out an id at the request of the agent.

>     configured on the agent and middlebox.

I agree!! If a middlebox does not support 'direction' or 'interface', that's
fine. But if it does, the agent should be able include that information in
its pin-hole requests.

As far as interface, what I want to be able to express is the domain/realm
an interface or set of interfaces is connected to. If a middlebox is
connected to only two domains/realms, a 'direction' would suffice. The
middlebox and the agent would have to be configured the same so that both
knew which was inside and which was outside. If a middlebox is connected to
more than two domains/realms, both the middlebox and the agent would have to
be configured with the same set of names or ids for those domains/realms.
The association of the names or ids with physical interfaces is up to the
middlebox.

---

From: [email-masked]
Date: Thu, 28 Jun 2001 10:49:48 -0700 (PDT)

>     unregistered.  This isn't to say we can't support timers for the

A variant of the need to support 'close pin-hole' when there was never
an 'open pin-hole' might also arise when there are multiple midcom
agents which might address the same middle box.  A midcom agent which
was not the requestor of a pin-hole might request that a pin-hole
be closed.  There are obvious rights and privileges issues here,
but I think we do need to build appropriately secure methods for this
into the protocol.

>     middlebox should perform that function.

Boy, do I not want to go down *this* rathole.  As Melinda mentioned, anyone
with a taste for why not should look at the discussion of OPES on the
main IETF mailing list.   Let the Midcom agents' role be limited to asking
that a flow be permitted, and let the middlebox make the decisions about how
the permitted flow should be treated.  

				regards,
					Ted Hardie