Subject: [midcom] R79/80

From: Melinda Shore <[email-masked]>
Date: Tue, 28 Aug 2001 15:16:27 -0400

Next question:

R79/80 - kill or keep?  It's related to the question of ownership
but isn't the same.  R79 says:

"If a particular ruleset is created multiple times, it must be
deleted the same number of times"

and R80 says:

"If two rulesets overlap, and one is deleted, the overlapping
area must not be deleted until the other is deleted."

If we keep R80 we need to do something about defining "overlap."
I believe that it's not currently addressed elsewhere in our documents.

Melinda

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Aug 2001 13:11:10 -0700

> deleted the same number of times"

Dump.  See previous Email.

> area must not be deleted until the other is deleted."

Why should it be anything other than an error to have overlapping rule
sets in the first place?  We may instead have to mention something about
race conditions when changing allocations/reservations.
--
Eliot Lear
[email-masked]

---

From: Scott Brim <[email-masked]>
Date: Tue, 28 Aug 2001 16:32:57 -0400

> Dump.  See previous Email.

Eliot, could you repeat the opinion in the previous Email?  I don't know
which message you're referring to.

---

From: [email-masked]
Date: Tue, 28 Aug 2001 13:45:40 -0700 (PDT)

> I believe that it's not currently addressed elsewhere in our documents.

I had been assuming that the ruleset overlap related to CIDR block
overlap, but can I see that there might be other issues.  To use the
CIDR block example, let's assume that we get an pinhole request that
says:

allow from 128.102.33.5/32

then a covering request:

allow from 128.102.33/24

If you delete:

allow from 128.102.33/24

should 

allow from 128.102.33.5/32

also go away?  I would say it should not.  

The worse problem here relates to ruleset discovery and the crafting
of behaviors based on dependency on multiple rules, but since that
falls into the discovery bin I believe it to be out of scope for
this discussion.

			regards,
				Ted Hardie

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Aug 2001 14:02:11 -0700

Hi Ted!

> allow from 128.102.33.5/32

Why is this NOT an error?
--
Eliot Lear
[email-masked]

---

From: [email-masked]
Date: Tue, 28 Aug 2001 14:24:41 -0700 (PDT)

Hi Eliot,

The covering request isn't necessarily from the same agent; I was
representing what the request would look like to the MIDCOM box.  

For the second agent to re-write its request not to cover the original
request /32, it would have to know about the /32 pinhole and decide
whether its request should or shouldn't over-ride.  If it does have
to construct its request to avoid the 128.102.33.5/32,it's going to
have to keep state about the same rule applying to plural bit boundaries
(the 128.102.33.0/30 and whatever hash it makes for the 128.102.33.6+).
That seems icky.  

Perhaps the underlying question is whether the operation is "Delete
rule 'allow from 128.102.33/24'" or "deny from 128.102.33/24".  I
would agree that if a midcom box got "deny from 128.102.33/24" it
should delete all rules that allowed from that range.  If it gets a
"delete rule 'allow from 128.102.33/24'" (or that rule expired), then
I believe the other rule should remain valid.
		regards,

				Ted

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Aug 2001 14:43:27 -0700

Ted,
> representing what the request would look like to the MIDCOM box.

Understood.  The error doesn't necessarily need to be a logic error, but
more of a 4xx-like error because someone else has already grabbed the
resource.  If a pinhole is being opened on behalf of an application on an
end host, the application is working in concert with the the midcom agent.

In the case where the request is simply superfluous because firewall
policy already allows the ports through or because someone has already
authorized the access, that other somebody is responsible for monitoring
and closing the hole.  So return an error indicating such.

Perhaps the concern is that a wildcard has been opened by one application
when another application is planning to use a more specific pinhole?  I
would need to see an example of this.
--
Eliot Lear
[email-masked]

---

From: [email-masked]
Date: Tue, 28 Aug 2001 15:20:43 -0700 (PDT)

