Re: [Dime] Updated DOIC Requirements Analysis

[Steve Donovan <[e-mail]>]

On 1/20/15 2:30 PM, Ben Campbell wrote:
>> On Jan 20, 2015, at 12:49 PM, Steve Donovan <[e-mail]> wrote:
>>
>> I'm not currently planning to make any updates to the requirements analysis section as I haven't seen consensus on the need to change anything in the portion that will remain in the document.
>>
>> If we want to continue to debate the sections that are slated to be removed then I suggest we do that in a separate email thread that is not tied to moving the document out of WGLC.
> Isn't this that separate thread?
SRD> Yes, I was thinking in terms of the set of items that needed 
addressing for WGLC.
>
> But in any case, I do not think we need changes to the reqs analysis sections, especially the detail section that we have been directed to remove.
SRD> Cool
>
>> Regards,
>>
>> Steve
>> On 1/7/15 2:54 PM, Ben Campbell wrote:
>>> (Catching up on older stuff)
>>>
>>> Comments inline. But keep in mind that the detailed requirements are to be removed from the RFC, so I'm not sure we need to spend too much time on them. (Only the first discussion point addresses text that is to remain in the RFC.)
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>>> On Dec 12, 2014, at 2:24 AM, Maria Cruz Bartolome <[e-mail]> wrote:
>>>>
>>>> Hello Ben,
>>>>
>>>> See comments below
>>>> Thanks
>>>> /MCruz
>>>>
>>>>> C.2.  Detection of non-supporting Intermediaries
>>>>>
>>>>>    The DOIC mechanism as currently defined does not allow supporting
>>>>>    nodes to automatically determine whether OC-Supported-Features or OC-
>>>>>    OLR AVPs are originated by a peer node, or by a non-peer node and
>>>>>    sent across a non-supporting peer.  This makes it impossible to
>>>>>    detect the presence of non-supporting nodes between supporting nodes,
>>>>>    except by configuration.  The working group determined that such a
>>>>>    configuration requirement is acceptable.
>>>>>
>>>>>    This limits full compliance with certain requirements related to the
>>>>>    limitation of new configuration, deployment in environments with
>>>>>    mixed support, operating across non-supporting agents, and
>>>>>    authorization.
>>>>> [MCruz] I think this paragraph should state what are the limitations
>>>>> (generally, like you did for rest of them) Morever, since detailed descriptions will be deleted.
>>>>>
>>>> The limitations are discussed in the security consideration section. Basically if a node expects an agent to enforce any DOIC related policy (e.g. making sure DOIC avps do not leak to unauthorized nodes), it has to know that the agent itself supports DOIC. Right now it can only know that by having an administrator tell it that (violating the limitation on new configuration), by knowing that all agents in the network support DOIC (violating the mixed support and non-supporting agent requirements.)
>>>> [MCruz] Please, include text accordingly then. The text now "certain requirements related to" does not provide an information that anyone could trace easily.
>>> I was explicitly asked by other people (e.g. Lionel) to list the impacted requirements descriptively, rather than by reference, in this section. The "certain requirements related to" are described by the words immediately after that phrase. That is, the requirement to limit new configuration, the requirement to allow deployments with mixed support, and the requirements to authorize who can send and receive overload information.
>>>
>>>>>
>>>>>    REQ 6:  The solution designers SHOULD seek to minimize the amount of
>>>>>            new configuration required in order to work.  For example, it
>>>>>            is better to allow peers to advertise or negotiate support
>>>>>            for the solution, rather than to require that this knowledge
>>>>>            to be configured at each node.
>>>>>
>>>>>            *Partially Compliant*. Most DOIC parameters are advertised
>>>>>            using the DOIC capability announcement mechanism.  However,
>>>>>            there are some situations where configuration is required.
>>>>>            For example, a DOIC node detect the fact that a peer may not
>>>>>            support DOIC when nodes on the other side of the non-
>>>>>            supporting node do support DOIC without configuration.
>>>>>
>>>>> [MCruz] Could you clarify last example? “withoug configuration”? I do not understand what you meant.
>>>> Here's an example:
>>>>
>>>> C ------ A ------ S
>>>>
>>>> If both C and S support DOIC, there is no way for them to tell whether A supports DOIC. Consider two cases:
>>>>
>>>> 1) A supports DOIC. But since C already inserts OC-S-F in all requests, and S inserts it in all answers, A passes them through unchanged.
>>>> 2) A does not support DOIC, but passes through unknown AVPs. Since OC-S-F will be unknown to it, it passes it through unchanged.
>>>>
>>>>  From the perspective of C and S, the requests and answers look identical for both cases. Even if A actually changes the content of an OC-S-F avp, neither endpoint can tell if the resulting AVP came from A or the opposite endpoint.
>>>>
>>>> Personally, I think this is a showstopper. But the working group consensus did not agree.
>>>>
>>>> [MCruz] Several comments:
>>>> a) Then you consider this requirement as "partly compliant" since you consider configuration is required in a node to identify whether or not its adjacent peers support DOIC, right? If so, could you explain why a node needs to know whether or not the peer support DOIC, a part from what is included in the advertisement mechanism we defined?
>>> If you do not know that a peer supports DOIC, you cannot assume that it will enforce DOIC related policies (I believe that is sufficiently described in the security configurations.)
>>>
>>>> b) What do you think is a "show stopper"? The need for configuration?
>>> Explicitly, the need to configure whether you can trust a peer to enforce DOIC related polices. I believe this is an important security issue, and that being unable to determine it automatically is a real problem. Requiring this sort of configuration doesn't scale well, and has the potential of creating real management and operations problems. (Note the IETF area that DIME is in.)
>>>
>>> But, as I said, the working group seems to have chosen to move forward without an automatic way to do this. Perhaps it can be improved in a future extension.
>>>
>>>>
>>>>>    REQ 23: The solution MUST provide sufficient information to enable a
>>>>>            load-balancing node to divert messages that are rejected or
>>>>>            otherwise throttled by an overloaded upstream node to other
>>>>>            upstream nodes that are the most likely to have sufficient
>>>>>            capacity to process them.
>>>>>
>>>>>            *Not Compliant*. DOIC provides no built in mechanism to
>>>>>            determine the best place to divert messages that would
>>>>>            otherwise be throttled.  This can be accomplished with a
>>>>>            future "load" extension, or with proprietary load balancing
>>>>>            mechanisms.
>>>>>
>>>>> [MCruz] Partly Compliant. DOIC Overload information can be used already by proprietary load-balancing implementations.
>>>>>
>>>>> Load information will be a plus to this.
>>>>>
>>>> I disagree, or at least think that would be _very_ partial. You won't have any overload information unless the potential diversion targets are also overloaded.
>>>> [MCruz] In case servers in the pools are DOIC enabled the Overload information is provided by all of them, under overload occurrences, then this information is valid (maybe not sufficient in all cases, I agree, but valid in most of them) to divert.
>>>> In case we have mixed servers (DOIC-supporting and non-DOIC) we have some limitations as well.
>>> The purpose behind this requirement was to allow load balancing of requests that are diverted to (hopefully) non-overloaded servers, in a way that reduces the chance of causing those servers to also become overloaded. Those servers will not be providing OLRs.
>>>
>>> I still do not agree that the corner case of diverting request to _overloaded_ servers is big enough to consider this partially compliant.
>>>
>>>>>    REQ 30: The solution MUST NOT interfere with any Diameter-compliant
>>>>>            method that a node may use to protect itself from overload
>>>>>            from non-supporting nodes or from denial-of-service attacks.
>>>>>
>>>>>            *Compliant*. The specification recommends that any such
>>>>>            protection mechanism needed without DOIC should continue to
>>>>>            be employed with DOIC.
>>>>> [MCruz] Could you point our where in the draft it is described?
>>>> 9.3
>>>> [MCruz] I do not think 9.3 says what you mentioned here.
>>>> It says "In the absence of an overload control mechanism...". It is not said the DOIC shall not interfere with any other Diameter method for protection, we may need to add this information to the draft in fact.
>>>> A part from that, I think 9.3. should say "for non-DOIC supporting nodes/networks..." not just "in the absence of _an_ overload control mechanism"...
>>> The "absence of an OC strategy" part is there to provide the context that these protection mechanisms existed, or needed to exist, prior to the availability of DOIC. The section goes on to say that, even with DOIC, these protections are still needed to deal with non-compliant nodes.
>>>
>>> Are you arguing that we don't comply with Req 30? (Keeping in mind that this text is to be removed from the RFC.)
>>>
>>>>
>>>>
>>>>
>>>> /Ben.
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>