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

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 30 Sep 2002 20:21:45 -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