Subject: [midcom] AD evaluation comments on draft-ietf-midcom-mib-07

From: Magnus Westerlund <[email-masked]>
Date: Wed, 26 Jul 2006 16:39:07 +0200

Hi,

I have reviewed the draft and do have a few comments. Please answer my 
questions and I think the draft will benefit from a smaller update. I 
will start my vacation on Monday so I hope we can resolve things this week.

1. midcomGroupLifetime:

I wonder why this object is defined as providing the longest time until 
something expires. Would not the MIDCOM client be more interested in the 
shortest time until something in the group expires?

2. Section 5.2.1:
"  The second object indicates whether or not the middlebox capabilities
    described by midcomConfigIfBits are available or not available at the
    indexed IP interface."

I think this refer to "midcomConfigIfEnabled" however the description 
does not match the declaration.

3. Section 7.3, first bullet: How does the MIDCOM client determine which 
midcomGroupIndex that are unused if it wants to create a new group?

4. Section 9: midcomRulePortRange:

What if one like to create a rule with a larger range of ports than a 
single one or two. I have seen at least some applications that uses port 
ranges. They are also not dependent on the even odd rule. Because of 
this I ask if there wouldn't make sense to allow larger ranges. I 
haven't analyzed if that would have impact on other things. As I see the 
alternative is to try to reserve the complete range using single or pairs?

5. midcomRuleInternalIpAddr, midcomRuleExternalIpAddr, 
midcomRuleInsideIpAddr and midcomRuleOutsideIpAddr:

I think the descriptions should include the A0-A3 designation of what 
addresses one is discussing. Because the current definitions are not 
particular clear on what address one refers to.

6. midcomRuleInternalIpAddr and midcomRuleInternalIpPrefixLength:

The wildcarding of the addresses does not seem 100% to me. You can use 
the prefix length to wildcard an address. However the support is 
optional. So what happens when one like to wildcard or not specify an 
address because one can't or it does not make sense? Especially for the 
outsideIpAddr that the MIDCOM client may not know and is actually 
requesting the MIDCOM server to assign?

7. midcomConfigFirewallGroupId: I don't understand what scope and effect 
this object has. It is not clear if it can be used to reassign rules or 
if only rules created after the value takes effect. In fact I have some 
problem seeing what it is used for at all with the definition it has.

Nits:

1. Page 10, last paragraph:
"The manager polls status
    information at the SNMP agent using SNMP get transactions until it
    detects the end of the processing the request."

This sentence is missing an "of" before "the request".

2. Section 4.2.4.3:
"Potentially, the monitoring transactions Policy Rule List (PRL),
    Policy Rule Status (PRS) Group List (GL) and Group Status (GS) are
    not atomic, because these transactions may be implemented by more
    than one SNMP get operations."

Seem to be missing a comma after (PRS).

3. Section 9, midcomRulePortRange:
"Requesting the a consecutive pair of port numbers
             is required for supporting the RTP and RTCP protocols,
             see RFC1889."

I would like to change this to:
"Requesting a consecutive pair of port numbers may be used by RTP 
[RFC3550] and may even be required to support older RTP applications."

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 27 Jul 2006 17:19:46 +0200

Hi Magnus,

Many thanks for the review!

Please find replies inline.
We can post a new version immediately after agreeing on the changes.

Best regards,

    Martin and Juergen

--On 26.07.2006 16:39 Uhr +0200 Magnus Westerlund wrote:

> Hi,
>
> I have reviewed the draft and do have a few comments.
> Please answer my questions and I think the draft will benefit
> from a smaller update. I will start my vacation on Monday so
> I hope we can resolve things this week.
>
> 1. midcomGroupLifetime:
>
> I wonder why this object is defined as providing the longest
> time until something expires. Would not the MIDCOM client be
> more interested in the shortest time until something in the
> group expires?

Groups in the MIDOCOM MIB only exist conceptually.
There are no explicit group instances containing any state
beyond the the state contained in members.

Please see the DESCRIPTION clause of midcomGroupTable:

         Entries in this table are created or removed
         implicitly when entries in the midcomRuleTable are
         created or removed, respectively.  A group entry
         in this table only exists as long as there are
         member rules of this group in the midcomRuleTable.

