@@ -190,287 +203,277 @@
, with documentation on how to use the tools, pointers to documentation for individual testbeds, and a helpdesk to respond to user questions.
-
- Additional support, such as accompaniment through the design and deployment of experiments and the interpretation of their results, is available through
- higher levels of service.
-
-
- 2.2 Best effort, without guarantees
-
-
- OneLab and the owners of the individual OneLab testbeds do their best to provide the services outlined here, with the understanding that Basic level
- service offers no guarantees. Users should clearly understand the following limitations.
-
-
- -
- Reliability:
- OneLab does not provide any guarantees with respect to the reliability of the portal, of other tools, or of the individual nodes on platforms. These
- may be taken down for maintenance, rebooted, or reinstalled at any time. Reinstallation implies that disks are wiped, meaning that users should not
- consider a local disk to be a persistent form of storage.
-
- -
- Fitness:
- OneLab does not guarantee that the platforms are suitable for the experiments that users intend to conduct. There may be limitations in the
- technologies that are offered that prevent certain types of experiments from being carried out.
-
- -
- Privacy
- : OneLab does not guarantee the privacy of traffic generated on the platforms (e.g., wireless signals, packets). Unless otherwise specified by an
- individual platform owner, users should assume that traffic is monitored and logged. Such monitoring may be done intentionally, for example, to allow
- platform administrators as well as other users to investigate abuse.
-
-
-
- Users who seek such guarantees are invited to consider a higher level of service.
-
-
- 2.3 Limitedliability
-
-
- In no event shall the partners of the OneLab consortium be liable to any user for any consequential, incidental, punitive, or lost profit damages, or for
- any damages arising out of loss of use or loss of data, to the extent that such damages arise out of the activities of OneLab consortium partners, or any
- breach of the present terms and conditions, even if the consortium partner has been advised of the possibility of such damages.
-
-
- Nothing contained in these terms and conditions shall be deemed as creating any rights or liabilities in or for third parties who are not Basic level users
- of OneLab.
-
-
- 3 Acceptable use policy
-
-
- 3.1 Responsibilities of managers and standard users
-
-
- OneLab creates and administers accounts for managers and delegates to managers the responsibility for creating and administering accounts for standard
- users. Both managers and standard users are required to follow OneLab's acceptable use policy. In addition, managers are fully responsible for the
- activities of the standard users whose accounts they create.
-
-
- A manager is expected to grant user access only an individual with whom he or she has a working relationship. In general, this means an individual who
- works for the same institution as the manager, or, in the case of higher education and research, an individual who is a student at the university where the
- manager works. Managers may also grant access to individuals from other institutions, provided that they are collaborating on a common project on OneLab.
- If there is a doubt, a manager should refer the question to support@onelab.eu.
-
-
- 3.2 Types of use
-
-
- OneLab may be used by enterprise, by scientific researchers, and by educators.
-
-
- OneLab may be used for pre-commercial research and development. In keeping with OneLab's not-for-profit status, it may not be used to deploy services that
- are designed to generate a commercial profit.
-
-
- Not-for-profit use of OneLab to deploy services that are designed to generate revenue requires prior approval through a written agreement, and thus may not
- be carried out on a Basic level account. Interested users are invited to contact support@onelab.eu.
-
-
- OneLab may be used for scientific research.
-
-
- OneLab may be used to host lab exercises for university courses.
-
-
- Questions about other types of use should be addressed to support@onelab.eu.
-
-
- 3.3 Applicable laws and regulations
-
-
- OneLab is managed, and the portal is hosted, in France. Information regarding the countries in which individual testbeds are managed and hosted is
- available from those testbeds. Users are responsible for being aware of the countries in which their experiments are deployed and for ensuring that their
- use of OneLab fully conforms to the laws and regulations of those countries, as well as the laws and regulations of the country in which they themselves
- are present when conducting their experiments.
-
-
- Above and beyond specific national laws, the activities email spamming, phishing through web services, and all types of Internet fraud are prohibited on
- OneLab.
-
-
- 3.4 Security and accounting mechanisms
-
-
- Users are expected to respect the security and accounting mechanisms put in place by OneLab, its platforms, and federated platforms. For example, access to
- PlanetLab Europe is designed to take place through the SSH cryptographically-secured connection protocol, which uses public/private key pair
- authentication, and so users should not attempt to bypass this mechanism. As another example, OneLab's notion of a "slice" associates a set of resources
- with the group of users who have reserved those resources, and users should not attempt to obscure the identities of participants in a slice.
-
-
- Hacking attempts against the OneLab portal and testbeds are not permitted. This includes "red team" (hacker test) experiments.
-
-
- 3.5 Sharing of resources
-
-
- OneLab is intended for ambitious experiments. Large numbers of resources and extended leases on resources may legitimately be granted in order to carry
- these out. At the same time, OneLab and its testbeds are shared environments, and when there is contention for resources, limits must be imposed.
-
-
- Each OneLab platform sets its own policies for handling resource contention. As a general rule, users are encouraged to design their experiments to use
- resources efficiently. In particular, spinning/busy-waiting techniques for extended periods of time are strongly discouraged. Some resource contention
- policies (e.g., PlanetLab Europe's) terminate the jobs that are using the most resources in the case of contention.
-
-
- 3.6 Internet-connected platforms
-
-
- Some of OneLab's platforms allow experiments to take place on resources that have access to the public internet. These experiments can potentially generate
- traffic to, and receive traffic from, any host or router in the internet.[LB1]
-
-
- Furthermore, some internet-connected platforms (e.g., PlanetLab Europe) consist of servers that are hosted by a large number of member institutions.
-
-
- The accessibility of internet-connected platforms and the distributed hosting model of some of these platforms imply certain responsibilities on the part
- of users, as detailed below.
-
-
- 3.6.1 General guidance
-
-
- A good litmus test when considering whether an experiment is appropriate for such internet-connected platforms is to ask what the network administrator at
- one's own organisation would say about the experiment running locally. If the experiment disrupts local activity (e.g., uses more than its share of the
- site's internet bandwidth) or triggers complaints from remote network administrators (e.g., performs systematic port scans), then it is not appropriate for
- such internet-connected platforms.
-
-
- It is the responsibility of the user and the user's manager to ensure that an application that will run on an internet-connected platform is tested and
- debugged in a controlled environment, to better understand its behaviour prior to deployment.
-
-
- 3.6.2 Standards of network etiquette
-
-
- Internet-connected platforms are designed to support experiments that generate unusual traffic, such as network measurements. However, it is expected that
- all users adhere to widely accepted standards of network etiquette in an effort to minimise complaints from network administrators. Activities that have
- been interpreted as worm and denial-of-service attacks in the past (and should be avoided) include sending SYN packets to port 80 on random machines,
- probing random IP addresses, repeatedly pinging routers, overloading bottleneck links with measurement traffic, and probing a single target machine from
- many nodes.
-
-
- For internet-connected platforms that have a distributed hosting model, each host institution will have its own acceptable use policy. Users should not
- knowingly violate such local policies. Conflicts between local policies and OneLab's stated goal of supporting research into wide-area networks should be
- brought to the attention of OneLab administrators at support@onelab.eu.
-
-
- 3.6.3 Specific network usage rules
-
-
- It is not allowed to use one or more nodes of an internet-connected platform to generate a high number of network flows or flood a site with high traffic
- to the point of interfering with its normal operation. Use of congestion-controlled flows for large transfers is highly encouraged.
-
-
- It is not allowed to perform systematic or random port or address block scans from an internet-connected platform.
-
-
- For internet-connected platforms that use a distributed hosting model, it is not allowed to spoof or sniff traffic on a hosted server or on the network the
- server belongs to.
-
-
- Access to a server on a distributed hosting platform may not be used to gain access to other servers or networked equipment that are not part of the
- testbed.
-
-
- 3.7 Wireless platforms
-
-
- Wireless-connected platforms give users access to nodes that communicate via Wi-Fi and other wireless technologies. They may be capable of detecting
- wireless activity in the neighbourhood of those nodes: traffic generated by other users of the platform or by individuals not associated with the platform.
- In general, much of the traffic will be encrypted, with certain aspects (such as SSIDs) not encrypted, but it is also possible that there will be fully
- unencrypted traffic. They may also be capable of generating wireless activity that reaches equipment outside of the testbed.
-
-
- Furthermore, some wireless-connected platforms may have built-in limitations to prevent them from generating signals at a strength that exceeds health and
- safety regulations.
-
-
- These characteristics of wireless-connected platforms imply certain responsibilities on the part of users, as detailed below.
-
-
- 3.7.1 Specific network usage rules
-
-
- Experimenters may make no attempt to defeat the encryption of encrypted third-party traffic. Furthermore, experimenters must treat with utmost discretion
- any unencrypted traffic. Limited metadata can be recorded for the bona fide purposes of an experiment, but under no case should third party communications
- be recorded.
-
-
- No attempt may be made to reverse engineer traffic in order to learn the identities of the parties who have generated the traffic.
-
-
- Wireless-connected platforms may not be used to gain access to any network equipment that is not part of the testbed itself.
-
-
- It is not allowed to perform systematic or random scans of wireless networks that are not part of a wireless-connected platform. Similarly, it is not
- allowed to spoof or sniff wireless traffic of the institution that hosts a wireless-connected platform or of other networks in the proximity.
-
-
- Care must be taken so that traffic on wireless-connected platforms does not interfere with the normal functioning of network equipment that is not part of
- the testbed itself.
-
-
- No attempt may be made to defeat the mechanisms that limit signal strength on wireless-connected platforms.
-
-
- 3.8 Handling suspected violations
-
-
- Suspected violations of the OneLab acceptable use policy should be reported to support@onelab.eu.
-
-
- Upon notification or detection of a possible violation, OneLab management will attempt to understand if a violation has in fact occurred. To do so,
- management will freely communicate with the users concerned, the operators of the platforms concerned, as well as any third parties that might be involved.
- An example of a third party is a network operator who detects what they believe to be unauthorized traffic emanating from a OneLab platform.
-
-
- The priority is to resolve any real or apparent violations amicably. However, if OneLab management believes that a violation may have occurred, it can, at
- its sole discretion, and without prior notice, apply any of the following measures:
-
-
- -
- notification of the users of the concerned slice (set of resources);
-
- -
- disabling of the concerned slice;
-
- -
- disabling an individual user's account;
-
- -
- reporting of the user's activity to his/her manager;
-
- -
- disabling of the manager's account and all user accounts for which the manager is responsible;
-
- -
- disabling of all accounts associated with the user's institution.
-
-
-
- In the case of suspected illegal activity, OneLab management might need, without prior notice, to notify the relevant authorities.
-
-
+
+ Additional support, such as accompaniment through the design and deployment of experiments and the interpretation of their results, is available through
+ higher levels of service.
+
+
+ 2.2 Best effort, without guarantees
+
+
+ OneLab and the owners of the individual OneLab testbeds do their best to provide the services outlined here, with the understanding that Basic level
+ service offers no guarantees. Users should clearly understand the following limitations.
+
+
+ -
+ Reliability:
+ OneLab does not provide any guarantees with respect to the reliability of the portal, of other tools, or of the individual nodes on platforms. These
+ may be taken down for maintenance, rebooted, or reinstalled at any time. Reinstallation implies that disks are wiped, meaning that users should not
+ consider a local disk to be a persistent form of storage.
+
+ -
+ Fitness:
+ OneLab does not guarantee that the platforms are suitable for the experiments that users intend to conduct. There may be limitations in the
+ technologies that are offered that prevent certain types of experiments from being carried out.
+
+ -
+ Privacy
+ : OneLab does not guarantee the privacy of traffic generated on the platforms (e.g., wireless signals, packets). Unless otherwise specified by an
+ individual platform owner, users should assume that traffic is monitored and logged. Such monitoring may be done intentionally, for example, to allow
+ platform administrators as well as other users to investigate abuse.
+
+
+
+ Users who seek such guarantees are invited to consider a higher level of service.
+
+
+ 2.3 Limitedliability
+
+
+ In no event shall the partners of the OneLab consortium be liable to any user for any consequential, incidental, punitive, or lost profit damages, or for
+ any damages arising out of loss of use or loss of data, to the extent that such damages arise out of the activities of OneLab consortium partners, or any
+ breach of the present terms and conditions, even if the consortium partner has been advised of the possibility of such damages.
+
+
+ Nothing contained in these terms and conditions shall be deemed as creating any rights or liabilities in or for third parties who are not Basic level users
+ of OneLab.
+
+
+ 3 Acceptable use policy
+
+
+ 3.1 Responsibilities of managers and standard users
+
+
+ OneLab creates and administers accounts for managers and delegates to managers the responsibility for creating and administering accounts for standard
+ users. Both managers and standard users are required to follow OneLab's acceptable use policy. In addition, managers are fully responsible for the
+ activities of the standard users whose accounts they create.
+
+
+ A manager is expected to grant user access only an individual with whom he or she has a working relationship. In general, this means an individual who
+ works for the same institution as the manager, or, in the case of higher education and research, an individual who is a student at the university where the
+ manager works. Managers may also grant access to individuals from other institutions, provided that they are collaborating on a common project on OneLab.
+ If there is a doubt, a manager should refer the question to support@onelab.eu.
+
+
+ 3.2 Types of use
+
+
+ OneLab may be used by enterprise, by scientific researchers, and by educators.
+
+
+ OneLab may be used for pre-commercial research and development. In keeping with OneLab's not-for-profit status, it may not be used to deploy services that
+ are designed to generate a commercial profit.
+
+
+ Not-for-profit use of OneLab to deploy services that are designed to generate revenue requires prior approval through a written agreement, and thus may not
+ be carried out on a Basic level account. Interested users are invited to contact support@onelab.eu.
+
+
+ OneLab may be used for scientific research.
+
+
+ OneLab may be used to host lab exercises for university courses.
+
+
+ Questions about other types of use should be addressed to support@onelab.eu.
+
+
+ 3.3 Applicable laws and regulations
+
+
+ OneLab is managed, and the portal is hosted, in France. Information regarding the countries in which individual testbeds are managed and hosted is
+ available from those testbeds. Users are responsible for being aware of the countries in which their experiments are deployed and for ensuring that their
+ use of OneLab fully conforms to the laws and regulations of those countries, as well as the laws and regulations of the country in which they themselves
+ are present when conducting their experiments.
+
+
+ Above and beyond specific national laws, the activities email spamming, phishing through web services, and all types of Internet fraud are prohibited on
+ OneLab.
+
+
+ 3.4 Security and accounting mechanisms
+
+
+ Users are expected to respect the security and accounting mechanisms put in place by OneLab, its platforms, and federated platforms. For example, access to
+ PlanetLab Europe is designed to take place through the SSH cryptographically-secured connection protocol, which uses public/private key pair
+ authentication, and so users should not attempt to bypass this mechanism. As another example, OneLab's notion of a "slice" associates a set of resources
+ with the group of users who have reserved those resources, and users should not attempt to obscure the identities of participants in a slice.
+
+
+ Hacking attempts against the OneLab portal and testbeds are not permitted. This includes "red team" (hacker test) experiments.
+
+
+ 3.5 Sharing of resources
+
+
+ OneLab is intended for ambitious experiments. Large numbers of resources and extended leases on resources may legitimately be granted in order to carry
+ these out. At the same time, OneLab and its testbeds are shared environments, and when there is contention for resources, limits must be imposed.
+
+
+ Each OneLab platform sets its own policies for handling resource contention. As a general rule, users are encouraged to design their experiments to use
+ resources efficiently. In particular, spinning/busy-waiting techniques for extended periods of time are strongly discouraged. Some resource contention
+ policies (e.g., PlanetLab Europe's) terminate the jobs that are using the most resources in the case of contention.
+
+
+ 3.6 Internet-connected platforms
+
+
+ Some of OneLab's platforms allow experiments to take place on resources that have access to the public internet. These experiments can potentially generate
+ traffic to, and receive traffic from, any host or router in the internet.[LB1]
+
+
+ Furthermore, some internet-connected platforms (e.g., PlanetLab Europe) consist of servers that are hosted by a large number of member institutions.
+
+
+ The accessibility of internet-connected platforms and the distributed hosting model of some of these platforms imply certain responsibilities on the part
+ of users, as detailed below.
+
+
+ 3.6.1 General guidance
+
+
+ A good litmus test when considering whether an experiment is appropriate for such internet-connected platforms is to ask what the network administrator at
+ one's own organisation would say about the experiment running locally. If the experiment disrupts local activity (e.g., uses more than its share of the
+ site's internet bandwidth) or triggers complaints from remote network administrators (e.g., performs systematic port scans), then it is not appropriate for
+ such internet-connected platforms.
+
+
+ It is the responsibility of the user and the user's manager to ensure that an application that will run on an internet-connected platform is tested and
+ debugged in a controlled environment, to better understand its behaviour prior to deployment.
+
+
+ 3.6.2 Standards of network etiquette
+
+
+ Internet-connected platforms are designed to support experiments that generate unusual traffic, such as network measurements. However, it is expected that
+ all users adhere to widely accepted standards of network etiquette in an effort to minimise complaints from network administrators. Activities that have
+ been interpreted as worm and denial-of-service attacks in the past (and should be avoided) include sending SYN packets to port 80 on random machines,
+ probing random IP addresses, repeatedly pinging routers, overloading bottleneck links with measurement traffic, and probing a single target machine from
+ many nodes.
+
+
+ For internet-connected platforms that have a distributed hosting model, each host institution will have its own acceptable use policy. Users should not
+ knowingly violate such local policies. Conflicts between local policies and OneLab's stated goal of supporting research into wide-area networks should be
+ brought to the attention of OneLab administrators at support@onelab.eu.
+
+
+ 3.6.3 Specific network usage rules
+
+
+ It is not allowed to use one or more nodes of an internet-connected platform to generate a high number of network flows or flood a site with high traffic
+ to the point of interfering with its normal operation. Use of congestion-controlled flows for large transfers is highly encouraged.
+
+
+ It is not allowed to perform systematic or random port or address block scans from an internet-connected platform.
+
+
+ For internet-connected platforms that use a distributed hosting model, it is not allowed to spoof or sniff traffic on a hosted server or on the network the
+ server belongs to.
+
+
+ Access to a server on a distributed hosting platform may not be used to gain access to other servers or networked equipment that are not part of the
+ testbed.
+
+
+ 3.7 Wireless platforms
+
+
+ Wireless-connected platforms give users access to nodes that communicate via Wi-Fi and other wireless technologies. They may be capable of detecting
+ wireless activity in the neighbourhood of those nodes: traffic generated by other users of the platform or by individuals not associated with the platform.
+ In general, much of the traffic will be encrypted, with certain aspects (such as SSIDs) not encrypted, but it is also possible that there will be fully
+ unencrypted traffic. They may also be capable of generating wireless activity that reaches equipment outside of the testbed.
+
+
+ Furthermore, some wireless-connected platforms may have built-in limitations to prevent them from generating signals at a strength that exceeds health and
+ safety regulations.
+
+
+ These characteristics of wireless-connected platforms imply certain responsibilities on the part of users, as detailed below.
+
+
+ 3.7.1 Specific network usage rules
+
+
+ Experimenters may make no attempt to defeat the encryption of encrypted third-party traffic. Furthermore, experimenters must treat with utmost discretion
+ any unencrypted traffic. Limited metadata can be recorded for the bona fide purposes of an experiment, but under no case should third party communications
+ be recorded.
+
+
+ No attempt may be made to reverse engineer traffic in order to learn the identities of the parties who have generated the traffic.
+
+
+ Wireless-connected platforms may not be used to gain access to any network equipment that is not part of the testbed itself.
+
+
+ It is not allowed to perform systematic or random scans of wireless networks that are not part of a wireless-connected platform. Similarly, it is not
+ allowed to spoof or sniff wireless traffic of the institution that hosts a wireless-connected platform or of other networks in the proximity.
+
+
+ Care must be taken so that traffic on wireless-connected platforms does not interfere with the normal functioning of network equipment that is not part of
+ the testbed itself.
+
+
+ No attempt may be made to defeat the mechanisms that limit signal strength on wireless-connected platforms.
+
+
+ 3.8 Handling suspected violations
+
+
+ Suspected violations of the OneLab acceptable use policy should be reported to support@onelab.eu.
+
+
+ Upon notification or detection of a possible violation, OneLab management will attempt to understand if a violation has in fact occurred. To do so,
+ management will freely communicate with the users concerned, the operators of the platforms concerned, as well as any third parties that might be involved.
+ An example of a third party is a network operator who detects what they believe to be unauthorized traffic emanating from a OneLab platform.
+
+
+ The priority is to resolve any real or apparent violations amicably. However, if OneLab management believes that a violation may have occurred, it can, at
+ its sole discretion, and without prior notice, apply any of the following measures:
+
+
+ -
+ notification of the users of the concerned slice (set of resources);
+
+ -
+ disabling of the concerned slice;
+
+ -
+ disabling an individual user's account;
+
+ -
+ reporting of the user's activity to his/her manager;
+
+ -
+ disabling of the manager's account and all user accounts for which the manager is responsible;
+
+ -
+ disabling of all accounts associated with the user's institution.
+
+
+
+ In the case of suspected illegal activity, OneLab management might need, without prior notice, to notify the relevant authorities.
+
+
User sign-up