Subject: Re: [midcom] Protocol Requirements Bullet List v2.0

From: "Abdallah Rayhan" <[email-masked]>
Date: Mon, 02 Apr 2001 13:13:03 -0400

See comments below.

Andrew Molitor wrote:

>         Throughout, I use this terminology:
> 
>         Client - something that requests pinholes and NAT bindings. For
>                 example, a MIDCOM aware ALG or SIP proxy.
> 
>         Server - something which is spoken to by a client. By implication,
>                 a Server resides in (logically, if not literally) a
>                 Middlebox, and exposes the services of that Middlebox
>                 to Clients.
> 
>         Middlebox - a firewall or NAT device which is coupled to a
>                 MIDCOM server, which offers the firewall/NAT services
>                 to Clients.

I dont understand the need for the distinction between the server
and the middlebox in view of the functionality described above. 
If the middlebox is considered to be a policy enforcement point (PEP) 
and the it is usually controlled by a policy server which is the
policy decision point (PDP). The middlebox may require 
to outsource decisions to its policy server which is in alignment
with the policy framework. However, introducing a new server 
will add no value and crumble the PEP-PDP relationship. Furthermore,
the server-middlebox will require defining a new interface between
them which is something already being done in the policy framework.
I believe that the client should talk to the middlebox and the 
middlebox talks to the policy server when it needs to. If the 
objective of the above terminology is to utilize the client-server 
concepts into the midcom architecture then it might be better to 
say that the middlebox implements the server side of the midcom 
protocol rather than introducing a new logical/physical device.

>         Do we want to require a 1-to-1 relationship between Servers
> and Middleboxes?

In view of what I said before, outside the scope of the WG.
 
>         Protocol requirements in no particular order:
> 
> General Stuff
> =============
> *       - must support low-latency, high-throughput operation, with
> *         best effort to maintain low latency in the face of a lossy network.
> *         This is necessary for telecom grade operations -- backoff
> *         policies in retransmit timers are not necessarily a good idea
> *         on controlled channels controlling equipment. (This boils
> *         down to: TCP Considered Harmful -- in rather specific
> *         environments.)

I believe that the kind of protocol we are looking at is an application
protocol as we are not to solve a transport problem here. So, I recommend
separating the requirements into the protocol requirements describing 
the functionality and transport requirements for the transport performance
issues. There are protocols like SCTP which is designed for performance 
in telecom like scenarios but that should not mean rolling out TCP.

> *
> *       - must also support more ordinary network traffic models for
> *         use on standard networks where backoff policies for retransmit
> *         timers, and the like, are a good ideas. (This boils down to:
> *         TCP is a hell of a good idea most of the time.)
> *
> *       [ I think the first bullet above pretty much requires UDP
> *         transport with wicked timers, but if there's another option
> *         I'd be pleased to hear about it. The situation I am thinking
> *         of is: some goober in a POP unplugs the wrong cable for
> *         a moment, or there is some other glitch in connectivity.
> *         It would Be Bad if this glitch made TCP back off and make
> *         the POP unable to complete calls for, say, 2 or 3 seconds
> *         AFTER connectivity is restored. This could readily create
> *         irritating post-dial delays for several hundred customers
> *         over the next 10 seconds while the queue clears. This is the
> *         sort of thing that gives telecom geeks nightmares. ]
> 
>         - should be transport independent, a la SIP.
> 
>         - must support high transaction throughput over highish
>           latency networks (read: must support message streaming.)

High transaction of the middlebox, the transport, the client, or the
protocol itself. Remove high.

>         - must support one or more strong authentication models.

Most firewall if not all implement IPSec. What is the meaning of
requiring more?

> 
> *       - must support one or more privacy models.

See the above comment.
 
>         - must support client-to-server request/response transactions.
 
> *       - must support server-to-client "alerts" (unacknowledged messages)
> *
> *       - should support an acknowledged server-to-client messaging
> *         model as well?
> 
>         - must support models in which multiple clients talk to
>           multiple servers.

Is this an architectural or protocol issue?

