Subject: RE: [midcom] policy & duration

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 8 Aug 2001 16:50:20 -0700

> -----Original Message-----
> From: Andrew Molitor [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2001 4:36 PM
> To: [email-masked]
> Subject: RE: [midcom] policy & duration
> 
> 
> 
> 
> On Wed, 8 Aug 2001, Reinaldo Penno wrote:
> 
> > Forget me if I got the wrong impression, but browsing 
> through the emails on
> > the list if seems that we want to take the intelligence out of the
> > middlebox...but not quite. It seems we are taking out 
> intelligence of a
> > middlebox that's not that intelligent, since we are not 
> asking much from the
> > capabilities of the agent.
> 
> 	We say this, I think. I think we MEAN that we want to remove
> application specific code from the middlebox. 

Hello Andrew,

But when  you remove, for instance, SIP specific code from my middlebox, you
also remove the possibility of interaction that the SIP code had with other
parts of the system (routing processes, interface manager, firewall, etc).

So, unless you compensate that somehow so that the MA can send me extended
information beside the 5/6 tuple, the MA will never be able to open
pinholes/NAT for complex deployments since it has very little knowledge the
system. 

regards,

Reinaldo

I am all for lots of
> intelligence in middleboxes, just nothing specific to SIP or whatever.

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

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 8 Aug 2001 18:58:36 -0500 (CDT)

> pinholes/NAT for complex deployments since it has very little knowledge the

	I think it's important to figure out what those essential
interactions are between your SIP code and the routing processes,
interface manager, firewall, etc. Presumably the SIP code interacts
with many things non-SIP, some of those things are sort of network-ish,
and some of THOSE things might naturally fall into a middlebox.

	Whatever interactions can be reasonably imagined between
say, SIP code and such middleboxy non-SIP things should be well
understood before we go much further. The point of MIDCOM is, to
first order, to develop a protocol expressive enough to capture
those interactions. If we fail to produce something powerful enough
for, say, the SIP community, we have failed entirely.

	I don't actually know what, apart from 5-tuples and masks
for them needs to get carted around in these interactions. That much
information seems to work fairly well for pinholes and NAT bindings,
at any rate. Well, it's nice to be able to carry around things
like expected bandwidth and pinhole lifetime and whatnot, is this
the kind of thing you mean? Or do you want to open a pinhole for
RTP traffic, and be able to specify approximately what RTP traffic
looks like BEYOND 'UDP traffic from that place to this other place'?
Things like size of packet, expected values at expected offsets in
the payload?

		Andrew