Subject: RE: [midcom] Topology considerations documents

From: John LaCour <[email-masked]>
Date: Thu, 6 Sep 2001 16:13:11 -0700

> > Picture a carrier-based middlebox that can provide a 
> firewall service
> > independently to multiple enterprises.  Assume that it is 
> possible that
> > multiple enterprises A, B, and C may be connected to this 
> middlebox *via
> > the same interface* of the middlebox.  A certain pinhole is 
> to be opened
> > for packets being sent to enterprise A, but not for those 
> forwarded to B or
> > C.  To control this via midcom, "interface" is not a powerful enough
> > criterion.  "Realm", which is more general, is.
> > 
> > >	a) useful
> >     Yes, since it allows midcom to control this firewall
> > 
> > >	b) not isomorphic to interface names
> >     Yes, because in this case realm::interface  is many::one

Actually, it can also be one::many as well as many::one.  Consider a 
single Access List applied to multiple interfaces.

> I can think of some schemes using IP addresses
> or the various and sundry Tags which can be shoved in packets. I
> am happy to stipulate that this is a middlebox specific problem,
> and we may assume that every packet is Somehow classified, and
> has a Source Realm and a Target Realm attached to it before policy
> is applied.

Which packets get associated with which realms is a middlebox
implementation problem not a MIDCOM problem.  Some things that
implementors might use to solve the middlebox problem, by way of 
example, include 802.1q tags, which interface a packet arrives on,
what the src mac address is, etc.

The key thing here is that MIDCOM should communicate changes to
security policy in a specified realm.  MIDCOM should not try to
communicate which realm certain traffic/flows/packets belong to.

-John

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 6 Sep 2001 16:40:39 -0700

Hello, 

I was going to write a draft about topologies, etc but IMO what those three
drafts and recent comments (John, Mark, etc) are trying to get to is this:

We need to go to
http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-framework-01.txt and in
every complex topology you see, substitute PE router by a MB and/or put a MB
after or before the PE router. If we can then come up with a method identify
each flow uniquely for all those cases, we are in good shape.

regards,

Reinaldo

> -----Original Message-----
> From: John LaCour [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 4:18 PM
> To: 'Christian Huitema'; [email-masked]
> Subject: RE: [midcom] Topology considerations documents
> 
> 
> See comments below...
> 
>  
> > 
> >         +-------------+ 
> >         |             |           +------+ 
> >         | Customer A  |           |      |      +---------------+ 
> >         |             +-----------+      |      |               | 
> >         |  10.0.0.x   |           |      |      |               | 
> >         |             |           |      |      |   Service     | 
> >         +-------------+           |Middle|      |   Provider    | 
> >                                   |  Box +------+               | 
> >         +-------------+           |      |      |               | 
> >         |             |           |      |      |  192.168.20.x | 
> >         | Customer B  |           |      |      |               | 
> >         |             +-----------+      |      +---------------+ 
> >         |  10.0.0.x   |           |      | 
> >         |             |           +------+ 
> >         +-------------+
> > 
> > Well, we may observe that such constructs are by and large 
> > equivalent to
> > a multiple-box construct:
> > 
> >         +-------------+ 
> >         |             |           +------+ 
> >         | Customer A  |           |      |      +---------------+ 
> >         |             +-----------+ MB-A |      |               | 
> >         |  10.0.0.x   |           |      |      |               | 
> >         |             |           +......+      |   Service     | 
> >         +-------------+           .      .      |   Provider    | 
> >                                   .      +------+               | 
> >         +-------------+           .      .      |               | 
> >         |             |           +......+      |  192.168.20.x | 
> >         | Customer B  |           |      |      |               | 
> >         |             +-----------+ MB-B |      +---------------+ 
> >         |  10.0.0.x   |           |      | 
> >         |             |           +------+ 
> >         +-------------+
> > 
> > We don't want to split the hardware, but nothing prevents us from
> > adopting a logical view in which "MB-A" and "MB-B" are 
> > different "midcom
> > servers", i.e. have different logical names. So, if an 
> agent wants to
> > open a port for A, it sends comment to the midcom server 
> > "MB-A", and to
> > "MB-B" if it wants to open a port for B. Pretty soon, we have 
> > a generic
> > mechanism with a clear naming rule -- a name associated with the
> > protected domain -- and a simple semantic -- interior and exterior.
> > 
> > Looks nice, uh?
> 
> 
> In total agreement. 
> 
> I just want a way in MIDCOM to specify MB-A or MB-B so that I can 
> avoid having multiple MIDCOM servers on my middlebox and 
> avoid duplicating 
> authentication mechanisms whenever I have one middlebox agent talking 
> to both MB-A and MB-B.
> 
> -John
>

---

From: Mark Duffy <[email-masked]>
Date: Fri, 07 Sep 2001 10:28:00 -0400

Hi Christian,

I believe modelling the multi-realm middlebox as a number of logical
2-realm middleboxes as you suggest is sufficiently powerful and hence an
acceptable alternative to specifying realms.

I do take issue with one section of your posting: 

>I guess we all agree that the simplest topology is that of the "basic
>firewall" configuration: a protected domain that we can call "the
>interior", and by opposition a non protected side that we can call "the
>exterior". The concept of interior and exterior leads us in this case to
>a very simple pinhole specification. The pinhole is identified by:
>	Interior address
>	Protocol type
>	Interior port
>	Exterior address
>	Exterior port
>Indeed, each of these values can be wildcarded, or maybe replaced by a
>"prefix" in the case of addresses. The pinhole will then have
>attributes, such as:
>	Direction: send, recv, sendrecv, closed
>	Mapping of the interior address to the outside, if NAT
>	Maybe mapping of the exterior address on the inside
>	Etc.
>A very good outcome of the directionality, i.e. from the inside out, is
>that we can order the list of pinholes, as if the 5 tuple was one big
>number. This allows us to define unambiguously which pinhole is most
>specifically matching a given packet header -- i.e., in the matching
>list, the one that comes first in the ordering, assuming that wildcards
>rank after specified values.

I do not see how this affords a useful unambiguous way to determine the
relative precedence of rules that may match a packet in the presence of
wildcards.

If we have
Rule 1:  SA= any, DA= 1.2.3.4, protocol= any, SP= any, DP= any
Rule 2:  SA= any, DA= any,     protocol= tcp, SP= any, DP= any
Then which rule does a tcp packet to address 1.2.3.4 match?

Do you propose to concatenate the fields of the tuple in some fixed order
eg SA|DA|P|SP|DP and also specify a lexicographic sorting order between 1
bits, 0 bits, and don't care bits?  That would make the system
deterministic but I'm not sure it would be meaningful/useful.  How is one
to decide which fields of the tuple are more "important" hence more
significant in the concatenation?  

And, what about future extensibility if more fields are added to the
n-tuple.  Do they just go at the least significant end in the order they
are defined?  And systems that don't support particular optional n-tuple
fields omit them?

-Mark