--- irc3-20000330.txt Thu Mar 30 14:22:28 2000 +++ irc3-20000415.txt Sat Apr 15 14:01:55 2000 @@ -1,5 +1,5 @@ Network Working Group A. Church -Request For Comments: nnnn March, 2000 +Request For Comments: nnnn April, 2000 Obsoletes: 1459 Category: Experimental @@ -134,6 +134,7 @@ 5.2.1 Nickname collisions 5.2.2 Server name or ID collisions 5.2.3 Channel collisions + 5.2.4 Network name collisions 5.3 Timekeeping 5.4 Connection desynchronization 5.5 Cyclic networks @@ -777,16 +778,20 @@ character set use in future versions of the protocol (see section 1.5), and MUST be cleared (zero) in all messages. - If bit 9 of the flag parameter is set, all strings are considered to - have 32-bit length fields rather than 16-bit length fields. - Bits 7 and 6 of the flag parameter are reserved for experimental or local use. - Bit 5 of the flag parameter is set when the message's source or - destination is a remote network. The network field MUST be included - wherever listed in the message grammar if bit 10 of the flag - parameter is set; otherwise the network field MUST NOT be included. + Bits 5 and 4 of the flag parameter are set iff the message's source + or destination, respectively is a remote network. The source and + dest fields listed in the message grammar MUST use the remote-name + format instead of the id-set format iff the relevant flag is set. + Messages between border servers on different networks MUST have bits + 5 and 4 both set (and use the remote-name format for both sender and + target) to ensure that sender information is correctly propogated to + the remote network; border servers forwarding a message received from + a remote network MUST convert the target information to an id-set and + clear bit 4 in the message to be forwarded (or return an error reply + to the sender if the target does not exist). Additional bits are defined below, and all of the flag bits are summarized in section 2.3. All flag bits not defined by this @@ -902,7 +907,7 @@ disconnections and channel joins and parts) are transmitted to all servers. Should this situation occur, it could be resolved by breaking the connection between the two servers (if one existed) and - reestablishing it. + establishing a new connection. Note also that this algorithm assumes that all data is transmitted in sequence along all paths. Without this assumption, it is possible @@ -958,10 +963,12 @@ seqnum = longint hop-list = hop-count *32767 hop-count = shortint ;number of servers in hop-list - source = [network] serverid clientid + source = id-set / remote-name + id-set = serverid clientid + remote-name = network sendername senderaddr serverid = shortint clientid = shortint - dest = [network] serverid clientid + dest = id-set / remote-name timestamp = <64-bit integer> 2.2.3 Replies @@ -995,11 +1002,12 @@ 12: Reserved, set to 0. 11: 1 if the message includes a sender address field, else 0. 10: 1 if the message is a reply, else 0. - 9: 1 if the message has strings with 32-bit lengths, else 0. + 9: Reserved, set to 0. 8: 1 if the message includes a timestamp, else 0. 7-6: Reserved for experimental or local use; values undefined. - 5: 1 if the message is to or from a remote network, else 0. - 4-2: Unused, set to 0. + 5: 1 if the message's source is on a remote network, else 0. + 4: 1 if the message's target is on a remote network, else 0. + 3-2: Unused, set to 0. 1-0: Identify the destination of a message with destination client ID equal to zero; see section 2.2.2. @@ -1007,9 +1015,11 @@ A number of messages require timestamps to be sent. All servers on a network MUST assign the same meaning to this time value; servers - SHOULD use the current Unix standard (seconds since 1 January 1970 - 00:00 GMT), to reduce difficulties for clients in determining what - timestamp system is in use. + SHOULD use the current de-facto standard (seconds since 1 January + 1970 00:00 GMT, used in most if not all current IRC servers and also + the return value of the standard Unix time(2) system call), to + reduce difficulties for clients in determining what timestamp system + is in use. Since servers that use the time system described above will run into problems beginning in January 2038 if a 32-bit signed integer is @@ -1139,11 +1149,12 @@ 3.1.2 User message Code: 0x0001 - Parameters: version-id (shortint), nickname (string), - username (user-string), real-name (string) - Server-only parameters: time (timestamp) + Client-server parameters: version-id (shortint), nickname (string), + username (user-string), real-name (string) + Server-server parameters: client-id (shortint), nickname (string), + username (user-string), real-name (string), + hostname (string), time (timestamp) - longint = <32-bit value> user-string = * Registers a connection as a client. The nickname parameter indicates @@ -1169,9 +1180,6 @@ features of this protocol MUST choose a new version-id value in that range for their revised protocol. - The time parameter is added to the message by the server to which the - client connected before the message is broadcast to other servers. - If the nickname given by the client is longer than the maximum length (31 characters), the server MUST return ERR_NAME_TOO_LONG and ignore the message. @@ -1189,7 +1197,20 @@ the server might remove all invalid characters, or replace them with an innocuous character such as "x".) See section 6.5 for a discussion of potential security problems with allowing any character - to be used in a name. + to be used in a name. Servers SHOULD NOT modify the real-name + parameter. + + Once the user message has been successfully processed, the server + generates a new user message to forward to other servers. The + nickname, username, and real-name parameters are retained from the + client's original message, except when modified as described above. + The client-id parameter is a 16-bit value used to identify the client + (see section 1.2) and may be assigned arbitrarily by the server. The + hostname parameter is the client's hostname as determined by the + server; see section 6.2 for security notes on address-to-hostname + resolution. The time parameter is the time at which the client + connected to the server, or alternatively the time at which the + message is generated (either are acceptable). Examples: @@ -2651,7 +2672,10 @@ signon: Time in seconds since 1 January 1970 00:00 UTC when the client connected to its server. idle: Time in seconds since the client last send a public or - private message (see sections 3.2.1 and 3.2.2). + private message (see sections 3.2.1 and 3.2.2). If + the client is not directly connected to the + responding server, the value is -1 (all bits set); + clients should interpret this value as "unknown". status: A 16-bit word with bits set as follows: Bit 1: 1 iff the client is marked away. Bit 0: 1 iff the client is an IRC operator. @@ -3597,6 +3621,20 @@ (Services for IRC Networks [9], originally developed by the author of this document, is an example of such a "network service" server). +5.2.4 Network name collisions + + If two servers on a network announce themselves as border routers + (see section 3.1.5) for the same network, the servers are assumed to + have connected to the same network. Servers sending remote messages + to that network SHOULD choose the shortest path to a border server. + + Note that if two servers connect to different networks each of which + claims to have the same name, it is unspecified which network will + receive messages; this is similar to, for example, the case of two + nodes on a physical network claiming to have the same IP address. + Server and network administrators must take care to ensure that no + duplication of network names occurs. + 5.3 Timekeeping Because parts of this protocol -- in particular, the collision @@ -3761,9 +3799,9 @@ 123.45.67.89) for the remote hostname. Servers SHOULD NOT close the connection on a lookup failure or mismatch, because there are some legitimate hosts which have a mismatched IP address and DNS name - (likely due to errors on the part of the administrators for those IP - ranges or domains). However, servers SHOULD generate some sort of - warning for such an occurrance (for example, via a server message + (possibly due to errors on the part of the administrators for those + IP addresses or domains). However, servers SHOULD generate some sort + of warning for such an occurrance (for example, via a server message (section 3.2.4)). 6.3 Network sniffing @@ -3800,7 +3838,46 @@ 6.5 Special characters in names The wide range of allowable characters in names (nicknames, server - names, and so on) creates the potential for + names, and so on) creates the potential for attacks against clients. + While servers would be unlikely to encounter problems with any + particular character occurring in a name, since no processing of + names processing of names is performed, interactive clients in + particular may suffer from certain types of attacks. For example, an + an attacker may choose a nickname containing unprintable characters + or other characters which a user was unable to input; although this + protocol provides a method for clients to filter messages from other + clients (see section 3.4.3), the user would be unable to take + advantage of this feature and would be at the attacker's mercy. Some + clients also have features which rely on text representations of user + information (for example, the "@" between a user's username and + hostname), and it may be possible for attackers to choose names which + cause these features to malfunction; even without such features, + attackers can cause confusion to users who view the resulting text. + + For this reason, servers SHOULD disallow at least the following + characters, as well as any others determined by the server + administrator to pose a potential danger. + ASCII control characters (ASCII 0x00..0x1F) + May cause unintended display side effects. However, servers + MAY permit ESC (ASCII 0x1B) or other characters when those + characters are in common use; for example, the Japanese JIS + character (ISO-2022-JP) set uses the ESC character, and many + IRC clients use control characters for bold, underline, or + other display effects. + "!" (ASCII 0x21) + In nicknames, may cause old-protocol clients to consider the + "!" as a nickname-username separator. + "#" (ASCII 0x23), "&" (ASCII 0x26) + At the beginning of nicknames and server names, may cause + clients to misinterpret the name as a channel name. + "*" (ASCII 0x2A), "?" (ASCII 0x3F) + May be interpreted as wildcards when entered by a user. + "@" (ASCII 0x40) + In nicknames and server names, may cause unintended meaning + when a user attempts to send a message to the name (for + example, the client may attempt to send to a remote network). + In usernames, may cause confusion when combined with the + hostname. 7. AUTHOR'S ADDRESS @@ -3903,10 +3980,11 @@ client-message = flag length32 (cli-serv-msg / serv-cli-msg) clientid = shortint code = shortint - dest = [network] serverid clientid + dest = id-set / remote-name flag = shortint hop-count = shortint ;number of servers in hop-list hop-list = hop-count *32767 + id-set = serverid clientid length = length16 / length32 ;chosen as appropriate length16 = <16-bit count of octets in the remainder of the object which the rule describes> @@ -3917,6 +3995,7 @@ network = string ;destination network octet = parameter = string + remote-name = network sendername senderaddr reply = flag length code sendername [string] sendername = string ;sender's nick / servername senderaddr = addr-string | addr-unistring @@ -3928,7 +4007,7 @@ [time] * serverid = shortint shortint = <16-bit integer> - source = [network] serverid clientid + source = id-set / remote-name string = string16 / string32 string16 = length16 *32767 string32 = length32 *2147483647