> Specific Operations/Scenarios
> 
>         Note that these are protocol requirements, not box
> requirements. So, while the protocol must support the ability
> of a client to ask for a pinhole, the protocol also allows
> for a middlebox to return 'NO - I am a NAT, dummy.'
> 
> *       - must support a client-to-server transaction which returns
> *         the middlebox capabilities to the client. These capabilities
> *         must include, but not be restricted to:
> *               - firewalling
> *               - NAT
> *                       - NAT capabilities (ports and stuff)
> *               - Plumbing information (where does NAT fit
> *                 relative to other elements, specifically,
> *                 THIS MATTERS!)

I dont believe that it should be the case. The capabilities your
refer to are provisioning issues which are outside the scope. The
client should be able to know ahead of time what services a middlebox
supports and if makes a wrong request, then the result should be
service not supported and not this is what I support.

Pluming information! What is that?

> *
> *         and should include:
> *               - QoS
> *                       - QoS flavor(s)
> *       [ can someone help out with what one might want to say
> *         if one WERE a QoS capable middlebox? Is this far enough
> *         out of scope to just leave QoS out entirely, burying it
> *         in the 'but not be restricted to' part above? ]

There are other means of doing QoS and the middlebox protocol is and
should not be one of them.
 
>         - must support a client-to-server transaction to open a
>           "pinhole" in the middlebox's traffic policy.
> 
>         - must support a client-to-server transaction to request
>           a NAT binding, associating an IP address/port pair on
>           one interface with an IP address/port pair on another.
> 
>         - it would sure be nice if these binding requests could
>           specify information about the expected source of the
>           flow initiator. E.G. 'I have a server on the inside
>           at 192.168.1.99 port 5000, and I think someone on the
>           outside at address 209.46.41.61, I don't know the port'
>           will be connecting to my server -- please give me an
>           address/port I can advertise to the remote as the phone's
>           address/port'

You might want to call it late port binding feature and along
the same thought late ip binding. A mechanism might be needed
in this case to ensure the authenticity of the binding like
a token sent to the target and returned to the source to
authenticate the binding accordingly.

> *       - must support means for clients to manage redundant middlebox
> *         configurations. This means that it must be possible for a
> *         client or clients to:
> *               - apply the same NAT binding across multiple (NAT capable)
> *                 middleboxes.
> *               - apply the same pinhole across multiple (pinhole capable)
> *                 middleboxes (this is actually trivial and impossible
> *                 to NOT get right -- included for completeness)
> *
> *               [ these two boil down to: client can keep a primary
> *                 and a spare middlebox in synch ]

Middlebox synchronization is a client issue and not
a protocol nor a middlebox requirement. Leave it out. 

> *
> *               - bring a new middlebox into synch with a set of
> *                 synchronized redundant middleboxes.
> *
> *               [ this boils down to: a client can bring a formerly
> *                 dead primary middlebox back into service after repairs,
> *                 without bringing the network down.]

Out.

> 
>         - must support a client-to-server transaction to release an
>           individual NAT binding.
> 
>         - must support a client-to-server transaction to release an
>           individual pinhole.
> 
>         - should support a way to identify bundles of state (pinholes
>           and NAT) as belonging to the same group (a "session ID"
>           specified by the client in a set of requests)

I propose using the concept of service which could encompass a number
of functions like pinhole and NAT rather than session ID which
could be confused with transport and registration.

>         - should support a client-to-server transaction to delete all
>           the state bundled under a given session ID.
> 
> *       - should support a way to re-session-ID a bundle. That is,
> *         there should be a client-to-server transaction in which
> *         the client asks the middlebox to take all the stuff with
> *         session ID "A" and re-file it under session ID "B"
> *
> *       [ this is a surprisingly useful operation  but the uses of it
> *         that I know of might be proprietary so I shan't describe them.
> *         There are people reading who know whether they are or are not
> *         proprietary, so if there is curiosity, hopefully explanations
> *         will be forthcoming. Sorry to be so mysterious. ]

MEGACO utilizes a nice connection model which allows such operations
to take a place. It is very useful and I believe that it would be
more productive if we apply the same concepts here.

