Subject: [midcom] clarification requested on middlebox concept

From: "Jerome Moisand" <[email-masked]>
Date: Wed, 27 Nov 2002 10:40:25 -0500

Sorry, guys, still trying to catch up.... Help welcome.

The middlecom charter says:
<<
As trusted third parties are increasingly being asked to make policy decisions on behalf of the various entities participating in an application's operation, a need has developed for applications to be able to communicate their needs to the devices in the network that provide transport policy enforcement. Examples of these devices include firewalls, network address translators (both within and between address families), signature management for intrusion detection systems, and multimedia buffer management. These devices are a subset of what can be referred to as 'middleboxes.' 
This working group will focus its attention on communication with firewalls and network address translators (including translation between IPv6 and IPv4). Work will not preclude extensibility to other categories of middle box. 

Well, it seems to me that edge routers (where service & subscriber management is typically enforced) are a very good fit for this 'middlebox' definition. That is, for a service provider environment of course.

I've participated to multiple discussions about multimedia flows (VoIP, video, whatever) in various contexts (DSL, Cable, Metro-Eth, GPRS, etc), and I did hear Service providers express a clear desire to control such sessions on an individual basis (filtering unwanted traffic -all voice calls will get charged!-, doing session-based admission control to guarantee the level of service, enforcing differentiated QoS levels depending on the type of flow but also on the subscriber subscriptions, etc).

Some think that functions like NAT or Firewalling may also belong to such 'edge router' space, some do not. 

In any case, it seems to me that we should keep in mind a bigger picture where such 'midcom' transaction (say triggered by a SIP proxy of some sort, or a Video app server, etc) would not only act in the NAT/FW side of things, but also on the QoS side of things.

Sure, in such a larger picture, some may argue that the RSVP scheme from a CPE device is the way to go. Personally, I'm not sure to agree with such view, but in any case, I don't see a fundamental difference between poking per-session holes in a NAT/FW for a multimedia session, or working with filters and attach a QoS profile to an edge router subscriber interface. And the midcom control protocol design should then be similar.

Ok, so please, don't flame me on the RSVP comments, I JUST would like to understand if I properly understood the 'middlebox' concept and if a service/subscriber-oriented edge router qualifies.

Tx

Jerome

PS. going down this "multimedia control" route also begs the question of why MGCP/Megaco was not considered as a possible 'midcom' protocol candidate? Don't misread me, I'm not saying this is the right choice, just asking questions to better understand the history of the discussion.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Nov 2002 10:51:29 -0500

> In any case, it seems to me that we should keep in mind a bigger picture =
> where such 'midcom' transaction (say triggered by a SIP proxy of some =
> sort, or a Video app server, etc) would not only act in the NAT/FW side =
> of things, but also on the QoS side of things.

QoS is specifically out of scope.

> Sure, in such a larger picture, some may argue that the RSVP scheme from =
> a CPE device is the way to go. 

The NSIS working group is discussing an RSVP-like protocol
that will be used for QoS signaling and also middlebox
communication. 

> PS. going down this "multimedia control" route also begs the question of =
> why MGCP/Megaco was not considered as a possible 'midcom' protocol =
> candidate? 

It is still in the running - please read draft-ietf-midcom-
protocol-eval-06.txt.

Melinda
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Jerome Moisand" <[email-masked]>
Date: Wed, 27 Nov 2002 16:42:42 -0500

Melinda,

thanks for answering. See a few comments below.

Still, I'm still struggling a bit with what exactly is meant by middlebox
(in its largest meaning), so what's the answer to my initial question?
=> "I would like to understand if I properly understood the 'middlebox'
concept and if a service/subscriber-oriented edge router qualifies."

> > In any case, it seems to me that we should keep in mind a bigger picture
> > where such 'midcom' transaction (say triggered by a SIP proxy of some
> > sort, or a Video app server, etc) would not only act in the NAT/FW side

Well, for sure, QoS settings can be achieved by existing mechanisms (e.g.
SNMPv3 and Diffserv MIB, or COPS/COPS-PR and Diffserv PIB), but still, my
point is that in the context of a NAT/FW middlebox with QoS capabilities
(e.g. service-oriented edge router), one would want to perform a single
transaction taking care of all settings (NAT-oriented, FW-oriented,
QoS-oriented) for a given multimedia session. So the solution for NAT/FW
settings needs to be consistent with the solution for QoS settings.

This being said, this observation may not help a lot, since SNMPv3, COPS and
Diameter are all capable of provisioning QoS-related parameters. Although I
would argue that SNMPv3 transaction properties are pretty weak, notably when
performing a combination of operations. Ok, SNMP fans, shoot now!   ;-)

> > Sure, in such a larger picture, some may argue that the RSVP scheme from

Hmmm, I didn't know that. Interesting. Here is a good point for COPS, then.

Because if the policy decision is outsourced (QoS, NAT, FW, whatever), then
in an RSVP-like model, the middlebox will have to request a policy decision
to an external policy server (a policy "pull"). Where in a model where the
decision comes from an application server (e.g. SIP proxy) triggering a
policy server, then this is a "policy push". Personally, I believe both
models (pull and push) are valid. Only COPS can accomodate both.

Probably not a point strong enough for a decision, but still a good point.

Ok, enough for today. Happy Thanksgiving, all.

Cheers,
Jerome

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 28 Nov 2002 10:39:07 +0100

Hi Jerome,

just a quick shot (inline):

Jerome Moisand wrote:
[...]

> Hmmm, I didn't know that. Interesting. Here is a good point for COPS, then.

