• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

A few constructive criticisms

Started by gerbil, October 04, 2011, 10:13:44 PM

Previous topic - Next topic

gerbil

I apologize if I sound a bit frustrated in this post (which I happen to be); regardless of the tone, this post is meant to be constructive.  Also, it might have been best to break this post up into separate posts under different forums, but I wanted to unload in one place, and this seemed to be the most appropriate.

First thing I noticed as an HE 'customer', having signed up for a tunnel, is that account names are made public as the first part of RDNS/PTR hostnames for easily guessed/discovered IPv6 addresses that the user has no RDNS control over, and thus cannot override (I'm talking about addresses outside of the 'routed prefixes').  This would seem to be an unnecessary security faux pax for obvious reasons.

The second issue involves HE providing personal information of customers on its whois server.  I'm not disputing that this may be part of RIR (ARIN's) policy.  However, I don't believe there is full disclosure in your terms of service, where you state "Hurricane Electric will provide your information to the appropriate RIRs when required under RIR policy. This data may be published by the RIR in a database such as whois."  With there apparently being no 'may' about the release of this information, and it not so much being provided from you (HE) to the RIR as you (HE) providing it directly to any third party querying your whois server.  At the least I think the terms of service should be amended to be clearer (and more accurate), but I also (and probably more importantly) think that a short disclosure of this specific policy near any forms (on HE's network of websites) that request personal information would be a good idea.

Along the same line (and for similar reasoning) as the first point, I find it a fairly bad idea to both require using a monolithic HE account for forum access *and* not allow an over-riding 'display' name to be specified in the forum profile.  Along the same line as the second point, there doesn't seem to be any disclosure of personal information (location) being taken from input at other locations within the HE network and being made available on the forum (under the user profile).  If I'm missing something on these points, hints/corrections are welcome.

The 24-hour timer on the daily IPv6 seems odd and inappropriate.  Even if people can independently keep close track of this timer (which seems a completely unnecessary burden), offset drift will happen such that days will be lost in completing the repetitive march to 1400/1500 points.  Much better would be to keep track of the last day that the user completed each challenge.  This eliminates the need to keep track of a 24-hour timer, and eliminates any drift that would result in lost days for completing these tests.

These daily IPv6 tests aren't proving any technical knowledge that you haven't tested in the certification levels leading up to these daily tests.  They are so mindlessly repetitive that most people probably relegate the task of completing them to simple scripts; they don't seem to really serve a productive purpose to the user.  If I were to guess by the looks of them, these tests seem designed solely for HE to farm information (from its users/customers) about 'active' IPv6 allocations and services.  What follows are just a few ideas for tests that might require a little bit of thought.

  • Simple subnetting questions that go at least a little beyond 'how many /64 prefixes are available in a /48 prefix'.  What about less common prefix allocations?  What about number of hosts available per prefix?
  • Ask the user which assignee organization has been assigned the prefix XXXX:XXXX/32
  • Ask the user if the PTR and AAAA records match for a given hostname or IPv6 address (one chance per day at correct answer, and these records could be generated on HE DNS servers authoritative for a sub-domain reserved daily tests).
  • Have the user generate a bind line/entry to fulfill X condition which is then syntactically checked, or alternatively have the user create the record in a zone they have control over and verify it.
I don't imagine it would take much brainstorming to come up with other examples, as I came up with these examples on-the-fly while writing this post.

Also, I've been caught two times (and I've only been doing these tests for four or five days) by an apparent bug in the daily tests where if I submit output for a host within a prefix that I've used in past daily tests, the test locks up and doesn't allow me to use other fresh, un-unused prefixes that I'm absolutely sure I've never used before.  Also, I think it should be a bit clearer as to where the line is drawn in prefixes, as far as reuse goes, such as using static /32 as a delineation point, or the smallest/largest CIDR prefix (smallest if you consider host space, or largest if you consider CIDR number, such as /48 > /32) shown in the RIR whois database (or whatever other reasonable approach you might take).  Though, maybe you have made it clear somewhere and I missed it.

