Subject: RE: [midcom] Semantics: CHOOSE the destination?

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 18 Jul 2002 09:48:54 -0400

Bob, I wonder if I could finesse your concerns with the following text.
Basically I am proposing that we are effectively doing just one thing:
enabling a packet flow.  We do it in two ways: by installing filters and by
installing bindings.  I should say that by the time I on the one hand and
Juergen and Martin on the other finish updating our respective drafts with
the results of the meeting discussion, the basic difference between us will
be that they show the installation of bindings as a separate step from the
installation of filters.  If my proposed combined representation is seen as
merely confusing, I suppose I should give up on it.  In the meantime, here's
the proposed text:

[3:2.15] defines a Policy Rule as a combination of one or more filters and
an action.  The basic idea is that packets matching the filter have the
action applied to them.  The canonical form of the filter in [3] is the
5-tuple: 

{source address, source port, destination address, destination port,
protocol}

Given the decision in the meeting (which is obviously subject to further
testing on the Working Group list) that "deny" actions are out of scope,
only two types of action remain: NAT "bind" and firewall "allow".  It is
possible to express either of these two actions individually or both
combined in a single expression, having the semantics of "enable".  This is
done by expanding the five-tuple shown above by adding two more address/port
pairs, representing addresses to which the enabled packet flow is bound on
the two sides of the Middlebox.

Before looking at the details, it is necessary to examine the implications
of this expression of a Policy Rule.  There are two such implications:

·	If the scope of the MIDCOM protocol expands beyond the initial
framework, additional semantic expressions may be required to express new
actions.  It is for this reason that the general "Policy Rule Request"
message shown in the the previous version of this document is now replaced
by "Enable Request".

·	If both NAT and firewall operations are being applied, the combined
expression is in itself ambiguous as to which is applied first.  [3:7.3]
makes the point that firewall operations are applied to packets as seen on
the wire, and that as a result NAT bindings must be established before
making firewall requests based on those bindings.  The "Enable Request"
described below is assumed to have the necessary semantics to make this
happen.

That said, the proposed representation of the "enable" Policy Rule has the
form:

{external address, external port,
 external mapped address, external mapped port,
 internal mapped address, internal mapped port, 
 internal address, internal port,
 direction,
 protocol}

The four address-port components mark the successive points through which
the packets enabled by this Policy Rule will flow.  In the absence of NAT,
neither mapped address-port will appear in a packet header.  For single NAT,
the external mapped address-port will be bound, and for double NAT, both the
internal and external mapped address-port will be bound.  These
considerations introduce a requirement to indicate whether a binding exists
at a given interface on the Middlebox.  The "ANY" wildcard is used to denote
an unbound address-port. 

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Wednesday, July 17, 2002 9:24 AM
To: Martin Stiemerling
Cc: midcom
Subject: Re: [midcom] Semantics: CHOOSE the destination?

----- Original Message -----
From: "Martin Stiemerling" <[email-masked]>

> Bob Penfield wrote:
> > In sec 2.3 of draft-taylor-midcom-semantics-00.txt, it indicates that
the
> > MIDCOM Agent can request an address+port for the mapped address. If the
> > source and destination of a packet are matched against the source and
> > destination of a Policy Rule Filter, the destination address for
operation
> > d) & e) of scenario [3:7-2] (NAPT control) would need to "CHOOSE" the
> > destination address. The mapped address would be the internal endpoint
> > address + port.
> >
> > If the middlebox is suppose to match the received packet's destination
with
> > the mapped address of the filter, the usage of the components of the
filter
> > would be inconsistent between a firewall pinhole and a NAT translation.
> >
> > For an inbound NAT, a packet match would be:
> >      src=<source>, dest=<mapped>
> >
> > For an inbound pinhole, outbound pinhole, and outbound NAT,
> > a packet match would be:
> >      src=<source>, dest=<destination>
> >
> > There seems to be the same inconsistency in the Stiemerling draft.
> >
> > Or is there not suppose to be a direct relationship between the filter
> > fields and what the middlebox uses to match packets to rules?
>
> With the filter of the policy rule you can specify the parameter, like
> "I want packets from x to y". How the actual pin hole/NAT binding is set
> inside the middelbox shouldn't care the agent. Since the configuration
> might differ and involve multiple rules inside the box, like:
> packet filter: src=<internal IP> dest=<external IP> allow
> NAT:           binding<internal IP, mapped IP>
> packet filter: src=<mapped IP> dest=<external IP> allow
>
> or
> NAT:           binding<interal IP, mapped IP>
> packet filter: src=<mapped IP> dest=<external IP> allow

