0009290: How should subscription Id and session Id be chosen to ensure reconnect on a restarted server doesn't steal wrong subscriptions? - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0009290	10000-004: Services	Spec	public	2023-11-28 07:20	2023-12-05 16:42

Reporter	Martin Regen	Assigned To	Matthias Damm
Priority	normal	Severity	major	Reproducibility	sometimes
Status	closed	Resolution	no change required
Platform	UA .NET, maybe others too	OS	any
Product Version	1.04
Target Version	1.05.04 RC1

Summary	0009290: How should subscription Id and session Id be chosen to ensure reconnect on a restarted server doesn't steal wrong subscriptions?
Description	Currently I see some strange issues, because the UA .NET ref server always starts the subscription id with 1 after a restart. When the server is restarted and had, say 20 subscriptions from multiple sessions with id 1..20, when reconnecting the reconnected sessions are rebuilding the subscriptions and there is some opportunity for a session to try a transfer on a subscriptionId which is already owned by another session, but which has nothing to do with the previous ownership. To overcome this issue an idea would be that servers have to start subscription ids from a random number, to avoid subscription transfer of unknown subscriptions. Similar for the session id. Is there a note in the spec or the compliance tests yet that random ids are required? Is there a way for an additional check in the server on a transfer that the subscription was really owned by that session, e.g. by comparing also the session name? Otherwise there might be cases where the subscription disappears under a session when nobody expects it, because a session transfers an outdated id.
Tags	No tags attached.

Commit Version
Fix Due Date

Matthias Damm 2023-12-05 15:15 developer ~0020486	The specification defines already aspects to avoid this issue: (1) Starting SubscriptionId 5.13.2 CreateSubscription Table 88 – CreateSubscription Service Parameters Response - subscriptionId: After Server start-up the generation of subscriptionIds should start from a random IntegerId or continue from the point before the restart. The only enhancement here would to change the "should" to "shall" (2) Prevent "steal wrong subscriptions" 5.13.7 TransferSubscriptions The authenticationToken contained in the request header identifies the Session to which the Subscription and MonitoredItems shall be transferred. The Server shall validate that the Client of that Session is operating on behalf of the same user. If the Client uses an ANONYMOUS user token, the Server shall validate if the ApplicationUri is the same for the old and the new Session and the MessageSecurityMode is SIGN or SIGNANDENCRYPT. If the Server transfers the Subscription, it returns the sequence numbers of the NotificationMessages that are available for retransmission. The Client should acknowledge all Messages in this list for which it will not request retransmission.

Jim Luth 2023-12-05 16:42 administrator ~0020490	The submitter agreed to no-fix.

Date Modified	Username	Field	Change
2023-11-28 07:20	Martin Regen	New Issue
2023-12-05 15:15	Matthias Damm	Assigned To	=> Matthias Damm
2023-12-05 15:15	Matthias Damm	Status	new => resolved
2023-12-05 15:15	Matthias Damm	Resolution	open => no change required
2023-12-05 15:15	Matthias Damm	Note Added: 0020486
2023-12-05 16:42	Jim Luth	Status	resolved => closed
2023-12-05 16:42	Jim Luth	Note Added: 0020490