Re: [Dime] Proposed REQ 35 Text

[Ben Campbell <[e-mail]>]

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