06 May, 2011, Scandum wrote in the 61st comment:
Votes: 0
I'm still not convinced about the utility of all this security, just sounds like a pain in the ass to me to exchange keys. Is a popular proxy really going to keep up with 500 keys? And as has been pointed out, if you automate key exchange you're back to square one.

Easiest would be using an existing data protocol (new-environ, msdp, gmcp) to exchange a 2nd IP address and have the MUD compare both IPs against ban and multiplay lists. The potential for abuse is so small that it can be safely ignored, while the gain is obvious for MUDs caring about multiplaying. I'd go along with supporting a new-environ implementation in my telnet snippet, as msdp and gmcp are likely to have a generic interface that would make implementation a breeze.
06 May, 2011, Orrin wrote in the 62nd comment:
Votes: 0
avidal said:
If the server supported those types of connections, there would be no need for the proxy to exist.


As far as Flash goes it's probably easier for a mud to just serve their own policy file than implement this protocol. On mudgamers there's a non proxy version of the client that can be used by any game that is concerned about the IP issue although it's only come up as a problem once or twice.

Edit: I'm not knocking it, have at it by all means, but it's not something I personally see as much of an issue.
06 May, 2011, David Haley wrote in the 63rd comment:
Votes: 0
Twisol said:
The alternative is an open proxy. IP forwarding is irrelevant here: I'm not allowing people to connect to arbitrary hosts through my client. And I won't just allow any-odd MUD I discover because that also imposes on MUDs that disallow multiplaying. So yes, a MUD will need to give me permission to connect to it. If you have any better ideas I'm all ears, but it can't be an open proxy.

You're making the assumption that everybody will care about this. Clearly, in the current world, not everybody cares about it.

I think that a less robust mechanism would be sufficient in many cases. I can believe that, look, this proxy-client is probably reasonable, so I'll assume that if somebody is doing something stupid behind it, it's not the proxy's fault. If it keeps happening, I can worry then – and end up in the same boat regardless of not being able to really rely on IPs.
06 May, 2011, Twisol wrote in the 64th comment:
Votes: 0
Scandum said:
I'm still not convinced about the utility of all this security, just sounds like a pain in the ass to me to exchange keys. Is a popular proxy really going to keep up with 500 keys? And as has been pointed out, if you automate key exchange you're back to square one.

Well, you can just fill out an online form and get your keys… :thinking:

What's the problem with 500 keys?

Scandum said:
The potential for abuse is so small that it can be safely ignored, while the gain is obvious for MUDs caring about multiplaying.

Well, multiplayers who care about multiplaying can pretty easily use this as a workaround… as for potential for abuse, lets see who implements what. Whatever succeeds will be the de facto solution anyways.
06 May, 2011, Twisol wrote in the 65th comment:
Votes: 0
David Haley said:
I think that a less robust mechanism would be sufficient in many cases. I can believe that, look, this proxy-client is probably reasonable, so I'll assume that if somebody is doing something stupid behind it, it's not the proxy's fault. If it keeps happening, I can worry then – and end up in the same boat regardless of not being able to really rely on IPs.

That doesn't explain how can I avoid being an open proxy and yet not require the MUD to give me permission. Also, there's no way to tell that someone's a proxy simply by looking at the connection.

You don't really end up in the same boat, either. You can only ban the character account, since many people are behind the same IP, and you can't tell who's multiplaying.

How about this? The ClientInfo message, as described, can be sent with or without a signature. The MUD can decide whether to allow it or not based on the presence of a signature, removing the need for an exchange of keys beforehand. MSDP and/or GMCP can have messages added to provide the IP as well, if it doesn't plan on ever supporting signed messages. This reduces the entry-level work to a minimum, but allows MUDs to enforce a stricter access policy if desired.
06 May, 2011, David Haley wrote in the 66th comment:
Votes: 0
Twisol said:
That doesn't explain how can I avoid being an open proxy and yet not require the MUD to give me permission.

My bad, I meant to add that you'd just make the pre-arranged keys optional.

Twisol said:
Also, there's no way to tell that someone's a proxy simply by looking at the connection.

I was assuming that you'd determine proxy-ness based on using this protocol in the first place. (This whole protocol and key thing doesn't do anything for proxies that don't, anyhow.)

Twisol said:
You don't really end up in the same boat, either. You can only ban the character account, since many people are behind the same IP, and you can't tell who's multiplaying.

Well, I meant w.r.t. the current world of not being able to tell people apart from the IP address alone.