> 
>         - must support a way to specify a desired timeout value for
>           and piece of state created by a client-to-server transaction.
> 
>         - should support both activity based timeouts as well as
>           absolute timeouts (i.e. support both 'if you don't see any
>           packets for 60 seconds, please make this NAT binding go
>           away by itself' AND 'make this NAT binding go away in 60
>           seconds')
> 
>         - must support client-to-server transactions to query middlebox
>           state, including but not restricted to:
> 
>                 - currently installed pinholes
>                 - currently installed NAT bindings
>                 - statistics of various sorts

MEGACO provides a complete set of queries. I recommend borrowing
from its requirements draft. 
 
>         - should support a client-to-server transaction allowing the
>           client to register to receive notifications of various
>           sorts from the server.
> 
>         - should support some server-to-client transactions to inform
>           the client of events such as:
> 
>                 - timeouts of pinholes and NATs
>                 - violations of policy
>                 - other?
> 

regards

Abdallah

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

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 2 Apr 2001 13:46:41 -0500 (CDT)

On Mon, 2 Apr 2001, Abdallah Rayhan wrote:

> See comments below.
> 
> Andrew Molitor wrote:
> [ regarding Andrew's fondness for splitting the notion of a Server
>   off from the notion of a Middlebox ] 
>
	I addressed this very worthy criticism in another note
to someone else earlier. In summary, I agree that a middlebox
is essentially a monolithic Thing, but I felt it useful to separate
its 'talking to Clients' aspect from its 'doing NAT to packets'
aspect.

	Since I seem to be the only person who likes this distinction,
I will have a bash at re-writing things with a more monolithic view,
to see if it works. If it does not, I will report to the list, and if
it does, I will leave it monolithic.

>  >  [ transport must support high telecom performance requirements ]
> 

	Are you happy with my transport requirements, but unhappy
with the organisation of them? I'd be happy to stipulate that transport
requirements and protocol requirements should be split. Right now
I am just hashing a randomly ordered bullet list.

	If you meant something else, please clarify!

> protocol itself. Remove high.

	I don't understand this. If I have an excess 'high' in there,
my brain refuses to see it (which in no way implies that there isn't
one -- we all know how our brain locks up on these things sometimes!)

> > *       - must support one or more privacy models.

	IPSec is a wonderful thing, but it's unfair to assume that
all clients will speak it, or that all clients will speak it in a
manner that is currently interoperable with the middleboxes. I confess
that I haven't followed IPSec that closely, recently. Does it really
solve the application-to-application problem? I thought it focuses
more on host-to-host and net-to-net.

	Anyways, it would be fine with me if MIDCOM wound up stating
that IPSec or TLS or something was a requirement to meet these needs
of the protocol. The point is, the protocol needs authentication and
privacy -- where they come from is a problem to be solved soon, but
not right now!

> Is this an architectural or protocol issue?

	Mostly architectural. It's still reflected in the protocol.
It would be possible, though I admit very difficult, to devise a protocol 
which did not support the (quite correctly observed) _Architectural_
requirement of many clients/many servers.

	I would be happy to drop this many-to-many requirement as
Too Damn Obvious to Mention.

> service not supported and not this is what I support.

	So far I seem to be the only member of the 'Client should
be able to figure out what the Middlebox can do' camp. If anyone else
agrees with me, let me know! Otherwise, I will assume that the WG
collectively thinks Andrew is a doofus, and I will cheerfully drop
this from my little list.

> Pluming information! What is that?

	Plumbing, as in the way pipes are connected to one another
to supply water to sinks and whatnot, and to carry waste water away
from same? This word is also used in STREAMS based IP stacks to
indicate how various functional pieces are connected to one another.

	I use it, basically, to talk about whether NAT comes before
or after pinholes. That is, do you describe pinholes in terms of:

	Inside addresses
	Outside addresses
	Pre-NAT addresses
	Post-NAT addresses

	If this pushed out to a Client Provisioning problem, then
it all becomes moot.

> should not be one of them.

	There seems to be some debate on this as well. I think
that solving the problem of QoS is Out Of Scope, but the problem
of Making The Protocol Extensible is In Scope. I am happy to
drop mentions of QoS -- except that I think I stuck them in in
response to some other comments.

	I'd appreciate feedback on this issue -- drop all mention of
QoS in favor of a vague 'extensibility' or keep QoS as the canonical
extension?

> authenticate the binding accordingly.

	That is an interesting idea. How compatible with current
practice is it? Also, is it in-scope?

> a protocol nor a middlebox requirement. Leave it out. 

	Again, my intention is not solve the problem, but to require
that the protocol not make it impossible to solve. It's a real problem,
and if MIDCOM devices make it impossible to solve by not giving clients
enough information to synch middleboxes, then MIDCOM is essentially
pointless.

	You are perfectly correct that it is a Client problem, and
I in no way intend to suggest anything else.

	Basically, this requirement comes from having actually built
a protocol that wasn't expressive enough solve the synchronization
problem, and having to go back and do work to fix it. Thus, I know
it's a real problem, and I know it's relatively easy to accidentally
Not Solve It.

> could be confused with transport and registration.

	I'm happy to take suggestions for the right word here.
I think 'service' gets confused with port numbers? Perhaps something
like 'sheaf ID' or 'bundle ID,' since session ID apparently has
undesirable connotations.

> more productive if we apply the same concepts here.

	I will try to get a chance to go look at MEGACO in more detail
soon. Thanks for the pointer!

> Abdallah

	Thank you for your comments and criticism.

		Andrew

---

From: John Ladwig <[email-masked]>
Date: Tue, 3 Apr 2001 09:20:11 -0500 (CDT)

>>>>> On Mon, 2 Apr 2001 13:46:41 -0500 (CDT), Andrew Molitor <[email-masked]> said:

    >> High transaction of the middlebox, the transport, the client,
    >> or the protocol itself. Remove high.

    Andrew> I don't understand this. If I have an excess 'high' in
    Andrew> there, my brain refuses to see it (which in no way implies
    Andrew> that there isn't one -- we all know how our brain locks up
    Andrew> on these things sometimes!)

Suggest:

  - Midcom protocol must support high transaction throughput, even
    when the network path has significant latency.  (read: must
    support message streaming.)

    >> > *       - must support one or more privacy models.

    Andrew> IPSec is a wonderful thing, but it's unfair to assume that
    Andrew> all clients will speak it, or that all clients will speak
    Andrew> it in a manner that is currently interoperable with the
    Andrew> middleboxes. I confess that I haven't followed IPSec that
    Andrew> closely, recently. Does it really solve the
    Andrew> application-to-application problem? I thought it focuses
    Andrew> more on host-to-host and net-to-net.

You are correct, so far as I can tell.

    Andrew> Anyways, it would be fine with me if MIDCOM wound up
    Andrew> stating that IPSec or TLS or something was a requirement
    Andrew> to meet these needs of the protocol. The point is, the
    Andrew> protocol needs authentication and privacy -- where they
    Andrew> come from is a problem to be solved soon, but not right
    Andrew> now!

At the Minneapolis pre-conference Security Tutorial, Jeff Schiller
explicitly stated that "must run over IPSec" is *not* a general
solution for unsecured protocols which pass sensitive information.  In
particular, he noted that it's not generally possible for an
application to determine whether IPSec is in use, much less the
specifics of the protection scheme in use to a given host.

TLS is a rather different animal, and more appropriate to this
application.  However, TLS (re: RFC 2246) assumes a reliable transport
such as TCP.

    >> service not supported and not this is what I support.

    Andrew> So far I seem to be the only member of the 'Client should
    Andrew> be able to figure out what the Middlebox can do' camp. 

    Andrew> If anyone else agrees with me, let me know! Otherwise, I
    Andrew> will assume that the WG collectively thinks Andrew is a
    Andrew> doofus, and I will cheerfully drop this from my little
    Andrew> list.

In general, I'm (unsurprisingly) on the same page.  More specifically,
since draft-ietf-midcom-scenarios-00.txt was published this morning,
I'm even more on the same page.  Unless I read it wrong, the first
(2.1 - TCP server behind a firewall/NAT) scenario Christiane Huitema
posits direct signalling from a "terminal" (to use H.323 terminology)
application to the midcom server.  In the absence of site-specific
mass-configuration of such applications, and assuming that this
scenario is accepted by the WG, I think the midcom client should
indeed be able to "figure out" what the midcom server/box can control.

More generally, if we're to enable a variety of different sorts of
midcom boxes with this protocol, I think we need to allow for different
midcom client elements to ascertain the capabilities of midcom server
elements.  In large networks, there might be several different
implementations of midcom servers, whether simultaneously or over
time.  In the absence of capability negotiation, would not a
QoS-capable midcom client be faced with the possibility or likelihood
of generating a large number of unfulfillable QoS provisioning
requests to the server?  Alternatively, the midcom client is going to
have to build and track server-capability state, and that seems
fragile and unnecessary.

I need to go mull over the idea of direct midcom signalling by
applications.  I can see the appeal, for enabling peer-to-peer
applications, but to be quite frank, I'm not enamored of enshrining a
general-purpose firewall-avoidance architecture in the midcom WG.  All
of my thinking to date has been of enabling a controlled signalling
infrastructure to update policy as part of provisioning on behalf of
endpoints/terminals/applications.  The implications of allowing, for
example, any IP within a large (and inherently untrustable)
metropolitan network to signal changes to the firewall policy are
many; the policy engine at the midcom box would have to be quite
elaborate and robust for me to feel even slightly comfortable with
that, putting on my old academic network-security-admin hat for a
moment.

    -jml

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 3 Apr 2001 07:49:22 -0700 (PDT)

Andrew - Lots of good text for requirements. Fully agree with most of 
them. (nits commented below ;-).

I do have a gripe, however. That is w.r.t. new terms and defintiions.
This adds to confusion. Didnt we just agree in Minneapolis to use 
a single set of terms and that they shall be defined in framework 
draft? I am open to text changes to add clarity. But, let us simply
not proliferate terminology with each conversation. Let us try and
reuse the same terms consistently throughout. Thanks.
 
cheers,
suresh 

> >         Throughout, I use this terminology:
Andrew - We already have a framework draft with terms and definitions.
Can we work together to fix the terms and defintions, in just one 
place. Thanks.

> >                 Middlebox, and exposes the services of that Middlebox

I disagree with the client-server model. MIDCOM communication is one of 
peer-to-peer model in that MIDCOM session may be initiated by ether party
(Middlebox or MIDCOM agent). 

The MIDCOM agent is more like a co-processing entity than a client 
or a server. Asynchronous notification can be sent by either party. 
Requests are sent by MIDCOM agent (to permit sessions through firewall 
and create NAT BINDs and sessions) as well as Middlebox (to parse 
application specific payloads and modify the same).

As such, I would like to suggest using the terms "Middlebox" and 
"Midcom agent" as the two entities taking part in MIDCOM communication.
  
> >                 MIDCOM server, which offers the firewall/NAT services

MIDCOM protocol support is not a requirement for an entity to be called
a middlebox. NAT and firewall devices are middleboxes, irrespective of
whether they are party to MIDCOM protocol or not. 

I believe, Middlebox is an intermediate device that requires application 
specific intelligence for its operation. 

> protocol rather than introducing a new logical/physical device.

Abdallah - I disagree with the PDP-PEP model youare suggesting.
I dont see the Policy Server as equivalent of a PDP. 
A policy server is merely one that enforces authorization
and trust model. Policy Server is out of the way once a 
registration and trust model is established. ENd-to-End sessions
are established between Middlebox and MIDCOM agent.

It is also worth noting that the communication between Middlebox 
and Policy Server need not be based on MIDCOM protocol.

> > *       - should support an acknowledged server-to-client messaging

Andrew - Good collection of requirements. They all seem very relevant
and valid.

> Is this an architectural or protocol issue?

This is one of a framework/architectural issue. I believe, this is 
covered in the framework draft.

> service not supported and not this is what I support.

I agree with Andrew's observation. A Midcom agent should be able to
query a middlebox and learn of the specific middlebox functions 
supported. This is different from discovery. A midcom agent may choose
to co-opt with one or all of the middlebox functions supported.

As for plumbing, I suspect, Andrew is refering to the data path 
sequencing of the NAT and firewall. I believe, going into the 
sequencing can be a rat-hole. Anatomy of data path, I believe,
should be out of scope for this WG. Section 6.4 of the framework
draft punts this, assuming out-of-scope.

> > *         in the 'but not be restricted to' part above? ]

