Diameter Group Signaling
RFC 9390

[[ nits ]]

[ section 10 ]

* s/Session-group-Control-Vector/Session-Group-Control-Vector/

Sec 4.2.3 

"The server responds with a  service-specific auth response and includes one or multiple Session- Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and
   the Session-Group-Id AVP identifying the session group, to which the  identified session is to be assigned.  With the same response  message, the server may send one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP identifying the session groups from which the
   identified session is to be removed."

s/may/MAY, to match similar text in 4.2.2. Much as in that section, it is a little subtle that the state can be totally inferred by the first requirement, and the second MAY requirement is purely advisory.

I agree with Barry's editorial suggestions.

What does the "*)" in the table in Section 3.3 mean?

From Section 10:

   [...]  if the Diameter client or server is
   compromised, an attacker could launch DoS attacks by terminating a
   large number of sessions with a limited set of commands using the
   session group management concept.

Is it worth mentioning that an attacker could also mess with the set of sessions associated with a group, possibly causing disruptions other than bulk session terminations?

Thanks to Catherine Meadows for the SECDIR review.

** Section 3.3.  I had trouble reconciling the generic design principles espoused here with the more detailed specification of the protocol documented in Section 4.*.

The text here says:

This specification follows the most flexible model where both, a
   Diameter client and a Diameter server can create a new group and
   assign a new identifier to that session group.

And the table in this section says that the client could assign itself to a server owned session group.

Assign a Session to a non-owned Session Group   |    X   |    X   |

However, in Section 4.2.1

  If the Diameter server receives a command request from a Diameter
   client and the command includes at least one Session-Group-Info AVP
   having the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-
   Control-Vector AVP set, the server can accept or reject the request
   for group assignment.

It seems to me that this text in Section 4.2.1 is suggesting that the client could ask to be put into a group but the server has the ability reject it, which seems like an implicit permission model.

** Section 7.  In the table in this section the Session-Group-Id is of type OctetString, but in Section 7.3 it is UTF8String.

** Section 10.  Given the flexible permission model suggested in Section 3.3, is cautionary guidance needed to say that specific applications using this capability need to consider the decisions they make based on group membership?

Question: 
Are there any implementations of this? A section/appendix documenting the improvements would be nice if so (decrease in CPU / how quickly N sessions can be changed, etc.)


Comment: 
I also found some of this to be quite heavy reading, but I'm assuming that the readers are likely to be Diameter implementers who are already involved / willing to put in the work.


Nit:
"to the appended Group-Response-Action AVP ." -- extra space before period. Yes, 'tis a nit, but it would bug me if I didn't mention it...

Thank you for the work put into this document. Like Barry and other ADs, I found this document difficult to read: long and complex sentences do not help the reader (but I am not a native English speaker). Therefore, I trust the responsible AD for the correctness of all the details in the specification. E.g., FSM or time line diagrams would have been helpful.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==


== COMMENTS ==

Any reason why the authors affiliation is not shown ?

The shepherd write-up is dated back in 2018... Is it still applicable ?

-- Section 7.2 --
About the flag bits, I wonder why the values are not 0x01 and 0x02 rather than 0x01 and 0x10. Isn't this a waste of bits ? Should the IANA sub-registry for those flags be mentioned?

I have to say that I found this to be challenging to read: much of it is very dense, with paragraphs giving sometimes-subtly-different conditions, and I would be reading it thinking, “Does this paragraph apply to my situation?  I don’t think so, but what about the next one?  Wait, maybe it was the other one after all.”  I just have to assume that someon actually implementing Diameter would have an easier time following it.

I have some editorial comments that won’t help with that aspect, but that I hope will help with clarity in general:

— Section 3.1 —

   A session group, which has sessions assigned, can be deleted, e.g.,
   due to a change in multiple users' subscription profile so that the
   group's assigned sessions do not share certain characteristics

It appears that “has sessions assigned” is restrictive (it’s a required description, not just extra information).  If so, it should say, “A session group that has sessions assigned can be deleted, e.g., due to...” without the internal commas.

Another way to put it might be, “A session group can be deleted even if it has sessions assigned, e.g., due to...”

