Rabu, 08 September 2010

Internet Relay Chat (IRC)

Technical information

The standard structure of a network of IRC servers is a tree. Messages are routed along only necessary branches of the tree but network state is sent to every server and there is generally a high degree of implicit trust between servers. This architecture has a number of problems. A misbehaving or malicious server can cause major damage to the network and any changes in structure, whether intentional or a result of conditions on the underlying network, require a net-split and net-join. This results in a lot of network traffic and spurious quit/join messages to users and temporary loss of communication to users on the splitting servers. Adding a server to a large network means a large background bandwidth load on the network and a large memory load on the server. Once established however, each message to multiple recipients is delivered by multicast which means each message travels a network link exactly once. This is a strength in comparison to non-multicasting protocols such as Simple Mail Transfer Protocol (SMTP) or Extensible Messaging and Presence Protocol (XMPP).

Commands and replies

Channels

The basic means of communication in an established IRC session is a channel.[26] Channels in a server can be displayed using the IRC command LIST[27] that lists all currently available channels.

Modes

Standard (RFC1459) modes

User modes
Letter Symbol Description
i
Invisible—cannot be seen without a common channel or knowing the exact name
s
Receives server notices
w
Receives wallops[38]
o
User is an IRC operator (ircop)
Channel modes
Letter Symbol Parameter(s) Description
o @ Name of affected user Channel operator—can change channel modes and kick users out of the channel among other things
s

Secret channel—not shown in channel list or user whois except to users already on the channel
p

Private channel—listed in channel list as "prv" according to RFC 1459
n

Users cannot send external messages from outside the channel
m

Channel is moderated (only those who hold operator or voice status on the channel can send messages to it)
i

Only users with invites may enter the channel.
l
Limit number Limits number of users able to be on channel (when full, no new users can join)
b
Ban mask (nick!user@host with wildcards allowed) Bans hostmasks from channel
v + Name of affected user Gives a user voice status on channel (see +m above)
k None New channel key Sets a channel key such that only users knowing the key can enter

IRC operators

There are also users who maintain elevated rights on their local server, or the entire network; these are called IRC operators,[42] sometimes shortened to IRCops. As the implementation of the ircd varies, so do the privileges of the IRC operator on the given ircd. RFC1459[42] claims that IRC operators are "a necessary evil" to keep clean state of the network, as such they need to be able to disconnect and reconnect servers. Additionally, to prevent malicious users or even automated programs that may cause harm to enter IRC, IRC operators usually are allowed to disconnect Clients and completely ban IPs and complete subnets. Networks that carry services (Nickserv et al.) usually allow their IRC Operators also to handle basic "Ownership" matters. Further privileged rights may include overriding channel bans (being able to join channels they wouldn't be allowed to join if they were not opered), being able to op themselves on channels where they wouldn't be able without being opered, being auto-opped on channels always and so forth.

Hostmasks

Challenges

Attacks

Abuse prevention

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 which 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 which existed on the other side of the network, the server would kill both users when rejoining (i.e., '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 netsplits, which they would then abuse.

Nick/channel delay

Timestamping

The alternative, the timestamp or TS protocol, took a different approach. Every nickname and channel on the network was assigned a timestamp – the date and time when it was created. When a netsplit occurred, two users on each side were free to use the same nickname or channel, but when the two sides were joined, only one could survive. In the case of nicknames, the newer user, according to their TS, was killed; when a channel collided, the members (users on the channel) were merged, but the channel operators on the "losing" side of the split lost 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 which 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.

SAVE

Networks

freenode is quite popular with community based projects, especially Free and Open Source Software projects. A lot of users of various FOSS projects use freenode since a lot of FOSS projects have official IRC channels there.

Clients

Client software

Bots

Bouncer

Search engines

Modern IRC

Character encoding

File sharing


Tidak ada komentar:

Posting Komentar