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

From: Wanqun Bao <[email-masked]>
Date: Thu, 9 Oct 2003 14:41:53 -0700

Martin,

Thanks very much for the answers. Please see the inline comments.

Wanqun

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 09, 2003 9:00 AM
> To: Wanqun Bao
> Cc: [email-masked]; [email-masked]
> Subject: RE: Fwd: [midcom] Changes in semantics (Version 05)
> 
> 
> Hi Wanqun Bao,
> 
> many thanks for your comments!
> 
> See answers inline.
> 
> Cheers
>  Martin
> 
> > 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.
> 
> 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.

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

> > 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.)
> 
> 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.
You meant PRR is intended for cases when A3 is NOT known. Right?

> 
> > 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).
> 
> Fully agreed. That's the above scenario for SIP. In this case 
> the PRR is
> needed.
> 
> >
> >> |
> >> | 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.
> 
> 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.
> 
> >
> >> |
> >> | 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?
> 
> 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.
> 
> 
> 
> > 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. 

> >
> >> |
> >> | 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.
> 
> Fully agreed!
> 
> >
> > 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.
> 
> 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.
> 
> >
> > 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.
> 
> 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
> > 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).

Thanks again,

Wanqun

> 
> > 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?
> 
> 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
> 
> >
> > 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
> >>
> >
> 
> 
> 
> -----------------------------------------
> This email was sent using SquirrelMail.
>    "Webmail for nuts!"
> http://squirrelmail.org/
> 

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

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 10 Oct 2003 12:36:06 +0200

Hi Wanqun,

I have checked the semantics for the semantics of inbound, outbound, and 
bi-directional.

The current meaning is meaningful for UDP streams, but lacks indeed a more 
precise semantics for TCP.
I would propose to say that for TCP:
- inbound: First packet must arrive at the outside of the middlebox
- outbound: First packet must arrive at the inside of the middlebox
- bi-directional: First packet can arrive either outside or inside of the 
firewall.

Thanks for pointing this out.

Cheers
Martin

--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.
|
| Wanqun
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]]
|> Sent: Thursday, October 09, 2003 9:00 AM
|> To: Wanqun Bao
|> Cc: [email-masked]; [email-masked]
|> Subject: RE: Fwd: [midcom] Changes in semantics (Version 05)
|>
|>
|> Hi Wanqun Bao,
|>
|> many thanks for your comments!
|>
|> See answers inline.
|>
|> Cheers
|>  Martin
|>
|> > 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.
|>
|> 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.
|
|> >
|> >> |
|> >> | 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).
|>
|> 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.
|
|
|> > 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.)
|>
|> 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.
| You meant PRR is intended for cases when A3 is NOT known. Right?
|
|>
|> > 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).
|>
|> Fully agreed. That's the above scenario for SIP. In this case
|> the PRR is
|> needed.
|>
|> >
|> >> |
|> >> | 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.
|>
|> 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.
|>
|> >
|> >> |
|> >> | 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?
|>
|> 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.
|>
|>
|>
|> > 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.
|
|> >
|> >> |
|> >> | 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.
|>
|> Fully agreed!
|>
|> >
|> > 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.
|>
|> 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.
|>
|> >
|> > 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.
|>
|> 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
|> > 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).
|
| Thanks again,
|
| Wanqun
|
|>
|> > 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?
|>
|> 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
|>
|> >
|> > 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
|> >>
|> >
|>
|>
|>
|> -----------------------------------------
|> This email was sent using SquirrelMail.
|>    "Webmail for nuts!"
|> http://squirrelmail.org/
|>

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