snarked

Whois:  This appears to be new, but there was notice in these forums that such was planned.  I found it interesting that they called the commercial address that I used (that of a colocation facility) a "private residence."  It would be nice to have some options on what to publish (or not)....  If I were to have a phone # on my allocations at all, I would prefer my own # as opposed to HE's (as is on my forward domain registrations).  Same with e-mail.  Lastly, could we have the "network:Created:" date be set correctly?  It appears that you initalized the whois database in 2010 but I've had my tunnel for more than 3 years and I'd like the data to reflect such.

I don't like the "daily IPv6 tests" to increase one's "sage" point score to 1500.  I agree that they don't seem to serve a significant purpose, but other people seem to like them.

broquea

#2
First off, congrats on reaching Sage. Don't forget to validate your address information and pick a t-shirt size. That way we can get you a nifty reward for your efforts!

Quote
First thing I noticed as an HE 'customer', having signed up for a tunnel, is that account names are made public as the first part of RDNS/PTR hostnames for easily guessed/discovered IPv6 addresses that the user has no RDNS control over, and thus cannot override (I'm talking about addresses outside of the 'routed prefixes').  This would seem to be an unnecessary security faux pax for obvious reasons.

We have this information (username + location) for troubleshooting purposes. Sometimes it is simply quicker to look into a reported issue when that information is presented in a traceroute. Especially as we'll get tickets with either limited information by the user, or from other people not associated with the account experiencing issues.

Quote
The second issue involves HE providing personal information of customers on its whois server.  I'm not disputing that this may be part of RIR (ARIN's) policy.  However, I don't believe there is full disclosure in your terms of service, where you state "Hurricane Electric will provide your information to the appropriate RIRs when required under RIR policy. This data may be published by the RIR in a database such as whois."  With there apparently being no 'may' about the release of this information, and it not so much being provided from you (HE) to the RIR as you (HE) providing it directly to any third party querying your whois server.  At the least I think the terms of service should be amended to be clearer (and more accurate), but I also (and probably more importantly) think that a short disclosure of this specific policy near any forms (on HE's network of websites) that request personal information would be a good idea.

We can review the language of our posted relevant policies regarding the broker/certification/free dns. However at this time only the City/State/ZIP are published, and no other specific user information. This helps satisfy RIR policies. And even then it is only as accurate/correct as was submitted by the user.

Quote
Along the same line (and for similar reasoning) as the first point, I find it a fairly bad idea to both require using a monolithic HE account for forum access *and* not allow an over-riding 'display' name to be specified in the forum profile.  Along the same line as the second point, there doesn't seem to be any disclosure of personal information (location) being taken from input at other locations within the HE network and being made available on the forum (under the user profile).  If I'm missing something on these points, hints/corrections are welcome.

We prefer the single unified account method for access to the free services. Especially useful when we terminate an account for abuse. If you want your real name or some other name to be displayed on the forums, under your profile settings in the forums you would edit: "Name: This is the displayed name that people will see".

Quote
The 24-hour timer on the daily IPv6 seems odd and inappropriate.  Even if people can independently keep close track of this timer (which seems a completely unnecessary burden), offset drift will happen such that days will be lost in completing the repetitive march to 1400/1500 points.  Much better would be to keep track of the last day that the user completed each challenge.  This eliminates the need to keep track of a 24-hour timer, and eliminates any drift that would result in lost days for completing these tests.

We might adjust this, however all those with 1500 seem to have completed without issue. If we wanted people to script against it, and not interact with trying to find relevant IPv6 information and game the system by essentially setting up a data mining bot and walking away, yeah we could have it reset every day at like 3am.

