Re: [Dime] Updated DOIC Requirements Analysis

[Ben Campbell <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I may recall incorrectly, but I thought we decided the discussion on the mailing list was sufficient record. Does anyone remember something different?

Moving them to an informational draft only helps if we take that to RFC, since drafts expire over time.

On Jan 22, 2015, at 11:24 AM, Maria Cruz Bartolome <[e-mail]> wrote:

Dear all,

Yes, we agreed to remove detail statement of compliance from the main draft, but we agreed as well that it was worthy to keep this analysis for further references, even if it was only an informational draft.
What is now the intention?

Thanks
/MCruz

- -----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
Sent: martes, 20 de enero de 2015 21:56
To: Ben Campbell
Cc: [e-mail]
Subject: Re: [Dime] Updated DOIC Requirements Analysis


On 1/20/15 2:30 PM, Ben Campbell wrote:
On Jan 20, 2015, at 12:49 PM, Steve Donovan <[e-mail]> wrote:

I'm not currently planning to make any updates to the requirements analysis section as I haven't seen consensus on the need to change anything in the portion that will remain in the document.

If we want to continue to debate the sections that are slated to be removed then I suggest we do that in a separate email thread that is not tied to moving the document out of WGLC.
Isn't this that separate thread?
SRD> Yes, I was thinking in terms of the set of items that needed 
addressing for WGLC.

But in any case, I do not think we need changes to the reqs analysis sections, especially the detail section that we have been directed to remove.
SRD> Cool

Regards,

Steve
On 1/7/15 2:54 PM, Ben Campbell wrote:
(Catching up on older stuff)

Comments inline. But keep in mind that the detailed requirements are to be removed from the RFC, so I'm not sure we need to spend too much time on them. (Only the first discussion point addresses text that is to remain in the RFC.)

Thanks!

Ben.

On Dec 12, 2014, at 2:24 AM, Maria Cruz Bartolome <[e-mail]> wrote:

Hello Ben,

See comments below
Thanks
/MCruz

C.2.  Detection of non-supporting Intermediaries

  The DOIC mechanism as currently defined does not allow supporting
  nodes to automatically determine whether OC-Supported-Features or OC-
  OLR AVPs are originated by a peer node, or by a non-peer node and
  sent across a non-supporting peer.  This makes it impossible to
  detect the presence of non-supporting nodes between supporting nodes,
  except by configuration.  The working group determined that such a
  configuration requirement is acceptable.

  This limits full compliance with certain requirements related to the
  limitation of new configuration, deployment in environments with
  mixed support, operating across non-supporting agents, and
  authorization.
[MCruz] I think this paragraph should state what are the limitations
(generally, like you did for rest of them) Morever, since detailed descriptions will be deleted.

The limitations are discussed in the security consideration section. Basically if a node expects an agent to enforce any DOIC related policy (e.g. making sure DOIC avps do not leak to unauthorized nodes), it has to know that the agent itself supports DOIC. Right now it can only know that by having an administrator tell it that (violating the limitation on new configuration), by knowing that all agents in the network support DOIC (violating the mixed support and non-supporting agent requirements.)
[MCruz] Please, include text accordingly then. The text now "certain requirements related to" does not provide an information that anyone could trace easily.
I was explicitly asked by other people (e.g. Lionel) to list the impacted requirements descriptively, rather than by reference, in this section. The "certain requirements related to" are described by the words immediately after that phrase. That is, the requirement to limit new configuration, the requirement to allow deployments with mixed support, and the requirements to authorize who can send and receive overload information.


  REQ 6:  The solution designers SHOULD seek to minimize the amount of
          new configuration required in order to work.  For example, it
          is better to allow peers to advertise or negotiate support
          for the solution, rather than to require that this knowledge
          to be configured at each node.

          *Partially Compliant*. Most DOIC parameters are advertised
          using the DOIC capability announcement mechanism.  However,
          there are some situations where configuration is required.
          For example, a DOIC node detect the fact that a peer may not
          support DOIC when nodes on the other side of the non-
          supporting node do support DOIC without configuration.

[MCruz] Could you clarify last example? “withoug configuration”? I do not understand what you meant.
Here's an example:

C ------ A ------ S

If both C and S support DOIC, there is no way for them to tell whether A supports DOIC. Consider two cases:

1) A supports DOIC. But since C already inserts OC-S-F in all requests, and S inserts it in all answers, A passes them through unchanged.
2) A does not support DOIC, but passes through unknown AVPs. Since OC-S-F will be unknown to it, it passes it through unchanged.

- From the perspective of C and S, the requests and answers look identical for both cases. Even if A actually changes the content of an OC-S-F avp, neither endpoint can tell if the resulting AVP came from A or the opposite endpoint.

Personally, I think this is a showstopper. But the working group consensus did not agree.

