Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 12 Apr 2002 13:34:27 -0400

I partly agree with you.  When the Agent is asking for a mapping to be
granted, the Map Address-Port is a return value, not really part of the
filter.  Since we are talking semantics rather than protocol notation, the
distinction should be made clear.

On the other hand, when a mapping has been granted previously and the Agent
is now enabling a specific flow, the Map-Address-Port is legitimately part
of the flow specification.

To show what I mean, suppose we are talking about a rule allowing inbound
flows to a service.  To set this up, the Agent issues a request like this:

Source Address: Any
Source Port: Any
Destination Address: <specific>
Destination Port: <specific>
Protocol: TCP
Action: new destination address-port

The response provides a specific Map-Address-Port as requested.

Now consider a rule allowing inbound flows through that mapped address-port,
from a specific external address.  (To avoid extraneous issues, assume it is
replacing the previous rule.)  The rule should have the form:

Source Address: <specific>
Source Port: <specific>
Destination Address: <specific>
Destination Port: <specific>
Protocol: TCP
Action: allow

One other point: do your actions "new source address" and "new destination
address" mean what I think they mean:
 - new source address: please assign an address which will appear as the
external source of flows originated from inside
 - new destination address: please assign an address which will appear as
the external destination of flows being forwarded to the inside?

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Friday, April 12, 2002 10:12 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>
<snip>
> Let us turn now to the detailed semantic content of the {Filter, Action}
> pairs.  As the examples of section 4 illustrate, it is possible to
represent
> NAT and firewall policies using sets of uni-directional filters of the
form
>
> {<Source Address-Port>, <Map Address-Port>, <Destination Address-Port>,
> Protocol}

I would think that the filter would contain only the data used to match
packets. The Map Address-Port would part of the action. Also, I don't think
a single Map Address-Port is sufficient.

I see the parameters in the Filter as follows:

    Source Address-Port
    Destination Address-Port
    Transport Protocol (UDP, TCP, etc)

The actions would include:

    New Source Address-Port
    New Destination Address-Port
    Allow/Disallow

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

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 12 Apr 2002 15:16:07 -0400

Hi Tom,

I think we have different interpretations of "filter" and "action". I see
the "action" as the set of operations the middlebox performs for the packets
matching the filter, rather than the "action" the protocol does for the
policy rule. When a policy rule is created, both the filter and action parts
of the rule might be selected using the CHOOSE wildcard. For example, say I
want to enable an inbound UDP flow from "the-other-end" to "my-endpoint" in
a NAT box. I would specify:

Filter:
   Source: <the-other-end>
   Destination: CHOOSE
   Protocol: UDP
Action:
   Allow
   Change-Destination-To: <my-endpoint>

The corresponding outbound rule might look like this:

Filter:
   Source: <my-endpoint>
   Destination: <the-other-end>
   Protocol: UDP
Action:
   Allow
   Change-Source-To: CHOOSE

There may be scenarios where I want to change both the source and
destination addresses (twice-NAT), thus I would need to specify both in the
action. For example, I might have specified the outbound rule as:

Filter:
   Source: <my-endpoint>
   Destination: CHOOSE
   Protocol: UDP
Action:
   Allow
   Change-Source-To: CHOOSE
   Change-Destination-To: <the-other-end>

I might need to do this to guarantee that the outbound packets traverse this
particular middlebox it there are multiple ways out of the network.

cheers,
(-:bob

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