Subject: [midcom] RE: comments on midcom-requirements-01

From: [email-masked]
Date: Sun, 22 Jul 2001 12:25:46 +0100

Mark,

Thanks for your comments - and no it isn't too late to be raising some of
the points you make (actually it is very welcome!).

I have embedded some comments below. If the list gets wildly active on the
response, I suggest we break them down into specific issues. So here
goes......

> 
> 1.  In general, there is a lot of overlap between this 
> document and the
> framework document.  I would suggest restricting this 
> document to only the
> actual protocol requirements (more or less section 5 on).

This is true. However there is a need to focus in on the specific
environment of the protocol - the framework, from my last reading, the much
wider context of the problem MIDCOM is trying to address. 
> 
> 2.  In section 4.1, "a Middlebox forwards packets from one of 
> its physical
> interfaces to another."  I suggest that should refer to logical (IP)
> interfaces rather than physical.
> 

In thinking further about the problem we are trying to grapple with, I think
we need to have a much wider discusion on the "view" that a MIDCOM Agent can
obtain. The issue of interfaces is one aspect of this. For example, MIDCOM
is trying to enable an external (from the Middlebox) ALG to be written for a
specific protocol or application. However there - and I think we have agreed
this (this email is testing for concensus on the email list if not!) - the
requirement that the Middlebox can support multiple concurrent MIDCOM
Agents. So there is a need for the Middlebox to be able to say to an Agent,
here are the things that are appropriate to you (and by the way I'm not
telling you what else is going on!).

> 3.  In section 5.1,it states that "applications may 
> require... translation
> of IP addresses... and knowledge of the specific translations 
> used".  In
> fact, applications do not require this and cannot get this 
> knowledge unless
> they happen to be acting as the Midcom Agent.  Rather, 
> operation of the
> application through the middlebox may require the translation of IP
> addresses etc.  And it is the Midcom Agent that may require 
> knowledge of
> the specific translations used.  I propose replacing "Applications may
> require ..." with "Midcom agents may request...".

Yes I agree this area needs revisiting. I'll make a point to have a look at
the text and consider your observation appropriately.

> 
> 4.  Regarding the agent having knowledge of the specific 
> translations used,
> is there any requirement that the agent be able to *control* the
> translations used???  I think in general the middlebox itself 
> needs to be
> in control of allocating any address/port bindings, but are there
> applications where multiple packet flows associated with the same
> application instance must be assigned the same address, for 
> the application
> to work correctly?  If so, the midcom protocol must allow the agent to
> request this of the middlebox.
>

The Agent needs to be able to figure out what the Middlebox has done and is
planning to do with packets that travers the Middlebox that are pertinent to
the application that the Agent is assisting.
 
> 5.  In 5.2.1, 2nd paragraph, it says "The attributes associated with a
> Pinhole-Descriptor may be specific to a given Middlebox or 
> MIDCOM Agent."
> Can you please clarify what this means?  To what 'attributes' 
> does this
> refer?  If it refers to (direction, SA, DA, protocol, SP, DP) 
> than those
> should be specific to an application but not to a given 
> middlebox or agent!
> 

I believe we were referring to the directionality, source/destination
address etc.. I agree that the setting of the attributes are specific to an
applications (the data fill). I'll have a look.

> 6.  Also in 5.2.1, I believe that pinhole specification 
> should be specified
> by "DSCP field" (high 6 bits of the old TOS octet) rather than by the
> now-obsolete "TOS field".  This is probably also true for IPv6 traffic
> class field.
> 

Thanks - I take this on board.