I think, we should not try and address the QOS issue at this time.
Suffices to say that middlebox may also be one that enforces policy
based QOS. These issues may be considered while designing the MIDCOM 
protocol (to make it extensible and usable with a wider set of 
functions).
> authenticate the binding accordingly.

Abdallah - the trust model is established apriori. No additional 
mechansims need to be devised into the MIDCOM protocol, specific 
to a certain type of request. Note, Simple Source-address based 
security is the least form of security and may be permitted to 
the most trusted hosts.
 
> a protocol nor a middlebox requirement. Leave it out. 

I agree with Abdallah's comment. Client's redundacy
issues are out of scope.

> > *                 without bringing the network down.]
Same as above. Out of scope.

> >         - must support a client-to-server transaction to release an

Must also support a transaction to create or release a NAT session.

> could be confused with transport and registration.
A service/function is one of NAT or Firewall. Andrew is suggesting that 
there be a way to identify session bundling (not service bundling).

I dont understand, why it is confusing to have session ID. This is 
different from MIDCOM transport and MIDCOM registration. The session ID
that Andrew is refering to is the end-to-end user sessions, not the 
Middlebox-MIDCOM-agent sessions.

> >                 - timeouts of pinholes and NATs

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

---

From: John Border <[email-masked]>
Date: Tue, 03 Apr 2001 17:00:00 -0400

