Proposal for Jam Session Management

[gene96817]

Over the past months, I have read ideas and requirements for private jam sessions, educational/school use, and why public servers are being abandoned for private servers. I believe this document proposing Jam Session Management can help these use cases.

I hope this document will attract more use cases for consideration. I would like to take the challenge to model all these use cases into a single session management database.

The document is a rough first draft. For simplicity, I have glossed over some lesser features needed for a real implementation. Let's see if this deserves more work to polish.

https://docs.google.com/document/d/1Dy9XfdmhWRYGhyoB5xOUGWwRFINaSAvaIs2bOJ4Arq4/edit?usp=sharing

[hoffie]

Thanks for working on this and writing it down!

Some first questions (maybe with potential to clarify the document):

Add a new (optional) connection request carrying username, session name, session ticket, Jamulus server

• What is a session name (for example) and why is it needed?
• What is a session ticket and why is it neded?
• I wonder if those additional fields could either be kept to a bare minimum or if they could be decided upon by the Jam Session Manager (e.g. Client connects to Server, Server asks Jam Session Manager if this is ok, Jam Session Manager might reply "cannot decide yet, need a username and a secret for that", Jamulus server asks the client for such fields, client displays a form to the user to input that, sends back a new connection request to the Jamulus server with these fields, Jamulus server asks the Jam Session Manager again (now with all the fields), Jam Session Manager can now decide if the client should be accepted or rejected). As the length of this item shows, this quickly gets complicated.
• Why would the Jamulus server address have to be part of the protocol between client and server? The client already knows where it is connecting to. The server should already know its identity as well. Or are you thinking about some virtual hosting instead of a pure IP address?
• If we authorize based on usernames, should client names also be fixed to say what the Jam Session Manager authorized? (i.e. disabling user name changes)

C. Session admission control logic.
This module receives a connection request from the Jamulus client and looks up defined sessions to determine if a user is a participant.

Do you suggest that the Jamulus client would talk to a new "module" (i.e. independent server component)?

Some generic things to consider:

• The current protocol is based on UDP. Session handling is implicit. If the server receives audio, there is a session, if it does not, there isn't. There is no explicit connection handshake (although there are handshakes for various features and exchange of profile fields). In other words, any change we do here may make reconnects harder. I'm not saying this is a blocker and I'd not know how to avoid that, but it should be evaluated.
• The current protocol is unencrypted. It should be an explicit decision if we would accept transferring secrets such as passwords anyway (not sure of "session ticket" from your proposal is something like a secret?), if we should have a challenge-response scheme to avoid cleartext/replay attacks or if this should wait until (and if) we have TCP and could think about encrypting the whole protocol channel.
• As far as I understand, you are proposing more than access control, but session handling in addition. What would happen if a Jam Session Manager authorized a client at 17:00 and it stays connected, although at 18:00 another session starts and the client would not have been authorized? Would this require some mechanism to remove users? Access control has come up a lot so I think this is something we should solve somehow. Session management sounds rather niche, so my hope is to be able to couple this with access control in a way which avoids having session management logic within Jamulus client or server.

In summary, at first glance I like the idea of making very minimal changes to Jamulus client and server to enable such things and create some kind of interfaces to another, Jamulus-external component for that. I like the general integration part of A & B, I'm unsure of C & D & E (not sure if you are suggesting that this should be part of Jamulus server or client; I think it should not) and personally I would not be a fan of RADIUS at all. But as far as I understand your proposal, this would be totally independent of the Jamulus client/server changes, so anyone could implement the Jam Session Manager to their liking.

[gene96817]

In the interest of faster discussion, I provide a detailed reply to @hoffie here. We can update the original document later.

What is a session name (for example) and why is it needed?