[MCruz] Several comments:
a) Then you consider this requirement as "partly compliant" since you consider configuration is required in a node to identify whether or not its adjacent peers support DOIC, right? If so, could you explain why a node needs to know whether or not the peer support DOIC, a part from what is included in the advertisement mechanism we defined?
If you do not know that a peer supports DOIC, you cannot assume that it will enforce DOIC related policies (I believe that is sufficiently described in the security configurations.)

b) What do you think is a "show stopper"? The need for configuration?
Explicitly, the need to configure whether you can trust a peer to enforce DOIC related polices. I believe this is an important security issue, and that being unable to determine it automatically is a real problem. Requiring this sort of configuration doesn't scale well, and has the potential of creating real management and operations problems. (Note the IETF area that DIME is in.)

But, as I said, the working group seems to have chosen to move forward without an automatic way to do this. Perhaps it can be improved in a future extension.


  REQ 23: The solution MUST provide sufficient information to enable a
          load-balancing node to divert messages that are rejected or
          otherwise throttled by an overloaded upstream node to other
          upstream nodes that are the most likely to have sufficient
          capacity to process them.

          *Not Compliant*. DOIC provides no built in mechanism to
          determine the best place to divert messages that would
          otherwise be throttled.  This can be accomplished with a
          future "load" extension, or with proprietary load balancing
          mechanisms.

[MCruz] Partly Compliant. DOIC Overload information can be used already by proprietary load-balancing implementations.

Load information will be a plus to this.

I disagree, or at least think that would be _very_ partial. You won't have any overload information unless the potential diversion targets are also overloaded.
[MCruz] In case servers in the pools are DOIC enabled the Overload information is provided by all of them, under overload occurrences, then this information is valid (maybe not sufficient in all cases, I agree, but valid in most of them) to divert.
In case we have mixed servers (DOIC-supporting and non-DOIC) we have some limitations as well.
The purpose behind this requirement was to allow load balancing of requests that are diverted to (hopefully) non-overloaded servers, in a way that reduces the chance of causing those servers to also become overloaded. Those servers will not be providing OLRs.

I still do not agree that the corner case of diverting request to _overloaded_ servers is big enough to consider this partially compliant.

  REQ 30: The solution MUST NOT interfere with any Diameter-compliant
          method that a node may use to protect itself from overload
          from non-supporting nodes or from denial-of-service attacks.

          *Compliant*. The specification recommends that any such
          protection mechanism needed without DOIC should continue to
          be employed with DOIC.
[MCruz] Could you point our where in the draft it is described?
9.3
[MCruz] I do not think 9.3 says what you mentioned here.
It says "In the absence of an overload control mechanism...". It is not said the DOIC shall not interfere with any other Diameter method for protection, we may need to add this information to the draft in fact.
A part from that, I think 9.3. should say "for non-DOIC supporting nodes/networks..." not just "in the absence of _an_ overload control mechanism"...
The "absence of an OC strategy" part is there to provide the context that these protection mechanisms existed, or needed to exist, prior to the availability of DOIC. The section goes on to say that, even with DOIC, these protections are still needed to deal with non-compliant nodes.

Are you arguing that we don't comply with Req 30? (Keeping in mind that this text is to be removed from the RFC.)




/Ben.

_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime


_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUwUMHAAoJEIBWSmyV89QNMFUQAMBEVBKVTalNOB5IP6SI8QIt
PmhP9nY+VneOMCt9l+c0dWt4U1MTeZI1jDErhoOBeN469K7AC5Lfx56WhfX4jRXX
7rU0qKfX5FGknzSA5ZkFsh9EuNgmopBOSi+vBzI8tf8tZTnPU4HHj0Q+1TuzgK6O
i+9XeJDQUU2GpdiK/jMuWrm4WemTHKhoLJC4AiNDQp9l9a4VWRwlnRmUuc+8Z19F
QmXouFronRjG64zl0Uw+QnAfDexNitb3u/p22tXP5n8Io+iwnhAMJJb1vur34wuz
3qb0CovN+7yPyXTx7lueH9V1PYKjJoqpycnuwwDomOGvE0YHHId8V5zaat6PpAuo
SgIqexxvbQ66/bCXzF7B2OhYeHswpHLpWGfwlmWBV20hTHh1BwAqwDt/Gk1hmopi
6nx+WYWfKTDo81E+U5QeSKnb131eF1Qw/z86A39/QutH75m3QqcjhqoCGcDr3xkG
EupKESMbKTP9D/DiK25suJSk6D6sPNuU2BouQaweCa50WbfsfwCKtivPdgtHWUda
LWY2BgDZiSzXRyJlyISbcnghZQM9IOvYsxa67Wu5LCwuT/e+zTC0n8xxeCSUH7A4
k1RO8OT+mPtGyqIVmDrdnYXOCdAojaUqNYjNajZRC+r6nIJo37rJHP5TuRT9P7eH
Qb6R/uR2gtqArBuTZ8C7
=CJGq
-----END PGP SIGNATURE-----