> 7.  At the end of 5.2.1 it says that the midcom protocol 
> needs to convey
> directives to the middlebox on how to rewrite header fields such as
> addresses and port numbers.  How is the agent to know what 
> addresses/ports
> may be assigned?  Since the agents are distributed I think it 
> must be the
> middlebox that controls the allocation of these.  (Perhaps 
> subject to some
> influence from the agent per my comment #4 above.)
> 

I think this comes back to the resource discovery part discussed above. For
an Agent to work correctly is needs to know information about the Middlebox
to be able to manipulate the packet content correctly (i.e. to handle
embedded Source and Destination Addresses etc.).

> 8.  5.3.2 Close Pin-Hole.  Is it still the intent that only 
> the agent that
> created a pinhole can close it?  I recall some discussion 
> about this on the
> list but I don't recall the conclusion.  This would be an 
> impediment to
> distributed/redundant agents, but is also a factor in 
> how/whether pinholes
> are timed out.
> 

I don't recall any conclusion to the discussion and have this as an open
issue which we need to debate and close (if you will excuse the pun).

> 9.  Also relative to closing pinholes, if they are not to be 
> automatically
> closed when losing connectivity with the requsting agent, then I think
> there should be a mechanism for identifying stale pinhole 
> identifiers (as
> presented by an agent to a middlebox or vice-versa) so that 
> the devices can
> discard requests for actions on those pinholes.  This could 
> be sequence
> numbers or qualifying the pinhole identifier with the identity of the
> owning Midcom Agent.
> 

I think this needs to be factored into the debate as per your previous
comment. If it is possible to leave mases of pin-holes open then we are by
definition providing a route for a denial of service attack aren't we?

> 10.  Section 6.1 seems to embody a different concept of 
> "registration" than
> the framework draft.  From my read of the framework, 
> registration is the
> process of configuring a particular agent into either the middlebox or
> policy server as an authorized agent.  The agent and the 
> middlebox may then
> authenticate each other each time they want to have a session between
> themselves.  In this requirements draft "registration" seems 
> to refer to
> the mutual authentication.  The concepts of registration, 
> authorization,
> authentication, and the middlebox-agent session establishment 
> need to be
> more clearly delineated.
> 

Yes they do. Thanks for spotting this.

> 11.  Section 7, 7.1.1, 11.2, and 4.1(3rd paragraph) -- is 
> this all obsolete
> text describing diversion of packets to an OOP agent, and 
> slated for removal?
> 

Yes I think the in-path/out-of-path debate was a red herring. If the MIDCOM
Agent is identified as a sub-component of a ALG then the whole debate in
this area can be removed since it is then down to the application and the
ALG writer to determine how they handle things.

> 12.  7.1  "A MIDCOM Agent shall be able to request a pin-hole from a
> Middlebox for the purposes of establishing a presence on the external
> network."  -- I don't understand what is meant by 
> "establishing a presence
> on the external network".  Perhaps this should say "... purposes of
> allowing communication to or from the external network".
> 

I think this is a throwback to the in-path/out of path debate.

> 13.  7.1 "The MIDCOM communication protocol needs to allow 
> for selective
> communication between a specific MIDCOM agent and one or more 
> Middlebox
> functions on the interface to which it is connected."  -- why 
> only "on the
> interface to which it is connected"?  It seems to me the 
> pinholes may need
> to apply to interfaces other than the one(s) via which the agent
> communicates with the middlebox.
> 

Hmmmm - I'll have to look at that.

> 14.  10.4, 2nd paragraph: "The MIDCOM Protocol shall describe 
> the desired
> behaviour of the Middlebox for the purposes of a requested 
> flow(s)."  This
> paragraph does not seem to belong in this section which is about
> authentication requirements.
> 

Hmmmm - I'll have to look at that.

> 15.  Section 10.5 MIDCOM Policy Requirements. I'm confused by 
> this section
> which discusses a protocol between midcom *agents* and policy 
> servers.  The
> framework document discusses communication between the 
> middlebox and policy
> servers but not between the agents and policy servers.  And 
> that protocol
> is presumably out of the scope of this document anyway.  I 
> suggest removing
> section 10.5.
>

Hmmmm - I'll have to look at that.
 
> 16.  Section 10.7 -- protocol reliability.  It is highly desirable for
> redundant-hardware implementations that midcom sessions (i.e. 
> midcom-level
> shared state) between an agent and a middlebox be able to 
> survive restarts
> of the transport layer connection.  At least, if the 
> transport layer is TCP
> or a protocol that is similarly difficult to support across a 
> control plane
> hardware failover.  Work is underway in the IETF to address 
> this for BGP
> and LDP.  I think it is also important for midcom.
> 

Yes this is an area where we need to get a better understanding into the
document.

> 17.  In section 12: "Simple Source-address based security is 
> the least form
> of security and should be permitted only to the  most trusted 
> hosts."  It
> doesn't matter how trusted the hosts are if someone can spoof them.  I
> propose changing the wording to "... is a minimal form of security and
> should be permitted only in the most trusted environments 
> where those hosts
> won't be spoofed."
> 

Or in environments where it isn't important. Yes - good point.

> 18.  Section 12: "The MIDCOM protocol must enable a trust 
> relationship to
> be established between a specific MIDCOM Agent and a specific 
> Middlebox for
> the purposes of permitting flows between the hosts that flow via the
> Middlebox."  This is quite confusing, and it only seems to 
> cover pinholes
> not any other middlebox services.  I propose changing the 
> wording to "...
> for the purposes of permitting midcom operations to be 
> performed only in
> response to authentic and authorized requests."
> 

I'll look at the text again.

> 19.  Section 12. through 12.1.2.  This whole discussion of trusted and
> un-trusted agents is confusing.  It seems to state clearly that the
> middlebox should only accept requests from trusted agents but 
> it also talks
> about untrusted agents.  Is an untrusted agent just one we don't trust
> *yet*, or you trying to allow for a sort of "connectionless 
> trust"?  If the
> former the wording should be improved.  If the latter, I 
> don't see how this
> would work given the requirements (e.g. in section 6.2) to 
> close pinholes
> etc when the relationship (trust?) with the peer goes away.  
> Overall, the
> terms trust and trust relationship are overused in the 
> industry and poorly
> defined.  It might be more clear not to use those terms here 
> at all and
> instead talk in terms of authentication and authorization.

This area is a bit of a throwback to the charter and I agree it needs some
more careful development.

> 
> 20.  Section 12.2 item b.  "Allow for preservation of the 
> control messages
> once the association has been established."  I'm not sure 
> what preservation
> means.  Can this be reworded to "Allow for protection of 
> integrity of the
> control messages..."?
> 

Yes this is a difficult area. On the one hand we need to make sure that
things don't get out of synch that can't may need to be used in "evidence"
of service operation. Conversely I'm aware that this is the "Two Generals
and their sub-divisions" problem. I think more debate is needed.

> -- Thanks, Mark

Indeed you are most welcome - thanks for reading the document and providing
constructive feedback.

regards

Richard

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Jul 2001 17:03:31 -0500

> Mark,
...
> > now-obsolete "TOS field".  This is probably also true for IPv6 traffic

I already commented that the correct phrase is "DS field" (that is the field
that contains the DSCP value, if you want to be pedantic).

Also it occurs to me that the IPv6 Flow Label should also be a (possibly
wild carded) part of the pinhole spec. This is an active item now
(draft-conta-ipv6-flow-label-02.txt) and it is certainly a potential
requirement.

For the record, I still object to the assertion in section 9 that the
midcom protocol should be involved in QOS resource control, as was
discussed here on June 29.

   Brian

---

From: "Scott Brim" <[email-masked]>
Date: Mon, 23 Jul 2001 18:16:34 -0400

Brian, I believe we've agreed not to address such possibilities at this
time.  However, at some future date I can conceive of an agent telling a
middlebox "my client wants service to Tokyo and requests this kind of
treatment for his traffic".  If you're going to allow clients to make such
requests at all, via RSVP or however, and you allow for the concept of
agents at all, why wouldn't you allow agents to make such requests?
Especially when many agents will simply be compartmentalization of
intelligence which is already in some end systems.

...Scott

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 23, 2001 6:03 PM
Subject: Re: [midcom] RE: comments on midcom-requirements-01