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

From: Wanqun Bao <[email-masked]>
Date: Wed, 8 Oct 2003 13:21:40 -0700

Hi Martin,

I have some comments inline and some general comments
regarding the draft following that.

Thanks,

Wanqun Bao

> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]]
> Sent: Wednesday, October 08, 2003 6:57 AM
> To: Pyda Srisuresh
> Cc: [email-masked]
> Subject: Re: Fwd: [midcom] Changes in semantics (Version 05)
> 
> 
> Hi Suresh,
> 
> thanks for checking the document again. More comments inline 
> and I hope on 
> more comments from other working group members.
> 
> Martin
> 
> --On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh 
> <[email-masked]> wrote:
> 
> | Hi,
> |
> | I briefly read through the draft this weekend. I still do 
> not believe, the
> | semantics is clear. The abstractions are not adequate to eliminate
> | ALGs from a middlebox.
> |
> | 1. Terminology - I do not believe, you should  proliferate 
> of semantics
> | for "NAT binding". This sounds like, it will be whatever 
> you want it to
> | be in sessing up a session.
> 
> The intention was not to proliferate, but more an approach to 
> bring more 
> light to issue of NAT binding. Do you think that it confuses 
> more than it 
> does help?
> 
> |
> | 2. PRR is still fuzzy. The PRR reserves a maximum of two IP 
> addresses (in
> | the case of twice-NAT) and/or several ports on an address. 
> Depending upon
> | what the agent lists in the request parameters, this can be 
> reservation
> | of an address bind, or reservation of a bunch of ports 
> (from a NAPT map
> | entry, presumably) or reservation of an address each from two map
> | entries. The middlebox returned rule identifier can 
> represent any of this
> | (Bind handle or single map reservation or two address map 
> reservations).
> | This is simply a lot of stuff in a single transaction. Very 
> difficult and
> | confusing for a middlebox to do this.
> 
> Yes, that may look confusing, but pushing the task to the 
> MIDCOM agent is 
> more even more confusing to him.
> 
My understanding is that a PID returned from the middlebox uniquely
identifies a rule which contains a tightly related set of reserved 
resources(either one or two IP addresses, transport type, and port
number(s)).
These resources will be used for creating pinholes using PER.

> |
> | Specifying the internal IP address helps in reserving a 
> pool of ports in
> | a NAPT case or an address BIND in the case of basic NAT. 
> But, that alone
> | is not adequate for twice-NAT. The transaction needs to include the
> | destinaion end-point. otherwise, PRR is not usable for 
> Twice-NAT for the
> | same reason the PRR was not usable for traditional NAT in 
> the previous
> | rev of the draft. The middlebox cannot pick up an arbitrary 
> address from
> | one of the map entries for twice-nat, not with just A0 in 
> the request
> | list.
> 
> The idea behind PRR is that the agent does not know the destination 
> address.
> 
> This is the case for example in SIP call set-up. Only the 
> data receiver in 
> the private address realm is known on the first INVITE, if 
> the caller is in 
> this private address realm. This is a very tricky thing and PRR does 
> provide a good mean to cope with that, even when it looks 
> somehow strange. 
> I could offer a powerpoint presentation from one of the IETF meetings 
> explaining the need for PRR if you like.
> 
A middlebox does not need A3 to reserve A1. To me, a reservation
can be made without its final binding peer. Binding is only
needed when a PER is made, which will be used for the flow session(the
actual traffic).
On the other hand, if A3 is known and presented in the PRR request,
later PER needs not to really mention A1 and A3(although they
can be used for verification purpose.)
What is interesting is that in the case of SIP, even after call is
set-up(an ACK is sent from the caller), we may not really know the
source IP for the media from both directions until they
actually arrive at the middle box(e.g., a media gateway uses one IP
for sending and another IP for receiving).