Quote
These daily IPv6 tests aren't proving any technical knowledge that you haven't tested in the certification levels leading up to these daily tests.  They are so mindlessly repetitive that most people probably relegate the task of completing them to simple scripts; they don't seem to really serve a productive purpose to the user.  If I were to guess by the looks of them, these tests seem designed solely for HE to farm information (from its users/customers) about 'active' IPv6 allocations and services.

The daily tests are mostly for those that like leader-board bragging rights, as well as getting them to find out for themselves just how well IPv6 deployment is progressing.

Quote
Also, I've been caught two times (and I've only been doing these tests for four or five days) by an apparent bug in the daily tests where if I submit output for a host within a prefix that I've used in past daily tests, the test locks up and doesn't allow me to use other fresh, un-unused prefixes that I'm absolutely sure I've never used before.  Also, I think it should be a bit clearer as to where the line is drawn in prefixes, as far as reuse goes, such as using static /32 as a delineation point, or the smallest/largest CIDR prefix (smallest if you consider host space, or largest if you consider CIDR number, such as /48 > /32) shown in the RIR whois database (or whatever other reasonable approach you might take).  Though, maybe you have made it clear somewhere and I missed it.

We track only what was the subject of the submission; IP, hostname, etc. That is to make certain that an account doesn't keep submitting identical information over and over again. So for WHOIS, we store the entire range submitted. For rdns/aaaa just the IP/hostname, etc. If you are experiencing errors, please make certain you are emailing ipv6@he.net so we can look into them.

gerbil

