Subject: [midcom] Re: Midcom Semantics: Reserve vs. Address-Bind

From: Juergen Quittek <[email-masked]>
Date: Tue, 01 Oct 2002 11:27:30 +0200

Tom,

We see our approach rather as a one-step approach with a rare exception.
In most cases just the integrated (second) step of binding and enabling
is required. Only for very special scenarios, where the agent has
insufficient information, the (first) reservation step is required.

You split the actions required into two steps that are always reqired.
In contrary, we split the actions into one that is usually sufficient
and one that is only required additionally in rather rare special cases
where the agent lacks sufficient information for just performing a
single step.

You say you belive that in case of twice-NAT, three steps would be
required with our approach in some cases. We tried hard to find such
a case, but we did not find any. Could you give us an example where
our approach would require three steps?

    Juergen

-- Tom-PT Taylor wrote on 30 September 2002 20:21 -0400:

> In my analysis of Midcom semantics as presented in
> draft-taylor-midcom-semgen-00.txt, I separate rule instantiation into two
> phases: address binding and flow enabling.  In
> draft-stiemerling-midcom-semantics-02.txt the separation instead is into
> address reservation and flow enabling.  I have to ask the Working Group:
> which is a more realistic view of Middlebox operation?
>
> Just to show the difference: according to my analysis, setting up a combined
> NAT-firewall operation is done in two steps:
>
> (1) Provide the "actual" source and destination address-ports (one or the
> other may be "ANY"), and request a binding.  The middlebox will return the
> intermediate source and destination addresses associated with the binding.
> In the twice-NAT case both of these will correspond to interfaces on the
> middlebox itself.  Otherwise at least one will be the same as the actual
> source or destination respectively.
>
> (2) Request that a flow be enabled for packets with the given actual source
> and intermediate destination, mapping the matching packets to the
> intermediate source and actual destination.
>
> These two steps are the same regardless of whether we are dealing with an
> incoming or outgoing flow, and regardless of whether we are dealing with
> pure firewall, NAT-firewall, or twice NAT and firewall.
>
> As Juergen and Martin see it, the first step is to reserve addresses and
> ports on a given side of the middlebox.  If they are needed on both sides
> (and I believe that is so for twice-NAT), then two reservation requests are
> made.
>
> Their second step is then to request a flow and binding.  The basic
> difference is that they do not supply any information in the first step
> other than what they need reserved.  It strikes me that this deprives the
> middlebox of the opportunity to apply policy to address-port reservation
> based on source or destination.  The question is whether this matters.
>
> Tom Taylor
> [email-masked]
> Ph. +1 613 736 0961 (ESN 396 1490)
>

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 1 Oct 2002 10:46:07 -0400

It's a little ironic that my initial analysis called for a single step, but
I was convinced otherwise by considerations you raised.  I agree that you
can do everything in a single step if you have all the informatiopn policy
requires at that point, but I don't think this affects the core of my
observation on the difference between our approaches.  The real difference
still lies in the matter of simple address reservation versus reservation of
address bindings.  I ask again: does the difference matter?  My approach
gives the middlebox slightly more information on which to base its decision.

On the question of when two different address reservations are needed:
consider a situation where twice-NAT is in use because the interior and
exterior address spaces overlap.  Then as I understand it, taking outgoing
packets as an example, the internal endpoint needs an intermediate
destination at the middlebox which the latter mapps to the final destination
when it passes the packet.  At the same time, the middlebox must map the
internal endpoint address as source to a new source address on the middlebox
itself.  Thus to enable this flow you need to reserve one address-port on
each side of the middlebox.

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Tuesday, October 01, 2002 5:28 AM
> To: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]
> Cc: 'Martin Stiemerling'
> Subject: [midcom] Re: Midcom Semantics: Reserve vs. Address-Bind
> 
> 
> Tom,
> 
> We see our approach rather as a one-step approach with a rare 
> exception. In most cases just the integrated (second) step of 
> binding and enabling is required. Only for very special 
> scenarios, where the agent has insufficient information, the 
> (first) reservation step is required.
> 
> You split the actions required into two steps that are always 
> reqired. In contrary, we split the actions into one that is 
> usually sufficient and one that is only required additionally 
> in rather rare special cases where the agent lacks sufficient 
> information for just performing a single step.
> 
> You say you belive that in case of twice-NAT, three steps 
> would be required with our approach in some cases. We tried 
> hard to find such a case, but we did not find any. Could you 
> give us an example where our approach would require three steps?
> 
>     Juergen
> 
> 
> > draft-taylor-midcom-semgen-00.txt, I separate rule 
> instantiation into 
> > two
> > Just to show the difference: according to my analysis, setting up a 
> > combined NAT-firewall operation is done in two steps:
> >
> > (1) Provide the "actual" source and destination 
> address-ports (one or 
> > the other may be "ANY"), and request a binding.  The middlebox will 
> > return the intermediate source and destination addresses associated 
> > with the binding. In the twice-NAT case both of these will 
> correspond 
> > to interfaces on the middlebox itself.  Otherwise at least 
> one will be 
> > the same as the actual source or destination respectively.
> >
> > (2) Request that a flow be enabled for packets with the 
> given actual 
> > source and intermediate destination, mapping the matching 
> packets to 
> > the intermediate source and actual destination.
> >
> > These two steps are the same regardless of whether we are 
> dealing with 
> > an incoming or outgoing flow, and regardless of whether we 
> are dealing 
> > with pure firewall, NAT-firewall, or twice NAT and firewall.
> >
> > As Juergen and Martin see it, the first step is to reserve 
> addresses 
> > and ports on a given side of the middlebox.  If they are needed on 
> > both sides (and I believe that is so for twice-NAT), then two 
> > reservation requests are made.
> >
> > difference is that they do not supply any information in the first 
> > step other than what they need reserved.  It strikes me that this 
> > deprives the middlebox of the opportunity to apply policy to 
> > address-port reservation based on source or destination.  
> The question 
> > is whether this matters.
> >
> > Tom Taylor