| 1 |
Overview of the TS5 system |
| 2 |
Lee H <lee@leeh.co.uk> |
| 3 |
|
| 4 |
$Id$ |
| 5 |
|
| 6 |
For the purposes of this document, ircd versions: |
| 7 |
hybrid6.0 |
| 8 |
ircd-comstud-1.12 |
| 9 |
CSr31pl4 |
| 10 |
|
| 11 |
and prior, are TS3. |
| 12 |
|
| 13 |
ircd-hybrid-6.2 and later support TS5. |
| 14 |
|
| 15 |
Whats TS5? |
| 16 |
---------- |
| 17 |
|
| 18 |
The difference between TS5 and TS3 is what happened on opless channels. TS |
| 19 |
works by establishing which server has the oldest version of the channel, |
| 20 |
the version that is oldest, keeps its modes and ops, the version that is |
| 21 |
youngest, removes their modes and ops, and accepts the older version. |
| 22 |
|
| 23 |
There was an exception to this rule with opless channels, if a channel was |
| 24 |
opless, TS3 would allow anybody to keep their ops and modes on the channel. |
| 25 |
TS5 aims to stop this, by removing this exception. |
| 26 |
|
| 27 |
Example1: |
| 28 |
|
| 29 |
An irc network, with server A (every server is ts3) |
| 30 |
|
| 31 |
UserA is on ServerA, in channel #broken. This channel is opless, and has a |
| 32 |
TS of 800000000. ServerA splits, and whilst it is split, UserA cycles |
| 33 |
channel #broken, recreates the channel and is given ops. On ServerA #broken |
| 34 |
now has a TS of 900000000 and has ops. ServerA rejoins with the network, |
| 35 |
via HubB. HubB realises #broken is opless, so allows UserA to retain ops. |
| 36 |
The TS is moved forward to 900000000. |
| 37 |
|
| 38 |
The network now sees #broken as having a TS of 900000000, with UserA being |
| 39 |
opped. |
| 40 |
|
| 41 |
Example2: |
| 42 |
|
| 43 |
An irc network, with server C (every server is ts5) |
| 44 |
|
| 45 |
Same scenario as above. ServerC splits and UserC cycles channel #broken, |
| 46 |
recreating it with a TS of 900000000. ServerC rejoins with the network via |
| 47 |
HubD. HubD realises #broken has a TS of 800000000 locally, and ServerC is |
| 48 |
showing a TS of 900000000, it ignores ServerC's modes and ops. The channel |
| 49 |
remains opless. ServerC receives HubD's modes, and it notices HubD has a |
| 50 |
lower TS of channel #broken. It removes UserC's ops, removes the channel |
| 51 |
modes on #broken, and accepts HubD's status. |
| 52 |
|
| 53 |
The network version of #broken hasn't changed. It is still opless, with a TS |
| 54 |
of 800000000. |
| 55 |
|
| 56 |
|
| 57 |
As you can see, TS5 makes splitting a server to regain ops useless, as it |
| 58 |
cannot be abused to give ops after a netsplit. |
| 59 |
|
| 60 |
The problem with TS5 however, is what happens on a mixed TS5/TS3 network. |
| 61 |
Channels where the older TS has ops will behave the same way on TS5 and TS3, |
| 62 |
however an opless channel will behave differently, as you can see above. |
| 63 |
|
| 64 |
The result of TS5/TS3 mixed can be a desync: |
| 65 |
|
| 66 |
Example1: |
| 67 |
|
| 68 |
As per Example1 above, except the rest of the network is TS5, ServerA is |
| 69 |
TS3. ServerA would keep its modes and ops, whilst the rest of the network |
| 70 |
would remove them. This means only ServerA would see UserA as opped. The |
| 71 |
desync can be abused, as UserA can send modes. Hybrid6.0 servers will |
| 72 |
accept these modes from the unopped client, so if UserA ops UserB, who then |
| 73 |
ops UserA, the channel will be the same across all Hybrid6.0 and Hybrid6.1 |
| 74 |
servers. |
| 75 |
|
| 76 |
Example2: |
| 77 |
|
| 78 |
As per Example2 above, except the rest of the network is TS3. ServerC is |
| 79 |
TS5. ServerC would remove its modes and ops, therefore UserC would not be |
| 80 |
opped on ServerC, therefore it could not send any mode changes to the |
| 81 |
channel. Although it is opped elsewhere, it isn't opped locally, so the |
| 82 |
desync cannot be abused. |
| 83 |
|
| 84 |
As you can see, the desync's that can occur can either be resynced, or are |
| 85 |
useless to the user, so a mixed TS5/TS3 network is not a huge problem, |
| 86 |
although a desync is NOT a good thing to have. |
| 87 |
|
| 88 |
|
| 89 |
Why TS5? |
| 90 |
-------- |
| 91 |
|
| 92 |
We have jumped to TS5 from TS3, because there was a version of ircd that was |
| 93 |
TS4, so it was thought better to avoid a clash with an existing version. |
| 94 |
|
| 95 |
|
| 96 |
Advantages |
| 97 |
---------- |
| 98 |
|
| 99 |
It's a realistic event that a server will be attacked so it splits off a |
| 100 |
network, then used to regain ops in a channel. TS5 makes this pointless, |
| 101 |
the server will never give ops on a netsplit. TS5 is network wide, so it |
| 102 |
leaves individual servers free to choose options like NO_JOIN_ON_SPLIT, |
| 103 |
whilst keeping splits useless to users. |
| 104 |
|
| 105 |
|
| 106 |
Disadvantages |
| 107 |
------------- |
| 108 |
|
| 109 |
It's virtually impossible for a user to actively regain ops themselves (some |
| 110 |
regard this as an advantage..) because on a large sized channel, its |
| 111 |
impossible to get people to leave so it can be recreated, therefore if a |
| 112 |
network did not have some form of services, it could possibly end up |
| 113 |
requiring oper intervention, as you cant get everybody to leave, and you |
| 114 |
cant use splits to regain ops, therefore if the channel is open (an |
| 115 |
invite-only channel would gradually destroy itself as noone new can join) it |
| 116 |
could be impossible for a user to regain ops. |
| 117 |
|
| 118 |
On a network that has some form of services, The effect of TS5 would be |
| 119 |
minimal, however the services must be of sufficient quality to fix opless |
| 120 |
channels, as TS5 renders netsplits for ops worthless. |
| 121 |
|
| 122 |
|
| 123 |
Recommendations |
| 124 |
--------------- |
| 125 |
|
| 126 |
If your network has good stable services, we recommend TS5 is enabled, as |
| 127 |
people have no reason to abuse netsplits anyway. |
| 128 |
|
| 129 |
If your network has no services at all, then TS5 may cause problems with |
| 130 |
users being left with a permanently opless channel. |
| 131 |
|
| 132 |
If your network occupies the middle ground, then its a choice between users |
| 133 |
needing to be able to use splits to regain ops, or making netsplits that are |
| 134 |
caused to regain ops worthless. |
| 135 |
|
| 136 |
If TS5 is chosen, the FULL network must upgrade and this should be done in a |
| 137 |
relatively short space of time to minimise the possible desync effects. |
| 138 |
|
| 139 |
|
| 140 |
Alternatives |
| 141 |
------------ |
| 142 |
|
| 143 |
There is also NO_JOIN_ON_SPLIT and NO_OP_ON_SPLIT, however these use the |
| 144 |
configuration of minimum servers and users, and sometimes a split that is |
| 145 |
above these limits is enough to be abused to regain ops, whereas if the |
| 146 |
limits are too high, clients will never be able to join anything or be opped |
| 147 |
when they create a channel. |