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

From: Melinda Shore <[email-masked]>
Date: Wed, 23 Jul 2003 10:04:43 -0400

Some of you may be aware that there's an experiment underway
within the IETF, called "SIRS" (Senior Internet ReviewerS),
to provide a pool of expert reviewers with an eye towards
improving the quality of IETF documents.  The web page is
http://www.graybeards.net/sirs/sirs.html.  Partly as a way
of trying out the proposed service and largely because the
semantics document received so little review, I requested a
review of that document by SIRS participants.  I've appended
a copy of the first response we've gotten.

Thanks,

Melinda

------- Forwarded Message

Date:    Tue, 22 Jul 2003 23:20:59 -0700
From:    Alain Durand <[email-masked]>
To:      Melinda Shore <[email-masked]>
cc:      [email-masked]
Subject: Re: [ietf-sirs] Review request

On Monday, July 21, 2003, at 03:11  AM, Melinda Shore wrote:

> I'd like to request a review of
> http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-03.txt.
> The document has gone through wg last call with only one set
> of comments returned, and we need a more thorough review
> with an eye towards the question of whether or not the
> document is sufficiently mature to send to the IESG.

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.

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.

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.

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?

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.

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.

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.

------- End of Forwarded Message

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