Subject: [midcom] RE: Comments on draft-ietf-midcom-scenarios-01.txt

From: "Fleischman, Eric W" <[email-masked]>
Date: Thu, 10 May 2001 09:02:16 -0700

Christian,

I am not surprised to read that your goals and mine are the same. I would have been disappointed were that not the case. However, the current wording of this draft doesn't yet take us where we want to go, though it is a very fine beginning:

1) The confusion between policy and scenarios in the current draft needs to be corrected regardless of whether your document functions solely as a scenarios document or as the requirements document. Your second paragraph in your email below demonstrates that you also recognize that policy is orthogonal to the scenarios. If so, then you shouldn't intertwine policy within the scenarios at any point because by doing so you are implying that the scenarios prejudice policy decisions. They don't. Corporate policy will apply against all of the scenarios and you dare not guess what those policies or the local reaction to the scenarios will be, since it will be a local matter to that corporation (or individual), and may actually be a function of that local policy in response to specific established business relationships.

2) I have never understood the desire on the part of some of our peers to create a scenarios document separate from a requirements document. In my mind, what is needed is a single document where all of the requirements are located. Since I view these scenarios to be part of the requirements, I argued at the last IETF that you should be creating the first draft of this combined document. I still make the same argument, since I heard no explanation for why two documents are more desirable than one (i.e., why would anybody prefer to consult two documents to gather requirements when they could only consult one authoritative document? It just doesn't make any sense ... (to me, anyway)).

3) The requirements document must mention the requirement for optional authentication of the requestor. It also must address the fact that the requester needs to optionally specify the nature of the "hole" they are requesting, optionally including duration, ranges of remote addresses which can enter it, and the number of "simultaneous sessions" to that internal destination. Another requirement for the protocol is that the middlebox must be optionally able to tell the requester how it responded to the request, including whether it opened the "hole" as was originally requested or a "reduced hole", and if the latter, what the resulting "hole characteristics" are.

4) I had not previously thought of the operational requirements you mention in your third paragraph below. Now that I've thought of them, I very much want to see those ideas further developed in the requirements document (preferably by expanding your document, or else seeing a separate document). Those are indeed important requirements. They differ however from the items I was identifying in that those operational concepts don't need to be explicitly carried by the midcom protocol such as explicit authentication and policy negotiation do. They rather need to be attributes of the total system that are supported -- and anticipated -- by the total system, including the midcom protocol, even though the protocol itself will not need to carry any support negotiation. Please note that these last few sentences of mine are not a consensus of this WG. It is solely a personal opinion of mine. I encourage debate if anyone has a different perspective, otherwise I'd like to see it documen!
 te!
d as a straw man position of the group.

Changing topics, I did not see (in my glancing through the remainder of your document) any mention of a policy server (PDP) requesting "holes" through a middlebox to specific internal or external systems (note the plural). Is this out of scope (i.e., a local implementation matter) or in-scope? My own thoughts are confused on this point, since I see value in both positions. What does the WG think about this?

--Eric

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 6:47 PM
To: Fleischman, Eric W; [email-masked]
Subject: RE: Comments on draft-ietf-midcom-scenarios-01.txt

Eric,

Thanks for your comments. The absence of any mention of security
requirements in the scenario was quite deliberate. The idea was to
explain the nature of the holes that would have to be opened for the
applications to work, so as to derive what I would call the "functional
requirements" of the protocol.

It is quite clear that we also have other requirements, notably security
requirements. In the scenarios, I described what the application needs
in order to run; whether the application is actually allowed to run or
not is a matter of local policy. In order to meet the functional
requirements, the midcom protocol will have to enable the scenarios that
I described. In order to meet the security requirements, the midcom
protocol will have to provide adequate controls. I have my own
understanding of these controls: I believe that the protocol should be
able to express who is asking the query (authentication) as well as what
the query is intended to achieve, e.g. what application, for which user,
using what amount of resource.

In addition, we also have operational requirements, e.g. support stable
operation even if some of the systems involved crash; enable
multi-homing; etc.

I would expect that functional, security and operational requirements
will be written down in the "requirements" draft. Now, if we are waiting
too long for that draft, I could indeed increment the scenario draft
with a listing of these requirements...

-- Christian Huitema

