Subject: Re: [midcom] Rev4 of MIDCOM Architecture & framework document

From: Mark Duffy <[email-masked]>
Date: Fri, 02 Nov 2001 00:21:46 -0500

Thank you Suresh, here are my comments.
These are just suggestions on the document, not I think on the fundamental
concepts.  -- Mark.

Section 2.15 -- definition of "Ruleset".  I recommend we remove the second
paragraph:
   Ruleset specifies the dynamic resources (i.e., Filter Specs,
   Action Specs, Ruleset type, Timeout values etc.) that maybe
   communicated through the MIDCOM protocol.
I don't think it adds much to the definition, and it introduces another new
undefined term ("resources").  There was some discussion of removing this
on the list 4 Oct.

Section 6.0 -- policy server.  In the third paragraph it states
   The policy server acts in an advisory capacity to a middlebox to
   authorize or terminate authorization for an agent to gain 
   connectivity to the middlebox. The primary objective of a policy
I think "gain connectivity to the middlebox" is a fairly imprecise wording.
 Section 2.9 (policy server definition) has more/better description than
this section 6.0.  Perhaps some of that can be moved here and replace some
of 6.0.  BTW my understanding, and I can read this into the section 2.9
description but it is not unambiguously stated there, that the policy
server may govern which agents may establish midcom sessions with the
middlebox *and also* restrict what Rulesets a given agent may manipulate.
No?  Perhaps we can clarify that.

Section 6.2 -- registration.  The first paragraph explains that
registration is different than establishing a session.  The phrase
"transport session" is used several times in this paragraph.  I suggest
that the first two uses should be replaced with the recently defined term
"Midcom session".

Section 6.2.  The third paragraph seems confusing.  Also, it discusses
either the agent or the middlebox initiating the midcom session.  My
understanding from the requirements discussion etc. is that we have come
around to only the agent initiating the session.  I suggest modifying the
paragraph as follows:
   The MIDCOM agent profile may be pre-configured on the middlebox while
   provisioning the middlebox function. Thereafter, the agent may choose
   to initiate a Midcom session prior to any data traffic. Alternatively,
   it may choose to initiate a Midcom session only upon noticing the
   application specific traffic. 

Section 6.2.  The 4th paragraph discusses "Coupling MIDCOM agents with the
middlebox ruleset".  I'm not sure what that coupling refers to.  Can we
clarify this?

Section 6.2.  The seventh paragraph is confusing, and again contains the
concept of the middlebox initiating the midcom session.  Since the main
purpose of this paragraph (I think) is to point out that the agent
information may be provisioned into a policy server rather than the
middlebox, and we've said that above, I suggest just omitting this paragraph.

Section 6.2, 8th paragraph.  The first seven lines here are about midcom
session disconnection and have nothing to do with
registration/deregistration.  Since they cover material already presented
in section 4, I suggest deleting them.

Section 11-security considerations.  The first paragraph points out some
deleterious effects of middleboxes on security protocols.  The second
paragraph seems to state that midcom can fix all this because the middlebox
will no longer need to inspect or modify data.  The text should acknowledge
that the midcom model does not help with the problem of NAT breaking IPsec
since in this case the middlebox still modifies data that matters.

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 4 Nov 2001 23:17:21 -0800 (PST)

> These are just suggestions on the document, not I think on the fundamental
OK.
> undefined term ("resources").  There was some discussion of removing this

The above sentence is meant to provide the context in which the term is
applicable. SO, I will simply replace the above sentence as follows to avoid
adding new terms.

    Rulesets are communicated through the Midcom protocol.

> of 6.0. 

Hope the following rewording will work for you.

  The policy server acts in an advisory capacity to a middlebox to
  authorize or terminate authorization for an agent attempting
  connectivity to the middlebox.

>         BTW my understanding, and I can read this into the section 2.9

Mark -Please refer paragraph 2 of section 6.2. The docoument cannot be 
an exhaustive list of all the items people want to include in a policy
server. The paragraph lists items that may be included, but not limited
to these.

> that the first two uses should be replaced with the recently defined term
OK.

>    application specific traffic. 
You are right about the client-server conclusion. Only an agent is assumed
initiate the session. So, the first 2 sentences make sense. 

But, the last sentence is perhaps meaningless in the context of
client-server communication. How does a MIDCOM agent notice application
specific traffic, without the middlebox informing it? A middlebox will
not know to notify an agent it is not in session with. So, I will remove
the last sentence.

> middlebox ruleset".  I'm not sure what that coupling refers to.  Can we

The coupling (or preconfiguring) of Midcom agents with Filter Spec was 
described when a middlebox is permitted to initiate a session with an 
agent. When an Agent is preconfigured to be associated with a Filter Spec, 
the middlebox knows to invoke the agent for the first packet
matching the Filter Spec. 

Now, I understand, a decision has been made by the WG that the MIDCOM 
protocol should be client-server type and not peer-to-peer. Sorry, 
I wasnt able to participate in the discussion at the time. So, I will
go along with the WG decision.

In the revised light of client-server type communication, I believe,
the coupling of an Agent with Filter Spec is still relevant in that 
it refers to agent authorization policy (i.e., session tuples for 
which the agent is authorized to act as ALG) on the middlebox. I could
reword the paragraph as follows. 

   MIDCOM agent authorization policy may be preconfigured on a
   middlebox, by specifying the agent in conjunction with Filter Spec
   for a middlebox service. In the case of a firewall, for example, the 
   ACL tuple may be altered to reflect the optional Agent presence.
   The revised ACL may look something like the following.   

   (<Session-Direction>, <Source-Address>, <Destination-Address>, 
   <IP-Protocol>, <Source-Port>, <Destination-Port>, <Agent>)
 
> middlebox, and we've said that above, I suggest just omitting this paragraph.

This is about session termination (not initiation). SO, I dont believe
there should be any confusion about middlebox initiating the MIDCOM session.
Anyways, I am OK with dropping the paragraph.

> in section 4, I suggest deleting them.
OK.

> since in this case the middlebox still modifies data that matters.
OK. I will add the following sentence at the end of second paragraph.

   Note, however, the MIDCOM framework does not help with the problem 
   of NAT breaking IPsec since in this case the middlebox still modifies
   IP and transport headers.

regards,
suresh

=====

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com