Subject: [midcom] Re: Alain Durand: Re: [ietf-sirs] Review request

From: Martin Stiemerling <[email-masked]>
Date: Tue, 05 Aug 2003 16:01:32 +0200

Hi are some replies to the issues raised below, are all included inline.

Martin

|
| Melinda,
|
| Here is a first set of comments. Some are minor. Issue 6 & 7 are more
| important,
| as they would impact a number of sections in the document.
|
| 	- Alain.
|
|
| Issue 1:
| - --------
| 2.1.1.  Protocol Transactions
| [...]
|     An analysis of the requirements showed that four kinds of
|     transactions are required:
|
|       - configuration transactions allowing the agent to request state
|         transitions at the middlebox
|
|       - asynchronous transactions allowing the middlebox to change state
|         without a request by an agent.
|
|       - monitoring transaction allowing the agent to request state
|         information from the middlebox
|
|       - convenience transactions combining a set of configuration
|         transactions
|
|     Configuration transactions and notification transactions provide the
|     basic MIDCOM protocol functionality.  They are related to middlebox
|     state transactions and they concern establishment and termination of
|     MIDCOM sessions and of policy rules.
|
|     Monitoring transactions are not related to middlebox state
|     transitions.  They are used by agents for exploring number, status
|     and properties of policy rules established at the middlebox.
|
|     Convenience transaction simplify MIDCOM sessions by combining a set
|     of configuration transactions into a single one.  They are not
|     necessary for MIDCOM protocol operation.
|
| ==> There seems to be a terminology issue here, "notification
| transaction"
| is not part of the list of the 4 kinds of transactions.

Notification transactions do belong to the asynchronous transactions,
but of course this should be mentioned explicitly in the text.

|
|
|
| issue 2:
| - --------
| 2.1.2.  Message Types
| [...]
|     For request messages and positive reply messages there exists one
|     message type per request transaction.  Each reply transaction defines
|     the parameter list of the request message and of the positive
|     (successful) reply message using the transaction definition template
|     that is defined in Section 1.2.
|
|     In case of a failed request transaction, a negative reply message is
|     sent from the middlebox to the agent. This message has the same type
|     for all request transactions. It contains the request identifier
|     identifying the request on which the reply is sent and a parameter
|     indicating the failure reason.
|
| ==> it seems a bit strange to me to dissociate positive & negative
| messages
|      this way. There may be different failure mode, and negative return
|      message should be tailored to specific transaction in the same way
|      positive messages are.

I do not see exactly the point where the strange dissociation is. Is it
that: "For request messages and positive reply messages there exists one
message type per request transaction." together with having a separate
negative reply type?

|
|
| Issue 3:
| - --------
| 2.1.5.  Access Control
|
|     Access to policy rules and policy rule groups is based on ownership.
|     When a policy rule is created, a middlebox unique identifier is
|     generated for identifying it in further transactions.  Beyond the
|     identifier, each policy rule has an owner.  The owner is the
|     authenticated agent that established the policy rule.  The middlebox
|     uses the owner attribute of a policy rule for controlling access to
|     it:  each time an authenticated agent requests to modify an existing
|     policy rule, the middlebox determines the owner of the policy rule
|     and checks if the requesting agent is authorized to perform
|     transactions on the owning agent's policy rules.
|
|     All policy rules belonging to the same policy rule group must have
|     the same owner.  Therefore, authenticated agents either have access
|     to all members of a policy rule group, or to none of them.
|
|     The middlebox may be configured to allow specific authenticated
|     agents to access and modify policy rules with certain specific
|     owners.  Certainly, a reasonable default configuration would be that
|     each agent can access its own policy rules.  Also, it might be a good
|     idea, to have an agent identity configured to act as administrator
|     being allowed to modify all policy rules owned by any agent.  Anyway,
|     the configuration of authorization is not subject of the MIDCOM
|     protocol semantics.
|
| ==> The last sentence is a bit curious. I think it would actually make
| sense
|      to define the semantic of which agent are allowed to modify what.
|      For example, one could envision a hierarchy of agents, where each
| agent
|      would be allowed to modify configuration done by agent bellow him,
|      or, to define agent groups, where each agent of the group has equal
|      privileges.

