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

From: Martin Stiemerling <[email-masked]>
Date: Thu, 02 Oct 2003 16:44:02 +0200

Hello folks,

I have submitted an updated version of the semantics (Version 05). The 
version is available in advance here:

ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-midcom-semantics-05.t
xt

The changes in this version are:

- Policy Rule List (PRL) and Policy Rule Status (PRS) are now mandatory.
  (Based on comments from Juergen Schoenwaelder)

- Fixed comments from Daniel
  - Text in Section 2.1.8
  - Figure 2, (mc=0) inserted text before Figure 2
  - Text in 2.3.6  about IPv4 and IPv6 changed
  - in PRR mode parameter changed to service parameter, adapted text
    on middlebox modes
  - Fixed failure text in RLC
  - fixed all text errors

- added middlebox (NAT) policy rule idle-timeout to middlebox's capabilities
  with a link to ARE
- added 'optional interface specific policy rules' capability to
  capability list
- inserted new chapter "Interface specific Policy Rules"
- adapted references in whole text to the new numbering due to issue one
  above
- added optional inside/outside interface parameter to PRS (2.3.12)
- added optional inside/outside interface parameter to PRR (2.3.8)
   - added to request parameter list
   - added corresponding failure reasons
   - added semantical descriptions
- added optional inside/outside interface parameter to PER (2.3.8)
   - added to request parameter list
   - added corresponding failure reasons
   - added semantical descriptions
- added statements in conformance section
- checked spelling
- added A0 parameter to PRR transaction (Pyda's comment)
   - added PRR/A0 statement to PER
- added text about Pyda's concern w.r.t. reserved outside NATed addresses
  in PRR :
  Once a PRR transaction has reserved an outside address (A2) for an
  internal end point (A0) at the middlebox, the middlebox must ensure that
  this reserved A2 is available in any subsequent PER and PRR transaction.
- added paragraph about NAT terminology in terminology section
- revised examples to reflect changes in semantics

With best regards

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: Fri, 10 Oct 2003 12:18:59 +0200

Wanqun,

--On Thursday, October 09, 2003 14:41:53 -0700 Wanqun Bao 
<[email-masked]> wrote:

| Martin,
|
| Thanks very much for the answers. Please see the inline comments.

You are welcome! I have shortened the email to the necessary parts, since 
I'm sitting on small bandwidth line.

Martin

[...]

|> A PID returned from the middlebox identifiers a midcom policy
|> rule, which
|> may infact represent multiple firewall rules and NAT
|> configuration. The
|> PID out of the PRR is used for creating policy rules in PER,
|> that's right.
|>
| Agreed. But as long as an agent wants to manage these derived
| firewall rules and NAT mappings as a whole(a midcom policy
| rule), a single PID is enough.

Right, a single PID is enough. The idea behind a PRR PID and (perhaps) a 
different PER PID is to leave some flexibility to the implementors. Ideally 
the both PIDs are the same.

[...]

|> Right, but you can use PRR to reserve A1 and you get A2 as
|> well. In PRR
|> you don't need to know the external peer's address. As for
|> instance in a
|> SIP call from a peer behind a NAT: On the first INVITE you
|> don't know the
|> peer's address on the other side (the callee). In this case
|> you can use
|> PRR  or PER in the case you want to support SIP early media.
|>
| Agreed. In terms of supporting SIP early media, if PRR then PER
| is used, there's a chance that the some of the early media
| will be dropped by the middlebox within the window between right
| after the callee gets the INVITE and starts sending early media and
| before the moddlebox processing the PER. Depending on the situation,
| this window may not be small because the agent only sends PER out
| after it receives 200 OK.

Agreed.

[...]
|>
|>
|> > What about if the protocol is TCP?
|> > If the direction of flow really applies to the initial
|> packet, we need
|> > specify it clearly in the doc.
|>
|> Do you think that needs some clarification? Could you propose
|> some text?
|>
| There's a difference between the direction of the initial packet
| and the direction of the flow(all the packets). Based on
| your explanation, the "direction of flow" refers to the later. This's
| fine.
| What's interesting is that if there's a field that indicates the direction
| of the initial packet, we can effectively tighten the rule. For example,
| in the case of TCP, the direction of flow has to be bi-directional, which
| allows both internal and external to initiate a session. If a direction of
| initial packet is used and set to either "inbound" or "outboud", which
| can effectively allow only one direction of initiation.

Yes, you are right. I have to check this in the semantics and coming back 
in again on that.

[...]

|> > 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.

[...]

Regards
Martin

Martin Stiemerling