Re: [Dime] Proposed REQ 35 Text

[Andrew Booth <[e-mail]>]

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.

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.

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.

More comments inline.

On Tue, Mar 26, 2013 at 4:30 PM, Ben Campbell <[e-mail]> wrote:
> Hi,
>
> We had a discussion about whether REQ 35 in the
> draft-ietf-dime-overload-reqs should stay a SHOULD or become a MUST.  We
> further discussed that any use of a MUST here would require some caveats
> about what sort of intermediaries could be traversed, and the potential
> security issues. The chairs directed us to take the discussion to the list
> due to time constraints. Here's my attempt to do so.
>
> For reference, here's the original text:
>
> 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.
>
>
> 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)?
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)?

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.
>
>
>
> Which general approach do people prefer? I kept the security aspects
> non-normative, since normative text already exists in 28,30, and 31.
>
> Thanks!
>
> Ben.
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>