> -----Original Message-----
> From: Fleischman, Eric W [mailto:[email-masked]]
> Sent: Wednesday, May 09, 2001 5:58 PM
> To: [email-masked]'; Christian Huitema
> Subject: Comments on draft-ietf-midcom-scenarios-01.txt
> 
> I thank Christian Huitema for this excellent internet-draft document.
> Although I have only read the first five pages with care, having only
> glanced through the rest of the document at this time, I nevertheless
have
> a few comments that I would like to share with you based upon this
early
> (semi-)reading.
> 
> I like Christian's approach of describing distinct configuration
scenarios
> which the midcom protocol will need to support. I believe that this is
an
> excellent basis for stating these requirements and that Christian has
> provided us with an excellent text to base our discussions upon.
However,
> I find the granularity of this current discussion to be very
troubling,
> missing important sets of requirements that need to be captured up
front.
> 
> --------------------------
> Issue 1: Confusion of Scenarios with Policy
> The current text appears to imply that the first generic scenario (TCP
> Server behind a firewall/NAT), described in Section 2.1, will open a
semi-
> permanent hole through the middle box to a specific "Internal Host",
while
> the second generic scenario (Peer-to-Peer communication with ad-hoc
> rendezvous) produces an "authorization [that] is typically valid for
only
> a single TCP connection" (see penultimate paragraph in section 2.2). I
> firmly state that any such implication is unacceptable.
> 
> I rather state that the configuration scenarios are independent from
local
> policy issues. Specifically, it is a local policy decision whether the
> first approach can open "semi-permanent holes" and the second approach
a
> transitory hole (i.e., "valid only a single TCP connection") or vice-
> versa. The requirements need to recognize that the midcom protocol has
two
> orthogonal requirements it must fulfill: it must satisfy the needs of
> communication protocols to operate as described by Christian's
scenarios
> and it also must cooperate with and support local policies. These two
> functions are distinct from each other and must not be confused.
> 
> Specifically, I can not imagine (though I may be mistaken) the
> administrators of my company's firewalls deploying a product which,
based
> upon the protocol exchange described in section 2.1 [even with
explicit
> authentication checks (which weren't mentioned, BTW)], will permit the
> Internal Host to open any unconstrained hole through our firewall to
> itself. Rather, we will require the ability to restrict the nature of
that
> hole based upon local policy. Simultaneously, we would be very
interested
> in knowing just how big a hole that application wants, since it is
more
> aware than we are about the needs it is trying to satisfy. Policy is
> therefore not (always) a binary thing, and some policy negotiation
> capabilities need to be built into the midcom protocol.
> 
> It is therefore very desirable, but not required, that the Internal
Host,
> in such a scenario, provide input as to the nature of the hole they
are
> requesting. This input can specify the range of remote source
addresses
> which can be permitted to go through that hole as well as the duration
> during which that hole will be maintained. It should also optionally
state
> how many simultaneous sessions can be supported by this request.
> 
> The protocol should also address the possibility that corporate policy
> will restrict the hole to be smaller than what the requesting agent
> requested, and the nature of that restriction should be conveyable
back to
> the requesting party, since any policy enforcement point has "the
final
> word" on such matters.
> 
> This ability to restrict the hole to a "range of addresses" is a very
> important matter and should not be deprecated. It reflects the fact
that
> (increasingly) the interactions between corporations is partially a
> function of whether their respective policies collide or synergize
> together. This is a very big topic that I would prefer to not get into
> now, but I will point out that any company having ITAR restrictions
upon
> itself must be very aware of the nature of its interactions with other
> corporations, to ensure that their cumulative policies do not violate
this
> mandate of the US Government. It is difficult to imagine creating a
viable
> collaborate infrastructure in the aerospace industry without
addressing
> such concerns.
> 
> ------------------------------------
> Issue 2: Middleboxes are PEPs
> Middleboxes function as Policy Enforcement Points. As such, it
wouldn't
> hurt matters to explicitly mention that the firewall/NAT may need to
use
> COPS to query a Policy Server (PDP) concerning what response it should
> give to the Internal Host's request that it open a hole through
itself. I
> recognize that this is a implementation detail, but I am concerned
that a
> failure to capture this possibility may also mean that we fail to
> acknowledge the other parts of the system that need to be considered
to
> create a viable standard.
> 
> ---------------------------------------
> Issue 3: Authentication and Access Control are Big Issues
> I am concerned with the lack of emphasis given to the importance of
the
> midcom protocol to satisfy rigorous authentication and access control
> requirements. I readily admit that access control (i.e.,
authorization) --
> and how it is done -- is probably a "local implementation issue".
However,
> authentication isn't, and it needs to be explicitly addressed.
> 
> Specifically, the penultimate paragraph of Section 2.1 states: "It is
> quite clear that the interaction between the internal host and the
> firewall/NAT described in the first step of the scenario may require
some
> form of access control." This text assumes that access control is a
> function of this scenario, but not of the preceding one. This is
wrong.
> Authentication is potentially needed for ALL of the scenarios -- every
one
> of them. Thus, this idea is incorrectly positioned within the paper.
It
> should rather be noted up front within this document that a firm
> requirement of the Midcom Protocol is that it must optionally provide
> authentication between the Middlebox and the requester. I don't know
> whether two-way authentication is required or not, but I will assert
that
> the Middlebox had better be able to authenticate the requester if it
is
> going to be deployed upon our machines.
> 
> ---------------------------------------
> Issue 4: Section 2.2.2
> I would rather state that the issue of both peers being behind
firewalls
> should preferentially be treated by considering mechanisms by which
the
> external IP address, negotiated by the Internal host with the
firewall,
> can be communicated to its remote peer, and vice-versa. This can be
done
> via "out of band" signaling (e.g., Email exchange) or SDP-based
> approaches. Alternatively, it could be handled by both systems
publishing
> their IP addresses to name services. However it is done, the
configuration
> should not dictate policy as the current text implies when it says
"Allow
> the internal host to accept TCP connections from any external
address."
> 
> Thank you for your attention to this posting.
> 
> --Eric Fleischman

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 10 May 2001 13:50:55 -0700 (PDT)

--- "Fleischman, Eric W" <[email-masked]> wrote:
> Christian,
> 
> I am not surprised to read that your goals and mine are the same. I would
> have been disappointed were that not the case. However, the current wording
> of this draft doesn't yet take us where we want to go, though it is a very
> fine beginning:
> 
> 1) The confusion between policy and scenarios in the current draft needs to
> be corrected regardless of whether your document functions solely as a
> scenarios document or as the requirements document. Your second paragraph in
> your email below demonstrates that you also recognize that policy is
> orthogonal to the scenarios. If so, then you shouldn't intertwine policy
> within the scenarios at any point because by doing so you are implying that
> the scenarios prejudice policy decisions. They don't. Corporate policy will
> apply against all of the scenarios and you dare not guess what those policies
> or the local reaction to the scenarios will be, since it will be a local
> matter to that corporation (or individual), and may actually be a function of
> that local policy in response to specific established business relationships.
> 

Eric - Christian is simply depicting functional scenarios that ought to 
work with MIDCOM protocol. You have to make assumptions about an application,
the location of end-host participants, MIDCOM participants and policy 
governing the authorization of MIDCOM agents in order to illustrate the
scanarios. That is not making a statement about MIDCOM Policy Server. 

I really dont think scenarios are prejudicing policy decions. Scenarios
are merely making certain local policy decisions. Without that, you have
no credible scenario.

> want to see those ideas further developed in the requirements document
> (preferably by expanding your document, or else seeing a separate document).
> Those are indeed important requirements. They differ however from the items I
> was identifying in that those operational concepts don't need to be
> explicitly carried by the midcom protocol such as explicit authentication and
> policy negotiation do. They rather need to be attributes of the total system
> that are supported -- and anticipated -- by the total system, including the
> midcom protocol, even though the protocol itself will not need to carry any
> support negotiation. Please note that these last few sentences of mine are
> not a consensus of this WG. It is solely a personal opinion of mine. I
> encourage debate if anyone has a different perspective, otherwise I'd like to
> see it documen!

As for the role of Policy Server vis-a-vis middlebox, you are apparently 
envisioning a  PDP-PEP type of relationship. That is not the consensus of
the Work Group. Below is what I have in the framework draft on Policy 
Server - This has gone through reviews from some WG folks.

   Policy Server is a management entity that interfaces with a 
   middlebox to communicate policies concerning authorization of
   MIDCOM agents gaining access to middlebox resources. A MIDCOM
   agent may be pre-configured on a middlebox as a trusted entity.
   In the case where a MIDCOM agent is not pre-configured, the
   middlebox will consult Policy Server Out-of-band for validating
   the authorization to accept requests from the agent. A policy
   server might add or delete MIDCOM agents on a middlebox. 

   The protocol facilitating the communication between a middlebox
   and Policy Server need not be part of MIDCOM protocol.

> Changing topics, I did not see (in my glancing through the remainder of your
> document) any mention of a policy server (PDP) requesting "holes" through a
> middlebox to specific internal or external systems (note the plural).

Policy Server does not request holes. MIDCOM agents do.
See my comments earlier about PDP-PEP relationship you allude to.

>                                                                      Is this
> out of scope (i.e., a local implementation matter) or in-scope? My own
> thoughts are confused on this point, since I see value in both positions.

Policy Servers requesting holes on a middlebox is out-of scope, 
as far as I understand.

> What does the WG think about this?
> 
> --Eric

cheers,
suresh

> > Thank you for your attention to this posting.

=====

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 10 May 2001 16:59:48 -0400

> Policy Servers requesting holes on a middlebox is out-of scope, 

A policy server requesting a hole would 1) be using the
midcom protocol, and 2) be functioning as a midcom agent
in that case.

Melinda