— Section 3.3 —

   This specification follows the most flexible model where both, a
   Diameter client and a Diameter server can create a new group and

Nit: no comma here

   Either the client and the server
   can assign a session to a group.

Nit: “Either the client or the server can”, or “Both the client and the server can”.

   Details about
   enforcing a more constraint permission model

I think the word you want is “constrained”.

— Section 4.2 —

   Diameter AAA
   applications typically assign client and server roles to the Diameter
   nodes, which are referred to as relevant Diameter nodes to utilize
   session grouping and issue group commands.

I’m having trouble parsing this sentence and determining what you’re trying to tell me.  Can you please rephrase or repunctuate it to make it clearer?  What are referred to as “relevant Diameter nodes”?  What goes with “to utilize session grouping”?

   Diameter nodes, which are group-aware, MUST store and maintain an
   entry about the group assignment together with a session's state.

Similar to earlier: is “are group aware” meant to be restrictive (there are Diameter nodes that are group aware and those that are not, and you’re talking about the former), or non-restrictive (all Diameter nodes are group aware, and you’re just pointing that fact out).  It is currently written as non-restrictive, but I think you mean it to be restrictive.  If that is correct, remove both commas and change “which” to “that”.

   A Diameter node MUST also keep a record about sessions, which
   have been assigned to a session group by itself.

The comma shouldn’t be there, and “which” should be “that”.  But it’s a bit awkward anyway: may I suggest rephrasing in active voice as, “Each Diameter node MUST also keep a record about sessions that it has assigned to a session group.”

— Section 4.2.1 —

   If the
   response from the server indicates success in the result code but
   solely the assignment of the session to a session group has been
   rejected by the server, the client treats the session as single
   session without group assignment.

What does “solely” mean in this sentence?

   A Diameter client, which sent a request for session initiation

Please remove the comma (and change “which” to “that”).

— Section 4.2.2 —

   The session, which is to be removed from a group, is

Make it, “The session that is to be removed from the group is”

   When a Diameter client decides to remove a session from all session
   groups, to which the session has been previously assigned,

Remove the comma after “groups”.

   The session, which is to be removed from all groups, to
   which the session has been previously assigned, is identified in the
   Session-Id AVP of the command request.

Make it, “The session that is to be removed from all groups to which it had been previously assigned is identified in the Session-Id AVP of the command request.”

— Section 7.3 —

   The
   <DiameterIdentity> portion of the Session-Group-Id MUST identify the
   Diameter node, which owns the session group.

Please remove the comma and change “which” to “that”.

I agree with the other commenters that an editorial pass over the
document before it is sent to the RFC Editor is probably in order; I
only noted the more eggregious nits that have obvious fixes but skipped
the ones where I did not have a resolution ready at hand to suggest.
Barry's remarks about restrictive vs non-restrictive clauses are
particularly important.

I also have several high-level issues that don't quite rise to
discuss-level but seem worth getting resolution on; they mostly involve
edge cases where the current text either leaves me unclear on what is
supposed to happen or seems to present conflicting guidance:

- what's the error handling in cases of partial success?
  * For operations adding/removing sessions to/from groups, it seems that
    the general principle is that the new changes introduced with any
    group-relevant CCF exchange are to be treated atomically: either all
    group additions/removals succeed or all fail (and when it fails the
    session is forced into a single-session fallback mode).  But for
    server-initiated modifications this is enforced by "if the client
    can't do it, the client MUST tear down the affected session(s)", and
    I'm not sure if there's a case where the client can send a new
    request that includes some modifications and the server also tries
    to make some modifications in its response; such a scenario might in
    effect allow partial success and might also be hard to correctly
    interpret.
  * For operations acting on groups, we do allow partial success
    (DIAMETER_LIMITED_SUCCESS) and attempt to mandate fallback to
    single-session operation for affected sessions, but the specifics of
    how the Failed-AVP effectuates this are not clear to me (see my
    comment on Section 4.4.3).