You should first read the framework and requirements for Midcom in 
advance, since the COPS protocol and Midcom have (cite the meeting 
minutes from 54th IETF in Yokohoma) "a glaring mismatch" in their framework.

-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

---

From: Scott W Brim <[email-masked]>
Date: Fri, 29 Nov 2002 12:14:52 -0500

> concept and if a service/subscriber-oriented edge router qualifies."

In the general sense of the term, yes, I believe so.  In RFC 3234 we
punted and just said "any intermediary box performing functions apart
from normal, standard functions of an IP router on the data path between
a source host and destination host".  That sort of begs the question of
what's "normal".  IMHO an intermediary which is explicitly interacted
with at a layer above TCP/UDP is not a middlebox, since the IP-layer e2e
interaction is between the end system and the intermediary -- there is
nothing exotic going on.  

Intermediaries which alter packets, or spoof or constrain TCP acks, can
be considered as middleboxes (imho).  Intermediaries which mess with the
diffserv field are not, since that is the intermediaries'
responsibility.  Tunnel endpoints are not exactly middleboxes, in that
they act a lot like ordinary interfaces, but they allow packets to
disappear and reappear in an area which might have completely different
context, e.g. address scope rules.  RFC 3234 is an unfinished bit of
work. 

..Scott

---

From: "Jerome Moisand" <[email-masked]>
Date: Fri, 29 Nov 2002 17:16:25 -0500

Scott (Brim), thanks for the clarification. This really helped crystallize
my
thoughts. So ready for a long windy e-mail?  ;-)

Describing a middlebox as you did, an edge router which enforces
subscriber-specific and service-specific processing (filtering, QoS, policy
routing, metering/accounting, etc) on a given data flow (e.g. multimedia or
else) can be viewed as a middlebox, and this was definitely my gut feeling.

Consequently, I believe it is a useful exercize to make parallels between
the midcom (voluntarily focused) problem space, and QoS enforcement
problem space. And also to wonder how to deal with network elements
which happen to be capable to performing several types of functions
(e.g. QoS, Filtering, NAT, FW, etc).

My first thought when first looking at the midcom charter (and -voluntarily-
before reading the proposed architecture/requirements) was to say: ok, this
is nothing but a couple of additional policy rules, more geared at filtering
packets & translating IP addresses than the usual QoS stuff. So it looks
like a natural extension of the QoS/Diffserv policy-based and very stateful
approach described in the "rap" policy framework, and addressed by two
different types of model:
1. a "pull" model (e.g. coupling RSVP and COPS) driven by inband signaling
2. a "push" model (e.g. COPS-PR) driven by an application decision.

So my first conclusion was "let's just define the appropriate COPS
PIB and we're done".

Now, when I read the midcom framework/requirements and, afterwards, when
trying to understand the controversy about COPS directionality, it became
apparent that the issues are linked to the emergence of a third model,
allowing multiple instances of stateless proxies to push policy rules to
the network element (e.g. router/nat/fw).

Well, yes, such model was never envisioned by the COPS designers.
Admittedly, it looks a bit strange to perform session management
(which is a very stateful activity) using stateless proxies, but the SIP
designers clearly demonstrated the value of such architecture (note
that, wisely, they didn't exclude a stateful approach either).

So it seems to me that we have at least three equally valuable architectures
when outsourcing decisions:
* decisions triggerred by an inband protocol (ala RSVP/NSIS) => here I
believe only COPS addresses this scheme in a satisfying manner
* decisions triggerred by an application, which communicates with a stateful
policy server => COPS-PR works well, but many people think that SNMPv3 (or
even the dreaded CLI) would do the job.
* decisions triggerred by an application which can be stateless (ala SIP
proxy) => COPS doesn't work well here (at least as currently defined), and I
can see the point of using SNMPv3 (or even the dreaded... ok, forget it ;-).

Frankly, what disturbs me a lot about the existing midcom framework &
requirements is that it is clearly stirred at a given model (the 3rd one),
to the exclusion of other models. And I don't believe this is right.

I can see scenarios where either one of these models is significantly
better than the others. And I believe this is the root cause of the ongoing
protocol controversy.

Ok, maybe I'm just being a pain, but this brings me to a key question:
given this reasoning, given the NSIS "extended charter" factor, shouldn't
the 'midcom' framework be extended to accomodate several
models/architecture? And isn't that the way to exit the
current deadlock where the group appears to be stuck in?

Cheers,
Jerome

PS. Apologies to Diameter fans, I excluded it from my reasoning for
simplicity sake, and also... well, because philosophically I have a bit of a
hard time to envision a AAA protocol for such 'midcom' application. But no
doubt some of you would clearly disagree. Anyway, my main point is not about
protocols, but more about framework models & related architectures.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 29 Nov 2002 17:43:25 -0500

One of the unfortunate things that's happened in the IETF
over the past <n> years is the drift away from architectural
frameworks that are idiomatic to IP - i.e. they interwork
with IP, particularly routing and topology, really, really
poorly.  I personally think that midcom is one of these, but
even if we were to go to end-to-end, on-path signaling
there's a need to have application endpoints (or proxies,
another can of worms) communicate directly with various
sorts of individual middleboxes which may not be on a data
path (or cannot be "known" to be on one).  

The notion of having devices in the network make
determinations and push those out to the endpoints has the
smell of Bell about it.  It's typically not something that
will work well in IP networks, where making network elements
visible to application endpoints can create a host of
problems, ranging from lack of robustness to inter-layer
duplication of function to inability to scale with the
number of endpoints.

By the way, I don't think there is an "ongoing protocol
controversy."  There's been very little discussion at all.
If there's lack of progress it's because of lack of input,
not because participants in the working group are at
loggerheads.

Melinda