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

From: Mark Duffy <[email-masked]>
Date: Fri, 20 Jul 2001 17:29:06 -0400

Hi, I have some comments and questions on
draft-ietf-midcom-requirements-01.txt.  I know this draft has been out for
a while so my apologies if I am raising questions on any "stale" material.

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).

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.

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...".

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.

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!

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.

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.)

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.

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.

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.

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?

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".

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.

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.

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.

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.

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."

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."

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.

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..."?

-- Thanks, Mark

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

---

From: John LaCour <[email-masked]>
Date: Mon, 23 Jul 2001 15:51:30 -0700

It seems to me that the DS field is part of the layer 3 header
and therefore in scope.

I would like to be able to use MIDCOM for QoS type things
in the future.  I'm ok focusing on pin-holes and NAT initially,
but lets make sure that the Requirements reflect the ability
to add additional functions to the protocol such as this in 
the future.  

I'd also like the Requirements to reflect the need to support
custom/arbitrary/vendor specific MIDCOM requests.  There are
many protocols which support this concept such as DHCP,
HTTP etc.  This would allow me to use MIDCOM to ask my middlebox 
to perform functions that other middleboxes don't perform or
for my middlebox to perform the task in a different way.
Thoughts?

Another general comment... there are several MIDCOM related drafts
which are not reflected on the MIDCOM home page
(http://www.ietf.org/html.charters/midcom-charter.html).  It
would probably be a good thing for people who are just now
starting to do their homework on MIDCOM in preparation for the
meeting to review these documents as well.  

Is there any way to get the homepage updated or is there a 
reason why these drafts are not included?

-John

> From: Scott Brim [mailto:[email-masked]]
> Sent: Monday, July 23, 2001 3:17 PM
> To: Brian E Carpenter; [email-masked]
> Cc: [email-masked]
> Subject: Re: [midcom] RE: comments on midcom-requirements-01
> 
> 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
> 
> 
> > 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.
>