- we require that group identifiers are globally unique, which can be
  done with the diameter-node namespace prefix.  But for the portion
  after that prefix, we seem to suggest reusing the construction from
  Section 8.8 of RFC 6733, which is just (in essence) a 64-bit global
  counter.  In the vein of draft-gont-numeric-ids-sec-considerations,
  that seems overly constrained, in that it reveals sequencing across
  group creation and rate of per-node group creation to the remote peer.
  It seems that a construction akin to a keyed hash of a counter would
  preserve the guaranteed uniqueness property but avoid leaking such
  information to the network.

- the permissions model is a bit unorthodox, with groups "owned" by
  their creator but the binding of a session to a group "owned" by the
  node that performed the binding.  It seems like there is some risk of
  deadlock situations or conflict, e.g., where a client has added a
  session to a group G but the server wants to remove the session from
  G, or where a session is part of a group but the owner of the group
  wants to delete the group.  For the latter case, my understanding is
  that group deletion "trumps" ownership of the session/group binding,
  such that deletion can proceed even while sessions are in the group,
  but I'm less sure what should happen in the former case (or others).

- Is it possible to have a group with no member sessions?  Section 3.3
  suggests that if the last session is removed the group should be
  deleted, but AFAICT this would still require the node performing the
  removal to unset SESSION_GROUP_STATUS_IND, and I didn't see a
  requirement to do that spelled out.  I do see how it is impossible to
  create a group directly in a state with no member sessions.

- Is there a requirement to always send the current state of group
  membership when acting on a session?  I could (perhaps naively)
  imagine a case where due to previous interactions a session belongs to
  groups G1, G2, and G3, but in some subsequent request the client only
  mentions G1.  Does the membership in G2 and G3 get implicitly retained
  in the absence of an explicit unset SESSION_GROUP_ALLOCATION_ACTION or
  are there some other constraints that make such a scenario impossible?

- Is there supposed to be a strong distinction between "including" an
  AVP and "appending" one?  I see that 6733 does make some fairly clear
  distinction between the terms, but it seems that (e.g.) in Section
  4.2.1 we use both phrasings to discuss Session-Group-Info.

Now for some section-by-section (mostly editorial or nit-level) notes.

Abstract, Introduction

   a million concurrent Diameter sessions.  Recent use cases have
   revealed the need for Diameter nodes to apply the same operation to a
   large group of Diameter sessions concurrently.  The Diameter base

I note that the -00 is from 2012; are these use cases still "recent"?

Section 3

As an editorial note, the way the current text jumps in to say that
sessions can be assigned to groups leaves the reader uncertain whether
this is describing preexisting functionality or the new mechanisms added
by this document.  A top-level intro paragraph for Section 3 that says
roughly "to accomodate bulk operations on Diameter sessions, the concept
of session groups is introduced; once sessions are added to a group, a
command acting on the group will affect all the member sessions" might
help.

Section 3.3