> this from my little list.

I think this is part of "discovery" so I agree that it is out of scope.  But,
the 
protocol does need to include a means to indicate when a "mistake" in
provisioning
has occured, e.g. a NAT should return some kind of helpful (to the person who
will 
have to debug the problem) response if asked to "do" firewall and vice versa.

John

---

From: "Abdallah Rayhan" <[email-masked]>
Date: Wed, 04 Apr 2001 13:53:41 -0400

See comments below.

>     support message streaming.)

I am trying to differentiate between protocol requirements and
operational requirements. So if we come up with a protocol 
tomorrow what would constitute a high transaction throughput?
In my mind, throughput means how fast you process the requests
in a particular machine including the buffer size and complexity
of implementation. These are implementation issues and definitely 
not protocolish. The transport requirements most probably would
mandate the support of TCP and UDP. How UDP would provide you
with high transaction throughput when there is traffic congestion?
As for message streaming, is that really a requirement or a 
design decision? I believe that it is the latter.

Let us focus on the functional requirements. Sigtran and MEGACO 
looked into these issues before and I believe that they did 
pretty good job addressing them. btw, I tried to see if SIP
has "high transaction throughput" in the requirements. Guess 
what? It does not appear any where!

> You are correct, so far as I can tell.

These are transport requirements and deployment issues which I 
believe that IPSec can take of. This is the IETF where stacks
are developed. If necessary, make authentication and confidentiality
as transport requirements because they are not protocol requirements.
If you are going to require encryption at the application layer,
how do you expect to have high transaction throughput then?

