Subject: [midcom] SNMP proposal and transactional behavior

From: "Moisand, Jerome" <[email-masked]>
Date: Fri, 13 Dec 2002 09:09:36 -0500

Could somebody help me understand the following point? 

Say we have a VoIP scenario. With strong business constraints from a service
provider operating the middlebox of not allowing a VoIP/RTP session to flow
any longer than strictly necessary. Or strong security constraints from an
enterprise IT organization operating the middlebox (with same end
requirement).

Say some sort of SIP proxy ends up triggering a middlebox agent software,
which in turn pokes the appropriate hole in the middlebox via some form of
"midcom SNMP MIB". This "hole" is truly a dynamic state, which should be
removed whenever there is any doubt that the voice call is over.

Now say that the combination of the SIP proxy and the middlebox agent
software (functions may be actually colocated, but are probably pretty far
from the middlebox itself) loses connectivity with the middlebox for a
while. Then when the VoIP session is stopped via SIP (hence
accounting/billing -for time-based models- are stopped), the middlebox can't
know it via a regular SNMP set.

What will ensure that the "dynamic" state which has been created will
disappear? And disappear quickly enough? 

Note that a timer based on activity detection is not an answer, nothing says
that traffic is legit.

Tx
Jerome

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 13 Dec 2002 09:19:36 -0500

The Policy Rule lifetime may fulfill this role, though I would see it
operating at a granularity of minutes to keep Midcom traffic down.

> -----Original Message-----
> From: Moisand, Jerome [mailto:[email-masked]] 
> Sent: Friday, December 13, 2002 9:10 AM
> To: [email-masked]
> Subject: [midcom] SNMP proposal and transactional behavior
> 
> 
> 
> Say we have a VoIP scenario. With strong business constraints 
> from a service provider operating the middlebox of not 
> allowing a VoIP/RTP session to flow any longer than strictly 
> necessary. Or strong security constraints from an enterprise 
> IT organization operating the middlebox (with same end requirement).
> 
> Say some sort of SIP proxy ends up triggering a middlebox 
> agent software, which in turn pokes the appropriate hole in 
> the middlebox via some form of "midcom SNMP MIB". This "hole" 
> is truly a dynamic state, which should be removed whenever 
> there is any doubt that the voice call is over.
> 
> Now say that the combination of the SIP proxy and the 
> middlebox agent software (functions may be actually 
> colocated, but are probably pretty far from the middlebox 
> itself) loses connectivity with the middlebox for a while. 
> Then when the VoIP session is stopped via SIP (hence 
> accounting/billing -for time-based models- are stopped), the 
> middlebox can't know it via a regular SNMP set.
> 
> What will ensure that the "dynamic" state which has been 
> created will disappear? And disappear quickly enough? 
> 
> Note that a timer based on activity detection is not an 
> answer, nothing says that traffic is legit.
> 
> Tx
> Jerome
>

---

From: "Moisand, Jerome" <[email-masked]>
Date: Fri, 13 Dec 2002 13:13:53 -0500

Er... does this imply that each policy rule would have to be "refreshed"
every few minutes? If I properly understood you, then I'm afraid this is a
troublesome scaling issue? 

Plus this would imply states on the middlebox application, isn't it?

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 13 Dec 2002 14:00:29 -0500

The nature of policy rules for NATs and firewalls is that they are
transient.  They are assigned a lifetime when they are created (see the
semantics draft for details), and expire at the end of that life unless
renewed.  Some rules (giving access to servers, perhaps) may need a long
lifetime (are more or less permanent).  Others relate to a session which
typically will last minutes.

Yes, there's lots of state in the middlebox application.

> Sent: Friday, December 13, 2002 1:14 PM
> To: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]
> Er... does this imply that each policy rule would have to be 
> "refreshed" every few minutes? If I properly understood you, 
> then I'm afraid this is a troublesome scaling issue? 
> 
> The Policy Rule lifetime may fulfill this role, though I 
> would see it operating at a granularity of minutes to keep 
> Midcom traffic down.
>