> |
> | As I said earlier, I suggest, the PRR be simplified split 
> up into doing
> | BIND reservations and MAP reservations independently.
> |
> | 3. PER should simply be labelled as session creation 
> request. The text in
> | the draft that refers this as BIND in some cases shoudl simply be
> | eliminated. PER essentially boils down to setting up NAT 
> sessions/flows
> | using pre-established binds or pre-reserved map entries or simply
> | creating a new session. When the session is created, the 
> response should
> | indicate the BINDs used, if any, and the translation 
> end-points for the
> | session.
> 
> You are right in saying that with PER a NAT session is 
> created. But for 
> instance consider this scenario:
> 
> A PER request with an internal address (A0) and a wildcarded external 
> sender (A3) (dataflow from outside to inside). The external 
> sender is not 
> known (One example is SIP early media). For that case you can 
> not start a 
> NAT session, since the NAT must create a NAT bind. Via this NAT bind 
> several UDP/RTP flows from several destinations may traverse 
> the middlebox 
> to A0.
> 
Just want to add that enabling a rule is not the same as creating
a session. A session is only created when actual traffic comes
and matches a rule.

> |
> | The twice-NAT example doesn't make sense. If the session is 
> between A0 &
> | A1 (as would be in the case of twice-NAT) the agent cannot 
> know A3 ahead
> | of time. However, that is what the PER request parametere 
> description
> | indicates.
> 
> Hmm, I don't see the issue you raise immediately.
> 
> A3 is the external end point and A1 the inside IP 
> address/port number at 
> the twice-NAT. The application level session is between A0 
> and A3, but the 
> IP/transport 'sessions' are between A0/A1 and A2/A3.
> 
> Could you give me some more hints?
> 
> 
> | 3. The document says in several places that the NAT is one 
> of traditional
> | NAT or Twice-NAT. What about bi-directional NAT? I saw this 
> mentioned
> | just once in PER description. When you support 
> bi-directional NAT, it is
> | important for the PRR and PERs to support sessions 
> initiated from the
> | outside, in additiona to sessions initiated from the 
> private realm. The
> | request parameters in PRR and PER are not adequate to support this.
> 
> That's not true. For PRR the direction is not relevant, since only a 
> resource reservation is made at the NAT. In PER there is the 
> flow direction 
> parameter that indicates the flow direction (inbound, outbound, or 
> bi-directional). So with this it is possible to allow even sessions 
> initiated from the outside.
> 
Does "direction of flow" applies only to the initial packet or to all the
subsequent
packets enabled by this rule?
For example, if the direction of flow is inbound and the protocol is UDP,
the first packet comes from external to internal(inbound), it matches a
rule and a session is created. Will the middlebox drop any outbound packet
that actually matches with the session created?
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.

> |
> | 4. I still have an issue with GroupId assignment being 
> mandated on the
> | middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 
> does not madate
> | this.
> 
> Right the protocol requirements do not mandate this, but as a 
> lot of other 
> points this is a design issue. So far nobody else has any 
> objection about 
> this.
> 
I think GroupId is really needed for efficiently managing resources(rules)
in 
the middle box.

I have some general comments regarding the draft:
1. Rule's lifetime
For PRR, it is simple: if a PRR is not replaced by a PER in its lifetime, it
will be removed. It's a resource cleanup and there's no security issues.
For PER, a rule is enabled(a pinhole is punched and in most cases, it's
a cone). If there's no packet that macthes with the rule within rule's
lifetime,
the rule is removed. But what happens to the rule after the first packet
matches
with rule and a session is created for the intended flow? In many cases, in
order
to tighten the security, the pinhole should be closed immediately after the
first
packet comes and a session is created. A new field in PER might be needed to
indicate that and the policy rule state machine should be modified
accordingly.

