Subject: [midcom] Changes in the semantics I-D

From: Martin Stiemerling <[email-masked]>
Date: Mon, 17 Mar 2003 18:52:51 +0100

Hi,

as posted earlier on this list a new version of the MIDCOM semantics I-D 
is available. The major changes in this version are:

- Complete reworked group behaviour:
As agreed the groups are not created explicitly by the Group 
Establishment (GE) transaction anymore, but they are created implicit 
through a PER or PRR transactions type. A group is deleted after the 
last policy rule of this pariticular group has been deleted. There is no 
lifetime of a group anymore. The lifetime a group is equal to the 
maximum of all policy rule lifetimes. So the GE transaction is dropped, 
as well as the AGD notification.

- reworked the draft regarding wildcarding, address and transport 
address in order to provide a more clear view on this topic

- adapted the examples to latest changes

Martin

-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
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: "Bob Penfield" <[email-masked]>
Date: Tue, 18 Mar 2003 14:16:30 -0500

In section 2.3.6 the document states:

      When receiving the request, the middlebox determines how many
      address (and port) reservations are required based on its
      configuration.

I believe that section 2.2.2 of RFC 3304 requires that the agent be able to
indicate to the middlebox the desired function.

   The Midcom protocol must support the ability of an agent to install a
   ruleset that governs multiple types of middlebox actions (e.g.
   firewall and NAT).

   This states that a the protocol must support rules and actions for a
   variety of types of middleboxes.  A Midcom agent ought to be able to
   have a single Midcom session with a middlebox and use the Midcom
   interface on the middlebox to interface with different middlebox
   functions on the same middlebox interface.

This clearly states that the protocol must support a scenario where a given
middlebox provides multiple functions and that the agent can specify which
of those functions it wants for a given ruleset basis.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 18 Mar 2003 14:24:24 -0500

Although there is not an explicit requirement in RFC 3304, I believe that
most people agree that there are scenarios where the middlebox should not
delete the policy rules when the network connection to the agent is
interrupted (as section 2.2.4 indicates). When there is a redundant agent
and there is a failover to the redundant agent, the flows need to stay up in
the middlebox.

Either this should be left to the local policy/configuration of the
middlebox, or there should be a request parameter in the PER or the SE that
indicates whether or not policy rules are deleted in the event of
interruption of the network connection with the session agent.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Tom Taylor <[email-masked]>
Date: Tue, 18 Mar 2003 15:43:48 -0500

My reading of this section was that loss of the network connection implied loss of 
the session, not any loss of policy rules.  I am a bit uneasy about this: I feel 
that as stated it excessively confounds the application and transport levels.  I 
would prefer text that said:

"If the protocol has been defined in such a way that loss of the network connection 
between the agent and the middlebox implies loss of integrity of the MIDCOM session, 
the session MUST be terminated when the network connection is lost."

---

From: Tom Taylor <[email-masked]>
Date: Tue, 18 Mar 2003 15:47:20 -0500

If this is a consensus reading of the requirements, I suspect it requires a major 
rewrite of the existing semantics.  I think I can see justification for your 
interpretation, but up to now I understood the requirement to be that one should be 
able to tell the middlebox to 'do its thing' whatever the combination of actions 
that 'thing' implies.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 18 Mar 2003 22:25:02 +0100

Hi Bob,

Thanks a lot for reviewing the semantics!

> of those functions it wants for a given ruleset basis.

That's an interesting comment that probably will end up in some clarifications
added to the semantics.

We (at least intend to) realize section 2.2.2 of RFC 3304 by having just an
"enable" policy action telling the middlebox: Whatever you need to do for realizing
this, please do so. This includes all required pinhole creations and binding
establishments, inependent of the type of middlebox. In general, the agent should
be able to communicate with the middlebox without considering what kind of box
it is talking to.

The phrase you cited

>       address (and port) reservations are required based on its

is probably misleading as it is written now. It just replects that
  - a firewall does not need to perform any reservation
  - a traditonal NAT only needs to perform reservations on the external
    side
  - a twice-NAT needs to perform reservations on the external side as
    well as on the internal side.

The middlebox then returns the reservations made.

I think that this completely meets the the requirement stated in
section 2.2.2 of RFC 3304.

Cheers,

    Juergen

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 18 Mar 2003 22:30:14 +0100

Hi Bob,

thanks for reading the draft and your comments! Please find my comments 
inline.

Martin

>    ruleset that governs multiple types of middlebox actions (e.g.

The semantics support meet this requirement fully. Since the agent is 
able to install policy rulesets that govern multiple types of middlebox 
actions. The policy rules given by the middlebox agent to the middlebox 
may splitted internally in the middlebox to multiple actions, like 
packetfilter-NAT-packetfilter or only NAT-packetfilter (please read this 
as the combination of packetfilters and NATs). So the policy rule may 
comprise two packetfilter actions and a NAT mapping. If you assume that 
the agent should be able to indicate the action, the agent must be aware 
about the actuall configuration of the middlebox, whereas configuration 
is meant as: Where are the packet filters and NATs in the datagram flow.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 18 Mar 2003 22:31:55 +0100

Bob,

> interrupted (as section 2.2.4 indicates). When there is a redundant agent

This seems to be a misunderstanding. Section 2.2.4 states "same [effect] as
for the Asynchronous Session Terminaltion. In section 2.2.3 on Asynchronous
Session Terminaltion it is started that

    After session terminationthe middlebox keeps all established
    policy rules until thier lifetime expires or until an event occurs
    on which the middlebox terminates them.

So no policy rules are deleted on session interruption by the network.

Cheers,

    Juergen

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 18 Mar 2003 22:38:42 +0100

> and there is a failover to the redundant agent, the flows need to stay up in

I agree that a loss in network connection should not result in deleting 
all corresponding policy rules (nice DOS attack :).
The semantics say in 2.2.4 that the effect on network connection loss is 
the same as in 2.2.3 AST. This section says in the last sentence:

"After session termination the middlebox keeps all established
policy rules until their lifetime expires or until an event occurs
on which the middlebox terminates them."

So the middlebox keeps the policy rules until their lifetime expires.
Do you think that this behaviour is OK? So a failover agent could take 
over the rules as long as the policy rules do not timeout.

> interruption of the network connection with the session agent.

Good question. I would propose to append to the above statement 
something like "depending on local configuration".

Thanks again for reading it :)

