Subject: RE: [midcom] RE: Precedence of wildcards

From: John LaCour <[email-masked]>
Date: Mon, 10 Sep 2001 10:23:31 -0700

> Mark Duffy wrote:
>
> Another consideration in whether the midcom protocol should have a
> source/dest or interior/exterion slant is compatibility with 
> the existing
> base of middlebox devices.  I would have guessed that most 
> are oriented to
> source/dest, although I am saying that without much specific 
> knowledge.

I prefer interior/exterior because source and destination can be
ambiguous with regard to whether you're talking about ip addresses
in layer 3 packet headers or realms.  They're often equivalent, but 
consider anti-spoofing packet filtering rules - in that case the
source/destination addresses are opposite of the realm.

I'm aware of more middlebox implementations which use some form
of in/out or incoming/outgoing than source/destination when referring
to the realm.  Many use source and destination (ip address) when 
referring to the tuple contents for the matching rule itself however.

It would be nice to have different terminology for where the rule
gets applied and the contents of the rule itself.

-John

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

---

From: Mark Duffy <[email-masked]>
Date: Mon, 10 Sep 2001 15:07:02 -0400

>gets applied and the contents of the rule itself.

Hmm.  The way I had been looking at this (but maybe it's just my own
prejudice) was that the ruleset has the filter (matching) part and the
action (what to do) part:

I had been thinking that the filter part specifies "which" packets.  The
information involved could be subdivided into at least:
 a) attributes of the packets themselves e.g. source/dest address, protocol,
    src/dest ports.
 b) the domain boundary on which packets should be tested against the
    filter.  I.e. at which middlebox and on which of the realms
    supported by that mb.  (But by the time the agent is talking midcom to
    the middlebox, the "which middlebox" is already resolved.)

I figure the action part carries the directionality as part of the "what
to do", e.g  permit-inbound, permit-outbound, NAT, etc.

-Mark