Twisol said:
The ClientInfo message, as described, can be sent with or without a signature. The MUD can decide whether to allow it or not based on the presence of a signature, removing the need for an exchange of keys beforehand. (…) This reduces the entry-level work to a minimum, but allows MUDs to enforce a stricter access policy if desired.

Yes, this would be good, and along the lines of what I meant to add but forgot to. :tongue:

I think that this is a good compromise for accommodating people who care a lot about this and people who just want to take connections. Besides, if a proxy became popular enough, it could start requiring key-based connection if it had reason to care.
06 May, 2011, Twisol wrote in the 67th comment:
Votes: 0
Right. Well, I'm glad I finally figured out what you wanted. :cool: I do think it's a worthwhile change, though, or I wouldn't have suggested it.

David Haley said:
Twisol said:
You don't really end up in the same boat, either. You can only ban the character account, since many people are behind the same IP, and you can't tell who's multiplaying.

Well, I meant w.r.t. the current world of not being able to tell people apart from the IP address alone.

Well, it's a worse boat. Personal NATs don't usually cover more than a household of computers. Proxies are on the open internet though, and you have a lot more potential users.
06 May, 2011, Runter wrote in the 68th comment:
Votes: 0
Twisol is trying to start a MUD cartel where he controls teh traffic to your games. Beware.
06 May, 2011, Scandum wrote in the 69th comment:
Votes: 0
Twisol said:
Well, you can just fill out an online form and get your keys… :thinking:

What if you lose your key? You can't simply reset the key cause someone might be an impersonator. I guess MSSP could be used to provide a verified email address associated to the MUD so you can resend the key, and this would allow emailing a hard to guess key resetting link. That adds MSSP to the implementation burden, but 10% of all MUDs already support it, and most have the EMAIL variable set. You can only use this for TELNET servers as plaintext servers have the annoying tendency to disconnect after sending the data.

Twisol said:
That doesn't explain how can I avoid being an open proxy and yet not require the MUD to give me permission.

Could add a PROXIES MSSP variable which can be set to 0 to indicate the MUD doesn't want proxy connections.

MTTS could be used to identify yourself as a proxy, I'll assign a bit if anyone is interested.
07 May, 2011, David Haley wrote in the 70th comment:
Votes: 0
Twisol said:
Personal NATs don't usually cover more than a household of computers.

Well, yes, I agree that the majority of NATs out there are for households. But there are schools/universities where a large number of people are behind NATs.
07 May, 2011, Twisol wrote in the 71st comment:
Votes: 0
Scandum said:
What if you lose your key? You can't simply reset the key cause someone might be an impersonator.

…you go back to the proxy and ask for it again, or register for a new key. If you've registered with the proxy there's no reason you can't go back and do that.

Scandum said:
Could add a PROXIES MSSP variable which can be set to 0 to indicate the MUD doesn't want proxy connections.

Well, that doesn't really help MUDs that don't understand MSSP. If that wasn't an issue, yes, that would be nice.
07 May, 2011, Scandum wrote in the 72nd comment:
Votes: 0
Twisol said:
Scandum said:
What if you lose your key? You can't simply reset the key cause someone might be an impersonator.

…you go back to the proxy and ask for it again, or register for a new key. If you've registered with the proxy there's no reason you can't go back and do that.

Yet another site requiring registration.. just what we're looking for. ;)
07 May, 2011, Twisol wrote in the 73rd comment:
Votes: 0
Scandum said:
Yet another site requiring registration.. just what we're looking for. ;)

Still open to suggestions….
07 May, 2011, David Haley wrote in the 74th comment:
Votes: 0
The optional system Twisol and I discussed solves this. If you don't feel like dealing with it, don't. If you care, deal with it.
07 May, 2011, Twisol wrote in the 75th comment:
Votes: 0
So I'm deliberating how IPv6 addresses should be transmitted. IPv4 is fairly obvious and easy, but IPv6 has some rules for compacting an address. For example, the address [0000:0000:0000:0000:0000:0001] can be reduced to [0:0:0:0:0:1] and [::1]. If you were to store an IP as a string, this isn't very helpful for checking ban lists and stuff. You could either require the most compact form or the least compact form, but that's kind of funky and I'm not sure how I feel about that. Or there's an RFC for another representation which I quite like for this purpose (it's also always the same length and it's trivial to convert between it and the raw 128bit numeric address). Unfortunately I'm finding it a bit hard to actually get the raw address from within Ruby, and I'm sure most high-level languages provide strings instead of numbers. So I'm a bit stumped.