A server, Studio1, could have several sessions scheduled. E.g. 1000 hrs - quartet-A practice, 1400 hrs. - chorus-Y practice, 1500 hrs - chorus Z practice. So musician-F could request admission for Studio1, chorus-Y session. You could say that this is over-specified but it prevents confusion later. Consider a school with Studio1, Studio2, ... Studio-N with a student in chorus-Y requesting connection to Studio2 when it should be Studio1 or if a student shows up early. In any case, it is easy to be unambiguous about who (musician), what (which event), when, and where.

What is a session ticket and why is it needed?

It could be a password or an event code or a (unique) ticket. It's all a password to me, but sometimes it makes sense to have a shared passcode (or an event code, similar to a Zoom meeting code) or a unique one-time password (call it an event ticket).

I wonder if those additional fields could either be kept to a bare minimum or if they could be decided upon by the Jam Session Manager

As the length of this item shows, this quickly gets complicated.

Yes. Depending on the use case, some parameters can be . I know some people don't like to have as a valid parameter. Complicated? Let's collect use cases and map them into the database. I am used to this exercise (especially with RADIUS) since it is about service provisioning. This potential complexity is why we don't want to build our own solution.

The server should already know its identity as well. Or are you thinking about some virtual hosting instead of a pure IP address?

Two reasons. The server address helps prevent ambiguity. And yes, this scheme can handle virtual hosting or virtual servers. The distinction between physical IP address and virtual servers is trivial to the database. We should anticipate handling any kind of server (or rehearsal /jamming space).

If we authorize based on usernames, should client names also be fixed to say what the Jam Session Manager authorized? (i.e. disabling user name changes)

I am open to discussion. My preference is we don't disable user name change. Therefore for the school rehearsal, the user could be John H. Then for the coffee shop jam session, that same user could be Cool Sax Man. If the session organizer is happy, we are happy. Note that the user name is might not be enough to enter a session. There could be a session ticket required.

Do you suggest that the Jamulus client would talk to a new "module" (i.e. independent server component)?

Yes and no. The client would talk to the server with some new protocol elements and the server would relay the new message to the independent component. There are open-source PAM and FreeRADIUS components that could minimize the amount of code that needs to be written.

The current protocol is based on UDP.

Let's discuss. My expectation is we keep the original code for backward compatibility and there is a new client protocol for users wanting/needing to connect to a session that has session management controls. The new protocol is UDP-based.

The current protocol is unencrypted. It should be an explicit decision if we would accept transferring secrets such as passwords anyway .....

We should use an EAP method (extensible authentication protocol) to protect the handling of secrets (aka passwords, tickets). These became well-known and common through the use of "enterprise-level authentication" with Wi-Fi. I can help with the selection of the specific method. Theoretically, EAP-TLS is the best choice, but there are lots of other methods that are also secure. Most of the EAP variations were created by vendor-driven politics.

What would happen if a Jam Session Manager authorized a client at 17:00 and it stays connected, although at 18:00 another session starts and the client would not have been authorized? Would this require some mechanism to remove users?

I glossed over this. It deserves some discussion among the developers. I think we want to have a concept of a session "hard" close and a "soft" close. The easy case is to make every session have a hard close. When the meter is up, everyone gets disconnected. I think this is unfriendly for musicians. A soft-close would let a session continue on or wind-down until the next session shows up (maybe the next day). To me this doesn't have to be difficult but I am not the coder.

Access control has come up a lot so I think this is something we should solve somehow. Session management sounds rather a niche, so my hope is to be able to couple this with access control in a way that avoids having session management logic within Jamulus client or server.

Yes, access control has come up a lot. However, many people have a very limited understanding of access control. For many, access control is a binary function, a user is allowed or disallowed. A full understanding of access control is about managing a service or provisioning and delivering a service. For Jamulus, it is about managing jam sessions. This could mean managing a server (as a 365/24/7 service) or it could be fine-grained where many sessions are delivered by a server. Managing service delivery is not a niche topic, for Jamulus it is a core topic. (Managing services for a subscriber is how the Internet developed RADIUS for configuring routers and service delivery). For these reasons I called this propose session management instead of access control.