> specifics of the protection scheme in use to a given host.

If that is the case, then why do we have IPSec in the first place?
IPSec is being used in the implementation of VPN which has more 
reaching effect than just one protocol between two devices. 

> indeed be able to "figure out" what the midcom server/box can control.
<snip>

You can accomplish the same thing without the need to place
such a requirement on the middlebox. For example, consider the
following scenario.

When the client registers with the middlebox, it could 
request the services it needs. The middlebox would 
authorize or deny the services accordingly without the need
to spill its guts. This way the client would know if it can 
carry out its duties with that particular middlebox or not. 
This state is global and there is no complexity in keeping 
it in the client. The client needs to register anyway with
the middlebox before communications starts. 

regards
Abdallah

---

From: Paul Sijben <[email-masked]>
Date: Wed, 18 Apr 2001 12:08:30 +0200

Dragging myself out of a pile of outher work....

I believe that the terminology below is correct.

>                 MIDCOM server, which offers the firewall/NAT services

Using this terminology we do not into terminology conflicts when we need to
introduce MIDCOM proxies to off-load authorisation of Client requests. 
>         Do we want to require a 1-to-1 relationship between Servers

yes. Even if you assume that one firewall will be spoken to from one domain of
control (i.e. clients under one ownership) you will want to allow redundancy
in that, so there may be requests coming in from several Clients. Now in
pratical cases you will want to allow several SIP proxies and other
application server all to establish flows through the firewall. So the
Middlebox really is a server, it will control the handing out of flows through
it and will have to authorise the requests.

