Hi all,
I think it's about time to discuss host-masking for users again.
There are (at least) two types of host-masking we could add: 1) hash based masks (statically mask part of the IP/host, i.e. dalnet-19309.example.com) 2) nick based masks (i.e. registered-nick.dalnet.user or whatever)
The second method will let users evade bans more easily so I'm going to focus on the first method.
My implementation suggestion: Each server will store both the user's real host and a hashed version of it. The hash for each IP/host will always be static and even if a user disconnects and re-connects, they will get the same hashed IP/host. By default, users will get a umode (i.e. +H) that will show the hashed version wherever their real host have been used until now (/whois, /who, joins, parts, etc). At any time, a user will be able to umode -H themselves and use their real host instead of the masked one. Bans will work both against the real host and the hashed host so if a user will get banned by his masked host, they won't be able to join a channel even if they umode -H themsleves. IRC Operators will be able to see any users' real IP/host, ofcourse.
IMO, we shouldn't pass the masked host with the NICK command between servers and just let each server hash it on their own. As for the actual encryption, I would let a module do the actual hashing of the masked host (we'll provide a sample module). The module will be able to support (at least) two encryption types so we will be able to be change the type we're using on the fly by services after all servers have upgraded their module (in the case we'll ever want to change it).
Let the discussion begin!
-Kobi.
Personally, I don't think DALnet needs masking. I see plenty of room for abuse, and inability to properly ban things, especially if each server is independently hashing a hostmask.
BUT, if we WERE to mask, I'd go with a static hash of the address shared among servers. Connecting server hashes it, passes it as the hostmask to all other servers. Helps prevent abuse. Nick based masks hold plenty of room for abuse.
On Tue, Oct 13, 2009 at 7:50 PM, Kobi Shmueli kobi@dal.net wrote:
Hi all,
I think it's about time to discuss host-masking for users again.
There are (at least) two types of host-masking we could add:
- hash based masks (statically mask part of the IP/host, i.e.
dalnet-19309.example.com) 2) nick based masks (i.e. registered-nick.dalnet.user or whatever)
The second method will let users evade bans more easily so I'm going to focus on the first method.
My implementation suggestion: Each server will store both the user's real host and a hashed version of it. The hash for each IP/host will always be static and even if a user disconnects and re-connects, they will get the same hashed IP/host. By default, users will get a umode (i.e. +H) that will show the hashed version wherever their real host have been used until now (/whois, /who, joins, parts, etc). At any time, a user will be able to umode -H themselves and use their real host instead of the masked one. Bans will work both against the real host and the hashed host so if a user will get banned by his masked host, they won't be able to join a channel even if they umode -H themsleves. IRC Operators will be able to see any users' real IP/host, ofcourse.
IMO, we shouldn't pass the masked host with the NICK command between servers and just let each server hash it on their own. As for the actual encryption, I would let a module do the actual hashing of the masked host (we'll provide a sample module). The module will be able to support (at least) two encryption types so we will be able to be change the type we're using on the fly by services after all servers have upgraded their module (in the case we'll ever want to change it).
Let the discussion begin!
-Kobi. _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
On Tue, Oct 13, 2009 at 7:55 PM, Vin King vin.king@gmail.com wrote:
Personally, I don't think DALnet needs masking. I see plenty of room for abuse, and inability to properly ban things, especially if each server is independently hashing a hostmask.
BUT, if we WERE to mask, I'd go with a static hash of the address shared among servers. Connecting server hashes it, passes it as the hostmask to all other servers. Helps prevent abuse. Nick based masks hold plenty of room for abuse.
Considering DALnet's rate of growth over the past few years, and the fact that there are thousands upon thousands of networks that have successfully done hostmasking for close to a decade, I'd have to wonder why DALnet would not want to implement this feature.
For that matter, let's throw in client SSL. I don't want to hear the excuse that it uses too much load. A Gentoo box powered by a Dell 2950 with an Intel PT 1000 can handle over 100 million SSL connection setups and takedowns in a day, with a load average of 0, and this is without hardware acceleration.
DALnet has successfully done no hostmasking for over a decade, so if it ain't broke, don't fix it, in my opinion. Client side ssl, though, I feel is a reasonable enhancement request. What with more places offering wifi, and internet options on the go these days, I feel a more secure client to server communication is higher priority than hostmask offerings.
On Tue, Oct 13, 2009 at 8:33 PM, Michael Reynolds < michael.reynolds@gmail.com> wrote:
On Tue, Oct 13, 2009 at 7:55 PM, Vin King vin.king@gmail.com wrote:
Personally, I don't think DALnet needs masking. I see plenty of room for abuse, and inability to properly ban things, especially if each server is independently hashing a hostmask.
BUT, if we WERE to mask, I'd go with a static hash of the address shared among servers. Connecting server hashes it, passes it as the hostmask to
all
other servers. Helps prevent abuse. Nick based masks hold plenty of room
for
abuse.
Considering DALnet's rate of growth over the past few years, and the fact that there are thousands upon thousands of networks that have successfully done hostmasking for close to a decade, I'd have to wonder why DALnet would not want to implement this feature.
For that matter, let's throw in client SSL. I don't want to hear the excuse that it uses too much load. A Gentoo box powered by a Dell 2950 with an Intel PT 1000 can handle over 100 million SSL connection setups and takedowns in a day, with a load average of 0, and this is without hardware acceleration. _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
On Tue, Oct 13, 2009 at 7:43 PM, Vin King vin.king@gmail.com wrote:
DALnet has successfully done no hostmasking for over a decade, so if it ain't broke, don't fix it, in my opinion. Client side ssl, though, I feel is a reasonable enhancement request. What with more places offering wifi, and internet options on the go these days, I feel a more secure client to server communication is higher priority than hostmask offerings.
With that line of reasoning, there is no reason to add additional features to the ircd, ever -- including client-side SSL.
I don't have strong feelings for or against hostmasking, but using your "if it ain't broke, don't fix it" reasoning, coupled with the belief that it increases the potential for abuse, as a case to not implement this feature just seems rather silly to me. This argument surfaces every time hostmasking is proposed on this list. Do you have any specific examples as to how this would make banning more difficult, or increase abuse across the network?
As previously mentioned by another poster, other networks have shown that hostmasking can be implemented in a successful manner. Now, does this mean DALnet should offer hostmasking simply because a vast majority of other networks do? No, but DALnet can use them as a reference point on what does and does not work should a decision be made to implement this feature.
-SecretAgent
As I said in the email you quoted, SSL is actually becoming a concern, as there is more room for monitoring with open networks these days. Client to server communications should have an expectation of privacy. That being said, when the conversation is started with the idea that each server should hash the address independently, then channel operators would have no protection from server to server movements by a rogue client. Nick based hostmasks allow for a collection of hostmasks to be generated.
The potential from abuse by a vhost is mitigated by wildcarding the ip address, which can't be done with hostmasks.
Additionally, with each hostmask now being independent, wildcard bans on ISPs become ineffective, and the current limitations on ban list lengths become a major shortfall.
Providing the capability without proper planning into all the affected systems will easily create room for abuse, especially if the system isn't properly tested for abuse potential.
Specific examples of how hard it is for your average channel operator to keep a determined attacker out of a channel when the IRCD provides the attacker with the ability to change their hostmask can be seen on any network that does provide the address. I know I myself have abused the capabilities of other networks easy enough, so it's not impossible.
I personally don't see how hostmasking provides any end user security, as the vast majority of the network users are not dealing with attacks against themselves or their connections, and since the vast majority of attacks on the network are through query anyways with OMG DO THIS FOR OPS //decode
It's good to hear that SSL is coming, as more and more of our users these days are using untrusted public connections.
On Tue, Oct 13, 2009 at 9:19 PM, Jason Hill secrtagnt@gmail.com wrote:
On Tue, Oct 13, 2009 at 7:43 PM, Vin King vin.king@gmail.com wrote:
DALnet has successfully done no hostmasking for over a decade, so if it ain't broke, don't fix it, in my opinion. Client side ssl, though, I feel
is
a reasonable enhancement request. What with more places offering wifi,
and
internet options on the go these days, I feel a more secure client to
server
communication is higher priority than hostmask offerings.
With that line of reasoning, there is no reason to add additional features to the ircd, ever -- including client-side SSL.
I don't have strong feelings for or against hostmasking, but using your "if it ain't broke, don't fix it" reasoning, coupled with the belief that it increases the potential for abuse, as a case to not implement this feature just seems rather silly to me. This argument surfaces every time hostmasking is proposed on this list. Do you have any specific examples as to how this would make banning more difficult, or increase abuse across the network?
As previously mentioned by another poster, other networks have shown that hostmasking can be implemented in a successful manner. Now, does this mean DALnet should offer hostmasking simply because a vast majority of other networks do? No, but DALnet can use them as a reference point on what does and does not work should a decision be made to implement this feature.
-SecretAgent _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
On Tue, Oct 13, 2009 at 8:33 PM, Vin King vin.king@gmail.com wrote:
As I said in the email you quoted, SSL is actually becoming a concern, as there is more room for monitoring with open networks these days. Client to server communications should have an expectation of privacy. That being said, when the conversation is started with the idea that each server should hash the address independently, then channel operators would have no protection from server to server movements by a rogue client. Nick based hostmasks allow for a collection of hostmasks to be generated.
The actual security provided by client-side SSL is debatable. Trust is not transitive, and for client-side SSL to truly work a lot of assumptions have to be made (e.g. clients are not on compromised machines with logging turned off, servers are not on compromised machines and don't log anything, etc.); however, this is another discussion in itself.
That said, independent hashing of the address can work reliably, depending on the algorithm being used; however, it would also be rather trivial for the user's server to generate the hash during the registration process and propagate it across the network to other servers (e.g. by using NICK or by implementing something like ENCAP <sub-command>).
I also agree that nickname-based hostmasks won't work reliably on DALnet, given how insanely easy it is to register a nickname.
The potential from abuse by a vhost is mitigated by wildcarding the ip address, which can't be done with hostmasks.
Additionally, with each hostmask now being independent, wildcard bans on ISPs become ineffective, and the current limitations on ban list lengths become a major shortfall.
Providing the capability without proper planning into all the affected systems will easily create room for abuse, especially if the system isn't properly tested for abuse potential.
Specific examples of how hard it is for your average channel operator to keep a determined attacker out of a channel when the IRCD provides the attacker with the ability to change their hostmask can be seen on any network that does provide the address. I know I myself have abused the capabilities of other networks easy enough, so it's not impossible.
I personally don't see how hostmasking provides any end user security, as the vast majority of the network users are not dealing with attacks against themselves or their connections, and since the vast majority of attacks on the network are through query anyways with OMG DO THIS FOR OPS //decode
Ban evasions will be possible with or without hostmasking; however, a lot of what you mentioned can be mitigated by the fact that a server will know both the real and masked host for a user. This makes it possible for ban list entries (and silence lists, etc) to be easily matched against a user, regardless of whether a user has enabled/disabled hostmasking and whether the ban is against the user's real or masked host. For example, a ban against *!*@*.aol.com should work even if the user is umode +H and their mask is generated based on their IP address (due to the server being unable to perform a reverse lookup).
It's good to hear that SSL is coming, as more and more of our users these days are using untrusted public connections.
-SecretAgent
On Tue, Oct 13, 2009 at 9:31 PM, Jason Hill secrtagnt@gmail.com wrote:
On Tue, Oct 13, 2009 at 8:33 PM, Vin King vin.king@gmail.com wrote:
<snip>
The potential from abuse by a vhost is mitigated by wildcarding the ip address, which can't be done with hostmasks.
Additionally, with each hostmask now being independent, wildcard bans on ISPs become ineffective, and the current limitations on ban list lengths become a major shortfall.
Providing the capability without proper planning into all the affected systems will easily create room for abuse, especially if the system isn't properly tested for abuse potential.
Specific examples of how hard it is for your average channel operator to keep a determined attacker out of a channel when the IRCD provides the attacker with the ability to change their hostmask can be seen on any network that does provide the address. I know I myself have abused the capabilities of other networks easy enough, so it's not impossible.
I personally don't see how hostmasking provides any end user security, as the vast majority of the network users are not dealing with attacks against themselves or their connections, and since the vast majority of attacks on the network are through query anyways with OMG DO THIS FOR OPS //decode
Ban evasions will be possible with or without hostmasking; however, a lot of what you mentioned can be mitigated by the fact that a server will know both the real and masked host for a user. This makes it possible for ban list entries (and silence lists, etc) to be easily matched against a user, regardless of whether a user has enabled/disabled hostmasking and whether the ban is against the user's real or masked host. For example, a ban against *!*@*.aol.com should work even if the user is umode +H and their mask is generated based on their IP address (due to the server being unable to perform a reverse lookup).
I accidentally deleted half of my example, so I'll clarify...
Ban matching should not be problem if the server knows both the real and masked host for the user, regardless of whether the user is actually umode +H or not. For example, a ban against *!*@98a866b7.ipt.aol.com should match userA even if their umode +H and their masked (visible) host is now dalnet-84725.ipt.aol.com. As for ISP wildcard bans no longer matching masked users, this would only be the case if the hash is generated against the user's IP address, which would only happen if the server is unable to perform a reverse lookup on it -- in which case it wouldn't match regardless of hostmasking.
-SecretAgent
If the user is masked, how do you ban their ISP?
On Tue, Oct 13, 2009 at 10:42 PM, Jason Hill secrtagnt@gmail.com wrote:
On Tue, Oct 13, 2009 at 9:31 PM, Jason Hill secrtagnt@gmail.com wrote:
On Tue, Oct 13, 2009 at 8:33 PM, Vin King vin.king@gmail.com wrote:
<snip>
The potential from abuse by a vhost is mitigated by wildcarding the ip address, which can't be done with hostmasks.
Additionally, with each hostmask now being independent, wildcard bans on ISPs become ineffective, and the current limitations on ban list lengths become a major shortfall.
Providing the capability without proper planning into all the affected systems will easily create room for abuse, especially if the system
isn't
properly tested for abuse potential.
Specific examples of how hard it is for your average channel operator to keep a determined attacker out of a channel when the IRCD provides the attacker with the ability to change their hostmask can be seen on any network that does provide the address. I know I myself have abused the capabilities of other networks easy enough, so it's not impossible.
I personally don't see how hostmasking provides any end user security,
as
the vast majority of the network users are not dealing with attacks
against
themselves or their connections, and since the vast majority of attacks
on
the network are through query anyways with OMG DO THIS FOR OPS //decode
Ban evasions will be possible with or without hostmasking; however, a lot of what you mentioned can be mitigated by the fact that a server will know both the real and masked host for a user. This makes it possible for ban list entries (and silence lists, etc) to be easily matched against a user, regardless of whether a user has enabled/disabled hostmasking and whether the ban is against the user's real or masked host. For example, a ban against *!*@*.aol.com should work even if the user is umode +H and their mask is generated based on their IP address (due to the server being unable to perform a reverse lookup).
I accidentally deleted half of my example, so I'll clarify...
Ban matching should not be problem if the server knows both the real and masked host for the user, regardless of whether the user is actually umode +H or not. For example, a ban against *!*@98a866b7.ipt.aol.com should match userA even if their umode +H and their masked (visible) host is now dalnet-84725.ipt.aol.com. As for ISP wildcard bans no longer matching masked users, this would only be the case if the hash is generated against the user's IP address, which would only happen if the server is unable to perform a reverse lookup on it -- in which case it wouldn't match regardless of hostmasking.
-SecretAgent _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
Err, lemme clarify that a little.
If the user is banned, how do you ban a segment if their ISP? Example, 127-0-0-1.mn.rocks.someisp.net can be banned at a state level, without banning all of someisp.net. Banning all of an ISP isn't usually a wanted thing, but banning regions of an ISP is.
On Tue, Oct 13, 2009 at 10:46 PM, Vin King vin.king@gmail.com wrote:
If the user is masked, how do you ban their ISP?
On Tue, Oct 13, 2009 at 10:42 PM, Jason Hill secrtagnt@gmail.com wrote:
On Tue, Oct 13, 2009 at 9:31 PM, Jason Hill secrtagnt@gmail.com wrote:
On Tue, Oct 13, 2009 at 8:33 PM, Vin King vin.king@gmail.com wrote:
<snip>
The potential from abuse by a vhost is mitigated by wildcarding the ip address, which can't be done with hostmasks.
Additionally, with each hostmask now being independent, wildcard bans
on
ISPs become ineffective, and the current limitations on ban list
lengths
become a major shortfall.
Providing the capability without proper planning into all the affected systems will easily create room for abuse, especially if the system
isn't
properly tested for abuse potential.
Specific examples of how hard it is for your average channel operator
to
keep a determined attacker out of a channel when the IRCD provides the attacker with the ability to change their hostmask can be seen on any network that does provide the address. I know I myself have abused the capabilities of other networks easy enough, so it's not impossible.
I personally don't see how hostmasking provides any end user security,
as
the vast majority of the network users are not dealing with attacks
against
themselves or their connections, and since the vast majority of attacks
on
the network are through query anyways with OMG DO THIS FOR OPS //decode
Ban evasions will be possible with or without hostmasking; however, a lot of what you mentioned can be mitigated by the fact that a server will know both the real and masked host for a user. This makes it possible for ban list entries (and silence lists, etc) to be easily matched against a user, regardless of whether a user has enabled/disabled hostmasking and whether the ban is against the user's real or masked host. For example, a ban against *!*@*.aol.com should work even if the user is umode +H and their mask is generated based on their IP address (due to the server being unable to perform a reverse lookup).
I accidentally deleted half of my example, so I'll clarify...
Ban matching should not be problem if the server knows both the real and masked host for the user, regardless of whether the user is actually umode +H or not. For example, a ban against *!*@98a866b7.ipt.aol.com should match userA even if their umode +H and their masked (visible) host is now dalnet-84725.ipt.aol.com. As for ISP wildcard bans no longer matching masked users, this would only be the case if the hash is generated against the user's IP address, which would only happen if the server is unable to perform a reverse lookup on it -- in which case it wouldn't match regardless of hostmasking.
-SecretAgent _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
Vin King wrote:
Err, lemme clarify that a little.
If the user is banned, how do you ban a segment if their ISP? Example, 127-0-0-1.mn.rocks.someisp.net http://127-0-0-1.mn.rocks.someisp.net can be banned at a state level, without banning all of someisp.net http://someisp.net. Banning all of an ISP isn't usually a wanted thing, but banning regions of an ISP is.
On FreeQuest, we have implemented hostmasking successfully (Bahamut 1.8.x). We mask the first part of the hostname (sometimes the second part as well, IIRC), or if you don't resolve your IP you'll have a long mask ending in .IP.
IRC Operators can still see the users real host, and the ban mechanism takes both into consideration, that is you can ban the users real IP, and if they mask it and try to join again, they're still banned.
A similar implementation shouldn't be too hard for DALnet to implement, since opermasking already is in place.
/Andreas aka ph0x
Hello, I like the idea of hostmasking, however as mentioned in the previous emails, its something that needs planning and to take into consideration many factors, personally I think only +r users deserve +H, since its used for legitimate purposes and in case of abuse would be way easier to control via services (SAbuse will have more work ;))
As Andreas mentioned it, fqircd has implemented it successfully, I've tried it on network some friends and I run without problems at all, works pretty decent, however, needs lots of testing before releasing, so thinking on every kind of abuse are considerations the coders should make.
You always have the option to use hostmasking or not, so whether if you like it or not, you will be able to use it or not. If aint broken dont fix it, well there is something maybe we should take into consideration which is masking the servers as well, from my undernet experience (which is different since you cant register nicknames) the hostmasking just make users go for the servers, so if I want nick X or nick Y what's the easiest way? take down the server.
Now, why do I mention serverhostmasking as well? in many cases, users try to register a channel that just dropped, and yes I know, chanserv kicks everyone after a channel dropped, but this is not working at all, why? I have seen users in #dalnethelp or #operhelp still asking for @ in certain channel to register it, so if they cant take down the users by DDoSing their hosts, they will target the servers they are in to register the channel.
My two cents,
./dros
2009/10/14 Andreas andreas@kolsyrad.net
Vin King wrote:
Err, lemme clarify that a little.
If the user is banned, how do you ban a segment if their ISP? Example, 127-0-0-1.mn.rocks.someisp.net http://127-0-0-1.mn.rocks.someisp.net can be banned at a state level, without banning all of someisp.net < http://someisp.net%3E. Banning all of an ISP isn't usually a wanted thing, but banning regions of an ISP is.
On FreeQuest, we have implemented hostmasking successfully (Bahamut
1.8.x). We mask the first part of the hostname (sometimes the second part as well, IIRC), or if you don't resolve your IP you'll have a long mask ending in .IP.
IRC Operators can still see the users real host, and the ban mechanism takes both into consideration, that is you can ban the users real IP, and if they mask it and try to join again, they're still banned.
A similar implementation shouldn't be too hard for DALnet to implement, since opermasking already is in place.
/Andreas aka ph0x
DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
Isil Drosdow wrote:
I like the idea of hostmasking, however as mentioned in the previous emails, its something that needs planning and to take into consideration many factors, personally I think only +r users deserve +H, since its used for legitimate purposes and in case of abuse would be way easier to control via services (SAbuse will have more work ;))
I disagree for a variety of reasons...but mainly that A: Services does occasionally go down, meaning people wouldn't be +r in some instances, and B: People don't connect as +r, so what's protecting them before they identify? If some abuser is going to target a specific user for ddos, which is, in my mind, what this feature would be all about preventing, it would be too easy to at some point find out their IP. What's the harm in doing +H on connect? There's no additional abuse one can do with it as described on this thread.
The only potential for abuse of hostmasking comes in when you tie it to nick registrations, and people start registering things like IAmTheBest.user.dalnet just to be cute, or other things to evade bans.
fix it, well there is something maybe we should take into consideration which is masking the servers as well, from my undernet experience (which is different since you cant register nicknames) the hostmasking just make users go for the servers, so if I want nick X or nick Y what's the easiest way? take down the server. Now, why do I mention serverhostmasking as well? in many cases, users try to register a channel that just dropped, and yes I know, chanserv kicks everyone after a channel dropped, but this is not working at all, why? I have seen users in #dalnethelp or #operhelp still asking for @ in certain channel to register it, so if they cant take down the users by DDoSing their hosts, they will target the servers they are in to register the channel.
Good point! And server masking is already in bahamut, just mostly unused on DALnet. -Brandon
On Tue, Oct 13, 2009 at 9:46 PM, Vin King vin.king@gmail.com wrote:
If the user is masked, how do you ban their ISP?
If I can make some suggestions: an implementation can address the matter of banning by isp, using piecewise hashing; don't just hash the entire address in one go, include multiple discrete hashes of different pices in the mask, so that banning certain segments of the hostname still works (when possible).
Some additional tools may be useful to deal with masking. Even the best efforts cannot make masking have zero effect on management of large channels. Large channels with persistent evaders may have troubles; one of the tradeoffs of masking, is channel ban management is harder.
Additional channel management tools may be warranted, alongside masking, to help put operators back in control over their channel memberships.
I suggest a channel mode should be provided to block all masked users joining, as a last resort, to offer an option for channels that really need it (the user has to weigh how much they trust the chanops), a channel mode such as "+H" Users that attempt to join receive some message like "masked users aren't allowed, and need either to be invited or use some special command, eg cf. /raw join #channel show-my-info To reveal true mask only to chanops of such channel as a one-time event while joining only (shown in the ":nick!user@host" prefix of their JOIN message).
Alternatively... just block-all masked users, they have to unmask prior to join, and reset it back (if they want to stay masked in general), but that's risky..
Another possibility would be to give channels detailed ban control, such as opting to ban a masked pattern, eg an entire ISP but only _while they are masked_. (so the chanops can pick whether their ban applies always, or _only_ when the subject is currently masked)
Eg. /mode #channel +b $m:<user mask here> where the leading $m, or something similar is a special case to inform banlist processing that this entry only matches a user currently masked.
I refer to such constructs as "ban rules", or "ban types". they simply allow special-purpose bans to share the same list as normal bans.
in any case.. have a ban for say $m:*!*@*.HASH(ISP).COM.hostmask mean ban the entire ISP, but _only_ when users apply masking. It forces them to unmask and join if they wish to participate, then the chanops can set a more exacting ban based on real address, if the person turns out to be the bad seed at that particular isp.
More risky: provide a command that allows any chanop to see the 'masked version' of any real hostname, so they can detect if an unmasked user is the same (as a previously seen masked user), by simply asking what the real hostname would mask to.
Masking IP addresses that do not resolve, and actually providing security is a much harder problem than masking hostnames. Consider that there are only 2^32 IPv4 IP addresses.. for masking to be secure, it should be impossible for an attacker to simply run through all 4 billion addresses and determine the mask values. Given that the attacker is armed with IRCD source code.
For hostnames you can mask piecewise, eg split the tokens and heuristically hash certain ones: Host = X.Y.Z.W.aol.com and mask this to Mask = HASH("X.Y").HASH("Z.W").HASH("AOL" ).COM.HMSK
It's not in all cases necessary to hash all tokens, but there's a danger an unexpected hostname token may contain the user's full IP, if the heuristics are not carefully written to handle such cases. an example would be
blahblah.blah4.city.state.172-16-0-1.blah6-3.someisp.com
For IP addresses (non-resolved IRC users)... it's best if they take a format so that mIRC users banning will do the right thing, eg /ban nick 3., so banning *!*@*.something.ipmask bans a /16, or approximates banning an IP when using /ban, just as if banning the leftmost part of a hostname.
Host = 1.2.3.4 Mask = Hash("4").Hash("3").Hash("2.1").IMSK
So doing a /ban nick 3 bans *!*@*.Hash("2.1").IPMASK,
Well... this is a problem... just compute 256 values, and the attacker can decipher every IP.
Mask = Hash("4.3.2.1") . Hash ("4.3") . Hash("3.2") . Hash ("2.1") . Hash("2")
Well, that's a little better... but still too easy to break, an attacker can just make a table of all 256 * 256 hash values. To mask an IPv4 address (unfortunately), necessary to either truncate [destroy information] or use encryption, to stop such brute force methods.
Encryption means choosing a shared secret key known only to the operational servers participating in the production IRC network. There is a need for permanency of the key (so masks never change), need to be stored in a config file, and agreement of the key, in that two servers with different masking keys can't be linking.
And accidental compromise of the key would be a serious matter, making encrypted mask data insecure.
Hostname piecewise masking doesn't do a good job at hiding common domains, however. I think it's generally good enough -- "Your ISP is AOL" doesn't reveal much.
If really worried about it, you could salt the mask, and again use encryption, use a symmetric cipher to encrypt it in a way that only the servers have the static key to decrypt it (for ban enforcement).
Compute a "salt" for the mask, based on the entire mask, and encrypt the SLD of the domain name using a secret key known to the network. Servers reading a banmask will need to know how to decrypt it (hence a major reason not to use this)
Salt = Hash2("X.Y.Z.AOL.COM") take Mask = Hash("X.Y.Z.AOL").ENCRYPT(SALT+HASH(SALT+"AOL",SomeSecretKey)).COM.HMSK
-- -J
Why? maybe DALnet need for my opinion, dont add this host-masking because i see in other network get problem with bans and abused from the users, maybe need to resolved other problems the first. if DALnet add this recieved a lot of problems for my opinion.Why start with this and the rest not finish.
/Gabo
On Thu, Oct 15, 2009 at 12:25 AM, James Hess mysidia@gmail.com wrote:
On Tue, Oct 13, 2009 at 9:46 PM, Vin King vin.king@gmail.com wrote:
If the user is masked, how do you ban their ISP?
If I can make some suggestions: an implementation can address the matter of banning by isp, using piecewise hashing; don't just hash the entire address in one go, include multiple discrete hashes of different pices in the mask, so that banning certain segments of the hostname still works (when possible).
Some additional tools may be useful to deal with masking. Even the best efforts cannot make masking have zero effect on management of large channels. Large channels with persistent evaders may have troubles; one of the tradeoffs of masking, is channel ban management is harder.
Additional channel management tools may be warranted, alongside masking, to help put operators back in control over their channel memberships.
I suggest a channel mode should be provided to block all masked users joining, as a last resort, to offer an option for channels that really need it (the user has to weigh how much they trust the chanops), a channel mode such as "+H" Users that attempt to join receive some message like "masked users aren't allowed, and need either to be invited or use some special command, eg cf. /raw join #channel show-my-info To reveal true mask only to chanops of such channel as a one-time event while joining only (shown in the ":nick!user@host" prefix of their JOIN message).
Alternatively... just block-all masked users, they have to unmask prior to join, and reset it back (if they want to stay masked in general), but that's risky..
Another possibility would be to give channels detailed ban control, such as opting to ban a masked pattern, eg an entire ISP but only _while they are masked_. (so the chanops can pick whether their ban applies always, or _only_ when the subject is currently masked)
Eg. /mode #channel +b $m:<user mask here> where the leading $m, or something similar is a special case to inform banlist processing that this entry only matches a user currently masked.
I refer to such constructs as "ban rules", or "ban types". they simply allow special-purpose bans to share the same list as normal bans.
in any case.. have a ban for say $m:*!*@*.HASH(ISP).COM.hostmask mean ban the entire ISP, but _only_ when users apply masking. It forces them to unmask and join if they wish to participate, then the chanops can set a more exacting ban based on real address, if the person turns out to be the bad seed at that particular isp.
More risky: provide a command that allows any chanop to see the 'masked version' of any real hostname, so they can detect if an unmasked user is the same (as a previously seen masked user), by simply asking what the real hostname would mask to.
Masking IP addresses that do not resolve, and actually providing security is a much harder problem than masking hostnames. Consider that there are only 2^32 IPv4 IP addresses.. for masking to be secure, it should be impossible for an attacker to simply run through all 4 billion addresses and determine the mask values. Given that the attacker is armed with IRCD source code.
For hostnames you can mask piecewise, eg split the tokens and heuristically hash certain ones: Host = X.Y.Z.W.aol.com http://x.y.z.w.aol.com/ and mask this to Mask = HASH("X.Y").HASH("Z.W").HASH("AOL" ).COM.HMSK
It's not in all cases necessary to hash all tokens, but there's a danger an unexpected hostname token may contain the user's full IP, if the heuristics are not carefully written to handle such cases. an example would be
blahblah.blah4.city.state.172-16-0-1.blah6-3.someisp.com
For IP addresses (non-resolved IRC users)... it's best if they take a format so that mIRC users banning will do the right thing, eg /ban nick 3., so banning *!*@*.something.ipmask bans a /16, or approximates banning an IP when using /ban, just as if banning the leftmost part of a hostname.
Host = 1.2.3.4 Mask = Hash("4").Hash("3").Hash("2.1").IMSKSo doing a /ban nick 3 bans *!*@*.Hash("2.1").IPMASK,
Well... this is a problem... just compute 256 values, and the attacker can decipher every IP.
Mask = Hash("4.3.2.1") . Hash ("4.3") . Hash("3.2") .Hash ("2.1") . Hash("2")
Well, that's a little better... but still too easy to break, an attacker can just make a table of all 256 * 256 hash values. To mask an IPv4 address (unfortunately), necessary to either truncate [destroy information] or use encryption, to stop such brute force methods.
Encryption means choosing a shared secret key known only to the operational servers participating in the production IRC network. There is a need for permanency of the key (so masks never change), need to be stored in a config file, and agreement of the key, in that two servers with different masking keys can't be linking.
And accidental compromise of the key would be a serious matter, making encrypted mask data insecure.
Hostname piecewise masking doesn't do a good job at hiding common domains, however. I think it's generally good enough -- "Your ISP is AOL" doesn't reveal much.
If really worried about it, you could salt the mask, and again use encryption, use a symmetric cipher to encrypt it in a way that only the servers have the static key to decrypt it (for ban enforcement).
Compute a "salt" for the mask, based on the entire mask, and encrypt the SLD of the domain name using a secret key known to the network. Servers reading a banmask will need to know how to decrypt it (hence a major reason not to use this)
Salt = Hash2("X.Y.Z.AOL.COM http://x.y.z.aol.com/") take Mask = Hash("X.Y.Z.AOL").ENCRYPT(SALT+HASH(SALT+"AOL",SomeSecretKey)).COM.HMSK
-- -J _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
Jose Almenara wrote:
Why? maybe DALnet need for my opinion, dont add this host-masking because i see in other network get problem with bans and abused from the users, maybe need to resolved other problems the first. if DALnet add this recieved a lot of problems for my opinion.Why start with this and the rest not finish. /Gabo
Why don't you tell us what problems these other networks have with bans and abuse from users so we'll be prepared for them?
There is not much of a difference for a channel op to ban dalnet-132123.whatever.com than whatever.whatever.com. Sure, a user with a dynamic IP will be able to evade bans by changing their IP but it's not something they can't already do now and banning their IP range will still work.
-Kobi.
On Thu, Oct 15, 2009 at 7:19 PM, Kobi Shmueli kobi@dal.net wrote:
Jose Almenara wrote:
i see in other network get problem with bans and abused from the users, maybe need to resolved other problems the first. if DALnet add this recieved
Why don't you tell us what problems these other networks have with bans and abuse from users so we'll be prepared for them?
In some rare cases, address masking might be used to assist a miscreant in commiting an abuse. They might use address masking to evade client-side /ignore filters. Torment a user while masked, then unmask.
However, my observation, in seeing the networks where masking has been implemented on a certain scale: this is not that common. When masking is enabled by default, especially.
Masking also helps curtail whole family of other types of abuse: attempts to 'hack' other IRC users. For example, attempts to spoof TCP RST packets to disconnect their target from IRC, by convincing either the server that the target closed the connection, or to convince them that the server disconnected them .
Not to mention other abusive activity such as attempts to "hack in" or make an intelligent effort to exploit unique security weaknesses on their PC (or NAT) box's open ports, in response to things said (or actions taken) on IRC
Or crude attempts to directly "flood" a user off IRC, such as by using a simple SYN flood, or other trivial technique that common windows-based desktop OSes and many Broadband "routers" are not equipped to handle.
There are both abuses to other IRC'ers enabled by masking, and abuses enabled by having no masking and making actual IP addresses of IRC'ers public.
A full analysis on the value (worth) VS cost of masking, should in theory include both (abuses possible only with masking, and abuses possible only without masking), at ends of the spectrum, I like to think neither abuse is _extremely_ common, but definitely neither possibilities should be ignored.
-- -J
James Hess wrote:
In some rare cases, address masking might be used to assist a miscreant in commiting an abuse. They might use address masking to evade client-side /ignore filters. Torment a user while masked, then unmask.
This is true.
However, my observation, in seeing the networks where masking has been implemented on a certain scale: this is not that common. When masking is enabled by default, especially.
*nod*, we should make /silence always affect both masked and unmasked hosts, though.
-Kobi.
Also lets not forget the fact that there are currently bnc and psybncs out there which can be used on top of open proxies to do the same job i.e. abuse users using different hostnames/ips/masks. Serverside hostmasking would not make that kind of significant difference in terms of abuse.
Regards, White`Shark.
On Sat, Oct 17, 2009 at 12:50 AM, Kobi Shmueli kobi@dal.net wrote:
James Hess wrote:
In some rare cases, address masking might be used to assist a miscreant in commiting an abuse. They might use address masking to evade client-side /ignore filters. Torment a user while masked, then unmask.
This is true.
However, my observation, in seeing the networks where masking has
been implemented on a certain scale: this is not that common. When masking is enabled by default, especially.
*nod*, we should make /silence always affect both masked and unmasked hosts, though.
-Kobi. _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
On Tue, Oct 13, 2009 at 8:43 PM, Vin King vin.king@gmail.com wrote:
DALnet has successfully done no hostmasking for over a decade, so if it ain't broke, don't fix it, in my opinion. Client side ssl, though, I feel is a reasonable enhancement request. What with more places offering wifi, and internet options on the go these days, I feel a more secure client to server communication is higher priority than hostmask offerings.
If it doesn't exhibit problems, don't assume it's not broke. Something's broke, but it's not the code. I have no opinions on hostmasks. I have used and continue to use networks with and without it. However, many users prefer networks with hostmasking. I've not yet found a single person who would refuse to use a network because it did have masking.
On top of the SSL, I do think services should use some kind of OTP system, since many public internet places have keyloggers.
On Tue, Oct 13, 2009 at 9:07 PM, Aaron Wiebe epiphani@gmail.com wrote:
Client-side SSL is already merged into my tree and being actively tested. It will be in the next minor release.
Could you do a format-patch -M -C --stdout between b5113839c45b00acde70b9db2850fec5d00e7d43 and your HEAD, and shoot a copy my way?
On Tue, Oct 13, 2009 at 8:33 PM, Michael Reynolds michael.reynolds@gmail.com wrote:
For that matter, let's throw in client SSL. I don't want to hear the excuse that it uses too much load. A Gentoo box powered by a Dell 2950 with an Intel PT 1000 can handle over 100 million SSL connection setups and takedowns in a day, with a load average of 0, and this is without hardware acceleration.
Client-side SSL is already merged into my tree and being actively tested. It will be in the next minor release.
-epi
On Tue, Oct 13, 2009 at 6:55 PM, Vin King vin.king@gmail.com wrote:
BUT, if we WERE to mask, I'd go with a static hash of the address shared among servers. Connecting server hashes it, passes it as the hostmask to all other servers. [...]
My suggestion would be to use a deterministic algorithm to compute the mask, based on hostname.
Instead of passing around an extra mask between servers, all servers understand and use the same algorithm used to perform the masking (so all servers agree on mask), and present the hashed mask without need to store additional data explicitly (except they may cache for performance reasons).
However, if a need arises to change the algorithm used to calculate the masks, any change in the computed mask breaks compatibility. -
But it has the advantage that, since a deterministic algorithm is used: it is possible to enforce channel bans against masked users.
Especially important if users are allowed to disable masking (if they disable masking, it is necessary to still match the masked version of their hostname against channel bans, OR they can use unmasking as an evasion tool).
Effective ban checking is done either by testing both the user's real address, and the masked version of their address against all channel bans, and /silence entires.
OR providing some method of annotating or analyzing banlist entries, in IsBanned, so as to determine whether a REAL host or a MASK host is referenced in the ban... and always attempting to match the right version of the user's hostname against each banlist entry.
-- -J
Speaking only for myself, not any particular group...
I've never really been happy with any of the hostmasking implementations I've seen so far. They all seem to have flaws in either mask effectiveness or usability.
Hosts as used on IRC have a few useful properties. For one thing, they are set at connect and do not change; a client always has the same host for as long as it's online. This is a pretty fundamental assumption that makes everything from pretty client displays to access lists and scripting work. Another property is that hosts have a hierarchy, where certain parts may change for dynamically-assigned addresses while other parts remain static based on ISP or geographical location; this of course is what makes wildcard masks in access lists etc work.
One usability flaw in most hostmasking implementations then is assigning it to a usermode. This means from the perspective of the client itself, its host on IRC is not static, as the mode (and thus its host) can be changed at any time. This breaks the assumption above and affects things as basic as automatic line breaks in channel or private message text. (A client that knows its own host length can calculate the maximum length of message text it can send before one server along the chain will truncate it, and can do its own line splitting to compensate.)
It also affects other clients, as things like bot access lists and channel bans no longer apply properly, WATCH/MONITOR-generated notifications might not be correct for subscribing clients, etc. The most common workaround to this is for each server to fake quit/ reconnect the mask-changing client for the benefit of other clients, but whether they internally reevaluate channel bans or deal with WATCH etc appropriately is of course an open question. It's a rather fragile and kludgy practice.
The proper way to handle masking is to do it on connect, and not allow the masked status to change during the session.
I'll assume the goal of hostmasking is to replace the IRC-visible host with one that does not indicate the actual host the client is connecting from.
Hash-based hostmasking, being derived from the client's actual host and therefore anonymous, usually has the secondary goal of maintaining at least a partial hierarchy. This allows channel bans and bot access lists to still cover a group of clients by ISP or region.
I often see such masking implemented as hashing hostnames first. As pointed out by others, this is problematic because hostnames vary in the number of components and amount of information available in each component. What happens is that either not enough of the real host is hidden (so masking fails), or not enough of the hierarchy is preserved (so the secondary goal is not met).
10.1.2.3.city.state.isp.tld -> mask.1.2.3.city.state.isp.tld 10.1.2.3.city.state.isp.tld -> mask.isp.tld
Hashing unresolved IP addresses is more useful due to the relative stability in number of components and amount of information revealed by each one. This is also a more important area to focus on because the effectiveness of a hash-based mask is decided here.
Because the identifier space of an IPv4 address is so small in number- crunching terms, a fixed hash algorithm is easily applied in a brute- force manner to find the real host for a masked host (again mentioned by others). Fixed hash algorithms therefore do not meet the goal of hostmasking.
The logical change is to use an algorithm that incorporates a secret known only to the server, which artificially increases the identifier space of the real host. This can entirely avoid the simple brute-force attack if properly implemented. (That last point is worth emphasizing, as I've obtained the secrets of more than one server simply by analyzing known masked hosts, because they used flawed algorithms.)
However, there remains an issue with the secondary goal of maintaining a hierarchy: a mapping attack. A fundamental property of a hierarchical host is that parts of it remain static based on ISP or region. This means that for a hierarchical mask, parts of the mask remain the same, and so obtaining only one real host in the region effectively breaks part of the mask for all hosts in the same region.
5342.8743.2357.9026 -> 10.1.2.3 5342.8743.2357.1824 -> 10.1.2.something
One counter-proposal to this is to periodically change keys, but that is simply a less-effective way of not having a hierarchy at all, as the fundamental property of portions being static is voilated.
I'm not aware of any hash-based system that actually achieves the basic goal of hostmasking while still preserving hierarchy. It is an insecure combination by nature.
Masks based on centrally-assigned identifiers are much more effective, since they cannot reveal part of the real host if they are not based on it. The most common implementation of this is on networks that register user accounts (instead of nicknames), where the user account name becomes the identifying part of the masked hostname.
Since DALnet registers nicknames instead of user accounts, this approach doesn't seem directly useful. As mentioned by others, there are issues with simply changing nicks or identifying to different ones during a session, but there is also the point that nicknames can contain characters that are not appropriate for hostnames. Networks with user account registration typically only allow hostname- appropriate characters in account names.
Perhaps this could be applied to DALnet by using a unique identifier mapped to email address instead. (*Not* a hash based on the actual address, just an identifier assigned internally.) While making the resulting hosts not as aesthetically pleasing, it sidesteps the valid character issue, and should narrow the abuse window to the same size as networks using user account registration (as they usually limit number of registrations per email address).
Of course, most implementations of this tend to have two usability flaws: one being that masking is modifiable during the session; the other being that first a connection and then a roundtrip authentication to services is required before masking can be done at all. The result is that while the end mask is quite effective, there is a large window at the beginning of a session where it is entirely ineffective, and things like WATCH are left completely unprotected.
Again, the proper way to handle masking is to do it immediately at the start of a session. Connecting clients give the server a nickname, a username, and optionally a password, so the information necessary to make the decision is already present from the client side.
Another issue is that if masking is optional, then most people consider it desirable for server-side access lists (channel bans, SILENCE, etc) that contain entries based on real hosts to match even if a client is masked. However, that means those lists themselves can be used to perform mapping attacks, e.g. by CTCP PINGing a client repeatedly while modifying your own SILENCE list to see which address components block the response. Note that this works in real time regardless of the masking algorithm used.
A logical way to avoid this is to make hostmasking non-optional and forget about real hosts entirely.
-- Quension
On Tue, Oct 20, 2009 at 6:09 AM, Trevor Talbot quension@mac.com wrote:
Speaking only for myself, not any particular group...
I've never really been happy with any of the hostmasking implementations I've seen so far. They all seem to have flaws in either mask effectiveness or usability.
Hosts as used on IRC have a few useful properties. For one thing, they are set at connect and do not change; a client always has the same host for as long as it's online. This is a pretty fundamental assumption that makes everything from pretty client displays to access lists and scripting work.
I'm going to use UnrealIRCd as a base of comparison here, since it is currently the third oldest IRCd I'm aware of (beaten by hybrid and u), which has successfully deployed hostmasking across what was once a userbase of millions (hey, IRC is dying). It is the only IRCd capable of boasting this.
Another property is that hosts have a hierarchy, where certain parts may change for dynamically-assigned addresses while other parts remain static based on ISP or geographical location; this of course is what makes wildcard masks in access lists etc work.
This remains present in masked hosts on Unreal.
One usability flaw in most hostmasking implementations then is assigning it to a usermode. This means from the perspective of the client itself, its host on IRC is not static, as the mode (and thus its host) can be changed at any time. This breaks the assumption above and affects things as basic as automatic line breaks in channel or private message text. (A client that knows its own host length can calculate the maximum length of message text it can send before one server along the chain will truncate it, and can do its own line splitting to compensate.)
Using the hostname as part of the message length really is a design flaw. The message from the client never includes their own host.
It also affects other clients, as things like bot access lists and channel bans no longer apply properly, WATCH/MONITOR-generated notifications might not be correct for subscribing clients, etc. The most common workaround to this is for each server to fake quit/reconnect the mask-changing client for the benefit of other clients, but whether they internally reevaluate channel bans or deal with WATCH etc appropriately is of course an open question. It's a rather fragile and kludgy practice.
It's rather a successfully implemented practice. As you say, they simulate rejoin/reconnect to update other clients. Ban/watch/etc lists do not need reevaluated as they're checked against the masked and unmasked entry, neither of which change, unless some fruity oper gives the user a custom vhost (which isn't really covered in the realm of hostmasks).
The proper way to handle masking is to do it on connect, and not allow the masked status to change during the session.
Proper according to who?
I'll assume the goal of hostmasking is to replace the IRC-visible host with one that does not indicate the actual host the client is connecting from.
This is correct. I, for one, don't want people knowing where I'm from, which ISP I use, etc. Using my real IP address, it is possible for someone to locate me in the real world. (Think really tiny town with only one cable modem user)
Hash-based hostmasking, being derived from the client's actual host and therefore anonymous, usually has the secondary goal of maintaining at least a partial hierarchy. This allows channel bans and bot access lists to still cover a group of clients by ISP or region.
No disagreement there.
I often see such masking implemented as hashing hostnames first. As pointed out by others, this is problematic because hostnames vary in the number of components and amount of information available in each component. What happens is that either not enough of the real host is hidden (so masking fails), or not enough of the hierarchy is preserved (so the secondary goal is not met).
10.1.2.3.city.state.isp.tld -> mask.1.2.3.city.state.isp.tld 10.1.2.3.city.state.isp.tld -> mask.isp.tld
Haven't really used Unreal as an admin, but if I read correctly, it would convert 10.2.3.4.city.state.isp.tld to mask.city.state.isp.tld. Essentially chops off everything up until it has a dot followed by a letter.
<snipping most of your comments on IP hashing since it is mostly agreeable>
However, there remains an issue with the secondary goal of maintaining a hierarchy: a mapping attack. A fundamental property of a hierarchical host is that parts of it remain static based on ISP or region. This means that for a hierarchical mask, parts of the mask remain the same, and so obtaining only one real host in the region effectively breaks part of the mask for all hosts in the same region.
5342.8743.2357.9026 -> 10.1.2.3 5342.8743.2357.1824 -> 10.1.2.something
UnrealIRCd uses a system of 3 hashes, followed by '.IP', to make it appear as a hostname to clients. Thus, it reverses the hierarchy. A hashed IP becomes dddd.cccc.bbbb.IP. The whole thing is unique per IP. *.cccc.bbbb.IP is unique per /24, etc. Assuming the hashing algorithm doesn't suck, you'd need to trick a user in the same /24 to reveal their IP to be able to do anything about other users in the same block.
<more things I agree with snipped>
I'm not aware of any hash-based system that actually achieves the basic goal of hostmasking while still preserving hierarchy. It is an insecure combination by nature.
See above.
Masks based on centrally-assigned identifiers are much more effective, since they cannot reveal part of the real host if they are not based on it. The most common implementation of this is on networks that register user accounts (instead of nicknames), where the user account name becomes the identifying part of the masked hostname.
This becomes a hassle to users who just want to cover their ass. They should not have to waste time identifying on each connect, just to hide their host.
Perhaps this could be applied to DALnet by using a unique identifier mapped to email address instead. (*Not* a hash based on the actual address, just an identifier assigned internally.) While making the resulting hosts not as aesthetically pleasing, it sidesteps the valid character issue, and should narrow the abuse window to the same size as networks using user account registration (as they usually limit number of registrations per email address).
Not sure what you're saying here, but if I'm correct in assuming you'd like to include the local part of an email address, do take note that every character is valid in an email address, except NUL.
Another issue is that if masking is optional, then most people consider it desirable for server-side access lists (channel bans, SILENCE, etc) that contain entries based on real hosts to match even if a client is masked. However, that means those lists themselves can be used to perform mapping attacks, e.g. by CTCP PINGing a client repeatedly while modifying your own SILENCE list to see which address components block the response. Note that this works in real time regardless of the masking algorithm used.
This only works if you have enough of the hostmask to begin with. For example, network-deadbeef.hsd1.mi.comcast.net covers over 1 million IPs scattered in an accumulative block of tens of millions. The client would know something's up long before you even got the right /16.
A logical way to avoid this is to make hostmasking non-optional and forget about real hosts entirely.
And here I would have to wholeheartedly disagree wrt needing to forget real hosts. It's a feature that has been refined over the course of a decade, with constant development and testing. Oh, and it works.
-- Quension
On Oct 20, 2009, at 6:09 AM, Michael Reynolds wrote:
One usability flaw in most hostmasking implementations then is assigning it to a usermode. This means from the perspective of the client itself, its host on IRC is not static, as the mode (and thus its host) can be changed at any time. This breaks the assumption above and affects things as basic as automatic line breaks in channel or private message text. (A client that knows its own host length can calculate the maximum length of message text it can send before one server along the chain will truncate it, and can do its own line splitting to compensate.)
Using the hostname as part of the message length really is a design flaw. The message from the client never includes their own host.
If it were done again today I'd consider the statelessness that requires sending hostnames to be a flaw, but the issue with message length is more a consequence of a series of organic choices driven by constraints at the time. IRC message length was set before hosts were added, and the client and server software ran from the same codebase where prefixes were assumed.
Message length estimation isn't the only thing affected by a modern stateful client having its own host changed underneath it, though. As a random example, consider those old-school scripts that automatically remove bans placed against yourself.
It also affects other clients, as things like bot access lists and channel bans no longer apply properly, WATCH/MONITOR-generated notifications might not be correct for subscribing clients, etc. The most common workaround to this is for each server to fake quit/ reconnect the mask-changing client for the benefit of other clients, but whether they internally reevaluate channel bans or deal with WATCH etc appropriately is of course an open question. It's a rather fragile and kludgy practice.
It's rather a successfully implemented practice. As you say, they simulate rejoin/reconnect to update other clients. Ban/watch/etc lists do not need reevaluated as they're checked against the masked and unmasked entry, neither of which change, unless some fruity oper gives the user a custom vhost (which isn't really covered in the realm of hostmasks).
Note that that assumes the server is aware of what the mask will be ahead of time, which is still a problem for most registration-based masking implementations.
The proper way to handle masking is to do it on connect, and not allow the masked status to change during the session.
Proper according to who?
I admit personal bias, but it's based on several perspectives, including historical discussion by others. That is the only way I'm aware of to maintain the properties assumed by both server UI and clients of various ages. The assumption that a host does not change was embedded in IRC behavior when hosts were added. It's visible in the way server-side things like channel bans are handled, how stateful clients gather and apply information during a session, and even in relatively recent server-assisted state extensions like UHNAMES.
I:line-style masking and bahamut's own oper hostmasking work this way, and as a result need no special treatment by servers or clients.
However, there remains an issue with the secondary goal of maintaining a hierarchy: a mapping attack. A fundamental property of a hierarchical host is that parts of it remain static based on ISP or region. This means that for a hierarchical mask, parts of the mask remain the same, and so obtaining only one real host in the region effectively breaks part of the mask for all hosts in the same region.
5342.8743.2357.9026 -> 10.1.2.3 5342.8743.2357.1824 -> 10.1.2.something
UnrealIRCd uses a system of 3 hashes, followed by '.IP', to make it appear as a hostname to clients. Thus, it reverses the hierarchy. A hashed IP becomes dddd.cccc.bbbb.IP. The whole thing is unique per IP. *.cccc.bbbb.IP is unique per /24, etc. Assuming the hashing algorithm doesn't suck, you'd need to trick a user in the same /24 to reveal their IP to be able to do anything about other users in the same block.
I did have that implementation in mind, but acquiring partial masks for most popular regions is not terribly difficult for someone with enough time. Certain botnet runners tend to deal in information, and this is trivial information to gather. There are also the usual suspects like open proxy lists, along with more focused attacks using host information gathered from other online services, or social engineering like an accepted DCC request or a visit to a web site where the attacker reads the access logs.
Masks based on centrally-assigned identifiers are much more effective, since they cannot reveal part of the real host if they are not based on it. The most common implementation of this is on networks that register user accounts (instead of nicknames), where the user account name becomes the identifying part of the masked hostname.
This becomes a hassle to users who just want to cover their ass. They should not have to waste time identifying on each connect, just to hide their host.
Which is one reason I harp on about usability issues with the identification mechanisms commonly used. Most clients are fully capable of supplying authentication information automatically when they connect, but there are very few server implementations that actually do something with it.
So far the only viable alternative I've seen to registration hassle is the hash-based hierarchical scheme that can't actually guarantee the protection it claims to provide. Which is worse, some hassle and a masking implementation that actually hides the real host, or no hassle and a masking implementation that provides a false sense of security?
These options are not mutually exclusive; DALnet caters to a significant userbase that doesn't register nicknames anyway. If long- term stability is provided by registration-based masking, it might be acceptable to weaken the hierarchical properties of anonymous hash- based masking in favor of increasing attack difficulty. At that point users would have a choice.
Perhaps this could be applied to DALnet by using a unique identifier mapped to email address instead. (*Not* a hash based on the actual address, just an identifier assigned internally.) While making the resulting hosts not as aesthetically pleasing, it sidesteps the valid character issue, and should narrow the abuse window to the same size as networks using user account registration (as they usually limit number of registrations per email address).
Not sure what you're saying here, but if I'm correct in assuming you'd like to include the local part of an email address, do take note that every character is valid in an email address, except NUL.
I was envisioning something like A5432D42F768.masked.user, where the identifier is meaningless, just constant for a particular email address. It's a rough approximation to a "user account" using the existing information on DALnet.
Another issue is that if masking is optional, then most people consider it desirable for server-side access lists (channel bans, SILENCE, etc) that contain entries based on real hosts to match even if a client is masked. However, that means those lists themselves can be used to perform mapping attacks, e.g. by CTCP PINGing a client repeatedly while modifying your own SILENCE list to see which address components block the response. Note that this works in real time regardless of the masking algorithm used.
This only works if you have enough of the hostmask to begin with. For example, network-deadbeef.hsd1.mi.comcast.net covers over 1 million IPs scattered in an accumulative block of tens of millions. The client would know something's up long before you even got the right /16.
As mentioned above, there are already ways of narrowing it ahead of time. For popular regions, it's also easy to find enough online clients to distribute a mapping attack up to the last component.
The problem with the mapping attack is that time is on the attacker's side.
A logical way to avoid this is to make hostmasking non-optional and forget about real hosts entirely.
And here I would have to wholeheartedly disagree wrt needing to forget real hosts. It's a feature that has been refined over the course of a decade, with constant development and testing. Oh, and it works.
But what function do real hosts serve in an environment that encourages hiding them?
-- Quension
I wrote:
On Oct 20, 2009, at 6:09 AM, Michael Reynolds wrote:
This only works if you have enough of the hostmask to begin with. For example, network-deadbeef.hsd1.mi.comcast.net covers over 1 million IPs scattered in an accumulative block of tens of millions. The client would know something's up long before you even got the right /16.
As mentioned above, there are already ways of narrowing it ahead of time. For popular regions, it's also easy to find enough online clients to distribute a mapping attack up to the last component.
Sorry, wrong context/response pair. I meant to say that you're right for that particular example of a masked hostname, but it doesn't apply across the board to all other hostnames or situations where a IP-
hostname lookup fails. Providing effective masking for only a lucky
few isn't really a selling point.
Your example does emphasize the ever-present issue with hierarchy, though; IP addresses just don't express that region.
-- Quension
The best reason to use a user mode, is that it is a well-understood interface, that IRC users know about. It is the conventional way, that most IRC servers use to control options such as address masking, invisibility, etc.
There is a motivation to have consistency, and certainly it is easier for the user to control if a disconnect/reconnect cycle is not required to change host options.
On Wed, Oct 21, 2009 at 12:07 AM, Trevor Talbot quension@mac.com wrote:
example, consider those old-school scripts that automatically remove bans placed against yourself.
I'm not sure it's a good example. The user of that script has the option to forego masking in favor of continuing to use that particular script.
The scripts would need to be made aware of masking to succeed properly. In such a scenario, the ones that couldn't would be obsolete. Just like such an old-school script designed for an IRC environment with no channel services would be unable to detect and delete a ChanServ AKICK.
The script would fail if any ban for the unmasked version of a masked user's host would still be enforced (even while they are masked), in any event (as it should be).
ages. The assumption that a host does not change was embedded in IRC behavior when hosts were added. It's visible in the way server-side things like channel bans are handled, how stateful clients gather and apply
I don't believe anything major breaks too badly when masking is implemented in violation of those assumptions that doesn't also break when those assumptions are preserved.
IRC clients in general do not keep long term record of channel member list information. Some cache it to varying extents. Some do keep the information. Someone's assumptions will be violated, no question.
Most of them constantly update any cached userlist information, especially when a new message is received from a user, with a different hostname in the message prefix.
A masked user failing to match an old bot's access list is a consideration, but with a usermode, the effected user may temporarily resume their real hostname, for a long enough duration to update their access list to grant a suitable masked version access.
I don't think the ill effects of violation of the assumptions are worth imposing unusual or excessively inconvenient kludges, such as a requirement to pre-authenticate for masking, or to reconnect to change address masking status.
Other IRCD implementations have implemented masking without preserving those arbitrarily assumptions: if there were major issues in their experience, that would be one thing.
So far the justification for preserving these assumptions at the cost of some increased complexity seems pretty questionable...
A user negatively impacting themself by enabling masking is basically a non-issue, as long as it is an explained caveat, that is understood before masking begins to be used...
What should be avoided is a user's choice to enable masking negatively impacting _other_ users.
-- -J
On Oct 20, 2009, at 11:02 PM, James Hess wrote:
On Wed, Oct 21, 2009 at 12:07 AM, Trevor Talbot quension@mac.com wrote:
example, consider those old-school scripts that automatically remove bans placed against yourself.
I'm not sure it's a good example. The user of that script has the option to forego masking in favor of continuing to use that particular script.
It's not a particularly good example on its own, no, but it does demonstrate that the issue affects not just server and client implementers, or even script writers, but end users as well.
ages. The assumption that a host does not change was embedded in IRC behavior when hosts were added. It's visible in the way server- side things like channel bans are handled, how stateful clients gather and apply
I don't believe anything major breaks too badly when masking is implemented in violation of those assumptions that doesn't also break when those assumptions are preserved.
IRC clients in general do not keep long term record of channel member list information. Some cache it to varying extents. Some do keep the information. Someone's assumptions will be violated, no question.
I agree, and it's fairly obvious by the number of popular hostmasking implementations out there that everyone involved has dealt with the small issues in some way and that nothing major is left. My point is that changing such an assumption causes small issues in a very widespread area; servers have to create workarounds specifically to keep clients happy, modern clients have to create workarounds for state management purposes, and script writers have to be aware of the trouble clients are having with state and deal accordingly. End users get stuck with the fallout.
That's a sign of a badly implemented feature. (Or a badly designed protocol, but we've had that discussion before...)
I respect the people implementing hostmasking; it is, after all, an organically grown feature like the rest of IRC. However, like most network services, most implementations appear to be bolted on rather than integrated as much as possible, and so I am not happy with them. With the experience learned from those implementations it should be possible to do better.
So far the justification for preserving these assumptions at the cost of some increased complexity seems pretty questionable...
Why is the ability to opt out of hostmasking in realtime considered so desirable that it is worth the violation of the host-immutability assumption and all of the associated ill effects?
-- Quension
On Wed, Oct 21, 2009 at 3:53 AM, Trevor Talbot quension@mac.com wrote:
Why is the ability to opt out of hostmasking in realtime considered so desirable that it is worth the violation of the host-immutability assumption and all of the associated ill effects?
To be perfectly blunt, users don't really care about standards and protocols. What they care about is hiding their host, and the amount of work necessary to accomplish that goal. Undernet and Quakenet gets away with registration based via redundant services.
On Oct 21, 2009, at 10:06 AM, Michael Reynolds wrote:
On Wed, Oct 21, 2009 at 3:53 AM, Trevor Talbot quension@mac.com wrote:
Why is the ability to opt out of hostmasking in realtime considered so desirable that it is worth the violation of the host- immutability assumption and all of the associated ill effects?
To be perfectly blunt, users don't really care about standards and protocols. What they care about is hiding their host, and the amount of work necessary to accomplish that goal. Undernet and Quakenet gets away with registration based via redundant services.
That's not what I was getting at.
In many of the comments in this thread, I'm seeing the idea that: A) users want the ability to *avoid* hostmasking B) it is important that they toggle it in realtime, without disconnecting
I'm asking why users want to avoid hostmasking, why it is important that it happen in real time, and why this is so useful that it outweighs the disadvantages of supporting it.
If toggling hostmasking in realtime is not required, then servers do not need to implement quit/reconnect simulations and other workarounds, and various small problems do not ripple out to annoy client maintainers, script writers and end users.
If disabling hostmasking is not required, then servers do not need to implement matching for real hosts, basic users never have to question whether they are protected, technically minded users don't have the mental baggage of a parallel host namespace they may or may not see, and channel ops and harassment victims don't have to deal with Yet Another Way abusers can evade their bans and ignores, however rare it may be.
Applying non-optional fixed hostmasking on connect seems to reduce complexity across the board. What are the advantages to increasing it?
-- Quension
There may be a compromise that bahamut almost has implemented already. We could use the oper port method to create a port that masks connections that come through it, and have our standard connection system that functions as is. Once the host has been processed during the connection, everything ends up the same from there. If someone wants to remove their hostmask, they could go through the process of disconnection/reconnection without it having to be coded for.
They want hostmasking? Connect on 6667 They don't? Connect on 7000
It may be a way to implement the feature with the least amount of possibilities of abuse, or other failures.
On Wed, Oct 21, 2009 at 6:13 PM, Trevor Talbot quension@mac.com wrote:
On Oct 21, 2009, at 10:06 AM, Michael Reynolds wrote:
On Wed, Oct 21, 2009 at 3:53 AM, Trevor Talbot quension@mac.com wrote:
Why is the ability to opt out of hostmasking in realtime considered so desirable that it is worth the violation of the host-immutability assumption and all of the associated ill effects?
To be perfectly blunt, users don't really care about standards and protocols. What they care about is hiding their host, and the amount of work necessary to accomplish that goal. Undernet and Quakenet gets away with registration based via redundant services.
That's not what I was getting at.
In many of the comments in this thread, I'm seeing the idea that: A) users want the ability to *avoid* hostmasking B) it is important that they toggle it in realtime, without disconnecting
I'm asking why users want to avoid hostmasking, why it is important that it happen in real time, and why this is so useful that it outweighs the disadvantages of supporting it.
If toggling hostmasking in realtime is not required, then servers do not need to implement quit/reconnect simulations and other workarounds, and various small problems do not ripple out to annoy client maintainers, script writers and end users.
If disabling hostmasking is not required, then servers do not need to implement matching for real hosts, basic users never have to question whether they are protected, technically minded users don't have the mental baggage of a parallel host namespace they may or may not see, and channel ops and harassment victims don't have to deal with Yet Another Way abusers can evade their bans and ignores, however rare it may be.
Applying non-optional fixed hostmasking on connect seems to reduce complexity across the board. What are the advantages to increasing it?
-- Quension
DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
On Wed, Oct 21, 2009 at 6:07 PM, Vin King vin.king@gmail.com wrote:
They want hostmasking? Connect on 6667 They don't? Connect on 7000
It seems a reasonable strategy.. add a an option to indicate masking status for the connection class associated with the I:line however, a standard port number shouldn't be used, otherwise users might activate masking accidentally.
Designate an additional port for all servers to indicate masking preference.
port 6667 outbound is commonly specifically firewalled, even by some ISPs and may be unavailable to significantly many IRC users (mainly because infected PC workstations commonly attempt to use port 6667 to get to botnet control channels). Wouldn't want to deny those people the use of masking.
On the other hand, using a port number to select options like this is not very scalable. It doubles the number of ports required for any port-specific protocols such as SSL.
I don't see running out of IRC port numbers as likely to be an issue, however. As long as masking is the only connect-time option that will ever be controlled by port number, it (should?) be fine
-- -J
Well, I wasn't trying to recommend the exact ports I stated, that was more of a recommendation than an actual port number proposal. As far as port number concerns go, we'd have the standard listening range, two for hostmasking (With/without SSL), and then two for oper hostmasking (With/without SSL). So with hostmasking on a port plus SSL, we'd be adding three new port requirements for the full feature spread, instead of a straight doubling across the board. Three additional ports for a new world of flexibility while connecting isn't that bad, and makes implementation easier and probably less prone to bugs.
On Wed, Oct 21, 2009 at 7:30 PM, James Hess mysidia@gmail.com wrote:
On Wed, Oct 21, 2009 at 6:07 PM, Vin King vin.king@gmail.com wrote:
They want hostmasking? Connect on 6667 They don't? Connect on 7000
It seems a reasonable strategy.. add a an option to indicate masking status for the connection class associated with the I:line however, a standard port number shouldn't be used, otherwise users might activate masking accidentally.
Designate an additional port for all servers to indicate masking preference.
port 6667 outbound is commonly specifically firewalled, even by some ISPs and may be unavailable to significantly many IRC users (mainly because infected PC workstations commonly attempt to use port 6667 to get to botnet control channels). Wouldn't want to deny those people the use of masking.
On the other hand, using a port number to select options like this is not very scalable. It doubles the number of ports required for any port-specific protocols such as SSL.
I don't see running out of IRC port numbers as likely to be an issue, however. As long as masking is the only connect-time option that will ever be controlled by port number, it (should?) be fine
-- -J
If toggling hostmasking in realtime is not required, then servers do not need to implement quit/reconnect simulations and other workarounds, and
I'm saying: implement toggling, but do not fake any quit/reconnects when the "mask" user-mode is toggled. I see simulating "quit/rejoin" as excessive, a bad idea, and not needed, even when toggling is implemented.
The simplest thing to do is to allow toggling, and discard the artificial assumptions you crafted and stated that clients and scripts may make. I'm saying "to hell with their assumptions"; as long as they are not crashing or blowing up, the limited number of users utilizing masking mitigates any effect.
various small problems do not ripple out to annoy client maintainers, script writers and end users.
Well, problems *still* ripple out. There is no such thing rolling out masking as a seamless change, it is inherently a change that will effect users. And if masking is FORCED it will effect MANY all users all at once, instead of just users who are interested in masking, and want to try out a new feature.
It is best to stage changes such as this. Let users who want masking be the only ones to use it at first. At a future version, once users are comfortable with masking, consider making it the default.
If disabling hostmasking is not required, then servers do not need to implement matching for real hosts, basic users never have to question whether they are protected, technically minded users don't have the mental baggage of a parallel host namespace they may or may not see, and channel ops and harassment victims don't have to deal with Yet Another Way abusers can evade their bans and ignores, however rare it may be.
Some people won't want to be masked. Just like some people don't want to be +i. Their friends can't find them with /WHO
Toggling it off/on while on IRC only makes sense, if it is necessary to join channels that reject masked users perhaps.
I see being able to opt out as important. Until users have acclimated to masking, and updated any bot access lists to reflect their masked host, it certainly shouldn't be placed on them by default.
It *WILL* cause immediate issues if forced or made a default. Some users who didn't ask for or want to be masked will be unhappy..
If making masking a non-default prevents that, it is a reasonable tradeoff to allow a reasonable relatively non-disruptive adoption of masking (compared to forcing everyone into it at once).
-- -J
On Wed, Oct 21, 2009 at 6:14 PM, James Hess mysidia@gmail.com wrote:
If toggling hostmasking in realtime is not required, then servers do not need to implement quit/reconnect simulations and other workarounds, and
I'm saying: implement toggling, but do not fake any quit/reconnects when the "mask" user-mode is toggled. I see simulating "quit/rejoin" as excessive, a bad idea, and not needed, even when toggling is implemented.
The simplest thing to do is to allow toggling, and discard the artificial assumptions you crafted and stated that clients and scripts may make. I'm saying "to hell with their assumptions"; as long as they are not crashing or blowing up, the limited number of users utilizing masking mitigates any effect.
How is faking quit/reconnects a bad idea, especially when such an implementation is not even that complex? Making zero assumptions seems worse than at least making some "artificial" assumptions that do actually hold true in some use cases. The reason why such host cycling was added in ircu (and other ircds), for example, is because it has been shown that some clients and scripts assume a user's address can never change without the user quitting and returning. Perhaps that assumption is flawed, but it is what is. At least cycling helps ensure their address lists stayed syncd.
The simplest solution is not always the best or most practical solution.
Intentionally breaking clients and scripts just seems a bad way of going about implementing hostmasking, especially when said clients and scripts will work without problems on most other networks. I'll concede that clients and scripts provide support for the server, and not the other way around, but a lot of ircd developers, including myself, actually do try to keep interoperability between networks with the least amount of work for the client -- especially when something has been accepted as the norm by a vast majority of the community.
-SecretAgent
On Thu, Oct 22, 2009 at 12:41 AM, Jason Hill secrtagnt@gmail.com wrote:
On Wed, Oct 21, 2009 at 6:14 PM, James Hess mysidia@gmail.com wrote: How is faking quit/reconnects a bad idea, especially when such an implementation is not even that complex? Making zero assumptions seems
It does not do anything for assumptions a client makes about its own hostmask. What about IRC clients that resolve their own IP address, and assume the server came to the same conclusion about their hostname?
Faking quits/reconnects generates an excessively wasteful amount of IRC traffic. Consider how many messages would be generated when a user who is joined to and opped on 3 channels turns on masking, and each channel has 25 members.
At a bare minimum, all people joined to the 3 channels will each need to receive 3 messages, a "PART", "JOIN", and "MODE" message. It may also have other unwanted effects, such as triggering other users' ON-JOIN or QUIT scripted actions: e.g, the user may have to re-authenticate to on-channel bots due to the simulated quit, they may lose places in games, etc.
This type of spam is annoying, and 2 or 3 broadcast channel messages for one action is a significant waste, unless it is absolutely essential, it should not be done. IRC is a chatty enough protocol, without coming up with reasons to generate more messages to clients.
worse than at least making some "artificial" assumptions that do actually hold true in some use cases. The reason why such host cycling
"It's dark outside" holds true in some use cases. Some people/devices might have been lead to assume it would always be dark. But that doesn't mean a "sun" can't be introduced without simulating a destruction and instantaneous re-creation of all people on earth.
was added in ircu (and other ircds), for example, is because it has been shown that some clients and scripts assume a user's address can never change without the user quitting and returning. Perhaps that assumption is flawed, but it is what is. At least cycling helps ensure their address lists stayed syncd.
The simple fact is... the _very_ small number of clients and scripts that assume that, can be allowed to keep on their way with their flawwed assumption.
Even when the assumption is wrong.. there can be made to be no impact in almost all cases, the "brokenness" is non-fatal.
Synchronizing wrong data is a non-issue, when the synchronization doesn't even matter. With static masking, which version of a host a script bans or SILENCEs is not an issue.
It basically only leaves hostmask based access lists. Which have another issue.... ( access list entries created before masking existed are now obsolete )
-- -J
James Hess wrote:
it has been shown that some clients and scripts assume a user's address can never change without the user quitting and returning. Perhaps that assumption is flawed, but it is what is. At least cycling helps ensure their address lists stayed syncd.
The simple fact is... the _very_ small number of clients and scripts that assume that, can be allowed to keep on their way with their flawwed assumption.
Even when the assumption is wrong.. there can be made to be no impact in almost all cases, the "brokenness" is non-fatal.
Let's forget about modern stateful clients for a moment, and go back to basics: /ignore. You're suggesting a situation that will result in a user /ignoring someone in a channel, then having unwanted content from them suddenly show up with no indication as to the reason.
/ignore isn't just some feature that came along; it was the result of a need for content control with a minimum of administrative and ethical issues. The problem and various solutions are still debated occasionally, but full hosts and /ignore for host-based wildcard masks (along with channel bans) were added in lockstep by the developers of both the ircd and client at the time. The immutability of hosts during a session on IRC isn't a "flawed assumption" cooked up recently by a handful of people, it is something that was baked into IRC from the beginning, and something that very many implementors have implicitly understood since then.
/ignore is not implemented and used by a "_very_ small number of clients and scripts". End users rely on it not silently failing for inexplicable reasons.
I'm saying "to hell with their assumptions"; as long as they are not crashing or blowing up, the limited number of users utilizing masking mitigates any effect.
Based on what I've seen, hostmasking is considered an almost universally desired feature and is rarely *unused* on networks that offer it as an option. Why do you think it will only be used by a minority? Why do you imply that minority will have no effect on others in the same channels?
And the question remains: what practical use does realtime hostmask toggling actually have?
Some people won't want to be masked.
Just like some people don't want to be +i. Their friends can't find them with /WHO
I believe the usefulness of that of that particular approach was lost to spambots a decade ago; I would be interested in even anecdotal evidence that WHO is used by someone, somewhere to find his or her friends on a regular basis. It is also much less likely to be helpful on networks offering registration systems (like DALnet).
People who don't use +i currently make up less than 0.3% of DALnet's userbase.
It would be interesting to see numbers from networks implementing default-but-optional anonymous hostmasking with a significant userbase.
It *WILL* cause immediate issues if forced or made a default. Some users who didn't ask for or want to be masked will be unhappy..
If making masking a non-default prevents that, it is a reasonable tradeoff to allow a reasonable relatively non- disruptive adoption of masking (compared to forcing everyone into it at once).
That isn't the only part of the tradeoff, as there are long-term disadvantages to making hostmasking optional at all.
The closest thing to a practical reason for making hostmasking optional that I've seen mentioned so far is that it will require people to update various access lists, but this will happen for any client that chooses to use hostmasking anyway. It is also a short-term problem that will only occur during a transition period.
You believe that a minor reduction to disruption in the short term is worth the long-term problems of a complex implementation that is more open to abuse and unhappiness, even if the options that created that complexity are no longer significantly used?
It is best to stage changes such as this. Let users who want masking be the only ones to use it at first. At a future version, once users are comfortable with masking, consider making it the default.
My impression is that a great many users are already comfortable with hostmasking, since it has been available elsewhere for a long time and is apparently being considered here due to user demand. It is known to the majority of people as a security feature, and appears to have rapid adoption wherever it is introduced.
-- Quension
On Fri, Oct 23, 2009 at 3:04 AM, Trevor Talbot quension@mac.com wrote: It's interesting this reference to "modern stateful clients". What 'modern stateful clients'? As far as I know, modern clients do not make assumptions that hostnames are static in a way that leads to any lasting issues with masking, can you show what the exceptions would be, what one or two specific major IRC clients?
Let's forget about modern stateful clients for a moment, and go back to basics: /ignore. You're suggesting a situation that will result in a user /ignoring someone in a channel, then having unwanted content from them suddenly show up with no indication as to the reason.
This is true even if they can only opt out of masking by reconnecting on a different port (or logging off, then back on). Toggling being available or not doesn't hurt or help the situation with /ignore. As long as masking is optional the opt-in can be used to evade ignore.
There are probably no major IRC clients whatsoever that will fail to inspect the hostname in the prefix of a message when implementing the ignore function. It is not as if they will use an old version of the sender's host.
If the target user was masked, and then switched to unmasked, yes, there are two times that /ignore may need to be used.
Often ignore is based on nickname, it is rarer that hostname is used to create an ignore list entry, and it's well within the user's control to create additional ignore list entries if the subject somehow detects that they have been ignored and makes attempts to evade.
Based on what I've seen, hostmasking is considered an almost universally desired feature and is rarely *unused* on networks that offer it as an option. Why do you think it will only be used by a minority? Why do you imply that minority will have no effect on others in the same channels?
I don't think 'almost universally' is true... hostmasking is very commonly desired, however, and widely implemented.
I believe 'toggling' or use of a user-mode to toggle it on, is among the most common methods of user control of masking, most implementations don't make it mandatory. What then makes you suppose pre-masking assumptions are significant?
And the question remains: what practical use does realtime hostmask toggling actually have?
People who don't use +i currently make up less than 0.3% of DALnet's userbase.
Yes, but did they when +i was first being implemented?
Also, it's worth noting that +i (invisibility) wasn't made and hasn't been made mandatory, ever...
That isn't the only part of the tradeoff, as there are long-term disadvantages to making hostmasking optional at all.
The advantages can always be weighed in the long term... a mechanism could be provided for making it mandatory at a later date.
You believe that a minor reduction to disruption in the short term is worth the long-term problems of a complex implementation that is more open to abuse and unhappiness, even if the options that created that complexity are no longer significantly used?
No, i'm saying implementing something as optional at first does not not mean it's set in stone that masking is optional forever.
Make it by default at a time, once users have had an opportunity to acclimate... measure the number of users who turn it off.
When 98% of people are not disabling default masking, make it mandatory at that time.
My impression is that a great many users are already comfortable with hostmasking, since it has been available elsewhere for a long time and is apparently being considered here due to user demand. It is known to the
They may be familiar with the idea of hostmasking in general, but I expect there to be difficulities.
There is no standard implementation of hostmasking, as a result, especially with non-static or "registered" masks, it may work in a way that users are not familiar with.
-- -J
On Oct 23, 2009, at 6:10 AM, James Hess wrote:
On Fri, Oct 23, 2009 at 3:04 AM, Trevor Talbot quension@mac.com wrote: It's interesting this reference to "modern stateful clients". What 'modern stateful clients'?
Basically, any client that follows the spirit of IRC by translating, automating and otherwise turning the low-level interactions with the server into something as user-friendly as possible. Most mainstream clients maintained today keep significant amounts of state: modes, clients in a channel, current topic, channel types, mode types, ban lists, maximum length of available identifiers, online status of other users, etc. Much of 005 is dedicated to helping clients maintain state information about both their own sessions and those of other clients.
As far as I know, modern clients do not make assumptions that hostnames are static in a way that leads to any lasting issues with masking, can you show what the exceptions would be, what one or two specific major IRC clients?
One example is commonly implemented forms of flood detection. Eggdrop's sentinel.tcl, among others, uses a host-based hashtable to detect and respond to certain types of clones. If a client's host can silently change, that mechanism breaks.
Let's forget about modern stateful clients for a moment, and go back to basics: /ignore. You're suggesting a situation that will result in a user /ignoring someone in a channel, then having unwanted content from them suddenly show up with no indication as to the reason.
This is true even if they can only opt out of masking by reconnecting on a different port (or logging off, then back on).
You missed the qualifier, "with no indication". If a client quits, parts, or otherwise changes its presence in the channel and vanishes from view, the user is notified that something has changed and it might not be ignored anymore when it returns. If any client can change its host without notification, the user sees an unreliable and broken feature instead.
Based on what I've seen, hostmasking is considered an almost universally desired feature and is rarely *unused* on networks that offer it as an option. Why do you think it will only be used by a minority? Why do you imply that minority will have no effect on others in the same channels?
I don't think 'almost universally' is true... hostmasking is very commonly desired, however, and widely implemented.
I believe 'toggling' or use of a user-mode to toggle it on, is among the most common methods of user control of masking, most implementations don't make it mandatory. What then makes you suppose pre-masking assumptions are significant?
I agree it is the most common method of user control, but I am challenging the implicit assumption that it is even a *good* method of providing masking, let alone the best compromise currently available for most uses.
I'm not certain of your question. If you're asking why I think assumptions made before hostmasking existed are relevant, then my answer would be that various disadvantages exposed by implementations of masking that violate those assumptions continue to affect users today, despite having many years to work out solutions.
Several networks that implement realtime mask toggling have found it necessary to also provide quit/reconnect simulation, which is a strong indicator that the assumption of a hostname not silently changing is significant.
The problem of optional hostmasking making it more difficult to maintain client-side access controls (like /ignore or bot lists), and in some cases server-side access controls as well, continues to hassle users without any similar workaround. Again, evidence that an assumption that there are not parallel artificial host namespaces is still relevant today.
If you're asking why I think predictions about how masking would be used on DALnet are relevant, then my answer would be similar in that there is sufficient evidence available from other networks to make an educated guess.
People who don't use +i currently make up less than 0.3% of DALnet's userbase.
Yes, but did they when +i was first being implemented?
Spambots weren't an issue when +i was first implemented; it was solely a privacy feature. I do take your point that there was a gradual shift in use at that time, since people were used to not having it. I believe that shift is both greatly accelerated and has a head start for hostmasking, as it now exists on more networks than not, and like +i it has more than just a sense of privacy driving its adoption today.
Also, it's worth noting that +i (invisibility) wasn't made and hasn't been made mandatory, ever...
No, but it has been made default. I suspect that on networks with default anonymous hostmasking the percentage of people who choose not to mask is similarly low. Without a practical reason for avoiding it, that personal preference has all the substance of "I want pink ponies", and should be weighted accordingly in comparison to other issues.
-- Quension
On Sat, Oct 24, 2009 at 6:42 PM, Trevor Talbot quension@mac.com wrote:
On Oct 23, 2009, at 6:10 AM, James Hess wrote:
On Fri, Oct 23, 2009 at 3:04 AM, Trevor Talbot quension@mac.com wrote:
..
Also, it's worth noting that +i (invisibility) wasn't made and hasn't been made mandatory, ever...
No, but it has been made default. I suspect that on networks with default anonymous hostmasking the percentage of people who choose not to mask is similarly low. Without a practical reason for avoiding it, [...]
Do you think +i should be made mandatory now? Perhaps it should be. Spambots may be confused when they join a channel and see someone who is mode +i; after the spambot parts the channel, the user who switched to -i might receive two malware URLs instead of just one, as the bot crawls /who, and erroneously creates a second entry in its state table.
One spam message is bad enough...
..
Basically, any client that follows the spirit of IRC by translating, automating and otherwise turning the low-level interactions with the server into something as user-friendly as possible. Most mainstream clients maintained today keep significant amounts of state: modes, clients in a
I thought you were perhaps suggesting there is a broad category of IRC clients called "modern stateful clients" that would all have essential functionality broken by masking or toggling masking.. but I don't believe this to be true.
IRC clients do keep track of some stateful information from IRC, but it is mostly only channels that they keep track of: channels, the list of channel members' nicknames, and their operator status. Requesting host information requires an expensive /userhost command, a lot of extra work.
Hostmasks are not part of the state information other members of the channel get for free. That is: hostnames aren't advertised of existing users when you join a channel.
Major networks that do allow toggling of masking status may have influenced the design of IRC clients over the years.
One example is commonly implemented forms of flood detection. Eggdrop's sentinel.tcl, among others, uses a host-based hashtable to detect and respond to certain types of clones. If a client's host can silently change, that mechanism breaks.
This is a specialized type of script that also cannot do its job if masking is optional. Toggling doesn't make a difference: it's a fact, that the bad fellow conducting the clone flooding, could make some of the clones masked, and some unmasked, in order to evade detection using a hash table, unless masking is mandatory.
To be a good reason to fix masking status: the example should show a disadvantage of toggling specifically, that does not apply when clients can opt-out /in by reconnecting.
You missed the qualifier, "with no indication". If a client quits, parts, or otherwise changes its presence in the channel and vanishes from view, the user is notified that something has changed and it might not be ignored anymore when it returns. If any client can change its host without notification, the user sees an unreliable and broken feature instead.
This is an example, but it's a really really weak one. Users should be educated to use /silence
I believe users of IRC most commonly /ignore by nickname, that is they set an ignore for nickname!*@* Without regard to hostname. Because it is the default behavior of practically all IRC clients to just ignore the nickname, unless a host or other criteria has been specified.
Such ignores are already easily avoided by the bad user signing an additional client onto IRC or changing nicknames, while not on a common channel.
Again, if masking is optional, the user being ignored may reconnect without the /ignor'ing user knowing. The only way they can know about a /reconnect, in the first place, is if they share common channels.
The users who know to /ignore by hostmask, should also be the ones who know about the /userhost or /whois command, and can see that the hostmask has changed.
don't make it mandatory. What then makes you suppose pre-masking assumptions are significant?
I agree it is the most common method of user control, but I am challenging the implicit assumption that it is even a *good* method of providing masking, let alone the best compromise currently available for most uses.
What I'm saying is, that since networks have already implemented it for many years, modern IRC clients' designs are influenced, so that the assumptions are deadweight.
I'd actually be more concerned about old versions of IRC clients, but the only relevant example shown so far where they might break has been /ignore.
The type of example I'd really be interested in is: "/ban nick 3, is broken with mask toggling in the current version of client Xyz" not vague suggestions a feature might be broken, but a real indicator.
Where client Xyz is some software program used by at least 1% of IRC users or channels on the network; e.g. mIRC would count, some IRC client released in 1990 that 20 people in the world use would not.
Several networks that implement realtime mask toggling have found it necessary to also provide quit/reconnect simulation, which is a strong indicator that the assumption of a hostname not silently changing is
Examples? Which networks, and what made them feel it necessary? Do they still have that and still consider it necessary today?
On Sun, Oct 25, 2009 at 4:36 PM, James Hess mysidia@gmail.com wrote: <snip>
Several networks that implement realtime mask toggling have found it necessary to also provide quit/reconnect simulation, which is a strong indicator that the assumption of a hostname not silently changing is
Examples? Which networks, and what made them feel it necessary? Do they still have that and still consider it necessary today?
Three large networks (QuakeNet, Undernet and GameSurge) currently use quit/reconnect simulation, and dozens of smaller networks do as well -- for many of the same points brought up throughout this discussion. It should also be mentioned that all three of these networks do not allow toggling, as well. As for whether or not it is still necessary today, difficult to say. I'm sure there are scripts in use on these networks that probably take further advantage of this extra information they're given. On Rizon, where quit/reconnect simulation functionality is supported by the ircd, but not enabled, I have occasionally seen BNCs, scripts and the odd ball clients get "confused" because of it.
I don't think anyone is arguing that by not providing quit/reconnect simulation it will break all clients/scripts/bots/bncs in use today, but rather it has been shown to cause problems with some clients/scripts/bots in the past (and even today). This is one reason such functionality has been incorporated into ircu, inspircd, plexusircd, asuka, snircd, nefarious, and other ircds that provide hostmasking.
I have yet to see a strong argument for not including the same functionality in bahamut should hostmasking be optional, other than some finding it annoying. The actual "chatter" created by the few actual messages it would generate is trivial, as is is the actual "overhead." The added benefit seems to outweigh the assumption that it will annoy some users.
-SecretAgent
On Oct 26, 2009, at 3:37 AM, Jason Hill wrote:
Three large networks (QuakeNet, Undernet and GameSurge) currently use quit/reconnect simulation, and dozens of smaller networks do as well -- for many of the same points brought up throughout this discussion. It should also be mentioned that all three of these networks do not allow toggling, as well.
To expand on that, due to the registration model they use it is more like a one-shot switch: you can turn it on at any time, but you can't turn it back off during the session.
[...] such functionality has been incorporated into ircu, inspircd, plexusircd, asuka, snircd, nefarious, and other ircds that provide hostmasking.
It's also notable that many of them give explicit notification to the client that its own host has changed, which works around one of my earlier arguments (provided the clients are changed accordingly).
-- Quension
To add to this, after looking into how much stuff I personally have that absolutely relies on hostmasks not silently changing, it turns out my script relies entirely on mIRC Internal Address List. Everything my script does assumes that hostmasks will not change during a session. I'm probably not the only mIRC user on the network, and I'm probably not the only user who uses it's IAL features extensively.
On Wed, Oct 28, 2009 at 5:38 AM, Trevor Talbot quension@mac.com wrote:
On Oct 26, 2009, at 3:37 AM, Jason Hill wrote:
Three large networks (QuakeNet, Undernet and GameSurge) currently use
quit/reconnect simulation, and dozens of smaller networks do as well -- for many of the same points brought up throughout this discussion. It should also be mentioned that all three of these networks do not allow toggling, as well.
To expand on that, due to the registration model they use it is more like a one-shot switch: you can turn it on at any time, but you can't turn it back off during the session.
[...] such functionality has been incorporated into ircu, inspircd,
plexusircd, asuka, snircd, nefarious, and other ircds that provide hostmasking.
It's also notable that many of them give explicit notification to the client that its own host has changed, which works around one of my earlier arguments (provided the clients are changed accordingly).
-- Quension
DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
*A reason to allow toggling, is a user may be listed in some access lists using their old hostmask, and in other access lists using the masked version of their host. For example, they may be an operator of multiple channels, and be on the access list of multiple bots, some of which have been updated, some of which have not. It could be inconvenient for them to be unable to exercise access to both bots. If they could not switch between masked and unmasked, they might be forced to log multiple clients on IRC.
Or reconnect each time, which causes inconvenience due to (1) the amount of channel chatter annoying other IRC users, and (2) needing to rejoin channels and re-authenticate with services every time.
On Sat, Oct 31, 2009 at 10:26 AM, Vin King vin.king@gmail.com wrote:
To add to this, after looking into how much stuff I personally have that absolutely relies on hostmasks not silently changing, it turns out my script relies entirely on mIRC Internal Address List. Everything my script does assumes that hostmasks will not change during a session. I'm probably not the only mIRC user on the network, and I'm probably not the only user who uses it's IAL features extensively.
mIRC updates its internal address list at various times when presented with new information, it does not only update its internal address list at the start or end of a sesssion.
mIRC also provides (or provided) commands that allow you the user to manipulate the IAL or even disable the IAL and rely on the client requesting userhost info each time.
-- -J
On Oct 25, 2009, at 2:36 PM, James Hess wrote:
On Sat, Oct 24, 2009 at 6:42 PM, Trevor Talbot quension@mac.com wrote:
On Oct 23, 2009, at 6:10 AM, James Hess wrote:
On Fri, Oct 23, 2009 at 3:04 AM, Trevor Talbot quension@mac.com wrote:
..
Also, it's worth noting that +i (invisibility) wasn't made and hasn't been made mandatory, ever...
No, but it has been made default. I suspect that on networks with default anonymous hostmasking the percentage of people who choose not to mask is similarly low. Without a practical reason for avoiding it, [...]
Do you think +i should be made mandatory now?
An interesting thought exercise. If I were implementing an ircd right now, I would see making +i mandatory as a way to avoid dealing with that particular visibility check in various parts of my code. Two uses for -i that come to mind at the moment are in making opers visible to users, and for antispam automatons to trap certain spambots. However, both seem a bit weak: oper visibility can be addressed in a myriad of other ways on the server, and I believe the number of spambots currently caught with that method is sufficiently low to be irrelevant. Still, since the only advantage appears to be to me as a server implementor, with no benefit to clients or users, I would probably conclude that it's easiest to just maintain the status quo. I would, of course, be open to additional arguments either way.
IRC clients do keep track of some stateful information from IRC, but it is mostly only channels that they keep track of: channels, the list of channel members' nicknames, and their operator status. Requesting host information requires an expensive /userhost command, a lot of extra work.
Have you somehow missed the number of clients that have been using WHO <channel> on join all this time? mIRC, xchat, irssi, Klient, KVirc, ...
Hostmasks are not part of the state information other members of the channel get for free. That is: hostnames aren't advertised of existing users when you join a channel.
Which is why the UHNAMES extension was introduced in Unreal and inspircd. Note that both ircds also provide hostmasking with realtime toggling and rejoin simulation.
One example is commonly implemented forms of flood detection. Eggdrop's sentinel.tcl, among others, uses a host-based hashtable to detect and respond to certain types of clones. If a client's host can silently change, that mechanism breaks.
This is a specialized type of script that also cannot do its job if masking is optional. Toggling doesn't make a difference: it's a fact, that the bad fellow conducting the clone flooding, could make some of the clones masked, and some unmasked, in order to evade detection using a hash table, unless masking is mandatory.
The same script already has additional checks for joins, parts, and quits, and weights its evaluation of flood levels accordingly. It is not broken on implementations that simulate rejoins during hostmask toggling, as the results simply appear to be multiple independent flooders, and it can deal with those.
You missed the qualifier, "with no indication". If a client quits, parts, or otherwise changes its presence in the channel and vanishes from view, the user is notified that something has changed and it might not be ignored anymore when it returns. If any client can change its host without notification, the user sees an unreliable and broken feature instead.
This is an example, but it's a really really weak one. Users should be educated to use /silence
Well, aside from SILENCE not blocking channel messages as was the example here, not existing on all networks, being severely limited in number of entries, being primarily designed for clients to use automatically when appropriate and therefore missing a bunch of user- desired features such as persistence across sessions, fine-grained ignore types, exclusion entries and integration with the UI like query window ignore canceling, and the fact that in a discussion about backward compatibility you're proposing everyone else be magically compelled to change behavior instead, I suppose I can see the rationale in educating users to use SILENCE ;)
I agree [a usermode to change hostmasking status] is the most common method of user control, but I am challenging the implicit assumption that it is even a *good* method of providing masking, let alone the best compromise currently available for most uses.
What I'm saying is, that since networks have already implemented it for many years, modern IRC clients' designs are influenced, so that the assumptions are deadweight.
Then why are many networks explicitly reinforcing those assumptions with workarounds and extensions, and what incentive do clients have to change in the face of that?
I'd actually be more concerned about old versions of IRC clients, but the only relevant example shown so far where they might break has been /ignore.
The type of example I'd really be interested in is: "/ban nick 3, is broken with mask toggling in the current version of client Xyz" not vague suggestions a feature might be broken, but a real indicator.
So far in this thread there have been several examples given of disadvantages that exist for both realtime toggling of hostmasking, and for making hostmasking optional at all. However weak they may seem to be, many of them affect end users indefinitely, and therefore qualify as lasting issues with masking.
The question seeking advantages to realtime hostmask toggling remains unanswered.
The question seeking advantages to optional hostmasking has only one response so far, which is to decrease disruption during a transition period.
I don't see how downplaying the provided issues is useful when there hasn't been a significant advantage given in the first place. I find it particularly interesting that despite the number of current implementations of optional hostmasking, no one has posted an example of someone needing to turn it off to accomplish something.
I suppose I could add one for the sake of argument. There exist fserves that are behind firewalls, and therefore require you to run a dcc server in order to retrieve files from them. They work by having you disable masking so that they can retrieve your real address and connect to it. It is then important to be able to disable hostmasking, and rather convenient to be able to do it in realtime, especially since this is usually on a network that applies anonymous masking by default.
My primary counter-argument would be that this use is only for a situation that doesn't apply to DALnet: channels set up for the purpose of filesharing. A secondary point would be that the onward march of technology is making these types of fserves increasingly scarce.
[Obligatory repeat disclaimer: I'm speaking only for myself; what happens with hostmasking on DALnet is not up to me.]
-- Quension
On Wed, Oct 21, 2009 at 6:13 PM, Trevor Talbot quension@mac.com wrote:
That's not what I was getting at.
In many of the comments in this thread, I'm seeing the idea that: A) users want the ability to *avoid* hostmasking B) it is important that they toggle it in realtime, without disconnecting
I'm asking why users want to avoid hostmasking, why it is important that it happen in real time, and why this is so useful that it outweighs the disadvantages of supporting it.
Ah, wasn't looking at it from that point. I was arguing /for/ it. The only arguments against it that I can see are dealing with abuse, but this are mostly incorrect assumptions.
If toggling hostmasking in realtime is not required, then servers do not need to implement quit/reconnect simulations and other workarounds, and various small problems do not ripple out to annoy client maintainers, script writers and end users.
Too lazy to combine multiple replies, but James Hess made an excellent point. If the mask can't change during connect, nor the real host, why bother with realtime *notification* of changes to other users? A ban against either should affect you regardless of your displayed host. All existing scripts should work the same even without notification.
If disabling hostmasking is not required, then servers do not need to implement matching for real hosts, basic users never have to question whether they are protected, technically minded users don't have the mental baggage of a parallel host namespace they may or may not see, and channel ops and harassment victims don't have to deal with Yet Another Way abusers can evade their bans and ignores, however rare it may be.
Applying non-optional fixed hostmasking on connect seems to reduce complexity across the board. What are the advantages to increasing it?
Immutable masking is not a problem in my eyes, but may be an issue with those throwing away money and wasting IP space on vanity hosts. I might suggest removing umode x as squelching, and force the mode on users on connect, so certain scripts realize "ok, im masked". The only complexity with UnrealIRCd-like masking is matching against both hosts and masks.
To further reply to James on rolling it out, there would have to be two stages. One to all servers to display the hosts properly (assuming toggle-able masking), and a second to enable use of it.
-- Quension
DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
On Tue, Oct 20, 2009 at 5:09 AM, Trevor Talbot quension@mac.com wrote:
long as it's online. This is a pretty fundamental assumption that makes everything from pretty client displays to access lists and scripting work.
Mask "staticness" is not really a valid assumption within the scope of the IRC protocol, and not required for ChanServ access lists or scripting to work, with proper awareness of whatever masking scheme. Client A cannot ever actually be sure Client B's address won't change even in the absence of masking (Client B could reconnect at any time unbeknownst to client A).. hence every message in the IRC protocol contains a nick!user@host prefix when delivered to other IRC users.
Another property is that hosts have a hierarchy, where certain parts may change for dynamically-assigned addresses while other parts remain static based on ISP or geographical location; this of course is what makes wildcard masks in access lists etc work.
Sometimes they have a hierarchy, sometimes they do not. In some cases, IRCD may actually be working against IRC users, when it resolves IP addresses into a less useful form like
abc12345.ipt.aol.com E.g. Sometimes the IPs might actually have a hierarchy that is distorted or lost when the resolved name is shown, for example, if a /19 of addresses is designated for each region.
In fact, IRCD does not provide adequate banning tools for this scenario, you cannot ban a /19, a /20, or even a /22 from a channel with a single ban.
any time. This breaks the assumption above and affects things as basic as automatic line breaks in channel or private message text. (A client that knows its own host length can calculate the maximum length of message text it can send before one server along the chain will truncate it, and can do its own line splitting to compensate.)
Auto line breaks are not really that basic... most clients don't split messages in a way the user did not, and most clients simply limit message length at a point.
The truncation is basically an existing flaw in the protocol. It rarely comes into play, as legitimate messages rarely come close to the limit.
Clients aren't actually required to be told their own hostname, at any point during registration with an IRC server. The only way a client can possibly know its own address is if it asks for it, with a command such as /USERHOST <itsownnickname>
It is not within the IRC protocol that a user needs to know its mask. However... it is possible to always show the client its true hostname (even when masked), or a 'padded' version designed to be longer than the masked version of their hostname, so as to satisfy any automatic line breaking procedure.
The proper way to handle masking is to do it on connect, and not allow the masked status to change during the session.
Forcing mask status to be fixed upon connect (unless forcing all users to use masking), is a bit troublesome.
The main problem is IRC clients don't provide a way for the user to interact with the server in a general way _until_ the registration with IRC is done.
It's not really possible to simply add an option to the USER line for "request masking", and have it actually be usable by IRC users
-- -J
On Tue, Oct 20, 2009 at 8:31 AM, James Hess mysidia@gmail.com wrote:
On Tue, Oct 20, 2009 at 5:09 AM, Trevor Talbot quension@mac.com wrote:
<snip>
The proper way to handle masking is to do it on connect, and not allow the masked status to change during the session.
Forcing mask status to be fixed upon connect (unless forcing all users to use masking), is a bit troublesome.
The main problem is IRC clients don't provide a way for the user to interact with the server in a general way _until_ the registration with IRC is done.
It's not really possible to simply add an option to the USER line for "request masking", and have it actually be usable by IRC users
This can actually be done before the server finishes registering the user, assuming we've received both NICK and USER.
As seen in some other ircds, the client can pass its login credentials to a login service using PASS. A cookie could be used to verify replies from the login service, in case the client disconnects and the fd is reused. If everything checks out ok, the server simply introduces the user with their masked host. Should the login service be unable to verify the credentials supplied by the client, the server could prompt the user to reenter them using /QUOTE PASS. Or, should the server be unable to contact the login service, it could prompt the user to, for example, to enter /QUOTE PASS to continue connecting (alerting them that their host won't be automatically masked).
You could also go with an SASL implementation, which more and more clients are starting to support.
-SecretAgent
On Oct 20, 2009, at 6:31 AM, James Hess wrote:
Mask "staticness" is not really a valid assumption within the scope of the IRC protocol, and not required for ChanServ access lists or scripting to work, with proper awareness of whatever masking scheme. Client A cannot ever actually be sure Client B's address won't change even in the absence of masking (Client B could reconnect at any time unbeknownst to client A).. hence every message in the IRC protocol contains a nick!user@host prefix when delivered to other IRC users.
The reason a full prefix is delivered is to allow stateless clients to function; it enabled /ignore, predates SILENCE, and provides some identification information in the absence of channel context. The assumed immutability of a client's host during a session can be seen historically in channel interactions (notably joins and bans) and options like the host target of a PRIVMSG. The assumption has been continued since then with things like clients caching hosts within a channel context, and servers providing extensions like UHNAMES to assist them.
It isn't required for all things to "work", but it is an assumption that has been encoded into the behavior of both servers and clients from the beginning. I have yet to see anyone make an argument for why trying to change that is desirable; it just seems to be a side effect of the way hostmasking and internal vhosts were first done that people have mostly put up with despite the problems.
In fact, IRCD does not provide adequate banning tools for this scenario, you cannot ban a /19, a /20, or even a /22 from a channel with a single ban.
I do consider CIDR masks to be a desired feature when real hosts are used; some networks have implemented it.
Auto line breaks are not really that basic... most clients don't split messages in a way the user did not, and most clients simply limit message length at a point.
I suppose I should have said "simple" instead, but it's not *that* rare. A few clients have it built-in, and there are scripts available for some others.
Clients aren't actually required to be told their own hostname, at any point during registration with an IRC server. The only way a client can possibly know its own address is if it asks for it, with a command such as /USERHOST <itsownnickname>
Yes, or a WHOIS on itself, or by messaging itself. Many clients do all of the above and anything else they can think of in order to work around DCC+NAT+masking problems.
It is not within the IRC protocol that a user needs to know its mask.
It is desired by modern stateful clients, though.
Forcing mask status to be fixed upon connect (unless forcing all users to use masking), is a bit troublesome.
The main problem is IRC clients don't provide a way for the user to interact with the server in a general way _until_ the registration with IRC is done.
It's not really possible to simply add an option to the USER line for "request masking", and have it actually be usable by IRC users
A good point.
-- Quension
-
Aaron Wiebe -
Andreas -
brandon -
Isil Drosdow -
James Hess -
Jason Hill -
Jose Almenara -
Kobi Shmueli -
Michael Reynolds -
Omar Khan -
Trevor Talbot -
Vin King