personally I would not be a fan of RADIUS

A lot of developers dislike RADIUS. It has led to the creation of a lot of other authentication methods. Open-source FreeRADIUS and PAM would minimize our work. Only PAM needs to be adapted to the Jamulus code. FreeRADIUS and the database are available for this solution without any new code. I suggest we put a solution together and then let any team create new code if they have the interest.

The real work is collecting all related use cases and creating a database example of how this mechanism can solve each use case.

[hoffie]

Thanks for your reply and the clarifications.

The server should already know its identity as well. Or are you thinking about some virtual hosting instead of a pure IP address?

Two reasons. The server address helps prevent ambiguity. And yes, this scheme can handle virtual hosting or virtual servers. The distinction between physical IP address and virtual servers is trivial to the database. We should anticipate handling any kind of server (or rehearsal /jamming space).

While I do see benefits of "naming" Jamulus servers, I don't think adding virtual host support is that simple or should be part of this proposal.
Is there a use case for client A to connect to a.example.org and client B connecting to b.example.org while both target the same Jamulus server?

[hoffie]

(Sorry for replying in two comments, I hit submit too early)

Do you suggest that the Jamulus client would talk to a new "module" (i.e. independent server component)?

Yes and no. The client would talk to the server with some new protocol elements and the server would relay the new message to the independent component. There are open-source PAM and FreeRADIUS components that could minimize the amount of code that needs to be written.

I'm still not sure if I understand properly. Are you suggesting that PAM and FreeRADIUS integration would be part of the yet-to-be-developed, outside-of-Jamulus Jam Session Manager? Then I guess everyone would be free to use whatever implementation they would like or need. If you are suggesting that Jamulus server should integrate with PAM or RADIUS, then I'd be opposed to that.

The current protocol is based on UDP.

Let's discuss. My expectation is we keep the original code for backward compatibility and there is a new client protocol for users wanting/needing to connect to a session that has session management controls. The new protocol is UDP-based.

I guess there might be some confusion about the word "protocol". I assume you are mean one (or multiple) new protocol messages as part of the existing, UDP-based protocol implementation, right?
I wanted to hint at the fact that due to the UDP-based nature of the existing protocol, there is no concept of a session. Client's who've recently sent audio are there, client's who haven't are not.

What would happen if a Jam Session Manager authorized a client at 17:00 and it stays connected, although at 18:00 another session starts and the client would not have been authorized? Would this require some mechanism to remove users?

I glossed over this. It deserves some discussion among the developers. I think we want to have a concept of a session "hard" close and a "soft" close. The easy case is to make every session have a hard close. When the meter is up, everyone gets disconnected. I think this is unfriendly for musicians. A soft-close would let a session continue on or wind-down until the next session shows up (maybe the next day). To me this doesn't have to be difficult but I am not the coder.

To me it sounds like a significant difference if we are talking about admitting a client who had not been there before (i.e. a once-per-client access check), if we have to repeatedly check if a client is still allowed to be there (repeated access check) or, if we have to remove clients based on some timer.

Access control has come up a lot so I think this is something we should solve somehow. Session management sounds rather a niche, so my hope is to be able to couple this with access control in a way that avoids having session management logic within Jamulus client or server.

Yes, access control has come up a lot. However, many people have a very limited understanding of access control. For many, access control is a binary function, a user is allowed or disallowed. A full understanding of access control is about managing a service or provisioning and delivering a service. For Jamulus, it is about managing jam sessions. This could mean managing a server (as a 365/24/7 service) or it could be fine-grained where many sessions are delivered by a server. Managing service delivery is not a niche topic, for Jamulus it is a core topic. (Managing services for a subscriber is how the Internet developed RADIUS for configuring routers and service delivery). For these reasons I called this propose session management instead of access control.