> and closing the hole.  So return an error indicating such.

I think I'm lost in somebodies.  Let's imagine a case where
application A asks Midcom Agent Z for a pinhole, and Midcom Agent 
Z says to Midcom Box M:

Open pinhole 128.102.33.5/32

then Application B asks Midcom Agent W for a hole, and
Midcom Agent W say to Midcom Box M:

Open hole 128.102.33/24

Do you believe the M should send an error to Agent W noting that
128.102.33.5/24 is already open and reserved?

	If so, does Agent W then send some combination of CIDR blocks
	that excludes that /32 to request the other part of the /24?
	
		Doesn't that mean that when Midcom Agent Z withdraws
		its rule (or it expires) that Agent W hasn't accomplished
		what Application B requested?  If so, should it error
		to Application B at the start?

As I said, my view is that covering rules should be allowed and should
expire/be withdrawn independently, but that a new rule denying access
should override both matching rules and any rules they cover.

This does mean we require different behavior for "Withdraw 'allow from
128.102.33/24'" and "Deny from 128.102.33/24", but I think that's okay.
			regards,
				Ted

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Aug 2001 16:07:27 -0700

> Midcom Agent W say to Midcom Box M:

Let me more fully specify this example:

Z -> M: open pinhole("internal" address 128.102.33.5/32,port *,
                     "external" address *, port *, tcp)

W -> M: open pinhole("internal" address 128.102.33.0/24,port *,
                     "external" address *, port *, tcp)

> 128.102.33.5/24 is already open and reserved?

Not quite.  I believe M should send an error to W saying that it is unable
to perform the request due to a conflict.

>         that excludes that /32 to request the other part of the /24?

Application specific.

By the way, the more interesting case is if this happens in reverse
order.  Suppose an application requests a pinhole for a subset of a range
that is already opened.  I would still return an error.

What's going on that a MIDCOM agent would make such a wildcard request as
described above?  It's not helping an application at that point.  It's
essentially granting any access to a host.  Big difference.  So what if a
port were mentioned in each request?  That way one could argue that MIDCOM
is now helping the application.  Well if that's the case, while it's not
reasonable to expect midcom agents for two completely different
applications to coordinate, it is quite reasonable to expect two midcom
agents for the SAME application to coordinate.

> 128.102.33/24'" and "Deny from 128.102.33/24", but I think that's okay.

Hold the phone on this one.  Let's come back to it.

Regards,

Eliot

---

From: [email-masked]
Date: Wed, 29 Aug 2001 14:51:29 -0700 (PDT)

> essentially granting any access to a host.  Big difference.  

I've seen deployments in which "VPN Termination" devices were placed
in a DMZ, with a secondary pass through a firewall from there.  In a
world in which MIDCOM existed, you might well see someone signal from
such a device to an agent a request to allow an authenticated host or
an authenticated subnet, depending on the termination.  Having both
types of request (one a direct authentication to the midcom agent,
say, and the other via a "termination device") also doesn't seem all
that unlikely.  

I'm also not certain that there is that big a difference between a
request to a host/port pair and a covering subnet/port set is that
different from the example I gave above.  Imagine a configuration in
which I say, in essence, "Allow that non-managed host to use the SMTP
port to talk to my managed host's SMTP port" then another rule says
"Allow non-managed hosts from this range of addresses to use their
SMTP port to talk to my managed host's SMTP port".

In any case, there is nothing logically or morally wrong with a
wildcard request, so the ability to handle it well seems reasonable.

>So what if a

The discovery of one agent of the other in order to coordinate with it
seems *way* out of scope for this group.  If it coordinates with other
agents, it seems likely it must do so through the MIDCOM box through
the type of error condition you've already described.

---

From: [email-masked]
Date: Wed, 29 Aug 2001 15:02:41 -0700 (PDT)

Ignore this; I hadn't seen Christian's message when I wrote
it, and I think his requirement as written handles what i
think we need.
			thanks,
				Ted