Re: AD evaluation comments on draft-ietf-midcom-mib-07

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

>>
>>> 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.
>>
>> 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.
>>
>
> Thanks, seems good.
>
>>
>>> 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.
>
> 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.

>>
>>
>>> 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?
>>
>> 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.
>
> Sure, I am fine without any changes on this. There are ways around the problem.
>
>>
>>> 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.
>>
>> 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).
>>
>
> Thanks.
>
>>
>>> 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?
>>
>> 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.
>>
>
>
> 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.
>
>>> 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.
>>
>
> 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."

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

Thanks,

    Juergen