I think many people would be happy with binary access control (e.g. ensure that no unwanted participants appear). I also agree that there are more sophisticated use cases such as yours. However, having a concept of sessions is only one way to detail that. One can come up with lots of more ideas for access control, such as "only allow users from Germany", "only allow users with a ping time below 15ms", etc. I'm looking for a way to abstract all that and only introduce a very shallow interface into Jamulus which would allow Jamulus-external components to handle the complexity (if necessary).

personally I would not be a fan of RADIUS

A lot of developers dislike RADIUS. It has led to the creation of a lot of other authentication methods. Open-source FreeRADIUS and PAM would minimize our work. Only PAM needs to be adapted to the Jamulus code. FreeRADIUS and the database are available for this solution without any new code. I suggest we put a solution together and then let any team create new code if they have the interest.

I'm still not sure if you are suggesting PAM and RADIUS for the "Gene Jam Session Manager" (i.e. a specific implementation), which would be fine for me, or for the basic protocol (I don't think we need this complexity there).
I'm wondering if you could work with simple web hooks there which should be easy to integrate into Jamulus (via Qt) and easy to implement via a variety of web-related languages (PHP, Python, Go, ...).

The real work is collecting all related use cases and creating a database example of how this mechanism can solve each use case.

Yes, collecting use cases and trying to find an interface which can cover them sounds like a good plan.

[gene96817]

Are you suggesting that PAM and FreeRADIUS integration would be part of the yet-to-be-developed, outside-of-Jamulus Jam Session Manager?

Elements of PAM need to be implemented in the client and server. Nothing works in total abstraction. We can use an EAP method and RADIUS as an example (since it would be the fastest and least amount of work). Other methods can be created. For instance, a Microsoft shop can integrate this to Active Directory (but it would be ugly for a non-Microsoft shop).

Of course, the provisioning side (what to do after authentication) needs some new functions in the server.

If you are suggesting that Jamulus server should integrate with PAM or RADIUS, then I'd be opposed to that.

Well some "protocol" needs to be selected. I am proposing RADIUS because FreeRADIUS would provide a complete off-the-shelf solution. We can implement PAM to make it easy to integrate another authentication system. Are we using "integrate" in the same way? If it is integrate code, then we need to implement PAM. PAM is intended to allow change out of specific message protocols. I mean integrate as in building a system. In this case, Jamulus and RADIUS are loosely coupled through the EAP method we choose and the parameter list returned to define the jam session.

I guess there might be some confusion about the word "protocol". I assume you are mean one (or multiple) new protocol messages as part of the existing, UDP-based protocol implementation, right?
I wanted to hint at the fact that due to the UDP-based nature of the existing protocol, there is no concept of a session. Client's who've recently sent audio are there, client's who haven't are not.

There isn't a problem. EAP would be a new set of UDP messages. The concept of sessions would be at the application layer not the UDP layer. The existing protocol continues on for any session (specifically, client-to-server connection) that does not need session management. The new (superset) protocol would be needed for managed sessions. I don't see this as a (hard) problem.

To me it sounds like a significant difference if we are talking about admitting a client who had not been there before (i.e. a once-per-client access check), if we have to repeatedly check if a client is still allowed to be there (repeated access check) or, if we have to remove clients based on some timer.

It depends on whether we can agree on how to implement a "soft" close. Start-of-managed-session and end-of-managed-session are where the Jamulus server needs two new functions. If we agree, then session management is possible with all the variations based on database definitions. If we don't agree, then session management is impossible.

I'm looking for a way to abstract all that and only introduce a very shallow interface into Jamulus which would allow Jamulus-external components to handle the complexity (if necessary).

I believe this proposal can meet your goals. Some of your examples are handled by the database UI and permission management of who can make database entries (i.e. session definitions). The best part is all this complexity is outside of the Jamulus code.

I'm wondering if you could work with simple web hooks there which should be easy to integrate into Jamulus (via Qt) and easy to implement via a variety of web-related languages (PHP, Python, Go, ...).