2. Flow sessions derived from rules
Forgive me if this has been discussed here before. In this draft, except
"direction of flow", handling of flow sessions is totally excluded.
Correct me if I'm wrong, MIDCOM is used to allow application-layer enabled
traffic to traverse the middlebox. Traverse does not stop after a flow
session
is created. From the current draft, if an agent creates a number of rules
under
a group, intended traffic will traverse the middle box. After all the rules
are timeout, the group with all its members(rules) is removed. What's left
in the middle box are the flow sessions derived from these rules. 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.
At the meantime, we don't want to keep rules around for a long time.
One way to solve this is to let an agent tell the middlebox to use a flow
session
timeout for the entire group. As long as there's one session in the group
that's 
alive within this timeout, none of the sessions within the group should be
timed out.

3. Group Lifetime
A group can be removed using GLC with lifetime being 0.
A group should be removed when there is no rule and derived session in the
group.
A group's lifetime should be reset whenever there's a request(except GLC
with
lifetime being 0) from the agent.
A group should be timed out using its lifetime which is independent to its
rules
and derived sessions(to clean up "dead" calls with media still sending.) 

4. In 2.3.9., should PER also include a "service" field?

Thanks,

Wanqun

> 
> |
> | That's all for now.
> 
> Thanks for the comments.
> Martin
> 
> [... cut by Martin ]
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
> 

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

---

From: [email-masked]
Date: Thu, 9 Oct 2003 15:59:53 -0000 (GMT)

Hi Wanqun Bao,

many thanks for your comments!

See answers inline.

Cheers
 Martin

> These resources will be used for creating pinholes using PER.

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.

> needed when a PER is made, which will be used for the flow session(the

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.

> can be used for verification purpose.)

As described above PRR is intended for cases when A3 is known in advance.
So it is needed to have A3 in the PER. A1 is needed in PER since there is
a unified PER transaction, independently of having a reserved policy rule
(via PRR) or or having not a reserved policy rule. We discussed earlier in
the working group, if it is wise to split PER into two different PER. The
consensus was not to split PER.

> for sending and another IP for receiving).

Fully agreed. That's the above scenario for SIP. In this case the PRR is
needed.

> a session. A session is only created when actual traffic comes

That depends on your implementation. Perhaps you implement the PER in a
way that you load sessions into your NAT. Perhaps not. I see that this is
a difference, but this should be up to the implementor.

> that actually matches with the session created?

Right. If 'inbound' is selected only inbound packets can traverse the
middlebox (necessary for configuration of firewall rules). So if you need
in and outbound packet flow for this specific flow you have to specifiy
bi-directional. TCP must use always bi-directional, otherwise it doesn't
make sense. The TCP and bi-directional should be stated in the semantics,
unfortunately I don't have them by now, so I can not show the section
where it is printed.

> specify it clearly in the doc.

Do you think that needs some clarification? Could you propose some text?

> I think GroupId is really needed for efficiently managing resources(rules)

Fully agreed!

> indicate that and the policy rule state machine should be modified

I feel that is an issue for local policies. If the sytem adiminstrator
feels that this is needed he can configure the box in that way. MIDCOM
provides the ARE (asyncrhonous rule event notification) in order to tell
the agent that the policy rule was removed.

> in the middle box are the flow sessions derived from these rules.

The middlebox part must take care about removing pending sessions. Though
if a policy rule is removed, the middlebox should free any resource that
has been allocated through this binding (the box should of course not
remove for example firewall rules and NAT configuration that is still
needed by other flows).

> Different

But that is the intention. If the corresponding policy rule has been
removed, the middlebox should block the stuff.

> 4. In 2.3.9., should PER also include a "service" field?

It was decided (in favor of having a unified PER, please see above) to go
this way: We you need to choose the service, you first must a PRR
transaction and afterwards you issue the PER transaction on the reserved
policy reserve rule.

> Thanks,

You are welcome and thank you again for the comments. I hope I have
answered the properly.

Cheers
 Martin

>> [... cut by Martin ]

-----------------------------------------
This email was sent using SquirrelMail.
   "Webmail for nuts!"
http://squirrelmail.org/