#3
I thank you for your reply, broquea.  I think it's great how well-monitored these forums are by staff, and how quickly you respond.  That's a level of service that's not well-matched most other places.  And despite what I've said, and what I will say below, I am appreciative of the services HE provides, and enjoy their use.  In particular, the free DNS service is top-notch for a free service (far, far ahead of other free DNS services I've seen), and one I'm very glad to have discovered.

Quote
First off, congrats on reaching Sage. Don't forget to validate your address information and pick a t-shirt size. That way we can get you a nifty reward for your efforts!

Read here as 'Congratulations! Make sure to validate correct address information, because this was obviously not a concern of yours anywhere in your post!

Quote
We have this information (username + location) for troubleshooting purposes. Sometimes it is simply quicker to look into a reported issue when that information is presented in a traceroute. Especially as we'll get tickets with either limited information by the user, or from other people not associated with the account experiencing issues.

I imagine it would be quite easy for you to create a back-end tool for employee use only that would allow you to enter an IPv6 address and, if applicable, bring up assignee account information.  Heck, you could even create a tool to parse traceroutes and either inject useful information into the text, or display it contextually outside the original text.  You have plenty of options to make things easy enough for yourselves, but apparently user security is of no admitted importance in this issue.  Please don't underestimate the severity of a technically minded yet mentally unstable Internet troll who has made it their short-term goal to disrupt the life of a user of yours, and would salivate at access to account names for services that they use daily.

Quote
We can review the language of our posted relevant policies regarding the broker/certification/free dns. However at this time only the City/State/ZIP are published, and no other specific user information. This helps satisfy RIR policies. And even then it is only as accurate/correct as was submitted by the user.

I already established and admitted its purpose as satisfying RIR policy, but thanks.  And I'm quite aware of the information published.  You seemed to miss the issue being about disclosure.  You don't make it very clear, when a customer/user is entering personal information into a form, about how it will be used, besides the fact that the methods of information leak are not thoroughly outlined in your Terms of Service.  Again, it is not clear that a forum account is automatically created with profile page showing location information (which happens to be indexed and searchable by Google), or that you host a whois server that directly releases this information to any querying party.  Regarding such Internet trolls as previously mentioned, this can be yet one more piece of information they could salivate over.  Also of note, that sure, while a user can provide false information, this would be against HE TOS (from what I recall reading), and therefor I wouldn't think should be trivialized.

Quote
We prefer the single unified account method for access to the free services. Especially useful when we terminate an account for abuse. If you want your real name or some other name to be displayed on the forums, under your profile settings in the forums you would edit: "Name: This is the displayed name that people will see".

Apparently I'm still missing it.  When I'm viewing my profile, the first thing I see is the 'Summary' page, which does not allow editing of the name.  I viewed all pages under 'Modify Profile', with the link/page of seemingly most interest being 'Account Related Settings', which also does not have a text-box for editing the name (though it certainly displays the current name).  I'm sorry for being so oblique that I'm missing what you're referring to.

Quote
We might adjust this, however all those with 1500 seem to have completed without issue. If we wanted people to script against it, and not interact with trying to find relevant IPv6 information and game the system by essentially setting up a data mining bot and walking away, yeah we could have it reset every day at like 3am.

So you surveyed "all those with 1500" to verify they got to that point level without issue?  I guess I must be so unfortunate as to be one of the very few to run into a bug.   :(  As a side-note, I don't think it would be remotely fair to assume that because someone reached the 1500-point mark, that they did so without issue.  So you are claiming that the 24-hour timer is a built-in deterrant for scripts?  I'm just not quite comprehending that one.  I would also note that I am not the only recent user on this forum to make this suggestion, with still others agreeing with the suggestion.  What I have not seen is users disagreeing with the suggestion.  But I guess you've seen more than I have to the contrary.

Quote
We track only what was the subject of the submission; IP, hostname, etc. That is to make certain that an account doesn't keep submitting identical information over and over again. So for WHOIS, we store the entire range submitted. For rdns/aaaa just the IP/hostname, etc. If you are experiencing errors, please make certain you are emailing ipv6@he.net so we can look into them.

This still seems quite vague.  Do you mean you store the 'largest' range visible in the submitted whois output?  This would seem to exclude slices/re-allocations even at the RIR level (in the whois results).  What seems very certain, from what I've experienced, is that you completely exclude slices below the RIR level (such that if you use he.net as input one day, you won't be able to make submissions involving HE-administered /64 or /48 slices, and any non-HE services running there).  This type of exclusion seems to weigh much more toward discovering ISPs and other high level providers, and not more front-of-the-line resident/user-facing services that the customer is bound to encounter.  Whether this side-effect is intended or unintended, to me it seems fairly weird, and not quite as condusive to the discovery of IPv6 adoption.

Sorry if I seem like an irate and ungrateful user.  I'm using your free services, so I have no room to complain.  It just seems to me that the meat of my original post wasn't really addressed (in a way that seems meaningful), and I'm fine with that; it's also OK if this follow-up post isn't replied to (all questions can be viewed as rhetorical).  The original suggestions were only intended to reflect ideas I had on how the service(s) could be bettered, and to point out potential security/privacy concerns.

broquea

#4
QuoteRead here as 'Congratulations! Make sure to validate correct address information, because this was obviously not a concern of yours anywhere in your post!
Honestly I was extending a friendly offer of a free t-shirt for completing Sage, nothing more, nothing less. Read as you like.

QuoteI imagine it would be quite easy for you to create a back-end tool for employee use only that would allow you to enter an IPv6 address and, if applicable, bring up assignee account information.
Exists for senior engineers that have administrative access to the broker accounts, not the front-line support employees that don't.

QuoteApparently I'm still missing it.  When I'm viewing my profile, the first thing I see is the 'Summary' page, which does not allow editing of the name.
This is my fault. I view the forums with my Admin account at all times. Checked as a regular user, and it appears this was disabled. I flipped the bit and should be available now.

k1mu

#5
Quote from: broquea on October 05, 2011, 06:09:15 AM
We might adjust this, however all those with 1500 seem to have completed without issue. If we wanted people to script against it, and not interact with trying to find relevant IPv6 information and game the system by essentially setting up a data mining bot and walking away, yeah we could have it reset every day at like 3am.

I would like to mention that the current scheme can be frustrating. OK, so I've already posted in the last 24 hours - why not tell me when, so I don't have to keep clicking until the window opens up. Not a really big deal, mind you, but it could be a bit more friendly.