"Abusive" use of SSAD
Colleagues – Following up with my homework from last Thursday, here is the non-exhaustive list of “abusive” SSAD behaviors. I’ve been in discussions with Mark SV, and note that he has some concerns. Expect his comments/edits in a separate message that will be a fast-follow to this post. Thanks— J. ------------- James Bladel GoDaddy “Abusive” use of SSAD may include (but is not limited to) the following behaviors/practices: 1. High volume submissions of malformed or incomplete requests. 2. Frequent duplicate requests that were previously fulfilled or denied. 3. Use of distributed or spoofed source addresses or platforms to circumvent quotas or rate limits. 4. Use of false or counterfeit credentials to access the system. 5. Storing/delaying and sending high volume requests with the intention of causing SSAD or other parties to fail SLA performance. 6. Attempts or efforts to mine or harvest the data protected by SSAD. As with other access policy violations, abusive behavior can result in suspension or termination of access to the SSAD.
Thanks, James. Here are my concerns: * Some abuse may be high-volume, but high volume is not inherently abusive. If there are industry-standard methods for distinguishing denial-of-service attacks from other high-volume activity, we should adopt them here. * Request formats may change over time. Use of outdated formats during a transition period is not abusive. * Subsequent requests for data where the format has been improved (e.g. missing fields have been populated; more appropriate basis has been submitted; more information that has been discovered during an ongoing investigation is added; etc.) is acceptable. * Repeated requests for a domain name record over are justifiable when it is reasonable to assume that domain name registration data is likely to have changed during an investigation. * In the Port 43 public WhoIs system some requestors used multiple and/or spoofed IP addresses to avoid rate limits imposed by registrars. Until issues of SLAs and funding are resolved, we cannot assume that rate limiting, or quota systems, will apply to SSAD. Whatever systems are ultimately put in place, the following observations about IP addresses and distributed requests should be considered: * It is not unusual to have a case worked on by multiple vendors/attorneys/platforms (e.g. one organization for initial take down requests, another to handle escalations, outside counsel for follow-up and/or suit). * It is not unusual to have a case worked on from multiple geographies. * It is not unusual for a requestor to use a VPN. * Credentialed access should be based on credentials and be neutral to IP addresses - so mitigations based on IP addresses are only applicable for the noncredentialled users of SSAD, if at all. * I am very concerned about the undefined terms “harvesting” and “mining”, which seem to me to be more about intent than any specific activity. Until we specifically describe the behavior to be blocked, we should remove the last bullet. /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Tuesday, October 8, 2019 7:15 PM To: gnso-epdp-team@icann.org Subject: [Gnso-epdp-team] "Abusive" use of SSAD Colleagues – Following up with my homework from last Thursday, here is the non-exhaustive list of “abusive” SSAD behaviors. I’ve been in discussions with Mark SV, and note that he has some concerns. Expect his comments/edits in a separate message that will be a fast-follow to this post. Thanks— J. ------------- James Bladel GoDaddy “Abusive” use of SSAD may include (but is not limited to) the following behaviors/practices: 1. High volume submissions of malformed or incomplete requests. 2. Frequent duplicate requests that were previously fulfilled or denied. 3. Use of distributed or spoofed source addresses or platforms to circumvent quotas or rate limits. 4. Use of false or counterfeit credentials to access the system. 5. Storing/delaying and sending high volume requests with the intention of causing SSAD or other parties to fail SLA performance. 6. Attempts or efforts to mine or harvest the data protected by SSAD. As with other access policy violations, abusive behavior can result in suspension or termination of access to the SSAD.
Hi Mark, I think the times of legitimate high volume requests have passed. There are now less invasive methods of confirming domain ownership - such as modifications to the DNS records - that do not require knowing the personal data whom the domain belongs to. High volume requests are almost always an indicator for abuse. You have a point about request formats and we should allow some leeway for formats that have been accurate recently. If the data has actually changed, then that would not be a request for the same data anymore. But I I think we need to have some form of cap for requests for the dame domain by the same requestor. Two to three requests over the course of as many months probably would not count as abusive. Circumventing legitimate rate limits is abusive use of the system as those limits are there for a reason. If multiple vendors are used that access the data, each of those vendors would have to be accredited seperately and therefore not fall under the circumvention rule. If those vendors are however affiliated entities, this would be different. Which brings me to another affiliation requirement: Provide list of all affiliated entities that are already accredited, or have applied for accreditetion, similar to the obligation of registrars to provide lists of all affiliated registrars to ICANN. I think the terms harvesting and mining speak for themselves but I assume we can find a commonly acceptable definition. Best, Volker Am 09.10.2019 um 04:25 schrieb Mark Svancarek (CELA) via Gnso-epdp-team:
Thanks, James. Here are my concerns:
* Some abuse may be high-volume, but high volume is not inherently abusive. If there are industry-standard methods for distinguishing denial-of-service attacks from other high-volume activity, we should adopt them here. * Request formats may change over time. Use of outdated formats during a transition period is not abusive. * Subsequent requests for data where the format has been improved (e.g. missing fields have been populated; more appropriate basis has been submitted; more information that has been discovered during an ongoing investigation is added; etc.) is acceptable. * Repeated requests for a domain name record over are justifiable when it is reasonable to assume that domain name registration data is likely to have changed during an investigation. * In the Port 43 public WhoIs system some requestors used multiple and/or spoofed IP addresses to avoid rate limits imposed by registrars. Until issues of SLAs and funding are resolved, we cannot assume that rate limiting, or quota systems, will apply to SSAD. Whatever systems are ultimately put in place, the following observations about IP addresses and distributed requests should be considered: o It is not unusual to have a case worked on by multiple vendors/attorneys/platforms (e.g. one organization for initial take down requests, another to handle escalations, outside counsel for follow-up and/or suit). o It is not unusual to have a case worked on from multiple geographies. o It is not unusual for a requestor to use a VPN. o Credentialed access should be based on credentials and be neutral to IP addresses - so mitigations based on IP addresses are only applicable for the noncredentialled users of SSAD, if at all. * I am very concerned about the undefined terms “harvesting” and “mining”, which seem to me to be more about intent than any specific activity. Until we specifically describe the behavior to be blocked, we should remove the last bullet.
/marksv
*From:*Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *James M. Bladel *Sent:* Tuesday, October 8, 2019 7:15 PM *To:* gnso-epdp-team@icann.org *Subject:* [Gnso-epdp-team] "Abusive" use of SSAD
Colleagues –
Following up with my homework from last Thursday, here is the non-exhaustive list of “abusive” SSAD behaviors.
I’ve been in discussions with Mark SV, and note that he has some concerns. Expect his comments/edits in a separate message that will be a fast-follow to this post.
Thanks—
J.
-------------
*James Bladel*
GoDaddy
“Abusive” use of SSAD may include (but is not limited to) the following behaviors/practices:
1. High volume submissions of malformed or incomplete requests.
2. Frequent duplicate requests that were previously fulfilled or denied.
3. Use of distributed or spoofed source addresses or platforms to circumvent quotas or rate limits.
4. Use of false or counterfeit credentials to access the system.
5. Storing/delaying and sending high volume requests with the intention of causing SSAD or other parties to fail SLA performance.
6. Attempts or efforts to mine or harvest the data protected by SSAD.
As with other access policy violations, abusive behavior can result in suspension or termination of access to the SSAD.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
As we have not defined high volume, I think it is premature to say that its utility has passed. Recall, a few days ago you said that 1 request per minute would be an acceptable rate limit. That tells me we have a long way to go. Harvesting and mining are similarly undefined. What detectible behavior would you prohibit? From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Volker Greimann Sent: Wednesday, October 9, 2019 1:53 AM To: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] "Abusive" use of SSAD Hi Mark, I think the times of legitimate high volume requests have passed. There are now less invasive methods of confirming domain ownership - such as modifications to the DNS records - that do not require knowing the personal data whom the domain belongs to. High volume requests are almost always an indicator for abuse. You have a point about request formats and we should allow some leeway for formats that have been accurate recently. If the data has actually changed, then that would not be a request for the same data anymore. But I I think we need to have some form of cap for requests for the dame domain by the same requestor. Two to three requests over the course of as many months probably would not count as abusive. Circumventing legitimate rate limits is abusive use of the system as those limits are there for a reason. If multiple vendors are used that access the data, each of those vendors would have to be accredited seperately and therefore not fall under the circumvention rule. If those vendors are however affiliated entities, this would be different. Which brings me to another affiliation requirement: Provide list of all affiliated entities that are already accredited, or have applied for accreditetion, similar to the obligation of registrars to provide lists of all affiliated registrars to ICANN. I think the terms harvesting and mining speak for themselves but I assume we can find a commonly acceptable definition. Best, Volker Am 09.10.2019 um 04:25 schrieb Mark Svancarek (CELA) via Gnso-epdp-team: Thanks, James. Here are my concerns: * Some abuse may be high-volume, but high volume is not inherently abusive. If there are industry-standard methods for distinguishing denial-of-service attacks from other high-volume activity, we should adopt them here. * Request formats may change over time. Use of outdated formats during a transition period is not abusive. * Subsequent requests for data where the format has been improved (e.g. missing fields have been populated; more appropriate basis has been submitted; more information that has been discovered during an ongoing investigation is added; etc.) is acceptable. * Repeated requests for a domain name record over are justifiable when it is reasonable to assume that domain name registration data is likely to have changed during an investigation. * In the Port 43 public WhoIs system some requestors used multiple and/or spoofed IP addresses to avoid rate limits imposed by registrars. Until issues of SLAs and funding are resolved, we cannot assume that rate limiting, or quota systems, will apply to SSAD. Whatever systems are ultimately put in place, the following observations about IP addresses and distributed requests should be considered: * It is not unusual to have a case worked on by multiple vendors/attorneys/platforms (e.g. one organization for initial take down requests, another to handle escalations, outside counsel for follow-up and/or suit). * It is not unusual to have a case worked on from multiple geographies. * It is not unusual for a requestor to use a VPN. * Credentialed access should be based on credentials and be neutral to IP addresses - so mitigations based on IP addresses are only applicable for the noncredentialled users of SSAD, if at all. * I am very concerned about the undefined terms “harvesting” and “mining”, which seem to me to be more about intent than any specific activity. Until we specifically describe the behavior to be blocked, we should remove the last bullet. /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Tuesday, October 8, 2019 7:15 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] "Abusive" use of SSAD Colleagues – Following up with my homework from last Thursday, here is the non-exhaustive list of “abusive” SSAD behaviors. I’ve been in discussions with Mark SV, and note that he has some concerns. Expect his comments/edits in a separate message that will be a fast-follow to this post. Thanks— J. ------------- James Bladel GoDaddy “Abusive” use of SSAD may include (but is not limited to) the following behaviors/practices: 1. High volume submissions of malformed or incomplete requests. 2. Frequent duplicate requests that were previously fulfilled or denied. 3. Use of distributed or spoofed source addresses or platforms to circumvent quotas or rate limits. 4. Use of false or counterfeit credentials to access the system. 5. Storing/delaying and sending high volume requests with the intention of causing SSAD or other parties to fail SLA performance. 6. Attempts or efforts to mine or harvest the data protected by SSAD. As with other access policy violations, abusive behavior can result in suspension or termination of access to the SSAD. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C6fe6b369215d4571e29308d74c962a1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637062080173371482&sdata=nOmc%2FWqL60oRFuQhVO3TpO2ouAC1IaR9UiH%2FC7c2ikA%3D&reserved=0> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C6fe6b369215d4571e29308d74c962a1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637062080173381474&sdata=mSDHsjP0d2yXRRLHu4P2tn6C71sx2LuAyWGoHFF%2Bctw%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C6fe6b369215d4571e29308d74c962a1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637062080173381474&sdata=lbzdh8TsBpO6z1hKGLB6jMkc3nbHDLU2ls7xhiIH3go%3D&reserved=0>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Hi Mark, one per minute still sounds reasonable to me as it allows you 1440 queries per day, which should be sufficient for most legitimate purposes (with most registrars), especially given that each request will have to be reviewed. I can tell you right now that if our registrars would get the full quota of such a rate limit, requests would get backed up pretty quickly. And I guess no one will want a response like this: "Thank you for sending a disclosure request. Your request is currently number 356.152.425 in the queue, which means you can expect a response on or before December 21, 2119. " So setting realistic limitations will be essential for this system to work. Harvesting and mining to me is any activity that is designed to indiscriminately access registration records either with the purpose of finding records that match a specific search parameters (mining) or is designed to create a duplicate copy of the registration base (or parts thereof). So harvesting is basically the preparatory activity of actors such as spear phishers, spammers, DomainTools, autocrat governments, etc, e.g. everyone who has an interest in obtaining a (partial) copy of the database for whatever purpose. And mining is digging in the database with the hope of finding specific "gems". Others may have other or broader definitions, and these definitions may need more work, but these are my assiociations with these terms. Best, Volker Am 09.10.2019 um 17:31 schrieb Mark Svancarek (CELA):
As we have not defined high volume, I think it is premature to say that its utility has passed. Recall, a few days ago you said that 1 request per minute would be an acceptable rate limit. That tells me we have a long way to go.
Harvesting and mining are similarly undefined. What detectible behavior would you prohibit?
*From:*Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Volker Greimann *Sent:* Wednesday, October 9, 2019 1:53 AM *To:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] "Abusive" use of SSAD
Hi Mark,
I think the times of legitimate high volume requests have passed. There are now less invasive methods of confirming domain ownership - such as modifications to the DNS records - that do not require knowing the personal data whom the domain belongs to. High volume requests are almost always an indicator for abuse.
You have a point about request formats and we should allow some leeway for formats that have been accurate recently.
If the data has actually changed, then that would not be a request for the same data anymore. But I I think we need to have some form of cap for requests for the dame domain by the same requestor. Two to three requests over the course of as many months probably would not count as abusive.
Circumventing legitimate rate limits is abusive use of the system as those limits are there for a reason. If multiple vendors are used that access the data, each of those vendors would have to be accredited seperately and therefore not fall under the circumvention rule. If those vendors are however affiliated entities, this would be different. Which brings me to another affiliation requirement: Provide list of all affiliated entities that are already accredited, or have applied for accreditetion, similar to the obligation of registrars to provide lists of all affiliated registrars to ICANN.
I think the terms harvesting and mining speak for themselves but I assume we can find a commonly acceptable definition.
Best,
Volker
Am 09.10.2019 um 04:25 schrieb Mark Svancarek (CELA) via Gnso-epdp-team:
Thanks, James. Here are my concerns:
* Some abuse may be high-volume, but high volume is not inherently abusive. If there are industry-standard methods for distinguishing denial-of-service attacks from other high-volume activity, we should adopt them here. * Request formats may change over time. Use of outdated formats during a transition period is not abusive. * Subsequent requests for data where the format has been improved (e.g. missing fields have been populated; more appropriate basis has been submitted; more information that has been discovered during an ongoing investigation is added; etc.) is acceptable. * Repeated requests for a domain name record over are justifiable when it is reasonable to assume that domain name registration data is likely to have changed during an investigation. * In the Port 43 public WhoIs system some requestors used multiple and/or spoofed IP addresses to avoid rate limits imposed by registrars. Until issues of SLAs and funding are resolved, we cannot assume that rate limiting, or quota systems, will apply to SSAD. Whatever systems are ultimately put in place, the following observations about IP addresses and distributed requests should be considered:
o It is not unusual to have a case worked on by multiple vendors/attorneys/platforms (e.g. one organization for initial take down requests, another to handle escalations, outside counsel for follow-up and/or suit). o It is not unusual to have a case worked on from multiple geographies. o It is not unusual for a requestor to use a VPN. o Credentialed access should be based on credentials and be neutral to IP addresses - so mitigations based on IP addresses are only applicable for the noncredentialled users of SSAD, if at all.
* I am very concerned about the undefined terms “harvesting” and “mining”, which seem to me to be more about intent than any specific activity. Until we specifically describe the behavior to be blocked, we should remove the last bullet.
/marksv
*From:*Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> <mailto:gnso-epdp-team-bounces@icann.org> *On Behalf Of *James M. Bladel *Sent:* Tuesday, October 8, 2019 7:15 PM *To:* gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:* [Gnso-epdp-team] "Abusive" use of SSAD
Colleagues –
Following up with my homework from last Thursday, here is the non-exhaustive list of “abusive” SSAD behaviors.
I’ve been in discussions with Mark SV, and note that he has some concerns. Expect his comments/edits in a separate message that will be a fast-follow to this post.
Thanks—
J.
-------------
*James Bladel*
GoDaddy
“Abusive” use of SSAD may include (but is not limited to) the following behaviors/practices:
1. High volume submissions of malformed or incomplete requests.
2. Frequent duplicate requests that were previously fulfilled or denied.
3. Use of distributed or spoofed source addresses or platforms to circumvent quotas or rate limits.
4. Use of false or counterfeit credentials to access the system.
5. Storing/delaying and sending high volume requests with the intention of causing SSAD or other parties to fail SLA performance.
6. Attempts or efforts to mine or harvest the data protected by SSAD.
As with other access policy violations, abusive behavior can result in suspension or termination of access to the SSAD.
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team@icann.org <mailto:Gnso-epdp-team@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o...>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann....>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann....>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Joking aside, we can argue about exact numbers to no avail if we don’t establish some operational principles first. Those principles need to be grounded in SLAs and cost recovery models. A registrar will definitely have backlogs even at low volume if they do not invest in appropriate staffing and infrastructure to achieve the agreed-upon SLA. As I mentioned in my initial comments, Harvesting and Mining are presumed intents of a requestor, and I don’t know how you plan to determine that it is happening if a requestor is following all the other policy requirements. We’ve already planned safeguards against indiscriminate access. What is the specific behavior, in addition to the policy safeguards we already envisage, that should be prohibited? From: Volker Greimann <vgreimann@key-systems.net> Sent: Wednesday, October 9, 2019 8:45 AM To: Mark Svancarek (CELA) <marksv@microsoft.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] "Abusive" use of SSAD Hi Mark, one per minute still sounds reasonable to me as it allows you 1440 queries per day, which should be sufficient for most legitimate purposes (with most registrars), especially given that each request will have to be reviewed. I can tell you right now that if our registrars would get the full quota of such a rate limit, requests would get backed up pretty quickly. And I guess no one will want a response like this: "Thank you for sending a disclosure request. Your request is currently number 356.152.425 in the queue, which means you can expect a response on or before December 21, 2119. " So setting realistic limitations will be essential for this system to work. Harvesting and mining to me is any activity that is designed to indiscriminately access registration records either with the purpose of finding records that match a specific search parameters (mining) or is designed to create a duplicate copy of the registration base (or parts thereof). So harvesting is basically the preparatory activity of actors such as spear phishers, spammers, DomainTools, autocrat governments, etc, e.g. everyone who has an interest in obtaining a (partial) copy of the database for whatever purpose. And mining is digging in the database with the hope of finding specific "gems". Others may have other or broader definitions, and these definitions may need more work, but these are my assiociations with these terms. Best, Volker Am 09.10.2019 um 17:31 schrieb Mark Svancarek (CELA): As we have not defined high volume, I think it is premature to say that its utility has passed. Recall, a few days ago you said that 1 request per minute would be an acceptable rate limit. That tells me we have a long way to go. Harvesting and mining are similarly undefined. What detectible behavior would you prohibit? From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> On Behalf Of Volker Greimann Sent: Wednesday, October 9, 2019 1:53 AM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] "Abusive" use of SSAD Hi Mark, I think the times of legitimate high volume requests have passed. There are now less invasive methods of confirming domain ownership - such as modifications to the DNS records - that do not require knowing the personal data whom the domain belongs to. High volume requests are almost always an indicator for abuse. You have a point about request formats and we should allow some leeway for formats that have been accurate recently. If the data has actually changed, then that would not be a request for the same data anymore. But I I think we need to have some form of cap for requests for the dame domain by the same requestor. Two to three requests over the course of as many months probably would not count as abusive. Circumventing legitimate rate limits is abusive use of the system as those limits are there for a reason. If multiple vendors are used that access the data, each of those vendors would have to be accredited seperately and therefore not fall under the circumvention rule. If those vendors are however affiliated entities, this would be different. Which brings me to another affiliation requirement: Provide list of all affiliated entities that are already accredited, or have applied for accreditetion, similar to the obligation of registrars to provide lists of all affiliated registrars to ICANN. I think the terms harvesting and mining speak for themselves but I assume we can find a commonly acceptable definition. Best, Volker Am 09.10.2019 um 04:25 schrieb Mark Svancarek (CELA) via Gnso-epdp-team: Thanks, James. Here are my concerns: * Some abuse may be high-volume, but high volume is not inherently abusive. If there are industry-standard methods for distinguishing denial-of-service attacks from other high-volume activity, we should adopt them here. * Request formats may change over time. Use of outdated formats during a transition period is not abusive. * Subsequent requests for data where the format has been improved (e.g. missing fields have been populated; more appropriate basis has been submitted; more information that has been discovered during an ongoing investigation is added; etc.) is acceptable. * Repeated requests for a domain name record over are justifiable when it is reasonable to assume that domain name registration data is likely to have changed during an investigation. * In the Port 43 public WhoIs system some requestors used multiple and/or spoofed IP addresses to avoid rate limits imposed by registrars. Until issues of SLAs and funding are resolved, we cannot assume that rate limiting, or quota systems, will apply to SSAD. Whatever systems are ultimately put in place, the following observations about IP addresses and distributed requests should be considered: * It is not unusual to have a case worked on by multiple vendors/attorneys/platforms (e.g. one organization for initial take down requests, another to handle escalations, outside counsel for follow-up and/or suit). * It is not unusual to have a case worked on from multiple geographies. * It is not unusual for a requestor to use a VPN. * Credentialed access should be based on credentials and be neutral to IP addresses - so mitigations based on IP addresses are only applicable for the noncredentialled users of SSAD, if at all. * I am very concerned about the undefined terms “harvesting” and “mining”, which seem to me to be more about intent than any specific activity. Until we specifically describe the behavior to be blocked, we should remove the last bullet. /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Tuesday, October 8, 2019 7:15 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] "Abusive" use of SSAD Colleagues – Following up with my homework from last Thursday, here is the non-exhaustive list of “abusive” SSAD behaviors. I’ve been in discussions with Mark SV, and note that he has some concerns. Expect his comments/edits in a separate message that will be a fast-follow to this post. Thanks— J. ------------- James Bladel GoDaddy “Abusive” use of SSAD may include (but is not limited to) the following behaviors/practices: 1. High volume submissions of malformed or incomplete requests. 2. Frequent duplicate requests that were previously fulfilled or denied. 3. Use of distributed or spoofed source addresses or platforms to circumvent quotas or rate limits. 4. Use of false or counterfeit credentials to access the system. 5. Storing/delaying and sending high volume requests with the intention of causing SSAD or other parties to fail SLA performance. 6. Attempts or efforts to mine or harvest the data protected by SSAD. As with other access policy violations, abusive behavior can result in suspension or termination of access to the SSAD. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C6e6707304c3b4d06aec108d74ccfa5a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637062327032522884&sdata=cFDOjOM5pvUJZ6HZFvJtQgDZK%2FfBB7DLLA5FeSRKdmE%3D&reserved=0> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C6e6707304c3b4d06aec108d74ccfa5a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637062327032532882&sdata=yobE%2FEhFaqXeFrS1j8aawrwKlfbBdGL4ateUs7OOqI8%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C6e6707304c3b4d06aec108d74ccfa5a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637062327032542879&sdata=TD8WqDuTrCWy4mHNDPHOjJyYrgHKgyTnnae1%2FahUd4c%3D&reserved=0>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
You are right, intent is hard to track when the requestr is not being honest. OTOH, when such behavior is detected, this abusive use would serve to exclude them from the system henceforth. And any behavior that matched paterrns of requests where such intent is likely would be subject to increased scrutiny and review. Finally, our resources are finite and any SSAD must remain economically feasible as well. If it is not, we'd be better advised to stick to legal process for disclosure. Volker Am 09.10.2019 um 18:08 schrieb Mark Svancarek (CELA):
Joking aside, we can argue about exact numbers to no avail if we don’t establish some operational principles first. Those principles need to be grounded in SLAs and cost recovery models. A registrar will definitely have backlogs even at low volume if they do not invest in appropriate staffing and infrastructure to achieve the agreed-upon SLA.
As I mentioned in my initial comments, Harvesting and Mining are presumed intents of a requestor, and I don’t know how you plan to determine that it is happening if a requestor is following all the other policy requirements. We’ve already planned safeguards against indiscriminate access. What is the specific behavior, in addition to the policy safeguards we already envisage, that should be prohibited?
*From:*Volker Greimann <vgreimann@key-systems.net> *Sent:* Wednesday, October 9, 2019 8:45 AM *To:* Mark Svancarek (CELA) <marksv@microsoft.com>; gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] "Abusive" use of SSAD
Hi Mark,
one per minute still sounds reasonable to me as it allows you 1440 queries per day, which should be sufficient for most legitimate purposes (with most registrars), especially given that each request will have to be reviewed. I can tell you right now that if our registrars would get the full quota of such a rate limit, requests would get backed up pretty quickly.
And I guess no one will want a response like this:
"Thank you for sending a disclosure request. Your request is currently number 356.152.425 in the queue, which means you can expect a response on or before December 21, 2119. "
So setting realistic limitations will be essential for this system to work.
Harvesting and mining to me is any activity that is designed to indiscriminately access registration records either with the purpose of finding records that match a specific search parameters (mining) or is designed to create a duplicate copy of the registration base (or parts thereof).
So harvesting is basically the preparatory activity of actors such as spear phishers, spammers, DomainTools, autocrat governments, etc, e.g. everyone who has an interest in obtaining a (partial) copy of the database for whatever purpose.
And mining is digging in the database with the hope of finding specific "gems".
Others may have other or broader definitions, and these definitions may need more work, but these are my assiociations with these terms.
Best,
Volker
Am 09.10.2019 um 17:31 schrieb Mark Svancarek (CELA):
As we have not defined high volume, I think it is premature to say that its utility has passed. Recall, a few days ago you said that 1 request per minute would be an acceptable rate limit. That tells me we have a long way to go.
Harvesting and mining are similarly undefined. What detectible behavior would you prohibit?
*From:*Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> <mailto:gnso-epdp-team-bounces@icann.org> *On Behalf Of *Volker Greimann *Sent:* Wednesday, October 9, 2019 1:53 AM *To:* gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] "Abusive" use of SSAD
Hi Mark,
I think the times of legitimate high volume requests have passed. There are now less invasive methods of confirming domain ownership - such as modifications to the DNS records - that do not require knowing the personal data whom the domain belongs to. High volume requests are almost always an indicator for abuse.
You have a point about request formats and we should allow some leeway for formats that have been accurate recently.
If the data has actually changed, then that would not be a request for the same data anymore. But I I think we need to have some form of cap for requests for the dame domain by the same requestor. Two to three requests over the course of as many months probably would not count as abusive.
Circumventing legitimate rate limits is abusive use of the system as those limits are there for a reason. If multiple vendors are used that access the data, each of those vendors would have to be accredited seperately and therefore not fall under the circumvention rule. If those vendors are however affiliated entities, this would be different. Which brings me to another affiliation requirement: Provide list of all affiliated entities that are already accredited, or have applied for accreditetion, similar to the obligation of registrars to provide lists of all affiliated registrars to ICANN.
I think the terms harvesting and mining speak for themselves but I assume we can find a commonly acceptable definition.
Best,
Volker
Am 09.10.2019 um 04:25 schrieb Mark Svancarek (CELA) via Gnso-epdp-team:
Thanks, James. Here are my concerns:
* Some abuse may be high-volume, but high volume is not inherently abusive. If there are industry-standard methods for distinguishing denial-of-service attacks from other high-volume activity, we should adopt them here. * Request formats may change over time. Use of outdated formats during a transition period is not abusive. * Subsequent requests for data where the format has been improved (e.g. missing fields have been populated; more appropriate basis has been submitted; more information that has been discovered during an ongoing investigation is added; etc.) is acceptable. * Repeated requests for a domain name record over are justifiable when it is reasonable to assume that domain name registration data is likely to have changed during an investigation. * In the Port 43 public WhoIs system some requestors used multiple and/or spoofed IP addresses to avoid rate limits imposed by registrars. Until issues of SLAs and funding are resolved, we cannot assume that rate limiting, or quota systems, will apply to SSAD. Whatever systems are ultimately put in place, the following observations about IP addresses and distributed requests should be considered:
o It is not unusual to have a case worked on by multiple vendors/attorneys/platforms (e.g. one organization for initial take down requests, another to handle escalations, outside counsel for follow-up and/or suit). o It is not unusual to have a case worked on from multiple geographies. o It is not unusual for a requestor to use a VPN. o Credentialed access should be based on credentials and be neutral to IP addresses - so mitigations based on IP addresses are only applicable for the noncredentialled users of SSAD, if at all.
* I am very concerned about the undefined terms “harvesting” and “mining”, which seem to me to be more about intent than any specific activity. Until we specifically describe the behavior to be blocked, we should remove the last bullet.
/marksv
*From:*Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> <mailto:gnso-epdp-team-bounces@icann.org> *On Behalf Of *James M. Bladel *Sent:* Tuesday, October 8, 2019 7:15 PM *To:* gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:* [Gnso-epdp-team] "Abusive" use of SSAD
Colleagues –
Following up with my homework from last Thursday, here is the non-exhaustive list of “abusive” SSAD behaviors.
I’ve been in discussions with Mark SV, and note that he has some concerns. Expect his comments/edits in a separate message that will be a fast-follow to this post.
Thanks—
J.
-------------
*James Bladel*
GoDaddy
“Abusive” use of SSAD may include (but is not limited to) the following behaviors/practices:
1. High volume submissions of malformed or incomplete requests.
2. Frequent duplicate requests that were previously fulfilled or denied.
3. Use of distributed or spoofed source addresses or platforms to circumvent quotas or rate limits.
4. Use of false or counterfeit credentials to access the system.
5. Storing/delaying and sending high volume requests with the intention of causing SSAD or other parties to fail SLA performance.
6. Attempts or efforts to mine or harvest the data protected by SSAD.
As with other access policy violations, abusive behavior can result in suspension or termination of access to the SSAD.
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team@icann.org <mailto:Gnso-epdp-team@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o...>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann....>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann....>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
I agree that detection of policy violation shall result in sanction. But “behavior that matched patterns of requests where such intent is likely” needs to be objectively defined, or we’ll have an unworkable system. We’re not going to define which patterns meet this criteria here on email today, but I hope we’ll make time for it in our upcoming discussions. I’ve already stated that “Those principles need to be grounded in SLAs and cost recovery models.” It’s up to us to define the SLAs and cost recovery models. Let’s not start our policy discussions from an assumption that we’re going to collectively build an economically infeasible system. From: Volker Greimann <vgreimann@key-systems.net> Sent: Wednesday, October 9, 2019 9:23 AM To: Mark Svancarek (CELA) <marksv@microsoft.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] "Abusive" use of SSAD You are right, intent is hard to track when the requestr is not being honest. OTOH, when such behavior is detected, this abusive use would serve to exclude them from the system henceforth. And any behavior that matched paterrns of requests where such intent is likely would be subject to increased scrutiny and review. Finally, our resources are finite and any SSAD must remain economically feasible as well. If it is not, we'd be better advised to stick to legal process for disclosure. Volker Am 09.10.2019 um 18:08 schrieb Mark Svancarek (CELA): Joking aside, we can argue about exact numbers to no avail if we don’t establish some operational principles first. Those principles need to be grounded in SLAs and cost recovery models. A registrar will definitely have backlogs even at low volume if they do not invest in appropriate staffing and infrastructure to achieve the agreed-upon SLA. As I mentioned in my initial comments, Harvesting and Mining are presumed intents of a requestor, and I don’t know how you plan to determine that it is happening if a requestor is following all the other policy requirements. We’ve already planned safeguards against indiscriminate access. What is the specific behavior, in addition to the policy safeguards we already envisage, that should be prohibited? From: Volker Greimann <vgreimann@key-systems.net><mailto:vgreimann@key-systems.net> Sent: Wednesday, October 9, 2019 8:45 AM To: Mark Svancarek (CELA) <marksv@microsoft.com><mailto:marksv@microsoft.com>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] "Abusive" use of SSAD Hi Mark, one per minute still sounds reasonable to me as it allows you 1440 queries per day, which should be sufficient for most legitimate purposes (with most registrars), especially given that each request will have to be reviewed. I can tell you right now that if our registrars would get the full quota of such a rate limit, requests would get backed up pretty quickly. And I guess no one will want a response like this: "Thank you for sending a disclosure request. Your request is currently number 356.152.425 in the queue, which means you can expect a response on or before December 21, 2119. " So setting realistic limitations will be essential for this system to work. Harvesting and mining to me is any activity that is designed to indiscriminately access registration records either with the purpose of finding records that match a specific search parameters (mining) or is designed to create a duplicate copy of the registration base (or parts thereof). So harvesting is basically the preparatory activity of actors such as spear phishers, spammers, DomainTools, autocrat governments, etc, e.g. everyone who has an interest in obtaining a (partial) copy of the database for whatever purpose. And mining is digging in the database with the hope of finding specific "gems". Others may have other or broader definitions, and these definitions may need more work, but these are my assiociations with these terms. Best, Volker Am 09.10.2019 um 17:31 schrieb Mark Svancarek (CELA): As we have not defined high volume, I think it is premature to say that its utility has passed. Recall, a few days ago you said that 1 request per minute would be an acceptable rate limit. That tells me we have a long way to go. Harvesting and mining are similarly undefined. What detectible behavior would you prohibit? From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> On Behalf Of Volker Greimann Sent: Wednesday, October 9, 2019 1:53 AM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] "Abusive" use of SSAD Hi Mark, I think the times of legitimate high volume requests have passed. There are now less invasive methods of confirming domain ownership - such as modifications to the DNS records - that do not require knowing the personal data whom the domain belongs to. High volume requests are almost always an indicator for abuse. You have a point about request formats and we should allow some leeway for formats that have been accurate recently. If the data has actually changed, then that would not be a request for the same data anymore. But I I think we need to have some form of cap for requests for the dame domain by the same requestor. Two to three requests over the course of as many months probably would not count as abusive. Circumventing legitimate rate limits is abusive use of the system as those limits are there for a reason. If multiple vendors are used that access the data, each of those vendors would have to be accredited seperately and therefore not fall under the circumvention rule. If those vendors are however affiliated entities, this would be different. Which brings me to another affiliation requirement: Provide list of all affiliated entities that are already accredited, or have applied for accreditetion, similar to the obligation of registrars to provide lists of all affiliated registrars to ICANN. I think the terms harvesting and mining speak for themselves but I assume we can find a commonly acceptable definition. Best, Volker Am 09.10.2019 um 04:25 schrieb Mark Svancarek (CELA) via Gnso-epdp-team: Thanks, James. Here are my concerns: * Some abuse may be high-volume, but high volume is not inherently abusive. If there are industry-standard methods for distinguishing denial-of-service attacks from other high-volume activity, we should adopt them here. * Request formats may change over time. Use of outdated formats during a transition period is not abusive. * Subsequent requests for data where the format has been improved (e.g. missing fields have been populated; more appropriate basis has been submitted; more information that has been discovered during an ongoing investigation is added; etc.) is acceptable. * Repeated requests for a domain name record over are justifiable when it is reasonable to assume that domain name registration data is likely to have changed during an investigation. * In the Port 43 public WhoIs system some requestors used multiple and/or spoofed IP addresses to avoid rate limits imposed by registrars. Until issues of SLAs and funding are resolved, we cannot assume that rate limiting, or quota systems, will apply to SSAD. Whatever systems are ultimately put in place, the following observations about IP addresses and distributed requests should be considered: * It is not unusual to have a case worked on by multiple vendors/attorneys/platforms (e.g. one organization for initial take down requests, another to handle escalations, outside counsel for follow-up and/or suit). * It is not unusual to have a case worked on from multiple geographies. * It is not unusual for a requestor to use a VPN. * Credentialed access should be based on credentials and be neutral to IP addresses - so mitigations based on IP addresses are only applicable for the noncredentialled users of SSAD, if at all. * I am very concerned about the undefined terms “harvesting” and “mining”, which seem to me to be more about intent than any specific activity. Until we specifically describe the behavior to be blocked, we should remove the last bullet. /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Tuesday, October 8, 2019 7:15 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] "Abusive" use of SSAD Colleagues – Following up with my homework from last Thursday, here is the non-exhaustive list of “abusive” SSAD behaviors. I’ve been in discussions with Mark SV, and note that he has some concerns. Expect his comments/edits in a separate message that will be a fast-follow to this post. Thanks— J. ------------- James Bladel GoDaddy “Abusive” use of SSAD may include (but is not limited to) the following behaviors/practices: 1. High volume submissions of malformed or incomplete requests. 2. Frequent duplicate requests that were previously fulfilled or denied. 3. Use of distributed or spoofed source addresses or platforms to circumvent quotas or rate limits. 4. Use of false or counterfeit credentials to access the system. 5. Storing/delaying and sending high volume requests with the intention of causing SSAD or other parties to fail SLA performance. 6. Attempts or efforts to mine or harvest the data protected by SSAD. As with other access policy violations, abusive behavior can result in suspension or termination of access to the SSAD. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7Ca98b224c5be04e2b791b08d74cd4ff80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637062350024928220&sdata=QVwS3c%2BZz5cnwxCmkcyNA6brqRJAu7tuMUzf224O5X4%3D&reserved=0> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7Ca98b224c5be04e2b791b08d74cd4ff80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637062350024938214&sdata=YO%2FBQeJwV4olvrHIX3maLltKgFdcX5uMdI2igYT9H8w%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7Ca98b224c5be04e2b791b08d74cd4ff80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637062350024938214&sdata=OgEMNJbzdBfyMT4xwrk1gLAw%2B%2BOJC0RbhuHYDhpZ9YM%3D&reserved=0>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
participants (3)
-
James M. Bladel -
Mark Svancarek (CELA) -
Volker Greimann