Cheers
Martin

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 18 Mar 2003 17:34:08 -0500

My point was that if the agent is talking to a middlebox that can do both
NAPT and Twice-NAT, and the agent wants one or the other, it should be able
to tell the middlebox which type it wants.

The primary motivation for the original requirement was to be able to obtain
a NAT binding and open the firewall pin-hole in a single transaction as
opposed to two separate transaction and the semantics reflect that.

I have always believed that this requirement meant that the agent could
indicate which function or functions it wanted that the middlebox provided.

For example, with a middlebox that provides traditional NAT functionality
(i.e. NAPT on packets it sees rather than at the request of an agent) may
have Twice-NAT capability and a VOIP midcom agent wants both an inside and
an outside address when enabling an RTP flow.

Why do we need to restrict the agent to one type of middlebox function?

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Martin Stiemerling"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 18, 2003 4:25 PM
Subject: Re: [midcom] semantics does not allow agent to specify middlebox
function

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 18 Mar 2003 17:38:50 -0500

sorry, my mistake.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Martin Stiemerling"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 18, 2003 4:31 PM
Subject: Re: [midcom] semantics do now allow for agent failover

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 18 Mar 2003 17:36:16 -0500

see inline

----- Original Message -----
> is meant as: Where are the packet filters and NATs in the datagram flow.

If the middlebox is capable of both NAPT and Twice-NAT, how does the
middlebox know which one the agent wants?

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 18 Mar 2003 23:51:50 +0100

A basic question of understanding (inline):

> middlebox know which one the agent wants?

Are there middleboxes out there in operation that can do either NAPT or 
twice-NAT and switch instantly?
With NAPT you mean Network Address and Port Translation, right?

Martin

---

From: "Adina Simu \(asimu\)" <[email-masked]>
Date: Tue, 18 Mar 2003 16:24:57 -0800

There are middleboxes which can do both -- based on criteria like one of
the addresses, both addresses, direction of traffic, etc. one or both
types of translations are used.

-Adina

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Martin Stiemerling
> Sent: Tuesday, March 18, 2003 2:52 PM
> To: Bob Penfield
> Cc: [email-masked]
> Subject: Re: [midcom] semantics does not allow agent to 
> specify middleboxfunction
> 
> 
> >>>   This states that a the protocol must support rules and 
> actions for 
> >>> a
>

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 19 Mar 2003 01:31:38 +0100

Hi Bob,

> to tell the middlebox which type it wants.

The PRR request message contains a parameter (transport protocol) indicating
whether a NAT or NAPT service is requested by the agent. This is (hopefully
in a clear way) explained in the new section 2.3.5.

So - at least for your example - the agent can chose between the NAPT and the
twice-NAT.

I would not exclude the possibility that there are scenarios that are not
supported by our semantics, but so far, we did not find any. Further input
on this is very welcome.

Cheers,

    Juergen

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 18 Mar 2003 21:27:33 -0500

----- Original Message -----

> With NAPT you mean Network Address and Port Translation, right?

I know of at least one box that is capable of NAPT and Twice-NAT (actually
twice-NAPT) on a rule-by-rule basis.

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 18 Mar 2003 21:35:59 -0500

The twice-NAT in my scenario is actually twice-NAPT. It needs to reserve and
ip-address/port pair on the inside and the outside.

At one point (I think in Tom's early draft), the was a "CHOOSE" wildcard
that could be specified as the internal or external address+port request
parameter that would indicate to the middlebox that it needs to
select/reserve a address-port. Alternatively a parameter indicated which
ones (none, internal, external, or both) need to be selected be useful.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Martin Stiemerling"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 18, 2003 7:31 PM
Subject: Re: [midcom] semantics does not allow agent to specify middlebox
function

> >> > I believe that section 2.2.2 of RFC 3304 requires that the agent be
able
> > to
> >> We (at least intend to) realize section 2.2.2 of RFC 3304 by having
just
> > an
> >> "enable" policy action telling the middlebox: Whatever you need to do
for
> > realizing
> >> establishments, inependent of the type of middlebox. In general, the
agent
> > should
> >> be able to communicate with the middlebox without considering what kind
of
> > box
> >> >> last policy rule of this pariticular group has been deleted. There
is
> > no

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 21 Mar 2003 14:48:11 +0100

Ok, I see.

Thanks
Martin

Adina Simu (asimu) wrote:

>>>If the middlebox is capable of both NAPT and Twice-NAT, how 
>>>      
>>>
>>does the 
>>    
>>

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 21 Mar 2003 14:50:04 +0100

>twice-NAPT) on a rule-by-rule basis.
Ok, thanks, we will consider this, as Juergen told before, in the next 
version of the semantics.

Thanks for the hint
Martin