I can agree that the agent should not care, my point was that the filter
fields expressed in protocol have different meaning depending on whether the
rule is for a NAT or Firewall pin-hole. I find this the be inconsistent and
at odds with the statements "... it is possible to come up with a unified
semantic representation which has the same form for all the applications
intended for MIDCOM protocol" (from Taylor) and "We define the semantics of
configuration requests an a way that covers FW and NAT configuration in a
single request ..." (from Stiemerling).

Let me dive down a bit. Somewhere in the middlebox is a table of "filters"
that the middlebox compares received packets with. Each entry is this table
is the famous 5-tuple (source address, source port, destination address,
destination port, and transport protocol). If there is a one-to-one mapping
of fields from the filter of the protocol to the fields of the 5-tuple, the
procedures that middlebox uses to populate an entry are relatively trivial.
With the proposed semantics, there is not a consistent one-to-one mapping.
It depends on the middlebox function (NAT or Firewall). Granted this is not
all that difficult to implement, but it is a bit more complex.

Let me propose (again) what I believe is a straight forward semantic:

The "filter" of a Policy Rule consists of the 5-tuple that is used by the
middlebox to match received packets. All other data is part of the "action".
These would include the action of changing the source and or destination
address and port. In my mind, the filter should only contain packet matching
criteria. Any manipulation of the packet is an action. Thus FW and NAT
filters are represented the same way. The only difference is the
actions/manipulations the middlebox performs on the packets.

filter={source address,
        source port,
        destination address,
        destination port,
        transport protocol}

action={permit/deny,
        mapped source address,
        mapped source port,
        mapped destination address,
        mapped destination port}

Obviously these need to be extended to accommodate/represent types of
addresses (IPv4/IPv6), address spaces (public/private/whatever),
ranges/sequences of ports and parity, but this illustrates the general idea.

cheers,
(-:bob

_______________________________________________
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: "Bob Penfield" <[email-masked]>
Date: Thu, 18 Jul 2002 11:51:39 -0400

Hi Tom,

I was unable to make it to Japan, so I am not aware of how the discussions
went. However, what you propose below I find to be complete, although I have
a subtly different view which I describe below.

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>
> enabling a packet flow.

I strongly agree!

> We do it in two ways: by installing filters and by
> merely confusing, I suppose I should give up on it.

I strongly support a combined representation. I do not find that at all
confusing.

> In the meantime, here's

Exactly! I would say the NAT action is actually "bind+allow", but I agree,
the action for both is really just "enable".

> at a given interface on the Middlebox.  The "ANY" wildcard is used to
denote

I find this complete as far as all the necessary pieces are there. However,
I have a slightly different view which is based on what I will admit are
implementation details, but for us it has made implementation of a middlebox
a bit more straight forward by having the protocol express the data in the
same way as it would be keep in the lookup table used to match packets.

{input source address, input source port,
 input destination address, input destination port,
 protocol,
 direction,
 output source address, output source port
 output destination address, output destination port}

The "lookup key" for matching received packets in the middlebox is the first
six fields. The "output" fields define the "changes" to be applied if it is
a NAT. If there is no NAT, these fields are set to ANY.

However, it is certainly easy enough to manipulate the data in the filter
you propose into this form, and I have to admit that it makes keeping track
of the binding a bit more complicated, so I will not object to keeping your
proposal.

I do have to note that semantics of "direction" does imply that only
middlebox with one internal address space and one external address space are
supported. Are we saying that support for middleboxes with more than two
addresses spaces are out of scope?

cheers,
(-:bob