Subject: RE: Fwd: [midcom] Changes in semantics (Version 05)

From: Wanqun Bao <[email-masked]>
Date: Fri, 10 Oct 2003 11:21:57 -0700

Hi, Martin,

Thanks for the response. I've removed all other discussions but
one below which I'd like to have more discussion.
See inlines.

Cheers,

Wanqun

> |> > Wanqun Wrote:
> |> >
> |> > Different
> |> > middle box may have different timeouts for its sessions. If
> |> one session
> |> > times
> |> > out(for example, one of the audio channels may not send
> |> data at all for a
> |> > period
> |> > of time), it can not be re-established if the 
> corresponding rule has
> |> > already
> |> > been removed.
> |>
> |> But that is the intention. If the corresponding policy 
> rule has been
> |> removed, the middlebox should block the stuff.
> |>
> | In order to prevent the situation I've discribed above(some of the
> | sessions might be timed out during a call), you have to 
> keep all the rules
> | around. As we know, in many cases(e.g. SIP), the rules has wildcards
> | attributes(cones). Sessions are tightest rules in a sense. 
> Keeping rules
> | around while having sessions derived from them not only 
> wastes resources
> | but decreases security as well(leaving holes on the 
> firewall during the
> | entire call).
> 
> I see the problem your are describing.
> For each audio channel you would setup a policy rule, isn't 
> it? If this 
> audio channel is dead and the corresponding NAT session is going to 
> timeout, the middlebox may remove the NAT session (plus a NAT 
> bind) and 
> sent a ARE notification to the agent indicating the deletion 
> of the policy 
> rule.
> But the scenario you are pointing to is when a audio channel 
> is dead for 
> the idle timeout, but it is from the SIP view still active 
> (Hope that is 
> the scenario). A solution for this is to set the policy rule 
> lifetime in 
> the beginning to the idle timeout for instance. The agent 
> should extend the 
> lifetime at the given time.
> 
There're two things I can see here:
1) Correct me if I'm wrong, current middlebox's rule is indenpendent
of the session derived from it. When a rule is timed out, the session
derived from it can still exist. If the session is timed out later, 
how can the middlebox send a notification to the agent? Again, my 
assumption here is that we don't want to keep rules around for the 
same duration while the derived sessions exist.
2) Even though if somehow the middlebox can send a notification to
the agent when a session is gone, it might be too late for the agent
to send a new PER to the middlebox since the the very session might
be alive again at any time and its packets will be dropped before the
new PER is in effect.

The key to this issue is that in order for application-enabled traffic
(e.g., SIP enabled media) to traverse middlebox, not only does a middlebox
rule need to have information for openning pinholes, but also it
needs to instruct a middlebox how to handle all the derived sessions as
far as timeout is concerned.

I can see for those middleboxes that don't use sessions, they have
to keep rules all the time during a call. But for those middleboxes
that do use sessions, making rules independent of sessions does
impose problems such as decreased security and increased resource
usage.

Again, if this has been discussed in the group before and there's a
consensus regarding this issue, I will not use this bandwidth to
discuss this further.

Thanks!

Wanqun

> 
> [...]
> 
> Regards
> Martin
> 
> 
> Martin Stiemerling
> 
> NEC Europe Ltd. -- Network Laboratories  [email-masked]
> PGP Key at:        http://www.stiemerling.org/stiemerling_nec.gpg
> IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de
> 

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

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 13 Oct 2003 18:03:23 +0200

Hi,

Sorry for the delayed answer, I'm currently on a trip.

|> I see the problem your are describing.
|> For each audio channel you would setup a policy rule, isn't
|> it? If this
|> audio channel is dead and the corresponding NAT session is going to
|> timeout, the middlebox may remove the NAT session (plus a NAT
|> bind) and
|> sent a ARE notification to the agent indicating the deletion
|> of the policy
|> rule.
|> But the scenario you are pointing to is when a audio channel
|> is dead for
|> the idle timeout, but it is from the SIP view still active
|> (Hope that is
|> the scenario). A solution for this is to set the policy rule
|> lifetime in
|> the beginning to the idle timeout for instance. The agent
|> should extend the
|> lifetime at the given time.
|>
| There're two things I can see here:
| 1) Correct me if I'm wrong, current middlebox's rule is indenpendent
| of the session derived from it. When a rule is timed out, the session
| derived from it can still exist.

I see the middlebox's policy rule is tightly related to any resource in the 
middlebox. So a session derived from a middlebox rule is active in the box 
as long as the policy rule is enabled.

|                                   If the session is timed out later,
| how can the middlebox send a notification to the agent? Again, my
| assumption here is that we don't want to keep rules around for the
| same duration while the derived sessions exist.

The assumption in the design is that rules are kept as long as the session 
in the middlebox must work. That again results in a tight couple between 
policy rules and middlebox resources such as binds and sessions.

| 2) Even though if somehow the middlebox can send a notification to
| the agent when a session is gone, it might be too late for the agent
| to send a new PER to the middlebox since the the very session might
| be alive again at any time and its packets will be dropped before the
| new PER is in effect.

The agent is in charge of taking care of policy rules. So the agent must 
track his policy rules and extend the lifetime if necessary.

|
| The key to this issue is that in order for application-enabled traffic
| (e.g., SIP enabled media) to traverse middlebox, not only does a middlebox
| rule need to have information for openning pinholes, but also it
| needs to instruct a middlebox how to handle all the derived sessions as
| far as timeout is concerned.

The point is for instance, a session in a NAT may extend the duration of 
the SIP session (due to the session timeout). But when the SIP session ends 
the agent should remover all policy rules for this SIP session (and thus 
remove all sessions as well). If the agent feels to keep the policy rules 
alive he can keep the policy rules and even extend their lifetimes.

In order to archive the tight couple between policy rules and 
binds/sessions, a modification to the NAT engine could be needed.

|
| I can see for those middleboxes that don't use sessions, they have
| to keep rules all the time during a call. But for those middleboxes
| that do use sessions, making rules independent of sessions does
| impose problems such as decreased security and increased resource
| usage.
|
| Again, if this has been discussed in the group before and there's a
| consensus regarding this issue, I will not use this bandwidth to
| discuss this further.

Of course your comments are welcome and it is very useful to discuss 
unclear points.

Cheers
Martin

|
| Thanks!
|
| Wanqun
|
|>
|> [...]
|>
|> Regards
|> Martin
|>
|>
|> Martin Stiemerling
|>
|> NEC Europe Ltd. -- Network Laboratories  [email-masked]
|> PGP Key at:        http://www.stiemerling.org/stiemerling_nec.gpg
|> IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de
|>

Martin Stiemerling