Editing IRC (section)

==Challenges==
Issues in the original design of IRC were the amount of shared state data<ref>{{cite IETF
| rfc         = 1324
|title=A Discussion on Computer Network Conferencing
| sectionname = Size
| section     = 2.5.1
| pages       = 5 – 6
| idanchor    = ietf
}}</ref><ref>{{cite IETF
| rfc         = 2810
|title=Internet Relay Chat: Architecture
| sectionname = Scalability
| section     = 6.1
| page        = 7
| idanchor    = ietf
}}</ref> being a limitation on its scalability,<ref>{{harvnb|Loesch|2003}} 1.2.1 Growth</ref> the absence of unique user identifications leading to the nickname collision problem,<ref>{{cite IETF
| rfc         = 1324
|title=A Discussion on Computer Network Conferencing
| sectionname = User identification
| section     = 5.4.1
| page        = 10
| idanchor    = ietf
}}</ref> lack of protection from [[netsplit]]s by means of cyclic routing,<ref>{{cite IETF
| rfc         = 1324
|title=A Discussion on Computer Network Conferencing
| sectionname = Trees and cycles
| section     = 5.4.2
| page        = 10
| idanchor    = ietf
}}</ref><ref>{{harvnb|Loesch|2003}} 1.2.2 Network failures</ref> the trade-off in scalability for the sake of real-time user presence information,<ref>{{cite IETF
| rfc         = 1324
|title=A Discussion on Computer Network Conferencing
| sectionname = State Information problems
| section     = 2.1
| page        = 4
| idanchor    = ietf
}}</ref> protocol weaknesses providing a platform for abuse,<ref>{{harvnb|Loesch|2003}} 1.2.3 Sociological and security aspects</ref> no transparent and optimizable message passing,<ref>{{cite IETF
| rfc         = 1324
|title=A Discussion on Computer Network Conferencing
| sectionname = Message passing
| section     = 5.2.1
| page        = 7
| idanchor    = ietf
}}</ref> and no encryption.<ref>{{cite IETF
| rfc         = 1324
|title=A Discussion on Computer Network Conferencing
| sectionname = Conference security
| section     = 5.2.4
| page        = 8
| idanchor    = ietf
}}</ref> Some of these issues have been addressed in [[Internet Relay Chat#Modern IRC|Modern IRC]].

===Attacks===
Because IRC connections may be unencrypted and typically span long time periods, they are an attractive target for [[Denial-of-service attack|DoS/DDoS attackers]] and [[Hacker (computer security)|hackers]]. Because of this, careful security policy is necessary to ensure that an IRC network is not susceptible to an attack such as a [[Internet Relay Chat takeover|takeover]] war. IRC networks may also [[K-line (IRC)|K-line]] or [[G-line]] users or servers that have a harming effect.

Some IRC servers support [[Transport Layer Security|SSL/TLS]] connections for security purposes. This helps stop the use of [[packet sniffer]] programs to obtain the passwords of IRC users, but has little use beyond this scope due to the public nature of IRC channels. SSL connections require both client and server support (that may require the user to install SSL binaries and IRC client specific patches or modules on their computers). Some networks also use SSL for server-to-server connections, and provide a special channel flag (such as <code>+S</code>) to only allow SSL-connected users on the channel, while disallowing operator identification in clear text, to better utilize the advantages that SSL provides.<ref>{{cite web
 | url        = http://esper.net/help.php
 | title      = Getting Help on EsperNet
 | publisher  = The EsperNet IRC Network
 | access-date = 31 July 2012
}}</ref><ref>{{cite web
 | url        = http://www.dal.net/news/shownews.php?id=67
 | title      = New Feature: SSL For Users
 | author     = brandon
 | date       = 18 May 2010
| publisher  = DALnet
 | access-date = 31 July 2012
}}</ref>

IRC served as an early laboratory for many kinds of Internet attacks, such as using fake [[Internet Control Message Protocol|ICMP]] unreachable messages to break [[Transmission Control Protocol|TCP]]-based IRC connections ([[Nuke (computer)|nuking]]) to annoy users or facilitate [[Internet Relay Chat takeover|takeovers]].

===Abuse prevention===
{{Unreferenced section |date=June 2024}}
One of the most contentious technical issues surrounding IRC implementations, which survives to this day, is the merit of "Nick/Channel Delay" vs. "Timestamp" protocols. Both methods exist to solve the problem of denial-of-service attacks, but take very different approaches.
The problem with the original IRC protocol as implemented was that when two servers split and rejoined, the two sides of the network would simply merge their channels. If a user could join on a "split" server, where a channel that existed on the other side of the network was empty, and gain operator status, they would become a channel operator of the "combined" channel after the [[netsplit]] ended; if a user took a nickname that existed on the other side of the network, the server would kill both users when rejoining (a "nick collision"). This was often abused to "mass-kill" all users on a channel, thus creating "opless" channels where no operators were present to deal with abuse. Apart from causing problems within IRC, this encouraged people to conduct denial-of-service attacks against IRC servers in order to cause [[netsplit]]s, which they would then abuse.

{{anchor|delay}}
The '''nick delay''' (ND) and '''channel delay''' (CD) strategies aim to prevent abuse by delaying reconnections and renames. After a user signs off and the [[nickname]] becomes available, or a channel ceases to exist because all its users parted (as often happens during a [[netsplit]]), the server will not allow any user to use that nickname or join that channel, until a certain period of time (the ''delay'') has passed. The idea behind this is that even if a [[netsplit]] occurs, it is useless to an abuser because they cannot take the nickname or gain operator status on a channel, and thus no collision of a nickname or "merging" of a channel can occur. To some extent, this inconveniences legitimate users, who might be forced to briefly use a different name after rejoining (appending an [[underscore]] is popular).

The timestamp protocol is an alternative to nick/channel delays which resolves collisions using timestamped priority. Every nickname and channel on the network is assigned a timestamp{{spaced ndash}}the date and time when it was created. When a netsplit occurs, two users on each side are free to use the same nickname or channel, but when the two sides are joined, only one can survive. In the case of nicknames, the newer user, according to their TS, is killed; when a channel collides, the members (users on the channel) are merged, but the channel operators on the "losing" side of the split lose their channel operator status.

TS is a much more complicated protocol than ND/CD, both in design and implementation, and despite having gone through several revisions, some implementations still have problems with "desyncs" (where two servers on the same network disagree about the current state of the network), and allowing too much leniency in what was allowed by the "losing" side. Under the original TS protocols, for example, there was no protection against users setting bans or other modes in the losing channel that would then be merged when the split rejoined, even though the users who had set those modes lost their channel operator status. Some modern TS-based IRC servers have also incorporated some form of ND and/or CD in addition to timestamping in an attempt to further curb abuse.

Most networks today use the timestamping approach. The timestamp versus ND/CD disagreements caused several servers to split away from [[EFnet]] and form the newer [[IRCnet]]. After the split, EFnet moved to a TS protocol, while IRCnet used ND/CD.

In recent versions of the IRCnet ircd, as well as ircds using the TS6 protocol (including Charybdis), ND has been extended/replaced by a mechanism called SAVE. This mechanism assigns every client a [[Unique identifier|UID]] upon connecting to an IRC server. This ID starts with a number, which is forbidden in nicks (although some ircds, namely IRCnet and InspIRCd, allow clients to switch to their own UID as the nickname).

If two clients with the same nickname join from different sides of a netsplit ("nick collision"), the first server to see this collision will force ''both'' clients to change their nick to their UID, thus saving both clients from being disconnected. On IRCnet, the nickname will also be locked for some time (ND) to prevent both clients from changing back to the original nickname, thus colliding again.