We do not what any type of multiple agent hierachy. The flat hierachy
within the semantics is that agents usually have only rights to access
their policy rules/groups and that only a very small set (in most cases
one agent) is a superuser agent. This superuser agent can access all
policy rules/groups. The configuration of authorization at the middlebox
is out of scope.

|
| Issue 4:
| - --------
| 2.2.1.  Session Establishment (SE)
| [...]
|        Session establishment may be simplified by using only a single
|        transaction.  In this case server challenge and agent challenge
|        are omitted by the sender or ignored by the receiver, and
|        authentication must be provided by other means, for example by TLS
|        [RFC2246] or IPSEC [RFC2402][RFC2406].
|
| ==> As the rest of the document seem to imply that either TLS or IPsec
|      would be used, why bother using this double challenge response?
|      And if TLS or IPsec are not used, is this challenge/response
|      exchange mandatory?
|      Also, if TLS or IPsec are not used, why only protecting Session
|      Establishment using challenge/response and not all transactions?

It is mandatory to use TLS/IPSEC like securtiy protocols, since otherwise
the most security requirements of MIDCOM are not met. A possible scenario
for this additional challenge response: A user of MIDCOM does not want to
use any type of security protocol (certainly not recommended!)and run 
MIDCOM over a dedicated wire between agent and middlebox. In this case a 
challenge response handshake would make sure that the right middlebox and 
agent are
involved.

|
| Issue 5:
| - --------
| 2.3.2.  Establishing Policy Rules
| [...]
|     On a traditional NAT, just an external address is reserved; on a
|     twice-NAT, an internal and an external address is reserved.  In both
|     cases the reservation concerns either an IP address only or a
|     combination of an IP address with a range of port numbers.
|
| ==> Not being a NAT expert, I'm not sure to really understand what
|      reserving an IP address means. A little explanation will help.

OK, we will do so.

|
| Issue 6:
| - --------
| 2.3.5.  Address Tuples
|
|     Request and reply messages of the PRR, PER, and PRS transactions
|     contain address specifications for IP and transport addresses.  These
|     parameters include
|
|        - IP version
|        - IP address
|        - IP address prefix length
|        - transport protocol
|        - port number
|        - port parity
|        - port range
|
| ==> Actually, if one wants to specify a flow, this is not enough.
|      In particular, in the early stages of IPv6 deployment,
|      we see a lot of encapsulated traffic, IPv6/IPv4 (proto 41)
|      or IPv6/UDP/IPv4.
|      This would be of importance if the middlebox is a de-capsulator,
|      or a NAT/forwarder of IPv4 proto 41 and you'd like to use the
|      MIDCOM protocol to configure it.

There has been discussions about this topic on the list. Especially
SCTP was mentioned. But since nobody knows by now, how and when
this encapsulation is integrated into NATs, we concentrated us on
protocols that are used and furthermore documented in the NAT MIB.
(That are IP, TCP, and UDP).

|
|
| Issue 7:
| - --------
| 2.3.6.  Address Parameter Constraints
| [...]
|     The value of the transport protocol parameter can have one of the
|     following values: 'TCP', 'UDP', 'ANY'.
|
| ==> What about other transport protocols? Previous comment applies here
| too.
|      The semantic here should be extended to be more general.

Other protocols are not clear with respect to NAT handling. Since a MIB
module will do the job of MIDCOM, and the NAT MIB module is in the race,
the focus should be protocols supported by that MIB module.
Any other protocol is nice to have, but supporting all possible protocols
is too much and are better handled by further extensions.

Martin

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