Any comments?

(EDIT) Well, ignore that Ruby comment - I just found the stdlib IPAddr class that can give you an integer. Kind of surprising that it's easier to get/find in C than in Ruby though. Anyways, I'd still appreciate any opinions.
07 May, 2011, quixadhal wrote in the 76th comment:
Votes: 0
(replying to Kayle's comment about preventing certain player activity for multiple connections from the same IP)

That concept destroys community.

Lots of people use NAT firewalls at home. Making assumptions about multiplaying based just on IP address means you are rejecting any families that might want to hop onto your MUD to play together. Bad Idea IMHO, as that's just the kind of people you should be trying to attract. Young kids want pew-pew shiny graphics. The generation of folks who are most likely to play a text MUD is, in fact, the generation of people who are old enough to have families, and – surprise surprise – just might want to play together on the same game.

If you really want to know who each of your connections is, knowing the IP address is only a hint. To solve the problem, you really need to uniquely identify each client, and to do that each client is going to have to support some kind of key exchange.

It's a good step to let the proxy unmask IP addresses, but it doesn't actually solve the real problem.

I would say if the MUD administrator is going to go to the effort of supporting this protocol, they could also support getting such information directly from the client – and warning players using clients that don't support it that they are under scruity. My ancient MUD has support for Ident (RFC1413), which used to be semi-reasonable for knowing what user was playing what character. Even then, people playing on dialup or vt200 terminals wouldn't show up as anything but "unknown". Nowadays, Ident is easily spoofed, and would half the time return "root" regardless.
07 May, 2011, Kayle wrote in the 77th comment:
Votes: 0
That's easily avoided though. If they're playing form the same household, there's going to be a flag I can set that allows them to get around it, but after the flag is set, there'll be a period of time where I watch to make sure they are in fact different people, and if they are actually different people I'll leave the flag alone, but if they appear to just be multiplaying I'll take the flag back off.
07 May, 2011, quixadhal wrote in the 78th comment:
Votes: 0
Then we're back to having a human involved in the decision. If that's the case, I'd suggest erroring on the side of trust, since if you automatically restrict people and don't bother to review the game's actions, your family/friends/etc who are legitimately playing together from behind a NAT firewall may have already gotten frustrated and left. The odds of them coming back are pretty slim.

If you don't impose any restrictions, but flag suspected multiplayers (IE: same IP) so that the next time you log in, you get some messages telling you to check people, it accomplishes the same thing. The risk is, somebody might get away with something for a short time.

As for transmitting the addresses… I would definitely use a string form. Trying to kludge something in binary is just asking for mistakes in implementation, especially in byte ordering. In fact, it might be a rather nice service to also send along the DNS resolved address. I have no comment on IPV6, since I don't use it on my network.
08 May, 2011, Kayle wrote in the 79th comment:
Votes: 0
quixadhal said:
Then we're back to having a human involved in the decision. If that's the case, I'd suggest erroring on the side of trust, since if you automatically restrict people and don't bother to review the game's actions, your family/friends/etc who are legitimately playing together from behind a NAT firewall may have already gotten frustrated and left. The odds of them coming back are pretty slim.


I don't really see the issue here. I'm going to be up front about there being restrictions, and have clearly documented procedures for those that are legitimately multiple people in the same household. Considering the nature of the game, they'll end up understanding why the restriction is in place by the end of the tutorial area anyway.
08 May, 2011, Twisol wrote in the 80th comment:
Votes: 0
quixadhal said:
As for transmitting the addresses… I would definitely use a string form. Trying to kludge something in binary is just asking for mistakes in implementation, especially in byte ordering.

They're all string forms. The difference with the format I linked is that, unlike the default :-separated address, every address only has one representation. With the default format, you have the full, noncompact version as well as the 0-replaced and 0-removed versions.

I did a (very) small amount of research, and it looks like the standard compact form is pretty easy to get (such as with inet_ntop()). It seems like the easiest thing to do would be to match the syntax of the string returned from inet_ntop(), i.e. largest stretch of 0's replaced with :: and dotted-decimal for the last 32 bits if it's an IPv4-compatible address ("::ffff:127.0.0.1"). There's an example program in `man 3 inet_pton` you can play with.

quixadhal said:
I have no comment on IPV6, since I don't use it on my network.

You might not, but a proxy client could receive connections via IPv6 and connect to your MUD via IPv4. It still needs to give you the address somehow, whether you decide to use it or not.
Random Picks
60.0/81