Subject: [Dime] Proposed REQ 35 Text

From: Ben Campbell <[email-masked]>
Date: Tue, 26 Mar 2013 15:30:44 -0500

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

---

From: <[email-masked]>
Date: Wed, 27 Mar 2013 14:55:12 +0000

Hi,

Following the discussion in the meeting, here is my interpretation.
I said during the meeting that a new application will only be able to go through existing relay and redirect agent and not through "legacy" proxies i.e. proxies not supporting/advertising the new application.

So the question is simple: in the requirement elaboration phase, are we sure that any solution based on a new App-id will be rejected?

If not: the "SHOULD" is meaningful in REQ35.
If yes: this is a strong requirement and this must be stated somewhere in the draft.

Lionel

De : [email-masked] [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mardi 26 mars 2013 21:31
À : [email-masked]
Objet : [Dime] Proposed REQ 35 Text

Hi,

Thanks!

Ben.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Andrew Booth <[email-masked]>
Date: Wed, 27 Mar 2013 11:01:52 -0400

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 <[email-masked]> 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.
>
> 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.
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Mar 2013 10:28:11 -0500

Hi Lionel,

> If yes: this is a strong requirement and this must be stated somewhere in the draft.

For the record, the piggy-backed solution currently proposed also does not meet REQ35.

We don't necessarily try to prove feasibility in advance for all requirements. I'm not sure what the work group approach would be in handling a MUST level requirement that turns out to be infeasible. I suspect it would be to merely notate that we couldn't come up with a reasonable way to meet the requirement and move on. Making it a MUST means we need to try hard, though, and look for alternatives if none of our proposals meet it.

I'm also not convinced a MUST here automatically disallows an application-based approach. Other applications have to deal with relays that return just the relay app ID in the capabilities exchange. We also mentioned the possibility of a separate mechanism to handle the non-adjacent case.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 27 Mar 2013 16:06:09 +0000

Hi Lionel, Ben

I already  expressed my views for a MUST  on this REQ35 topic in previous mails.

As 3GPP will be a main user of the overlaod mechanism, and as 3GPP CT4 has a dedicated meeting on Diameter overlaod on April 9th 11th, where this toint will be discussed. I prefer to wait for the CT4 outputs before coming back to the DIME mail discussion.

Best regards

JJacques 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mercredi 27 mars 2013 16:28
À : [email-masked]
Cc : [email-masked]
Objet : Re: [Dime] Proposed REQ 35 Text

Hi Lionel,

---

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Mar 2013 13:13:32 -0500

Hi. Comments inline:

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

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

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

[...]

> limiting proxies that have not been upgraded to support the

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.

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

---

From: Glen Zorn <[email-masked]>
Date: Thu, 28 Mar 2013 10:09:15 +0700

On 03/27/2013 09:55 PM, [email-masked] wrote:
> I said during the meeting that a new application will only be able to 
> go through existing relay and redirect agent and not through "legacy" 
> proxies i.e. proxies not supporting/advertising the new application.
>

OK, but this is not different from any other new application, right?  
So, if the only route to a given destination realm is through a proxy, 
either the proxy must be updated to support the app or the application 
will fail.  That behavior seems fine to me: proxy application support 
(or non-support) is an administrative decision. If a transited realm 
doesn't want to carry the traffic generated by an application (perhaps, 
in this case, because the administrators are unconvinced that the 
solution to signaling overload is more signaling), I think that it is 
inappropriate to attempt to force it to do so.

> So the question is simple: in the requirement elaboration phase, are 
> we sure that any solution based on a new App-id will be rejected?
>

Do you mean rejected by the WG?

> *De :[email-masked] [mailto:[email-masked]] *De la part 
> de* Ben Campbell
> *Envoyé :* mardi 26 mars 2013 21:31
> *À :* [email-masked]
> *Objet :* [Dime] Proposed REQ 35 Text
>
> Hi,
>
> 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.
>
>     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.
>
>     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.
>
>         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.
>

---

From: <[email-masked]>
Date: Thu, 28 Mar 2013 09:28:39 +0000

Hi Glen,

Please see below.

Regards,

Lionel

-----Message d'origine-----
De : Glen Zorn [mailto:[email-masked]] 
Envoyé : jeudi 28 mars 2013 04:09
À : MORAND Lionel OLNC/OLN
Cc : Ben Campbell; [email-masked]; [email-masked]
Objet : Re: [Dime] Proposed REQ 35 Text

(or non-support) is an administrative decision. 

[LM] I'm fine with that also. And it means that a solution based on a new app-id would fail to meet the REQ35 containing a "MUST". And I'm not sure if it is really what we want at this stage.

If a transited realm 

[LM] Right!

[LM] Yes!

---

From: Andrew Booth <[email-masked]>
Date: Thu, 28 Mar 2013 15:18:54 -0400

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