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

From: "Christian Huitema" <[email-masked]>
Date: Wed, 9 May 2001 18:47:14 -0700

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: "Fleischman, Eric W" <[email-masked]>
Date: Thu, 10 May 2001 16:48:54 -0700

Thanks, Eliot. Based by your description, I am on the same page as you in that I did not envision a chatty protocol either, but rather a tight request/reply protocol.

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
Sent: Thursday, May 10, 2001 3:30 PM
To: Fleischman, Eric W
Cc: [email-masked]'; [email-masked]'
Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt

Hi Erik,

I'm not proposing NO feedback to the client.  I would, however, like the
client to make known all that is necessary on the first pass, or in the
absolutely worst case, the second pass.  

In other words:

client -> middlebox with request and that code frag I sent earlier. 
middlebox -> client with response, possibly including a valid ip address
it will be using.

What I want to avoid is this:

client -> middlebox (request)
middlebox -> client (i need username, application name)
client -> middlebox (username lear, application name netscape)
middlebox -> client (i need src,dst,proto)
client -> middlebox (src=10.1.33.23,4323,dst=128.33.239,110,TCP)
middlebox -> client (i need duration)
client -> middlebox (duration=1h)

user to both ends: (i need a coffee)

this is the sort of chit chat i want to avoid.
--
Eliot Lear
[email-masked]

---

From: [email-masked]
Date: Fri, 11 May 2001 09:24:23 +0100

Eliot,

I agree with this discussion but think there are probably two types of
interaction that we need to highlight. One is concerned with an application
being able to interact with infrastructure (eg DNS, SIP Proxy servers et al)
beyond the middlebox and the other is the media/stream/data transfer aspect.
I think both of these are imlicit in Christian's scenarios document although
may not have been brought out as distinct phases of activity. 

For some applications these two will have similar life times but for other
this will not necessarily be the case. I see this as being important to
appreciate because for large scale deployments the transactional load they
may create on infrastructure servers will be very different - if you follow
my point.

regards

Richard

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
Sent: 10 May 2001 23:30
To: Fleischman, Eric W
Cc: [email-masked]'; [email-masked]'
Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt

Hi Erik,

In other words: