Re: [Dime] Proposed REQ 35 Text

[Andrew Booth <[e-mail]>]

Hi Ben,

Thanks for the comments and clarifications.

I'm still a little uncomfortable with the idea that a MUST is just a
strong SHOULD, but I'll extrapolate from your comments: no matter
whether we put SHOULD or MUST, the working group can override it
anyway, so maybe it doesn't make much difference as long as the intent
is clear.

So the remaining comment is one more try at improved clarity.

I'm not sure that a MUST with an open ended limitation (without any
guidance on why that limitation is there) is any clearer than an
unqualified SHOULD.
So, if the idea is that the working groups work isn't done until REQ
35 is solved, but that some parts of the solution might require extra
work (e2e or some other idea), or could maybe even be deferred,
perhaps it is clearer to simply make that objective explicit?

For your consideration:

   ALT REQ 35:  The mechanism SHOULD provide a method for exchanging
            overload and load information between elements that are
            connected by intermediaries that do not support the
            mechanism.
            If a mechanism cannot immediately meet this requirement for
            technical reasons, or because the full solution depends on an
            unfinished prerequisite work, then the mechanism MUST
            describe its limitations related to this requirement and
the technical
            reasons why it was unable to meet this requirement fully.
            If the mechanism has substantial limitations with respect
to this requirement,
            it should convincingly describes why it should be possible
for the mechanism
            to operate in parallel with some future mechanism that completely
            meets this requirement, and the remaining work SHOULD be scheduled.

Thoughts?
Andrew


On Wed, Mar 27, 2013 at 2:13 PM, Ben Campbell <[e-mail]> wrote:
> Hi. Comments inline:
>
> On Mar 27, 2013, at 10:01 AM, Andrew Booth <[e-mail]> wrote:
>
>> Hi Ben,
>>
>> If we don't find a solution that supports REQ 35, I would prefer to
>> have a 95% solution now than scrap such a solution because it fails
>> the MUST of REQ 35.  Hence, I prefer that REQ 35 be a SHOULD.
>>
>
> I don't think that means we have to scrap a 95% solution. (Unless we have an alternate 100% solution, in which case a SHOULD and MUST would would have the same effect.)
>
> My personal opinion would be that a MUST means the working group's job isn't done until it either meets the requirement, or determines that the requirement was not reasonably feasible. The former could be accomplished with a 100% solution, or a 95% solution with an additional mechanism designed to solve just this requirement. In the same circumstances, a SHOULD would make it easier to just take the 95% solution and stop.
>
>> There is nothing to prevent multiple different implementations from
>> being standardized (well, other than the difficulty getting WG
>> cycles).  I don't see that all of them need to have full support for
>> REQ 35.  That opens the door for other approaches to be proposed once
>> end-to-end security in Diameter is standardized.
>
> Agreed. The "not reasonably feasible" bit in my previous comment could also mean "not reasonably feasible _now_". As a purely hypothetical example, if the security issues turn out to be the main thing to block Req 34, iIt might make sense to make sure the chosen solution doesn't prevent Req 35 from being solved in some future update once the e2e security work is complete, or at least stabile.
>
>>
>> There is also nothing that prevents interested parties that want
>> support for REQ 35 to propose a solution that supports it, and to
>> defend that solution compared to others.
>>
>> If I recall correctly, the desire to make this a MUST came from an
>> implementer that wanted to be able to signal handsets about the
>> congestion.  Is that the motivating statement?  If so, is it worth
>> taking a closer look at the motivating case to see what information
>> they really require (is it full information? or will partial
>> information do?), and whether it should have this much impact on the
>> potential solutions?
>> At first glance, signaling handsets about congestion sounds like a
>> (potentially useful) optimization, but does not sound to me as
>> important as protecting core network resources (by having some working
>> implementation of overload control).  Maybe I'm misunderstanding the
>> motivating case or it's importance, I'm willing to be convinced.
>
> I don't think that's the main case. The use case I think the most people care about is the situation where you have a non-supporting agent between islands of overload-control. For example, an IPX provider sitting between operators doesn't support overload control, but the operators still need to share overload information.
>
> There are certainly people that care about the use case you describe--but I think any solution to that use case would also solve the one you mention. It's the special case where _none_ of the agents support overload control.
>
>
> [...]
>
>>>
>>>
>>> Here's a proposed alternative for changing it to a MUST:
>>>
>>> The mechanism MUST provide a method for exchanging overload and load
>>> information between elements that are connected by intermediaries that do
>>> not support the mechanism. The mechanism MAY place limitations on the nature
>>> of the non-supporting intermediaries that may be traversed.
>>
>> Is there any limit to the limitations?  Currently loophole: a
>> mechanism can limit the non-supporting intermediaries to the empty
>> set, and we're back to REQ 35 being a SHOULD.
>> Is this extra text intended to allow for a new application id (hence
>> limiting proxies that have not been upgraded to support the
>> mechanism)?
>
> I think the "limitation" is an assumption of reasonable behavior on the part of the working group :-) This isn't a contract; it's a general agreement as to what we are working on.  Creating limitations rule out all possible intermediaries would not fit my idea of a reasonable interpretation. In general, making "letter of the rule" interpretations that don't fit the clear "spirit of the rule" doesn't seem like reasonable working group behavior.
>
> The sort of limitations we are likely to run up against are things like " can't cross a agent that does topology hiding". The reason we don't enumerate the limitations now is because we won't know what they are until we do the actual mechanism engineering. I could _hypothetically_ imagine things like "can't cross an agent that uses dynamic peer discovery" might pop up.
>
>> Is this extra text intended to allow for REQ 35 through "trusted"
>> intermediaries, hence working around the end-to-end security
>> requirement (this sounds dodgy to me)?
>
> I assume you are talking about the "nothing in this requirement..." paragraph. That's indented to show that it is intended as explanatory text, not normative text. The idea is not to allow or prohibit any particular security approach in advance, and to point out that accepting unauthenticated/unauthorized congestion information would violate the existing requirements about not adding new vulnerabilities.
>
> It's up to the working group to decide what security approach is "good enough". I personally have my doubts that simply assuming intermediaries are "trusted" is an adequate approach--but I'm happy to defer that argument for now. (I know there are strong opinions on both sides) We might end up requiring the e2e security work. We might end up with some other special-purpose authz/n solution no one has thought of yet.
>
>>
>> Thanks,
>> Andrew
>>
>>>
>>> Nothing in this requirement should be construed to relax the
>>> security-related requirements elsewhere in this document, in particular REQs
>>> 28, 30, and 31. Maliciously constructed overload information can potentially
>>> shut down a Diameter network; it's critical that a node be able to confirm
>>> that received information came unaltered from an authorized source, whether
>>> the information comes from an immediate peer or crosses an intermediary.
>>>
>