Groups are instantiated by instantiating the first member
and they are removed by removing the last remaining member.
Therefore, the lifetime of the group is the maximum of all member
lifetimes.

> does not match the declaration.

We suggest clarifying this sentence by replacing

OLD:

     The second object indicates whether or not the middlebox capabilities

with NEW:

     The second object called midcomConfigIfEnabled indicates whether or not the middlebox capabilities

The DESCRIPTION clause of object midcomConfigIfEnabled
in the MIB module needs fixing:

replace OLD:

        "The value of this object indicates the availability of
         the middlebox service described by midcomCapabilitiesBits
         at the indexed IP interface.

with NEW:

        "The value of this object indicates the availability of
         the middlebox service described by midcomConfigIfBits
         at the indexed IP interface.

> 3. Section 7.3, first bullet: How does the MIDCOM client determine
> which midcomGroupIndex that are unused if it wants to create a new group?

A group is identified by the combination of midcomRuleOwner and midcomGroupIndex.
Every client can maintain its own group name space indepenedent of others
clients, except they act at the same midcomRuleOwner, which the document
recommends only for fail-overs and other particular cases.

If, for example after a failover, the client does not know which groups
do already exist, it may browse the group table.

> What if one like to create a rule with a larger range of ports than a single
> one or two. I have seen at least some applications that uses port ranges.
> They are also not dependent on the even odd rule. Because of this I ask
> if there wouldn't make sense to allow larger ranges. I haven't analyzed
> if that would have impact on other things. As I see the alternative is to
> try to reserve the complete range using single or pairs?

Initially, we allowed ranges of arbitrary sizes.  But then usefulness
of this was questioned in the working group.  The only use case the WG
identified where dynamic configuration of a port range larger than 1
is required was the RTP/RTCP case.  All other applications requesting port
ranges usually do so because of lack of dynamic configuration means.
For instance, for a FTP server port ranges for incoming data connections
are solely defined, because the server cannot instruct the firewall
on a per FTP-session base to open pinholes.
This is not a problem for the MIDCOM MIB.

Finally, because it was not covered by the MIDCOM requirements in RFC
3304, the WG agreed on just supporting single ports and port pairs.

> 5. midcomRuleInternalIpAddr, midcomRuleExternalIpAddr, midcomRuleInsideIpAddr
> and midcomRuleOutsideIpAddr:
>

OK.  For the DESCRIPTION clause of object midcomRuleInternalIpAddr

replace OLD:

        "The internal IP address.

with NEW:

        "The internal IP address (A0).

For the DESCRIPTION clause of object midcomRuleExternalIpAddr

replace OLD:

        "The external IP address.

with NEW:

        "The external IP address (A3).

For the DESCRIPTION clause of object midcomRuleInsideIpAddr

replace OLD:

        "The inside IP address at the middlebox.

with NEW:

        "The inside IP address at the middlebox (A1).

For the DESCRIPTION clause of object midcomRuleOutsideIpAddr

replace OLD:

        "The outside IP address at the middlebox.

with NEW:

        "The outside IP address at the middlebox (A2).

> The wildcarding of the addresses does not seem 100% to me.
> You can use the prefix length to wildcard an address. However the
> support is optional. So what happens when one like to wildcard or
> not specify an address because one can't or it does not make
> sense? Especially for the outsideIpAddr that the MIDCOM client may
> not know and is actually requesting the MIDCOM server to assign?

insideIpAddr and outSideIpAddr are read-only.  They are not among
the input parameters listed in the DESCRIPTION clause of object
midcomRuleAdminStatus.  Both are output parameters of client request
and their values are assigned by the middlebox.

> 7. midcomConfigFirewallGroupId: I don't understand what scope and
> effect this object has. It is not clear if it can be used to
> reassign rules or if only rules created after the value takes effect.
> In fact I have some problem seeing what it is used for
> at all with the definition it has.

The midcomConfigFirewallGroupId defines to which firewall rule group
the MIDCOM rules are added. Some firewalls support grouping of rules
into sets/groups. This allows easier reading of rule sets. See, for
instance, groups o sets in ipf or IPFW on FreeBSD.

> This sentence is missing an "of" before "the request".

fixed.

> Seem to be missing a comma after (PRS).

fixed.

