Re: [Dime] Proposed REQ 35 Text

[<[e-mail]>]

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

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.

_________________________________________________________________________________________________________________________

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.