Subject: RE: [midcom] New requirement bullets for decision

From: "Christian Huitema" <[email-masked]>
Date: Tue, 2 Oct 2001 13:08:52 -0700

> R46: The Midcom Protocol MUST support the concept of an aggregated
>         Pinhole-Descriptor comprising a multiple of individual flows
> to
>         be treated as an aggregate.
> 
> Proposal: keep

Yes.

> R47: When accepting a request for a pin-hole, the Middlebox MUST be
>         able to provide the MIDCOM Agent with information that may be
>         used to identify the resource in subsequent operations.
> 
> Proposal: clean up the language and keep.  Need to change "accepting
> a request for a pin-hole" and "resource."

No. Accepting this would imply that the pin-hole is identified by
something else than the filter specification, which would be a major
source of complexity; in particular, it creates the possibility for
having several rulesets with the same filter specification, and the need
to define how to handle them, deal with possible contradictions, etc. We
may or may not have a consensus that the pinhole should be identified
solely by the filter specification, but we certainly don't have a
consensus that it should not. I propose to drop this and leave it for
the protocol design phase.

> R60: An operation is needed to enable a MIDCOM Agent to request that
>         a Middlebox maintain (refresh) an established Pin-Hole over
>         which the Agent has ownership.
> 
> Choose between two options: 1) accept this, or 2) instead create a
> requirement for idempotent operations which can create new thing-on-
> the-box or extend the lifetime of an existing thing-on-the-box.

Idempotent is much better.

-- Christian Huitema

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 2 Oct 2001 15:47:38 -0700

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2001 2:12 PM
> To: 'midcom'
> Subject: Re: [midcom] New requirement bullets for decision
> 
> 
> On Tue, Oct 02, 2001 01:34:41PM -0700, Reinaldo Penno allegedly wrote:
> > 
> > 
> 
> > Christian,
> > 
> > The protocol design phase *is* based on the requirements, 
> so if it's not
> > there, it might not be addressed.
> > 
> > We already discussed this lenghtly. There are severeal 
> boxes out there that
> might have exactly the same filter specification applied 
> for different
> > entities (or call it users/CPE, etc). We need something to 
> distinguish
> > between these two filter specifications. 
> 
> Why?
>

What you mean Scott? Besides Bob's reply, the need is straightforward. Let's
suppose Scott and Reinaldo are part of different VPNs with overlapping IP
addresses served by the same MB. 

If I install two firewall rules:

one for Scott saying "10.0.0.1 yahoo.com drop" and another one for Reinaldo
saying
"10.0.0.1 yahoo.com drop" 

and later want to modify or delete one of them, how can I identify them? Not
to mention that the protocol might get confused saying that a rule already
exists or think its a refresh.

regards,

Reinaldo

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 2 Oct 2001 16:57:38 -0700

Suppose that instead of installing the two rules that you mention, I
install one for Scott saying "10.0.0.1 yahoo.com drop" and another one
for Reinaldo saying "10.0.0.1 yahoo.com pass". What is the firewall
supposed to do? And how do you reconcile that with requirement R23? (By
the way, we should definitley not use DNS names in example, since DNS
names resolve to an indeterminate number of addresses.)

On the contrary, if you insist that the rule is identified by 
	"10.0.0.1 128.9.10.11 TCP * *"
then you get the following sequence, which is strictly deterministic:

1) Scott creates "10.0.0.1 128.9.10.11 TCP * *, action=Pass". The midcom
server on the firewall checks Scotts credentials, and installs a
ruleset:
	"10.0.0.1 128.9.10.11 TCP * *, action=Pass, owner=Scott"
2) Reinaldo attempts to create "10.0.0.1 128.9.10.11 TCP * *,
action=Drop". Them midcom server notices that there is already a ruleset
for that filter. It returns an error.
3) Reinaldo insits. It sends a modify on the existing rule, requesting
"action=Drop". Depending on access control lists, whether or not
reinaldo is a privileged user, etc., the firewall accepts or refuses the
modification.
4) Scott suspects that something fishy is happening. He issues a read
request for the rule "10.0.0.1 128.9.10.11 TCP * *", and get the
information "action=drop, owner=Scott, modifiedBy=Reinaldo".
5) The two of you sort that out by out of band mechanisms.