> [RFC3550] and may even be required to support older RTP applications."

done.

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 27 Jul 2006 08:46:20 -0700 (PDT)

Thanks, Martin & Juergen. I agree with all the responses below. 

regards,
suresh

--- Juergen Quittek <[email-masked]> wrote:

> single

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Jul 2006 18:42:58 +0200

Hi,

Thanks for the quick reply. I do have some follow up below. When these 
have been resolved please submit a new document. Then I should be able 
to put it on IETF last call so it will be ready to go to IESG when I am 
back from my vacation.

> Therefore, the lifetime of the group is the maximum of all member

Yes, you are correct that the groups lifetime is the maximum of the 
included rules. However from a usability point of view it seems that the 
minimum would be better. However if the WG thinks this is fine, then I 
will not persist with my point of view.

>         at the indexed IP interface.

Thanks, seems good.

> do already exist, it may browse the group table.

Okay, that is true. I would have preferred some clarification on this.

> 3304, the WG agreed on just supporting single ports and port pairs.

Sure, I am fine without any changes on this. There are ways around the 
problem.

>        "The outside IP address at the middlebox (A2).

Thanks.

> and their values are assigned by the middlebox.

Okay, so these are always know entities. Thus not a big problem. Only 
when defining like firewall rules for whole networks one will have real 
use for wildcarding. Thanks for the clarification.

> instance, groups o sets in ipf or IPFW on FreeBSD.

Okay, however is really the "all" part of the below description correct 
then?

"The firewall rule group to which all firewall
            rules of the MIDCOM server are assigned."

>> [RFC3550] and may even be required to support older RTP applications."

Thanks.

Magnus Westerlund

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 27 Jul 2006 11:23:34 -0700 (PDT)

Magnus,

Please see my comments below inline.

regards,
suresh

> will not persist with my point of view.
[suresh] The midcomGroupTable entries are created implicitly when rules are
created in the RuleTable. So, it is only natural that the lifetime of a group
entry match the largest (not the smallest) lifetime of the memeber entries.
Now, if the midcom client chooses to reduce the timing for the rules beloning
to a group, the group entry provides a shortcut to set the ceiling on lifetime
for all member entries. Hope this helps.

>             rules of the MIDCOM server are assigned."
[suresh] The firewall table is per-port specific. So, the "all" would be right
when the FirewallIndex is 0. Would the following rewording work for you.

    The firewall rule group to which all firewall rules for the 
    specified interface of the MIDCOM server are assigned. When 
    midcomConfigFirewallIndex is set to 0, all firewall rules
    of the MIDCOM server are assigned the same firewall rule group.

Similarly, the description for midcomConfigFirewallPriority can be changed as
follows.

OLD:
      "The priority assigned to all firewall rules
           of the MIDCOM server."
NEW: 

      "The priority assigned to all firewall rules for the specified
       interface of the MIDCOM server. When midcomConfigFirewallIndex
       is set to 0, all firewall rules of the MIDCOM server are assigned
       the same priority."

regards,
suresh
"

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 27 Jul 2006 20:27:37 +0200

Hi Magnus,

--On 27.07.2006 18:42 Uhr +0200 Magnus Westerlund wrote:

> Hi,
>
> Thanks for the quick reply. I do have some follow up below.
> When these have been resolved please submit a new document.
> Then I should be able to put it on IETF last call so it will
> be ready to go to IESG when I am back from my vacation.
>
>
> Juergen Quittek wrote:
>>>
>>> 1. midcomGroupLifetime:
>>>
> Yes, you are correct that the groups lifetime is the maximum of
> the included rules. However from a usability point of view it seems
> that the minimum would be better. However if the WG thinks this is
> fine, then I will not persist with my point of view.

When we discussed this in the WG, there was consensus that
groups provide shortcuts to actions on all members.

We consider a group to be existent as long as there is a member.
Hence, object midcomGroupLifetime contains the (expected) lifetime
of the group.

I see no problem with adding another object that provides what
you suggest, maybe called groupShortestMemberLifetime.
But so far, the group has not seen the need for it.

> Okay, that is true. I would have preferred some clarification on this.

I suggest appending a clarification to the second paragraph of
section 5.1.2. "midcomGroupTable":

