Subject: [midcom] Semantics: CHOOSE the destination?

From: "Bob Penfield" <[email-masked]>
Date: Tue, 16 Jul 2002 17:27:51 -0400

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?

Forgive me if I am being dense.

cheers,
(-:bob

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

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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 17 Jul 2002 02:50:06 +0200

> 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

> Forgive me if I am being dense.

Questions are mostly welcome.
Cheers
Martin

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 17 Jul 2002 09:24:12 -0400

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

> 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