If I understand correctly, the lines in the table for "remove a session
from an owned Session Group"/"remove a session from a non-owned Session
Group" mean only that this operation can be done sometimes, not that it
can always be done (per the lines about "created the assignment".  Would
it be helpful to indicate this, perhaps by using a different symbol for
those lines and adding a footnote?

Section 4

While I understand the desire to keep the document structure as it is,
with the actual AVPs specified in Section 7, it would have been very
helpful to have a toplevel introductory paragraph here that mentions or
references that there is a containing Session-Group-Info grouped AVP
that contains the Session-Group-Control-Vector with information about
the action and group, and zero or one(?) Session-Group-Id AVP to
identify the group when a specific group is being identified.  This
would also allow clarifying whether the Session-Group-Id AVP is
currently only defined to appear within the Session-Group-Info.

Section 4.1.1

                                           Such applications provide
   intrinsic discovery for the support of session grouping capability
   using the assigned Application Id advertised during the capability
   exchange phase two Diameter peers establish a transport connection
   (see Section 5.3 of [RFC6733]).

nit: I think there's a missing word here, perhaps "where" after "phase"?

Section 4.2.1

   The client may also indicate in the request that the server is
   responsible for the assignment of the session in one or multiple
   sessions owned by the server.  [...]

nit(?): is this supposed to be "assignment of the session into one or
multiple session *groups* owned by the server"?  I'm having a hard time
understanding it as written.

   If the assignment of the session to one or some of the multiple
   identified session groups fails, the session group assignment is
   treated as failure.  In such case the session is treated as single
   session without assignment to any session group by the Diameter
   nodes.  The server sends the response to the client and MAY include
   those Session-Group-Info AVPs for which the group assignment failed.
   The SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group-
   Info AVPs MUST be cleared.

I guess I understand the part where the entire set of group-assignment
operations has to succeed or fail as an atomic unit, but this text
perhaps implies some semantics that the server is supposed to only
explicitly include in the response the subset of group assignments that
were unable to be processed, omitting the ones that could have been
processed (but were not processed since a failure on one means that none
of the operations get applied).  If that's the intent, I'd suggest being
a bit more explicit about what is and isn't sent.

   A Diameter client, which sent a request for session initiation to a
   Diameter server and appended a single or multiple Session-Group-Id
   AVPs but cannot find any Session-Group-Info AVP in the associated

(editorial) the phrase "cannot find" makes me wonder how hard it's
expected to be looking; more definitive statements about "not present"
seem more typical for RFC style.

Section 4.2.3

   When a Diameter server enforces an update to the assigned groups mid-

nit: this seems to be the only time we use the word "enforce" in this
sense in the document; previous discussion seems to just use "decides to
make an update" or similar.

   answer.  The client subsequently sends a service-specific re-
   authorization request containing one or multiple Session-Group-Info
   AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the
   Session-Group-Id AVP identifying the session group to which the
   session had been previously assigned.  [...]

nit: I think this has to be "group or groups" to be consistent with the
rest of the doc.

Section 4.4.1

   Either Diameter node (client or server) can request the recipient of
   a request to process an associated command for all sessions assigned
   to one or multiple groups by identifying these groups in the request.
   The sender of the request appends for each group, to which the
   command applies, a Session-Group-Info AVP including the Session-
   Group-Id AVP to identify the associated session group.  Both, the
   SESSION_GROUP_ALLOCATION_ACTION flag as well as the
   SESSION_GROUP_STATUS_IND flag MUST be set.

What's the error handling if one or both listed flags are not set --
just ignore the request?

   Action AVP to ALL_GROUPS (1) or PER_GROUP (2).  If the answer can be
   sent before the complete process of the request for all the sessions
   or if the request timeout timer is high enough, the sender MAY set
   the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2).

(side note) just the phrase "high enough" doesn't give much of an
indication of what the criteria are and what numerical values might be
appropriate.  That said, it's not entirely clear how much guidance we
can really give in this situation.

Section 4.4.2

   If the received request identifies multiple groups in multiple
   appended Session-Group-Id AVPs, the receiver SHOULD process the
   associated command for each of these groups.  If a session has been
   assigned to more than one of the identified groups, the receiver MUST
   process the associated command only once per session.

Why is this only a SHOULD for each group -- what other behaviors could
the receiver do?

Section 4.4.3

   In the case of limited success, the sessions, for which the
   processing of the group command failed, MUST be identified using a
   Failed-AVP AVP as per Section 7.5 of [RFC6733].  [...]

My reading of the referenced part of RFC 6733 is that there is a single
Failed-AVP pointing to a single AVP that could not be processed
properly.  Is there such a single failed AVP in the case where
processing failed for multiple sessions in the group(s)?  It seems that
the "largest containing AVP" that includes all failed groups might be so
large so as to not be useful in indicating the problem.

Section 7.2

   SESSION_GROUP_STATUS_IND (0x00000010)

If there's a mnemonic for the "IND" part of "SESSION_GROUP_STATUS_IND",
that would be helpful to expand.

Section 9.2

The Specification Required policy includes review by Designated Experts;
is there any guidance we should provide to the DEs?

Appendix A.1

      Discon    GASA received                  Cleanup      Idle

Spot-checking against RFC 6733's state machine, the non-group ASA
received case only makes this transition when there was a previous ASR
that was successfully sent.  Is that am important distinction?  (Also,
as an editorial nit, RFC 6733 spells "Clean up" as two words.)