replace OLD:

   Entries are indexed by the midcomRuleOwner of the rules that belong
   to the group and by a specific midcomGroupIndex.

with NEW:

   Entries are indexed by the midcomRuleOwner of the rules that belong
   to the group and by a specific midcomGroupIndex.  This allows each
   midcomRuleOwner to maintain its own independent group name space.

> Sure, I am fine without any changes on this. There are ways around the problem.
>
>>
> Okay, so these are always know entities. Thus not a big problem.
> Only when defining like firewall rules for whole networks one will
> have real use for wildcarding. Thanks for the clarification.
>
> Okay, however is really the "all" part of the below description correct then?
>

I just saw a message from Suresh arriving on this issue.
I will reply to his message.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 27 Jul 2006 21:06:25 +0200

Hi Magnus and Suresh,

>> to put it on IETF last call so it will be ready to go to IESG when I am

 [...]

>> Okay, however is really the "all" part of the below description correct

The text is not really precise here. As Suresh explains below, all
firewall rules for a particular interface are assigned to the same
firewall group.  However, for different interfaces the groups may
be different.

>     of the MIDCOM server are assigned the same firewall rule group.

This text is better, but still not fully correct.
Even if there is an entry with index 0, then there still may
be entries for other interfaces as indicted in the DESCRIPTION clause
of midcomConfigFirewallTable:

%        The table is indexed by the object midcomConfigFirewallIndex.
%        For indexing a single interface, this object contains the
%        value of the ifIndex object that is associated with the
%        interface.  If an entry with midcomIfIndex = 0 occurs, then
%        bits set in objects of this entry apply to all interfaces
%        for which there is no entry in this table for the
%        interface's index."

Consequently, we should state:

NEW

    The firewall rule group to which all firewall rules are assigned
    that the MIDCOM server creates for the interface indicated by
    object midcomConfigFirewallIndex. If the value of object
    midcomConfigFirewallIndex is 0, then all firewall rules of the
    MIDCOM server that are created for interfaces with no specific
    entry in the midcomConfigFirewallTable are assigned to the
    firewall rule group indicated by the value of this object.

Not forgetting to fix the mistake in the DESCRIPTION clause of the
midcomConfigFirewallTable:

OLD:
        interface.  If an entry with midcomIfIndex = 0 occurs, then
NEW:
        interface.  If an entry with midcomConfigFirewallIndex = 0 occurs, then

>        is set to 0, all firewall rules of the MIDCOM server are assigned

Similarly, this text should be something like

NEW

    The priority assigned to all firewall rules that the MIDCOM
    server creates for the interface indicated by object
    midcomConfigFirewallIndex. If the value of object
    midcomConfigFirewallIndex is 0, then this priority is assigned
    to all firewall rules of the MIDCOM server that are created for
    interfaces for which there is no specific entry in the
    midcomConfigFirewallTable.

Finally, I fixed another small mistake to be fixed in the DESCRIPTION
clause of object midcomConfigIfTable:

OLD:
         The table is indexed by the object midcomIfIndex.
NEW:
         The table is indexed by the object midcomConfigIfIndex.

OLD:
         midcomIfIndex = 0 occurs, then bits set in objects
NEW:
         midcomConfigIfIndex = 0 occurs, then bits set in objects

Thanks,

    Juergen

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Jul 2006 09:50:54 +0200

> But so far, the group has not seen the need for it.

Okay, lets leave things as they are. I think my case is in most cases 
not relevant as it will be the MIDCOM client that has created the group 
and can easily keep track of the shortest itself. And in extreme cases 
when it doesn't have this state it can easily either retrieve it or set 
the midcomGroupLifetime to be certain that all rules in the group has 
the same lifetime.

I am fine with the other changes you propose. Please submit a new draft 
with these changes.

Thanks

Magnus Westerlund

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 28 Jul 2006 20:03:40 +0200

Magnus,

--On 28.07.2006 9:50 Uhr +0200 Magnus Westerlund wrote:

 [...]

> I am fine with the other changes you propose. Please submit a new draft with these changes.

Just submitted it.  You can preview it at

<ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-midcom-mib-08.txt>.

Please find a diff to version -07 at

<ftp://ftp.netlab.nec.de/pub/internet-drafts/diff-07-08.html>.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 4342-115
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de