When you look at this at carrier scale, introduction of a MIDCOM proxy seem
very likely so the box can just execute requests (in such a deployment).

IF we set the requirement right and get the protocol right, it will allow such
a deployment and not hamper other deployments.

Paul

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Message:+31 208702874			
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 18 Apr 2001 09:38:07 -0400

----- Original Message -----
From: "Paul Sijben" <[email-masked]>
To: "Andrew Molitor" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 18, 2001 6:08 AM
Subject: terminology (was Re: [midcom] Protocol Requirements Bullet List
v2.0)

> it and will have to authorise the requests.

I think that defining a relationship between the server and the middlebox is
beyond the scope of the WG. If the charter is to define a protocol, we can
define the requirements of the server to handle the protocol and provide the
services. As far as the client is concerned, the server is the middlebox.
What difference does it make if a given middlebox has more than one server?

---

From: "Melinda Shore" <[email-masked]>
Date: Wed, 18 Apr 2001 14:26:19 -0400

> What difference does it make if a given middlebox has more than one server?

A protocol between a server and middlebox absolutely
is out-of-scope.  However, we need to consider the case
of a multi-function middlebox - combined NAT/firewall,
etc.  In that case there's the possibility of having
multiple "servers" on the middlebox - one for each 
function.  I personally think that's not a particularly
desirable design, but we do have to consider that
possibility.

Melinda

---

From: Paul Sijben <[email-masked]>
Date: Thu, 19 Apr 2001 13:54:49 +0200

TIMEOUT!

as far as I am concerned the Middlebox IS a MIDCOM server. It is a server for
the protocol and the application or its proxy is a MIDCOM client.

The point I tried to make is that if we choose the terminology right, they are
not the ONLY clients and servers one may see, allowing the introduction of a
MIDCOM proxy, when (not if) we need it.

Paul

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 19 Apr 2001 09:10:45 -0400

> the protocol and the application or its proxy is a MIDCOM client.

We do need to address, however, the multifunction
middlebox.  They're very common (probably found more
often than not).  What I'd prefer to see happen here
is to choose terminology that's consistent with 
common usage and have it documented clearly in our
deliverables, making sure to resolve any ambiguities 
that might result from the particulars of what we're
doing.

Melinda

---

From: Scott Brim <[email-masked]>
Date: Thu, 19 Apr 2001 09:57:50 -0400

On Thu, Apr 19, 2001 at 09:10:45AM -0400, Melinda Shore wrote:
> middlebox.  

box != function (!!!).  There's a server FUNCTION etc.

One of the nice agreements to come out of the IETF meeting, and one that
I REALLY look forward to seeing in the new framework draft.

..Scott

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 19 Apr 2001 10:11:51 -0400

> box != function (!!!).  There's a server FUNCTION etc.

Understood.  That doesn't address, however, the
question of how to approach the situation in which
you've got a combined firewall/NAT.  There's the
possibility that each function may have its own
server/interface, or that there's a single server/
interface which demuxes and manages messages from
clients.

Melinda

---

From: Paul Sijben <[email-masked]>
Date: Thu, 19 Apr 2001 17:32:21 +0200

??????????

Now you got me seriously confused. Could you please explain why you think
that  these pose a problem?

Paul

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 19 Apr 2001 11:43:54 -0400

> that  these pose a problem?

I'd like us to take some care to avoid a situation
in which compliant implementations are not interoperable.
That would be a bummer.

If we say that a server is an interface to a function
and somebody (say, everybody) implements multiple functions
within their box, we want to make sure that we specify that
either one server controls multiple functions *or* that we've
explicitly addressed the implications of having multiple
servers running on a box.  Andrew has brought up the importance
of being able to manage the ordering of operations, and 
probably the easiest way to control that is single threading 
and atomicity.  If we're going to accept his requirement and 
we're going to reject atomicity/single threading as the way 
to handle the requirement, I think we need to document some 
very strong reasons for choosing a more complex approach.

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Apr 2001 11:12:38 -0500