-- Christian Huitema

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 2 Oct 2001 17:26:22 -0700

Hello Christian,

In the example I had in mind Reinaldo and Scott are not MAs, but home users
or some company. They have no control over the MB which is owned by a
carrier or ISP. The carrier's MA has the responsability to create the two
rules and ask the MB to apply them to different users which have overlapping
IP address.  

BTW, count me in as a volunteer.

regards,

Reinaldo.

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2001 4:58 PM
> To: Penno, Reinaldo [SC9:T327:EXCH]; Scott Brim; midcom
> Subject: RE: [midcom] New requirement bullets for decision
> 
>

---

From: Mark Duffy <[email-masked]>
Date: Tue, 02 Oct 2001 23:43:43 -0400

At 03:47 PM 10/2/01 -0700, Reinaldo Penno wrote: 

<excerpt>

> From: Scott Brim [<<mailto:[email-masked]>mailto:[email-masked]] 

What you mean Scott? Besides Bob's reply, the need is straightforward.
Let's suppose Scott and Reinaldo are part of different VPNs with
overlapping IP addresses served by the same MB. 

one for Scott saying "10.0.0.1 yahoo.com drop" and another one for
Reinaldo saying 

and later want to modify or delete one of them, how can I identify them?
Not to mention that the protocol might get confused saying that a rule
already exists or think its a refresh.

regards, 

Reinaldo 

</excerpt><<<<<<<<

Since the two rules when initially installed were intended to be applied
by the MB to different interfaces/realms/whatevers, presumably there was
a way when they were installed to specify that.  Perhaps a realm
identifier, perhaps by addressing a different logical middlebox, perhaps
some other way.  

In any event, it seems to me that the same way of distinguishing them
will still be available when agents want to go change them, delete them,
or refresh their timeouts.  So whether or not another key for the ruleset
is desirable for other reasons, I don't see the multi-context MB driving
such a requirement.

-Mark

---

From: "Sanjoy Sen" <[email-masked]>
Date: Wed, 3 Oct 2001 09:22:41 -0500

> Sent: Tuesday, October 02, 2001 6:47 PM
> To: Bob Penfield; Scott Brim; midcom
> > Which is a better "key" for the ruleset? One that is 
> > allocated when the
> > ruleset is created and remains constant or one the changes 
> > over the life of
> > the ruleset?
> 
> We debated that in London, and in fact I am supposed to head 
> a panel and
> write a draft on the issue. (Volunteers are welcome.) There are two
> options. If you want to keep "id=filter-spec", then the H.323 scenario
> is solved by creating two rulesets: create first a wildcard ruleset,
> then delete the wild card ruleset and create a specific ruleset.

I don't think its a good idea to create a ruleset id which can change in 
the middle of a session (what purpose does your name serves if it changes 
in the middle of your life!  You need to advertise to everybody who knows
you 
that you've a new name). 
I like Bob's idea of an id for rule-set and a separate id for rule-set
aggregate.
These ids should be separate from any attribute describing the entity and
should remain
unchanged for the lifetime of the entity.  

> 
> There are all kinds of pros and cons in this debate, but as an
> architecture rule, it is preferable to avoid creating extra 
> identifiers
> whenever possible.
> 
> -- Christian Huitema
>

---

From: "Cedric Aoun" <[email-masked]>
Date: Mon, 8 Oct 2001 16:56:37 +0100

I agree with Bob and Sanjoy about having a single identifier(that doesn't
change) during the lifetime of the ruleset or aggregate.

-----Original Message-----
From: Sen, Sanjoy [NGB:B602:EXCH] 
Sent: Wednesday, October 03, 2001 4:23 PM
To: 'Christian Huitema'; Bob Penfield; Scott Brim; midcom
Subject: RE: [midcom] New requirement bullets for decision

> From: Christian Huitema [ mailto:[email-masked]
<mailto:[email-masked]> ] 

> architecture rule, it is preferable to avoid creating extra 
<http://www1.ietf.org/mailman/listinfo/midcom>