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

From: "Fleischman, Eric W" <[email-masked]>
Date: Wed, 9 May 2001 17:58:29 -0700

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: "Melinda Shore" <[email-masked]>
Date: Thu, 10 May 2001 08:30:57 -0400

[Please wrap long lines - not everybody uses GUI-based
readers.  It's sufficiently annoying to reformat that I'm
not going to quote your text.]

Thanks for your comments.  A couple of things:  1) this is
not a requirements document, but rather a description of use
scenarios from which requirements and architecture can 
be further developed.  I think that we do need to pay more
attention to the second leg of our architecture (the nature
of the interface between middlebox and policy server), but 
I don't see Christian's document as obscuring that interface.
Incidentally, we won't get a document approved that doesn't
allow the middlebox to reject requests, whether it's because
policy forbids the action being requested or because resources
aren't available or because the middlebox simply has no idea 
what you're talking about.

The security stuff continues to be a problem in midcom, and 
thank you for bringing that out.  I'm not sure your concerns 
apply to this document, which is illustrative rather than 
definitive, but perhaps it would be useful to include an 
example where authentication is a gating operation.

Melinda

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 May 2001 09:05:24 -0700

Eric,

Thanks for your comments.  You raise a rather large concern, however.  How
much back and forth would you expect to have happen in the midcom
protocol?

Consider the following code-frag:

<open proto=TCP, from=(Internal,10.1.44.2,port=18294),
to=(external,128.33.28.12,port=110),
application=Netscape,duration=unknown,bandwidth=unknown,user=(lear,[credentials];
request=NAT>

Noting that some of this information will not always be available, what
would you like to receive?
--
Eliot Lear
[email-masked]