Terminology matters. It's been pointed out in the midtax discussion
that "box" implies a physical box, which is why the Web folk mainly
talk about "intermediaries", and of course one physical box can contain
multiple intermediaries. I'll be tweaking the midtax draft to point
out that middle boxes are not in 1:1 correspondence with physical
boxes.

Over in network management land this is hardly a new concept; one box can
contain many MIBs but only needs one SNMP agent.

    Brian

---

From: "Michael W. Condry" <[email-masked]>
Date: Thu, 19 Apr 2001 10:36:32 -0700

Do not you need to re-charter or address this
in the future?
>that might result from the particulars of what we're

Michael W. Condry
Director, Network Edge Technology

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 19 Apr 2001 13:52:29 -0400

> Do not you need to re-charter or address this

I don't see why we would - what we're talking about here is
ensuring that the work we're chartered to do is clear and
correct.

Melinda

---

From: Paul Sijben <[email-masked]>
Date: Fri, 20 Apr 2001 13:49:29 +0200

> in which compliant implementations are not interoperable.

Sure. 
> servers running on a box.

Ah, there is the disconnect. Like I posted, way, way back when on either the
foglamps list or the TIPHON security list, I fully agree that there are
multiple functions to discern in one box. Such functions may be:

- filtering (or selective forwarding)
- flowspec policing
- header rewriting (which as I have been told is something different from NAT
which also may modify payload)
- etc.

Since all of these functions may happen on ONE packet flow, I would be very
unhappy if we were to insist that each will have a separate interface on the
box. I would rather see one protocol identifying the flow and several
parts/plugings/packages that can be used to identify what to do with it.

So I would like to see one MIDCOM server per flow. It may be the case that one
will find multiple MIDCOM servers on the same box but pertaining to different
flows.

Paul

>  Andrew has brought up the importance

---

From: "Shai Mohaban" <[email-masked]>
Date: Fri, 20 Apr 2001 08:55:31 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Paul Sijben
> Sent: Friday, April 20, 2001 4:49 AM
> To: Melinda Shore
> Cc: Scott Brim; [email-masked]
> Subject: Re: terminology (was Re: [midcom] Protocol Requirements
> Bullet List v2.0)
>
>
>
>
> Melinda Shore wrote:
> >

This might be true on a single MidBox but you might have multiple MidBoxes
in a row (e.g. one performing firewall/NAT while the other deals with QoS).
In that case you will have to have multiple MidCom servers per flow hence
the requirement.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Sat, 21 Apr 2001 21:49:38 -0500

There are a couple of concerns near the end of this thread with my thoughts
that I feel should be addressed further.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Abdallah Rayhan
> Sent: Wednesday, April 04, 2001 12:54 PM
> To: [email-masked]
> Subject: Re: [midcom] Protocol Requirements Bullet List v2.0
>
>
> See comments below.
>
> John Ladwig wrote:
> >

- Clients should not be allowed to communicate directly with a middlebox.
Proxies/midcom controllers should be the only devices to communicate with a
middlebox.

- Internal clients may need to obtain NAT bindings just as they would today
in a "traditional" scenario (where most internal clients are allowed to
initiate communications with the outside world.

In a situation like this, whether the midcom controller is internal to the
client or external (on the outside),

- the client should still receive its bindings and communicate with the
midcom controller, since we are talking protocol specific control such as
for SIP communications.

- The midcom controller, whether implemented as a function on the middlebox
or externally, will then communicate the pinholes/bindings on the middle
box.

For security the following should be adhered to in order to maintain
integrity of the middlebox. This doesnt protect the proxy from being fooled
into subverting the middlebox, but does shield the middlebox from direct
control from any external client.

- internal clients always communicate with the application proxy which
initiates the midcom protocol

- external clients always communicate with the application proxy to the
internal clients.

We are not touching the mechanisms to provide accountability between clients
and application proxies but we do segregate the middlebox from direct
control by folowing these guidelines.