You are now proposing writing a lot of code to reinvent the features of RADIUS. RADIUS is 40 years old and it grew up managing the subscribers to the Internet. The opensource implementation gives us all the features for "free". Do you have a religious aversion to RADIUS? Your simple hooks are EAP and PAM.

My advice is you can hate RADIUS and wish to write some new code. Let us get a simple system integrated with FreeRADIUS and PAM. Define the Jamulus PAM parts to make it easy to replace RADIUS. I am perfectly happy to watch a team of coders reinvent RADIUS, after we have a simple system running. The worst-case scenario is to not have a solution until we invent a new system.

[ann0see]

Thanks for bringing it up. I'll have a look at it once I have more time

[ann0see]

Ok. So basically you propose a bigger change with APIs, multiple services etc.?

I think we should first try to define what

limited number of observers/visitors

means and focus on that. As hoffie said, we don't have a connection handshake yet.

That's the core topic jamulus can and should handle if we talk about session management. (we can think of something bigger later).

On my eduTools branch I disable audio mixing for clients which are not enabled. It's a fast and efficient way to stop audio from being sent from or to unknown users.

accept transferring secrets such as passwords

Although this is done on my branch, I don't think this should be done.

Anything else can be discussed, but is probably out of scope of Jamulus?

[dingodoppelt]

to add my 2cents:
i simply block clients by ip with nftables. it is really flexible and lets you cover a few usecases already (whitelisting as used for example on the worldjam, blacklisting as used for kicking from public servers)

[gene96817]

@ann0see It will be interesting to find all the places involved with session connect or start. Since I don't know the internal machinery, I can only assume this is a unitary function.

Consider the functions we need to add to the Jamulus server are:
1- send connection attempts to the session management logic to make a decision to accept or reject a user
2- if a user is rejected, deliver a message from the session management logic (so that rejects are not mysterious failures)
3- end a session (i.e. disconnected users)
3a- a no-notice disconnect, aka a hard disconnect, is unfriendly; allow a session end message from the session management logic
3b-allow a session to run overtime, aka a soft-disconnect, until the first attendee to the next planned session arrives; again allow a session end message from the session management logic

[ann0see]

1- send connection attempts to the session management logic to make a decision to accept or reject a user

Yes. I think this has to be done before receiving an audio packet. Somebody who's more familiar with the protocol stuff should hava a look at this.

2- if a user is rejected, deliver a message from the session management logic (so that rejects are not mysterious failures)

Agree. We could use the server full message maybe? But I don't know how the client reacts on this message.

3- end a session (i.e. disconnected users)

I think we already have a disconnect function. But I'm not exactly sure

3b-allow a session to run overtime, aka a soft-disconnect, until the first attendee to the next planned session arrives; again allow a session end message from the session management logic

Should be possible with some minor logic.

[gene96817]

The reason for not connecting a user quickly gets complicated when sessions are being managed. The messages might be specified by the session organizer. Some examples:

• The session name was not recognized, please reenter.
• The session is full.
• You are not listed as a participant of xxx session.

At the risk of making it more complicated, the disconnect and disconnect message can be managed by the session manager. For example, "Your session has ended, you will be disconnected in 5 minutes." or "The next session is about to begin, your session will be ended in 5 minutes."

[gene96817]

@ann0see

is a function we could have a look at if we want to reject clients although there are also other places I found where we might need to make adjustments.

I think this is easy to integrate. The logic already exist in RADIUS. Jamulus need only wait for a connect or reject decision. All the other friendly user interactions should be off-the-shelf.

[gene96817]

@dingodoppelt

i simply block clients by ip with nftables. it is really flexible and lets you cover a few usecases already (whitelisting as used for example on the worldjam, blacklisting as used for kicking from public servers)

Yes, that work if:
1- user IP address is a good enough identity,
2- you only need one policy (for participants) for the server. The proposal makes it easy to have different policies over a day, or week, etc.