https://wiki.sanctions.net/api.php?action=feedcontributions&feedformat=atom&user=Woody 2026-04-24T13:30:30Z User contributions MediaWiki 1.35.5 https://wiki.sanctions.net/index.php?title=Welcome_to_the_Internet_Sanctions_Project&diff=322 2024-01-15T12:59:20Z

<p>Woody: /* Why does this project exist? */</p> <hr /> <div>__NOTOC__<br /> This is an [https://en.wikipedia.org/wiki/Open_standard open], [https://en.wikipedia.org/wiki/Internet_governance Internet community governed], project which produces real-time [https://en.wikipedia.org/wiki/Border_Gateway_Protocol BGP] and [https://en.wikipedia.org/wiki/Response_policy_zone RPZ] data feeds of network resources ([https://en.wikipedia.org/wiki/IP_address IP addresses], [https://en.wikipedia.org/wiki/Autonomous_system_(Internet) Autonomous System numbers], and [https://en.wikipedia.org/wiki/Domain_name domain names]) associated with [https://en.wikipedia.org/wiki/Economic_sanctions sanctioned] entities. These data feeds facilitate [https://en.wikipedia.org/wiki/Internet_service_provider Internet network operators] in complying with governmentally-mandated sanctions against violators of international and human rights law.<br /> <br /> === Why does this project exist? ===<br /> Sanctions have been used as a tool of statecraft for [https://foreignpolicy.com/2012/04/23/smart-sanctions-a-short-history/ thousands of years], but their use has become particularly widespread in the latter part of the Twentieth Century. Most sanctions used since the Second World War and until the start of the new Millennium were employed through the United Nations. Over the past 20 years, however, impasse at the United Nations Security Council (UNSC) has meant that a number of national governments and regional organisations also use their own autonomous (or unilateral) sanctions. These can supplement multilateral (UN) sanctions, or can be imposed entirely in their absence. All sanctions regimes employed today are supposed to be &quot;targeted&quot; or &quot;smart&quot; (geared to only impact certain targets and not a country's entire population). <br /> <br /> The United States (US) is the most prolific user of autonomous sanctions, followed by the European Union (EU). A number of other nations, such as the United Kingdom (UK), Canada, Australia and Japan also use autonomous sanctions; often in close coordination with one another. All regional organisations (such as the African Union and the League of Arab States) use sanctions against their own members, but the EU is the only one to use it as a tool of external foreign and security policy. <br /> <br /> In contemporary times, the private sector within each nation is responsible for complying with sanctions adopted by the government where a given company is based. This can include multilateral and autonomous sanctions. In some cases, the US employs secondary sanctions, which have an extraterritorial reach, which means that all individuals, companies and other entities can be subject to US sanctions under certain regimes. The most common types of sanctions used by all actors are asset freezes (against individuals or entities), travel bans (against individuals) and arms embargoes. Since the early 2010s, there have been a rise in sectoral sanctions, such as those against finance, banking, energy and other commodities (in part, or in full). Some sanctions regimes have become so broad and hard-hitting that they can be considered de-facto comprehensive embargoes (or comprehensive sanctions) . <br /> <br /> In the case of sanctions targeting banking sectors, compliance is facilitated by the fact that, while superficially appearing to be multinational, banks are actually collections of individual, autonomous, independently-regulated entities, each existing within a single country, though they may share a common brand. In the case of the &quot;flat&quot; global, transnational nature of the Internet, compliance with diverse sanctions regimes is rendered much more difficult for Internet organizations. Large Internet networks operate as single networks spanning the world, with unitary policy and technical choices implemented globally. Thus a policy imposed by a single government on a global network, if implemented, has [https://en.wikipedia.org/wiki/Extraterritorial_jurisdiction extraterritorial effects] in every other country, violating those countries' [https://en.wikipedia.org/wiki/Westphalian_sovereignty Westphalian] rights of [https://en.wikipedia.org/wiki/Self-determination self-determination]. And conflicting policies imposed by different governments cannot be resolved without breaking the fundamental nature of Internet connectivity.<br /> <br /> At the same time, broadly-defined Internet sanctions tend to disproportionately affect the civilian population of sanctioned countries; this is both counterproductive and violates their human rights to freedom of communication and access to information as recognized by [[Policy:Freedom of Expression and Access to Information|the United Nations, the European Union, the Council of Europe, the Organization of American States, the African Union, and others]]. <br /> <br /> This project brings together governments, Internet organizations, civil society, and academia to provide a globally-harmonized Internet sanctions imposition mechanism that combines the expertise and perspectives of different stakeholders to develop proportional and effective sanctions that aim to not impinge upon civilians' access to information and communications. '''This project is neither pro-sanction nor anti-sanction'''; it exists to facilitate public-sector/private-sector coordination while ensuring that the human rights of civilians are protected.<br /> <br /> === Origin of the project ===<br /> This project originated in an [[The Open Letter|open letter]] from leaders of the multistakeholder Internet governance community, calling for constructive dialog about the imposition of Internet-related sanctions, and for a principled, structured, and transparent approach to sanctions, with the explicit aim of maintaining connectivity to civilian populations. <br /> <br /> === Structure ===<br /> The project is implemented by five working groups:<br /> <br /> * A [[Policy:Policy Group|'''policy group''']] monitors the political situation and the sanction initiatives of national governments, and evaluates whether a situation or proposed sanctions is relevant in light of the project's principles. If a sanction is deemed in-scope, the policy group defines the situation and (potentially) sanctioned entities and passes them to the [[Open Source Intelligence|intelligence group]]. The policy group is responsible for determining the limited scope of measures, analyzing when existing sanctions should be repealed, and for liaising with governments which are considering declaring this mechanism to be sufficient compliance with their nationally-defined sanctions.<br /> <br /> * An [[Open Source Intelligence|'''intelligence group''']] investigates and catalogs the Internet resources (IP addresses, Autonomous System numbers, and domain names) held by sanctioned entities. This helps the [[Policy Group|policy group]] understand the (potential) impact of measures and assess their proportionality. <br /> <br /> * An [[Oversight Board|'''oversight board''']] provides a final check on which resources are included in the blocking feed, verifying its conformity with international and human rights law. When anything is added to the feed, an announcement will be posted to the (read-only) [https://lists.sanctions.net/mailman/listinfo/announce announcement email list], which you're welcome to subscribe to, to keep track of the project's outcomes.<br /> <br /> * An [[Operations Group|'''operations group''']] keeps the BGP and RPZ feed publishing mechanisms working and gather feedback from implementers.<br /> <br /> * A [[Research Group|'''research group''']] is responsible for metrics and monitoring of the system and its effectiveness, and liaises with the academic community.<br /> <br /> === Participation ===<br /> This is a community volunteer effort, and your participation is welcome! Please consider [[Frequently Asked Questions|reading the FAQ]] and subscribing to the [[E-Mail Discussion Lists|email discussion lists]] as starting-points.<br /> <br /> <br /> &lt;!--<br /> == Getting started ==<br /> * Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]<br /> * [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]<br /> --&gt;</div>

Woody https://wiki.sanctions.net/index.php?title=Style_Test&diff=321 2023-02-01T16:13:29Z

<p>Woody: </p> <hr /> <div>=Level 1 Heading '''Bold'''=<br /> Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. [[Nonexistent link]] [[Welcome_to_the_Internet_Sanctions_Project]]<br /> <br /> ==Level 2 Heading '''Bold'''==<br /> Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. [[Nonexistent link]] [[Welcome_to_the_Internet_Sanctions_Project]]<br /> <br /> ===Level 3 Heading '''Bold'''===<br /> Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. [[Nonexistent link]] [[Welcome_to_the_Internet_Sanctions_Project]]<br /> <br /> ====Level 4 Heading '''Bold'''====<br /> Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. [[Nonexistent link]] [[Welcome_to_the_Internet_Sanctions_Project]]<br /> <br /> =====Level 5 Heading '''Bold'''=====<br /> Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. [[Nonexistent link]] [[Welcome_to_the_Internet_Sanctions_Project]]</div>

Woody https://wiki.sanctions.net/index.php?title=Style_Test&diff=320 2023-02-01T16:08:53Z

<p>Woody: Created page with &quot;=Level 1 Heading= Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. Link ==Level 2 Heading== Plain text, '''bold text''', ''italic text'', '''''b...&quot;</p> <hr /> <div>=Level 1 Heading=<br /> Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. [[Link]]<br /> <br /> ==Level 2 Heading==<br /> Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. [[Link]]<br /> <br /> ===Level 3 Heading===<br /> Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. [[Link]]<br /> <br /> ====Level 4 Heading====<br /> Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. [[Link]]<br /> <br /> =====Level 5 Heading=====<br /> Plain text, '''bold text''', ''italic text'', '''''bold italic text'''''. [[Link]]</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Intake_Database&diff=319 2022-08-11T14:17:21Z

<p>Woody: /* Schema Notes */</p> <hr /> <div>== Schema Notes ==<br /> Since a schema will need to be standardized across many governments, it should be as complete as possible in the first definition, since it will be extraordinarily difficult to revise or expand subsequent to adoption.<br /> <br /> * All sanctions should be published in an XML schema which is standardized across all participating governments.<br /> <br /> * When governments wish to &quot;inherit&quot; one or more sanctioned entities, or a whole sanctions regime, from another government, an &quot;inclusion by reference&quot; external citation record should be used, rather than a new record created. Such a record should consist of the URL of the cited entity, a start date, and a (potentially empty) end date.<br /> <br /> * Each government should provide a single canonical well-known location, containing a single file with all currently-active sanctions imposed by that government regardless of agency and, optionally, separate files archiving expired sanctions by decade (i.e. one file covering January 1, 1980 through December 31, 1989) with sanctions assigned to files by date of imposition. (If a sanction lasted from May 1, 2009 through February 15, 2011, it would be recorded in the 2000-2009 file, not the 2010-2020 file.) A standardized naming scheme should be established based on the ISO 3166 Alpha-2 country code and the year range; for example, &quot;sanctions-au-2000-2009.xml&quot; or &quot;sanctions-se-2020-present.xml&quot;<br /> <br /> * Other relevant metadata, like corporation type, gross revenue, gender of person, height and weight of person, should be recorded if available in standardized record types, in standardized (metric) units, with applicable date ranges and, if appropriate, source of authority or information.<br /> <br /> * The most authoritative name of any entity is the version as presented in its native language ''and script''. Not transliterations. The native version should have a flag set which indicates it as such. Each transliteration should be flagged as an alias and labeled by the destination language/script. Names should be rendered in Unicode and labeled as to script and language.<br /> <br /> * Countries should be canonically indicated by their ISO-3166 Alpha-2 abbreviation where available, and a flag should be used to indicate when a country without an assigned ISO-3166 abbreviation is being identified.<br /> <br /> * Suffixes for companies, such as &quot;LLC,&quot; &quot;Joint Stock Company,&quot; &quot;Corp,&quot; and prefixes and suffixes for people, such as &quot;Jr.,&quot; &quot;Honorable,&quot; &quot;Eng.,&quot; &quot;Ph.D&quot; should all be separated from the entity name proper, into separate corporate or individual prefix or suffix fields, and tokenized or harmonized to the degree possible.<br /> <br /> * Relationships between entities should be recorded using standardized forms (&quot;subsidiary,&quot; &quot;parent company,&quot; &quot;controlling owner,&quot; &quot;officer,&quot; &quot;director,&quot; &quot;father,&quot; &quot;step-son,&quot; &quot;spouse,&quot; with applicable date ranges and sources of authority or information where appropriate. Note that many relationships are asymmetrically bidirectional, and thus also require a directionality property: Aunt-Nephew for instance. It may be appropriate to use gender-neutral or gender-inclusive relationship names (i.e. use the same relationship to express father-daughter, mother-son, father-son, and mother-daughter) in order to avoid synchronization issues in cases of unknown or changed genders. Many types of relationships are possible, but this category should not be allowed to become overburdened: it may not be necessary to state that a sanctioned individual is the pilot of a sanctioned aircraft, for instance, when the individual and the aircraft are already related to a common sanctioned holding company by employment and ownership, respectively.<br /> <br /> * For each name, dates of first and most recent observed use should be attached.<br /> <br /> * If an organization is dissolved, or a person dies, a date should be recorded.<br /> <br /> * For each sanction, a start date and, eventually, an end date should be attached to the entity-record, along with the identity of the sanctioning entity, and a link to a standardized identifier of the sanctioning event or reason. A single entity-record may have many separate sanction records attached to it, associated with different countries, different events, and different (possibly overlapping) date-ranges.<br /> <br /> * Sanctioning events or reasons should exist in their own table of unique records, including dates of general imposition or retraction, the entity which imposed them, and a canonical reference to the law, regulation, or finding in which the sanction is documented. The dates attached to the overall event need not be specific to the date level, and need not align exactly with the specific dates on which individual entities were added to the sanction. Each act of national law or regulation which produces a sanction list, whether new or an amendment to an existing list, should be represented as a unique record, with the national legal action being the unique identifier.<br /> <br /> * A table of meta-sanctioning events should be used to link national sanction events. For instance, a meta &quot;Russia-Ukraine conflict&quot; event with a start date of 2014 might be used to tie together many separate national sanctions imposed by different countries with date ranges 2014-present, 2014-2014, 2014-2015, 2021-present, 2022-present, et cetera.<br /> <br /> * People names should be separated into parts, and each part should be flagged with an order-of-rendering and a type: &quot;given name,&quot; &quot;patronymic,&quot; &quot;family name,&quot; &quot;anglicization,&quot; &quot;nickname,&quot; etc.<br /> <br /> * The form of a personal name as it appears on a passport issued by the person's native country should have primacy. Other forms of the name should be flagged as aliases.<br /> <br /> * The most-commonly-used form of a personal name should be flagged as such.<br /> <br /> * All known identifying numbers (corporate registration numbers, [https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei Legal Entity Identifier (LEI)], [https://www.dnb.com/duns-number.html DUNS number], passport numbers, driver's license or ID numbers) should be saved, along with start and end dates of validity, date of issuance, name and location of issuing authority, etc.<br /> <br /> * Identification-issuing authorities should exist in their own separate table of unique entities, with aliases, most-commonly-used-form, structured place names, start and end date of authority, and hierarchical relationship to parent organizations.<br /> <br /> ----<br /> <br /> * When Internet resources are associated with sanctioned entities, they should exist in their own unique tables of IP address, Autonomous System Number, and Domain Name. Each resource should have a start (and potentially end) date which indicates ''its creation and deletion dates'', not the dates at which it was associated with a sanctioned entity. These resources are then linked to sanctioned entities through a table of links, each of which contains, minimally, a unique identifier, pointer to source of authority, sanctioning event or reason, date of record creation, party or process which created the record, start date of link applicability, optional end date of link (or still-in-effect), as well as the unique identifiers of the sanctioned entity and the Internet resource. These links are potentially many-to-many, and multiple links may exist between the same pair of sanctioned entity and resource, at different or overlapping date ranges.</div>

Woody https://wiki.sanctions.net/index.php?title=Welcome_to_the_Internet_Sanctions_Project&diff=318 2022-08-11T14:04:35Z

<p>Woody: /* Structure */</p> <hr /> <div>__NOTOC__<br /> This is an [https://en.wikipedia.org/wiki/Open_standard open], [https://en.wikipedia.org/wiki/Internet_governance Internet community governed], project which produces real-time [https://en.wikipedia.org/wiki/Border_Gateway_Protocol BGP] and [https://en.wikipedia.org/wiki/Response_policy_zone RPZ] data feeds of network resources ([https://en.wikipedia.org/wiki/IP_address IP addresses], [https://en.wikipedia.org/wiki/Autonomous_system_(Internet) Autonomous System numbers], and [https://en.wikipedia.org/wiki/Domain_name domain names]) associated with [https://en.wikipedia.org/wiki/Economic_sanctions sanctioned] entities. These data feeds facilitate [https://en.wikipedia.org/wiki/Internet_service_provider Internet network operators] in complying with governmentally-mandated sanctions against violators of international and human rights law.<br /> <br /> === Why does this project exist? ===<br /> Sanctions have been used as a tool of statecraft for [https://foreignpolicy.com/2012/04/23/smart-sanctions-a-short-history/ thousands of years], but their use has become particularly widespread in the latter part of the Twentieth Century. Most sanctions used since the Second World War and until the start of the new Millennium were employed through the United Nations. Over the past 20 years, however, impasse at the United Nations Security Council (UNSC) has meant that a number of national governments and regional organisations also use their own autonomous (or unilateral) sanctions. These can supplement multilateral (UN) sanctions, or can be imposed entirely in their absence. All sanctions regimes employed today are supposed to be &quot;targeted&quot; or &quot;smart&quot; (geared to only impact on certain targets and not a country's entire population). <br /> <br /> The United States (US) is the most prolific user of autonomous sanctions, followed by the European Union (EU). A number of other nations, such as the United Kingdom (UK), Canada, Australia and Japan also use autonomous sanctions; often in close coordination with one another. All regional organisations (such as the African Union and the League of Arab States) use sanctions against their own members, but the EU is the only one to use it as a tool of external foreign and security policy. <br /> <br /> In contemporary times, the private sector within each nation is responsible for complying with sanctions adopted by the government where a given company is based. This can include multilateral and autonomous sanctions. In some cases, the US employs secondary sanctions, which have an extraterritorial reach, which means that all individuals, companies and other entities can be subject to US sanctions under certain regimes. The most common types of sanctions used by all actors are asset freezes (against individuals or entities), travel bans (against individuals) and arms embargoes. Since the early 2010s, there have been a rise in sectoral sanctions, such as those against finance, banking, energy and other commodities (in part, or in full). Some sanctions regimes have become so broad and hard-hitting that they can be considered de-facto comprehensive embargoes (or comprehensive sanctions) . <br /> <br /> In the case of sanctions targeting banking sectors, compliance is facilitated by the fact that, while superficially appearing to be multinational, banks are actually collections of individual, autonomous, independently-regulated entities, each existing within a single country, though they may share a common brand. In the case of the &quot;flat&quot; global, transnational nature of the Internet, compliance with diverse sanctions regimes is rendered much more difficult for Internet organizations. Large Internet networks operate as single networks spanning the world, with unitary policy and technical choices implemented globally. Thus a policy imposed by a single government on a global network, if implemented, has [https://en.wikipedia.org/wiki/Extraterritorial_jurisdiction extraterritorial effects] in every other country, violating those countries' [https://en.wikipedia.org/wiki/Westphalian_sovereignty Westphalian] rights of [https://en.wikipedia.org/wiki/Self-determination self-determination]. And conflicting policies imposed by different governments cannot be resolved without breaking the fundamental nature of Internet connectivity.<br /> <br /> At the same time, broadly-defined Internet sanctions tend to disproportionately affect the civilian population of sanctioned countries; this is both counterproductive and violates their human rights to freedom of communication and access to information as recognized by [[Policy:Freedom of Expression and Access to Information|the United Nations, the European Union, the Council of Europe, the Organization of American States, the African Union, and others]]. <br /> <br /> This project brings together governments, Internet organizations, civil society, and academia to provide a globally-harmonized Internet sanctions imposition mechanism that combines the expertise and perspectives of different stakeholders to develop proportional and effective sanctions that aim to not impinge upon civilians' access to information and communications. '''This project is neither pro-sanction nor anti-sanction'''; it exists to facilitate public-sector/private-sector coordination while ensuring that the human rights of civilians are protected.<br /> <br /> === Origin of the project ===<br /> This project originated in an [[The Open Letter|open letter]] from leaders of the multistakeholder Internet governance community, calling for constructive dialog about the imposition of Internet-related sanctions, and for a principled, structured, and transparent approach to sanctions, with the explicit aim of maintaining connectivity to civilian populations. <br /> <br /> === Structure ===<br /> The project is implemented by five working groups:<br /> <br /> * A [[Policy:Policy Group|'''policy group''']] monitors the political situation and the sanction initiatives of national governments, and evaluates whether a situation or proposed sanctions is relevant in light of the project's principles. If a sanction is deemed in-scope, the policy group defines the situation and (potentially) sanctioned entities and passes them to the [[Open Source Intelligence|intelligence group]]. The policy group is responsible for determining the limited scope of measures, analyzing when existing sanctions should be repealed, and for liaising with governments which are considering declaring this mechanism to be sufficient compliance with their nationally-defined sanctions.<br /> <br /> * An [[Open Source Intelligence|'''intelligence group''']] investigates and catalogs the Internet resources (IP addresses, Autonomous System numbers, and domain names) held by sanctioned entities. This helps the [[Policy Group|policy group]] understand the (potential) impact of measures and assess their proportionality. <br /> <br /> * An [[Oversight Board|'''oversight board''']] provides a final check on which resources are included in the blocking feed, verifying its conformity with international and human rights law. When anything is added to the feed, an announcement will be posted to the (read-only) [https://lists.sanctions.net/mailman/listinfo/announce announcement email list], which you're welcome to subscribe to, to keep track of the project's outcomes.<br /> <br /> * An [[Operations Group|'''operations group''']] keeps the BGP and RPZ feed publishing mechanisms working and gather feedback from implementers.<br /> <br /> * A [[Research Group|'''research group''']] is responsible for metrics and monitoring of the system and its effectiveness, and liaises with the academic community.<br /> <br /> === Participation ===<br /> This is a community volunteer effort, and your participation is welcome! Please consider [[Frequently Asked Questions|reading the FAQ]] and subscribing to the [[E-Mail Discussion Lists|email discussion lists]] as starting-points.<br /> <br /> <br /> &lt;!--<br /> == Getting started ==<br /> * Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]<br /> * [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]<br /> --&gt;</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Conflict_with_Privacy_Law&diff=317 2022-06-27T11:10:28Z

<p>Woody: </p> <hr /> <div>We should probably begin a conversation with governments over exempting sanctioned entities from the protections of privacy law which would prohibit the sharing of personally identifiable information (such as names, addresses, and IP addresses) used in the sanction implementation process.</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Intake_Database&diff=316 2022-06-27T11:09:31Z

<p>Woody: /* Schema Notes */</p> <hr /> <div>== Schema Notes ==<br /> Since a schema will need to be standardized across many governments, it should be as complete as possible in the first definition, since it will be extraordinarily difficult to revise or expand subsequent to adoption.<br /> <br /> * All sanctions should be published in an XML schema which is standardized across all participating governments.<br /> <br /> * When governments wish to &quot;inherit&quot; one or more sanctioned entities, or a whole sanctions regime, from another government, an &quot;inclusion by reference&quot; external citation record should be used, rather than a new record created. Such a record should consist of the URL of the cited entity, a start date, and a (potentially empty) end date.<br /> <br /> * Each government should provide a single canonical well-known location, containing a single file with all currently-active sanctions imposed by that government regardless of agency and, optionally, separate files archiving expired sanctions by decade (i.e. one file covering January 1, 1980 through December 31, 1989) with sanctions assigned to files by date of imposition. (If a sanction lasted from May 1, 2009 through February 15, 2011, it would be recorded in the 2000-2009 file, not the 2010-2020 file.) A standardized naming scheme should be established based on the ISO 3166 Alpha-2 country code and the year range; for example, &quot;sanctions-au-2000-2009.xml&quot; or &quot;sanctions-se-2020-present.xml&quot;<br /> <br /> * Other relevant metadata, like corporation type, gross revenue, gender of person, height and weight of person, should be recorded if available in standardized record types, in standardized (metric) units, with applicable date ranges and, if appropriate, source of authority or information.<br /> <br /> * The most authoritative name of any entity is the version as presented in its native language ''and script''. Not transliterations. The native version should have a flag set which indicates it as such. Each transliteration should be flagged as an alias and labeled by the destination language/script. Names should be rendered in Unicode and labeled as to script and language.<br /> <br /> * Countries should be canonically indicated by their ISO-3166 Alpha-2 abbreviation where available, and a flag should be used to indicate when a country without an assigned ISO-3166 abbreviation is being identified.<br /> <br /> * Suffixes for companies, such as &quot;LLC,&quot; &quot;Joint Stock Company,&quot; &quot;Corp,&quot; and prefixes and suffixes for people, such as &quot;Jr.,&quot; &quot;Honorable,&quot; &quot;Eng.,&quot; &quot;Ph.D&quot; should all be separated from the entity name proper, into separate corporate or individual prefix or suffix fields, and harmonized to the degree possible.<br /> <br /> * Relationships between entities should be recorded using standardized forms (&quot;subsidiary,&quot; &quot;parent company,&quot; &quot;controlling owner,&quot; &quot;officer,&quot; &quot;director,&quot; &quot;father,&quot; &quot;step-son,&quot; &quot;spouse,&quot; with applicable date ranges and sources of authority or information where appropriate. Note that many relationships are asymmetrically bidirectional, and thus also require a directionality property: Aunt-Nephew for instance. It may be appropriate to use gender-neutral or gender-inclusive relationship names (i.e. use the same relationship to express father-daughter, mother-son, father-son, and mother-daughter) in order to avoid synchronization issues in cases of unknown or changed genders. Many types of relationships are possible, but this category should not be allowed to become overburdened: it may not be necessary to state that a sanctioned individual is the pilot of a sanctioned aircraft, for instance, when the individual and the aircraft are already related to a common sanctioned holding company by employment and ownership, respectively.<br /> <br /> * For each name, dates of first and most recent observed use should be attached.<br /> <br /> * If an organization is dissolved, or a person dies, a date should be recorded.<br /> <br /> * For each sanction, a start date and, eventually, an end date should be attached to the entity-record, along with the identity of the sanctioning entity, and a link to a standardized identifier of the sanctioning event or reason. A single entity-record may have many separate sanction records attached to it, associated with different countries, different events, and different (possibly overlapping) date-ranges.<br /> <br /> * Sanctioning events or reasons should exist in their own table of unique records, including dates of general imposition or retraction, the entity which imposed them, and a canonical reference to the law, regulation, or finding in which the sanction is documented. The dates attached to the overall event need not be specific to the date level, and need not align exactly with the specific dates on which individual entities were added to the sanction. Each act of national law or regulation which produces a sanction list, whether new or an amendment to an existing list, should be represented as a unique record, with the national legal action being the unique identifier.<br /> <br /> * A table of meta-sanctioning events should be used to link national sanction events. For instance, a meta &quot;Russia-Ukraine conflict&quot; event with a start date of 2014 might be used to tie together many separate national sanctions imposed by different countries with date ranges 2014-present, 2014-2014, 2014-2015, 2021-present, 2022-present, et cetera.<br /> <br /> * People names should be separated into parts, and each part should be flagged with an order-of-rendering and a type: &quot;given name,&quot; &quot;patronymic,&quot; &quot;family name,&quot; &quot;anglicization,&quot; &quot;nickname,&quot; etc.<br /> <br /> * The form of a personal name as it appears on a passport issued by the person's native country should have primacy. Other forms of the name should be flagged as aliases.<br /> <br /> * The most-commonly-used form of a personal name should be flagged as such.<br /> <br /> * All known identifying numbers (corporate registration numbers, [https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei Legal Entity Identifier (LEI)], [https://www.dnb.com/duns-number.html DUNS number], passport numbers, driver's license or ID numbers) should be saved, along with start and end dates of validity, date of issuance, name and location of issuing authority, etc.<br /> <br /> * Identification-issuing authorities should exist in their own separate table of unique entities, with aliases, most-commonly-used-form, structured place names, start and end date of authority, and hierarchical relationship to parent organizations.<br /> <br /> ----<br /> <br /> * When Internet resources are associated with sanctioned entities, they should exist in their own unique tables of IP address, Autonomous System Number, and Domain Name. Each resource should have a start (and potentially end) date which indicates ''its creation and deletion dates'', not the dates at which it was associated with a sanctioned entity. These resources are then linked to sanctioned entities through a table of links, each of which contains, minimally, a unique identifier, pointer to source of authority, sanctioning event or reason, date of record creation, party or process which created the record, start date of link applicability, optional end date of link (or still-in-effect), as well as the unique identifiers of the sanctioned entity and the Internet resource. These links are potentially many-to-many, and multiple links may exist between the same pair of sanctioned entity and resource, at different or overlapping date ranges.</div>

Woody https://wiki.sanctions.net/index.php?title=Frequently_Asked_Questions&diff=315 2022-06-11T16:23:30Z

<p>Woody: /* What is the purpose of this project? */</p> <hr /> <div>=== What is the purpose of this project? ===<br /> This project allows Internet organizations to comply with the sanctions imposed by the government or governments to which they're responsible, without &quot;over-complying&quot; by blocking entities which are not specifically named in those sanctions.<br /> <br /> === Who is it for? ===<br /> This project is operated by and for Internet organizations which are required by governmental regulation to comply with sanctions. Since this project is never inherently ''pro sanction'', we do not anticipate, nor advocate, that organizations which are not regulatorily required to comply with sanctions automate action based on the project's data feeds (e.g. the project does wants to help avoid over-compliance with sanctions by Internet organizations, rather than contributing to it).<br /> <br /> === How does it work? ===<br /> The project uses standardized protocols (BGP and RPZ) to distribute lists of Internet networks and domain names associated with sanctioned entities in ways that Internet network operators already use for blocking spam senders, DDoS attackers, malware distribution, and other threats against the Internet's infrastructure.<br /> <br /> === Who runs it? ===<br /> This is a typical Internet governance organization. It is operated by volunteers, and decisions are made by those who show up and do the work. There are no barriers to entry which would prevent any other organization from forming to perform the same function in a different way, or a competing effort in the same way.<br /> <br /> === Does this project advocate for sanctions? ===<br /> No, this project is agnostic with regard to whether sanctions should or should not exist, or should or should not be levied by any government against any party. Sanctions exist, and have done for centuries, and governments and society (particularly those in the Global North) generally regard them as deescalatory and preferable to violent alternatives. The aim of this project is to assist governments (that wish to impose sanctions) and network operators (that wish to comply with governmental requirements) to reach a mutually-satisfactory state. If you don't like the idea of sanctions, you can take that up with the government of your choice; this is not a forum for debate on fundamental questions such as whether sanctions should exist.<br /> <br /> === Do Internet sanctions disconnect anyone from the Internet? ===<br /> No, Internet sanctions remove the societal subsidy from the cost of Internet access to sanctioned entities. In the same way that banking sanctions don't prevent sanctioned entities from using money, they just increase the friction and cost of doing so, Internet sanctions don't disconnect sanctioned parties from the Internet, they just ensure that they pay the full cost of using it, without the subsidies which would normally be provided as a function of societal cooperation.<br /> <br /> === Is anyone required to use this project? ===<br /> No, this project is entirely voluntary. The relationship between this project and Internet network operators is exactly the same as the relationship between many preexisting organizations which provide similar blocklists identifying spam, malware, phishing, DDoS, and other forms of abuse to network operators, and the functional mechanisms are identical. Network operators choose to subscribe to the data-feeds we provide, or not, and choose to act upon the data, or not. The obligation to comply with sanctions imposed by the governments, regional organizations or international organizatinos in which the network operators are incorporated, however, is not voluntary, it's mandatory under law. This project gives network operators a mechanism for complying with those mandatory requirements and helping to avoid operators from over-complying with measures that might otherwise arise due to lack of clarity of sufficient information on sanctions designations and legal requirements.<br /> <br /> === What is the beacon? ===<br /> The beacon is a set of artificial IP addresses and domain names which are not associated with any real-world organization or users, which will always be &quot;sanctioned&quot; and can thus be used by researchers to measure the reach and effect of the system. If the beacon is visible to you, the Internet sanctioning feeds are not being consumed by your transit providers or DNS recursive resolver operators. Beacons are a frequently-implemented diagnostic feature of Internet routing security systems.<br /> <br /> === Is that really supposed to be a logo in the top left corner? ===<br /> Yes, well, it wasn't the highest priority at the time, and these things are always stickier than you hope. A better project logo would be very welcome. Consensus is, as always in open projects, the difficult part.</div>

Woody https://wiki.sanctions.net/index.php?title=User:Woody&diff=305 2022-06-01T10:05:23Z

<p>Woody: /* Hi! */</p> <hr /> <div>__NOTOC__<br /> ===Hi!===<br /> [[File:Bill Woodcock-Stockholm-2022.png|200px|frameless|right]]<br /> I'm [https://en.wikipedia.org/wiki/Bill_Woodcock '''Bill Woodcock'''].<br /> <br /> I'm one of the signatories of the [[open letter]], one of the administrators of this wiki, and I help with implementation of the back-end systems that provide the data feeds to subscribing networks.<br /> <br /> I'm also the executive director of [https://pch.net Packet Clearing House], chairman of the foundation council of [https://quad9.net Quad9], and serve on the boards of the [https://www.ccor.org Cooperative Corporation of .ORG Registrants] and the [https://www.m3aawg.org M3AA Foundation].<br /> <br /> You can also find me on [https://www.linkedin.com/in/bwoodcock/ LinkedIn], [https://www.quora.com/profile/Bill-Woodcock-3 Quora] or [https://twitter.com/woodyatpch Twitter].<br /> <br /> === Conflicts of Interest ===<br /> <br /> ==== Current ====<br /> I do not currently receive any money or other consideration from any military or propaganda agency, nor am I involved in the sanctions decision-making process of any government.<br /> <br /> '''Fuerzas Armadas de Honduras''': I oversee the DNSSEC cryptographic key management for the Honduran armed forces, along with the rest of the Honduran government and ccTLD, in a noncommercial role.<br /> <br /> '''Forças Armadas de Defesa de Moçambique''': I oversee the DNSSEC cryptographic key management for the Mozambican armed forces, along with the rest of the Mozambican government and ccTLD, in a noncommercial role.<br /> <br /> '''Nigerian Ministry of Defence''': I oversee the DNSSEC cryptographic key management for the Nigerian armed forces, along with the rest of the Nigerian government and ccTLD, in a noncommercial role.<br /> <br /> '''Ugandan Ministry of Defence and Veterans Affairs''': I oversee the DNSSEC cryptographic key management for the Ugandan armed forces, along with the rest of the Ugandan government and ccTLD, in a noncommercial role.<br /> <br /> '''Zimbabwe Ministry of Defence''': I oversee the DNSSEC cryptographic key management for the Zimbabwean armed forces, along with the rest of the Zimbabwean government and ccTLD, in a noncommercial role.<br /> <br /> '''Forcas Defesa Timor Lorosae''': I oversee the DNSSEC cryptographic key management for the Timor Leste armed forces, along with the rest of the Timor Leste government and ccTLD, in a noncommercial role.<br /> <br /> '''Illersuisut''': I oversee the DNSSEC cryptographic key management for the Greenlandic portion of the Forsvarsministeriet, along with the rest of the Greenlandic government and ccTLD, in a noncommercial role.<br /> <br /> '''Ministere de la Defense d'Haïti''': I oversee the DNSSEC cryptographic key management for the Haitian armed forces, along with the rest of the Haitian government and ccTLD, in a noncommercial role.<br /> <br /> '''Wasaaradda Gaashaandhigga''': I oversee the DNSSEC cryptographic key management for the Somali armed forces, along with the rest of the Somali government and ccTLD, in a noncommercial role.<br /> <br /> '''CISA''': I serve in an unpaid role on the US [https://en.wikipedia.org/wiki/Cybersecurity_and_Infrastructure_Security_Agency Cybersecurity and Infrastructure Security Agency] [https://twitter.com/CISAJen/status/1502313208547270658 Technical Advisory Council], advising on topics related to cyber-defense and infrastructure resilience.<br /> <br /> ==== Historical ====<br /> <br /> '''Al Jazeera''': In 2013, I wrote [http://america.aljazeera.com/articles/2013/9/20/brazil-internet-dilmarousseffnsa.html an article] on Brazilian industrial development which was published in [https://en.wikipedia.org/wiki/Al_Jazeera Al Jazeera]. Al Jazeera is funded in part by the government of [https://en.wikipedia.org/wiki/Qatar Qatar] and considered by some to be a voice of pro-[https://en.wikipedia.org/wiki/Sunni_Islam Sunni], anti-[https://en.wikipedia.org/wiki/Shia_Islam Shia], propaganda. Al Jazeera has been sanctioned at various times by Saudi Arabia, the United Arab Emirates, Bahrain and Egypt, generally as part of larger conflicts between Qatar and its neighboring countries.<br /> <br /> '''US Defense Department''': I was a member of the [http://www.pirp.harvard.edu/pubs_pdf/o%27neill/o%27neill-i01-3.pdf Highlands Forum], and have performed paid consulting for the [https://policy.defense.gov DoD office of Policy], and received research grants from [https://en.wikipedia.org/wiki/DARPA DARPA], all on topics related to cyber-defense and infrastructure resilience.<br /> <br /> '''Singapore Ministry of Defence''': I have performed paid consulting for the Singaporean [https://en.wikipedia.org/wiki/Ministry_of_Defence_(Singapore) Ministry of Defense] and precursors to the Singaporean [https://en.wikipedia.org/wiki/Cyber_Security_Agency_(Singapore) Cyber Security Agency], all on topics related to cyber-defense and infrastructure resilience.</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Intake_Database&diff=304 2022-05-18T11:37:19Z

<p>Woody: </p> <hr /> <div>== Schema Notes ==<br /> Since a schema will need to be standardized across many governments, it should be as complete as possible in the first definition, since it will be extraordinarily difficult to revise or expand subsequent to adoption.<br /> <br /> * All sanctions should be published in an XML schema which is standardized across all participating governments.<br /> <br /> * Each government should provide a single canonical well-known location, containing a single file with all currently-active sanctions imposed by that government regardless of agency and, optionally, separate files archiving expired sanctions by decade (i.e. one file covering January 1, 1980 through December 31, 1989) with sanctions assigned to files by date of imposition. (If a sanction lasted from May 1, 2009 through February 15, 2011, it would be recorded in the 2000-2009 file, not the 2010-2020 file.) A standardized naming scheme should be established based on the ISO 3166 Alpha-2 country code and the year range; for example, &quot;sanctions-au-2000-2009.xml&quot; or &quot;sanctions-se-2020-present.xml&quot;<br /> <br /> * Other relevant metadata, like corporation type, gross revenue, gender of person, height and weight of person, should be recorded if available in standardized record types, in standardized (metric) units, with applicable date ranges and, if appropriate, source of authority or information.<br /> <br /> * The most authoritative name of any entity is the version as presented in its native language ''and script''. Not transliterations. The native version should have a flag set which indicates it as such. Each transliteration should be flagged as an alias and labeled by the destination language/script. Names should be rendered in Unicode and labeled as to script and language.<br /> <br /> * Countries should be canonically indicated by their ISO-3166 Alpha-2 abbreviation where available, and a flag should be used to indicate when a country without an assigned ISO-3166 abbreviation is being identified.<br /> <br /> * Suffixes for companies, such as &quot;LLC,&quot; &quot;Joint Stock Company,&quot; &quot;Corp,&quot; and prefixes and suffixes for people, such as &quot;Jr.,&quot; &quot;Honorable,&quot; &quot;Eng.,&quot; &quot;Ph.D&quot; should all be separated from the entity name proper, into separate corporate or individual prefix or suffix fields, and harmonized to the degree possible.<br /> <br /> * Relationships between entities should be recorded using standardized forms (&quot;subsidiary,&quot; &quot;parent company,&quot; &quot;controlling owner,&quot; &quot;officer,&quot; &quot;director,&quot; &quot;father,&quot; &quot;step-son,&quot; &quot;spouse,&quot; with applicable date ranges and sources of authority or information where appropriate. Note that many relationships are asymmetrically bidirectional, and thus also require a directionality property: Aunt-Nephew for instance. It may be appropriate to use gender-neutral or gender-inclusive relationship names (i.e. use the same relationship to express father-daughter, mother-son, father-son, and mother-daughter) in order to avoid synchronization issues in cases of unknown or changed genders. Many types of relationships are possible, but this category should not be allowed to become overburdened: it may not be necessary to state that a sanctioned individual is the pilot of a sanctioned aircraft, for instance, when the individual and the aircraft are already related to a common sanctioned holding company by employment and ownership, respectively.<br /> <br /> * For each name, dates of first and most recent observed use should be attached.<br /> <br /> * If an organization is dissolved, or a person dies, a date should be recorded.<br /> <br /> * For each sanction, a start date and, eventually, an end date should be attached to the entity-record, along with the identity of the sanctioning entity, and a link to a standardized identifier of the sanctioning event or reason. A single entity-record may have many separate sanction records attached to it, associated with different countries, different events, and different (possibly overlapping) date-ranges.<br /> <br /> * Sanctioning events or reasons should exist in their own table of unique records, including dates of general imposition or retraction, the entity which imposed them, and a canonical reference to the law, regulation, or finding in which the sanction is documented. The dates attached to the overall event need not be specific to the date level, and need not align exactly with the specific dates on which individual entities were added to the sanction. Each act of national law or regulation which produces a sanction list, whether new or an amendment to an existing list, should be represented as a unique record, with the national legal action being the unique identifier.<br /> <br /> * A table of meta-sanctioning events should be used to link national sanction events. For instance, a meta &quot;Russia-Ukraine conflict&quot; event with a start date of 2014 might be used to tie together many separate national sanctions imposed by different countries with date ranges 2014-present, 2014-2014, 2014-2015, 2021-present, 2022-present, et cetera.<br /> <br /> * People names should be separated into parts, and each part should be flagged with an order-of-rendering and a type: &quot;given name,&quot; &quot;patronymic,&quot; &quot;family name,&quot; &quot;anglicization,&quot; &quot;nickname,&quot; etc.<br /> <br /> * The form of a personal name as it appears on a passport issued by the person's native country should have primacy. Other forms of the name should be flagged as aliases.<br /> <br /> * The most-commonly-used form of a personal name should be flagged as such.<br /> <br /> * All known identifying numbers (corporate registration numbers, [https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei Legal Entity Identifier (LEI)], [https://www.dnb.com/duns-number.html DUNS number], passport numbers, driver's license or ID numbers) should be saved, along with start and end dates of validity, date of issuance, name and location of issuing authority, etc.<br /> <br /> * Identification-issuing authorities should exist in their own separate table of unique entities, with aliases, most-commonly-used-form, structured place names, start and end date of authority, and hierarchical relationship to parent organizations.<br /> <br /> ----<br /> <br /> * When Internet resources are associated with sanctioned entities, they should exist in their own unique tables of IP address, Autonomous System Number, and Domain Name. Each resource should have a start (and potentially end) date which indicates ''its creation and deletion dates'', not the dates at which it was associated with a sanctioned entity. These resources are then linked to sanctioned entities through a table of links, each of which contains, minimally, a unique identifier, pointer to source of authority, sanctioning event or reason, date of record creation, party or process which created the record, start date of link applicability, optional end date of link (or still-in-effect), as well as the unique identifiers of the sanctioned entity and the Internet resource. These links are potentially many-to-many, and multiple links may exist between the same pair of sanctioned entity and resource, at different or overlapping date ranges.</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Intake_Database&diff=303 2022-05-18T11:30:35Z

<p>Woody: </p> <hr /> <div>== Schema Notes ==<br /> Since a schema will need to be standardized across many governments, it should be as complete as possible in the first definition, since it will be extraordinarily difficult to revise or expand subsequent to adoption.<br /> <br /> * All sanctions should be published in an XML schema which is standardized across all participating governments.<br /> <br /> * Each government should provide a single canonical well-known location, containing a single file with all currently-active sanctions imposed by that government regardless of agency and, optionally, separate files archiving expired sanctions by decade (i.e. one file covering January 1, 1980 through December 31, 1989) with sanctions assigned to files by date of imposition. (If a sanction lasted from May 1, 2009 through February 15, 2011, it would be recorded in the 2000-2009 file, not the 2010-2020 file.) A standardized naming scheme should be established based on the ISO 3166 Alpha-2 country code and the year range; for example, &quot;sanctions-au-2000-2009.xml&quot; or &quot;sanctions-se-2020-present.xml&quot;<br /> <br /> * Other relevant metadata, like corporation type, gross revenue, gender of person, height and weight of person, should be recorded if available in standardized record types, in standardized (metric) units, with applicable date ranges and, if appropriate, source of authority or information.<br /> <br /> * The most authoritative name of any entity is the version as presented in its native language ''and script''. Not transliterations. The native version should have a flag set which indicates it as such. Each transliteration should be flagged as an alias and labeled by the destination language/script. Names should be rendered in Unicode and labeled as to script and language.<br /> <br /> * Countries should be canonically indicated by their ISO-3166 Alpha-2 abbreviation where available, and a flag should be used to indicate when a country without an assigned ISO-3166 abbreviation is being identified.<br /> <br /> * Suffixes for companies, such as &quot;LLC,&quot; &quot;Joint Stock Company,&quot; &quot;Corp,&quot; and prefixes and suffixes for people, such as &quot;Jr.,&quot; &quot;Honorable,&quot; &quot;Eng.,&quot; &quot;Ph.D&quot; should all be separated from the entity name proper, into separate corporate or individual prefix or suffix fields, and harmonized to the degree possible.<br /> <br /> * Relationships between entities should be recorded using standardized forms (&quot;subsidiary,&quot; &quot;parent company,&quot; &quot;controlling owner,&quot; &quot;officer,&quot; &quot;director,&quot; &quot;father,&quot; &quot;step-son,&quot; &quot;spouse,&quot; with applicable date ranges and sources of authority or information where appropriate. Note that many relationships are asymmetrically bidirectional, and thus also require a directionality property: Aunt-Nephew for instance. It may be appropriate to use gender-neutral or gender-inclusive relationship names (i.e. use the same relationship to express father-daughter, mother-son, father-son, and mother-daughter) in order to avoid synchronization issues in cases of unknown or changed genders. Many types of relationships are possible, but this category should not be allowed to become overburdened: it may not be necessary to state that a sanctioned individual is the pilot of a sanctioned aircraft, for instance, when the individual and the aircraft are already related to a common sanctioned holding company by employment and ownership, respectively.<br /> <br /> * For each name, dates of first and most recent observed use should be attached.<br /> <br /> * If an organization is dissolved, or a person dies, a date should be recorded.<br /> <br /> * For each sanction, a start date and, eventually, an end date should be attached to the entity-record, along with the identity of the sanctioning entity, and a link to a standardized identifier of the sanctioning event or reason. A single entity-record may have many separate sanction records attached to it, associated with different countries, different events, and different (possibly overlapping) date-ranges.<br /> <br /> * Sanctioning events or reasons should exist in their own table of unique records, including dates of general imposition or retraction, the entity which imposed them, and a canonical reference to the law, regulation, or finding in which the sanction is documented. The dates attached to the overall event need not be specific to the date level, and need not align exactly with the specific dates on which individual entities were added to the sanction. Each act of national law or regulation which produces a sanction list, whether new or an amendment to an existing list, should be represented as a unique record, with the national legal action being the unique identifier.<br /> <br /> * A table of meta-sanctioning events should be used to link national sanction events. For instance, a meta &quot;Russia-Ukraine conflict&quot; event with a start date of 2014 might be used to tie together many separate national sanctions imposed by different countries with date ranges 2014-present, 2014-2014, 2014-2015, 2021-present, 2022-present, et cetera.<br /> <br /> * People names should be separated into parts, and each part should be flagged with an order-of-rendering and a type: &quot;given name,&quot; &quot;patronymic,&quot; &quot;family name,&quot; &quot;anglicization,&quot; &quot;nickname,&quot; etc.<br /> <br /> * The form of a personal name as it appears on a passport issued by the person's native country should have primacy. Other forms of the name should be flagged as aliases.<br /> <br /> * The most-commonly-used form of a personal name should be flagged as such.<br /> <br /> * All known identifying numbers (corporate registration numbers, [https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei Legal Entity Identifier (LEI)], [https://www.dnb.com/duns-number.html DUNS number], passport numbers, driver's license or ID numbers) should be saved, along with start and end dates of validity, date of issuance, name and location of issuing authority, etc.<br /> <br /> * Identification-issuing authorities should exist in their own separate table of unique entities, with aliases, most-commonly-used-form, structured place names, start and end date of authority, and hierarchical relationship to parent organizations.<br /> <br /> ----<br /> <br /> * When Internet resources are associated with sanctioned entities, they should exist in their own unique tables of IP address, Autonomous System Number, and Domain Name. Each resource should have a start (and potentially end) date which indicates ''its creation and deletion dates'' not the dates at which it was associated with a sanctioned entity. These resources are then linked to sanctioned entities through a table of links, each of which contains, minimally, a unique identifier, pointer to source of authority, date of record creation, party or process which created the record, start date of link, optional end date of link (or still-in-effect), as well as the unique identifiers of the sanctioned entity and the Internet resource.</div>

Woody https://wiki.sanctions.net/index.php?title=The_Open_Letter&diff=302 2022-04-22T09:38:00Z

<p>Woody: </p> <hr /> <div>{{TOC right}}<br /> {{clear}}<br /> On March 10, 2022, members of the Multistakeholder Internet governance community published the following open letter:<br /> {{clear}}<br /> ----<br /> {{right|Thursday, March 10, 2022}}&lt;br&gt;<br /> {{right|The Hague}}<br /> ==Multistakeholder Imposition of Internet Sanctions==<br /> <br /> ===Executive Summary===<br /> The invasion of Ukraine poses a new challenge for multistakeholder Internet infrastructure governance. In this statement, we discuss possible sanctions and their ramifications, lay out principles that we believe should guide Internet sanctions, and propose a multistakeholder governance mechanism to facilitate decision-making and implementation. <br /> <br /> ===Introduction===<br /> The Internet is in its thirtieth year of transition from national to multistakeholder governance. As we encounter pivotal moments, we must decide as a community whether Internet self-governance has matured sufficiently to address such newly encountered issue. Governments have imposed sanctions throughout history, but the global Internet governance community has not yet established a process dedicated to this task. <br /> <br /> We believe it is now incumbent upon the Internet community to deliberate and make decisions in the face of humanitarian crises. We may not responsibly dismiss such crises without consideration, nor with consideration only for the self-interest of our community’s own direct constituents; instead, maturity of governance requires that self-interests be weighed in the balance with broader moral and societal considerations. This document is the beginning of a global Internet governance conversation about the appropriate scope of sanctions, the feasibility of sanctions within the realm of our collective responsibility, and our moral imperative to minimize detrimental consequences.<br /> <br /> ===Principles for Internet Infrastructure Governance Sanctions===<br /> We, the undersigned, agree to the following principles:<br /> <br /> * Disconnecting the population of a country from the Internet is a disproportionate and inappropriate sanction, since it hampers their access to the very information that might lead them to withdraw support for acts of war and leaves them with access to only the information their own government chooses to furnish.<br /> <br /> * The effectiveness of sanctions should be evaluated relative to predefined goals. Ineffective sanctions waste effort and willpower and convey neither unity nor conviction. <br /> <br /> * Sanctions should be focused and precise. They should minimize the chance of unintended consequences or collateral damage. Disproportionate or over-broad sanctions risk fundamentally alienating populations.<br /> <br /> * Military and propaganda agencies and their information infrastructure are potential targets of sanctions.<br /> <br /> * The Internet, due to its transnational nature and consensus-driven multistakeholder system of governance, currently does not easily lend itself to the imposition of sanctions in national conflicts.<br /> <br /> * It is inappropriate and counterproductive for governments to attempt to compel Internet governance mechanisms to impose sanctions outside of the community’s multistakeholder decision-making process.<br /> <br /> * There are nonetheless appropriate, effective, and specific sanctions the Internet governance community may wish to consider in its deliberative processes.<br /> <br /> ===Recommendations===<br /> We believe it is the responsibility of the global Internet governance community to weigh the costs and risks of sanctions against the moral imperatives that call us to action in defense of society, and we must address this governance problem now and in the future. '''We believe the time is right for the formation of a new, minimal, multistakeholder mechanism, similar in scale to NSP-Sec or Outages, which after due process and consensus would publish sanctioned IP addresses and domain names in the form of public data feeds in standard forms (BGP and RPZ), to be consumed by any organization that chooses to subscribe to the principles and their outcome.''' This process should use clearly documented procedures to assess violations of international norms in an open, multistakeholder, and consensus-driven process, taking into account the principles of non-overreach and effectiveness in making its determinations. This system mirrors existing systems used by network operators to block spam, malware, and DDoS attacks, so it requires no new technology and minimal work to implement.<br /> <br /> We call upon our colleagues to participate in a multistakeholder deliberation using the mechanism outlined above, to decide whether the IP addresses and domain names of the Russian military and its propaganda organs should be sanctioned, and to lay the groundwork for timely decisions of similar gravity and urgency in the future.<br /> <br /> ===Signed,===<br /> Bart Groothuis{{gray|, Member of the European Parliament, Netherlands}}&lt;br&gt;<br /> Bill Woodcock{{gray|, Executive Director, Packet Clearing House}}&lt;br&gt;<br /> Ihab Osman{{gray|, Non-Executive Director, Internet Corporation for Assigned Names and Numbers}}&lt;br&gt;<br /> Mike Roberts{{gray|, founding President and CEO, Internet Corporation for Assigned Names and Numbers}}&lt;br&gt;<br /> Jeff Moss{{gray|, President, DEFCON}}&lt;br&gt;<br /> Niels ten Oever{{gray|, Postdoctoral Researcher, University of Amsterdam}}&lt;br&gt;<br /> Marina Kaljurand{{gray|, Member of the European Parliament, Estonia, former ambassador to Russia and the United States}}&lt;br&gt;<br /> Eva Kaili{{gray|, Member of the European Parliament, Greece}}&lt;br&gt;<br /> Runa Sandvik{{gray|, security researcher}}&lt;br&gt;<br /> Kurt Opsahl{{gray|, Electronic Frontier Foundation (affiliation for identification purposes only)}}&lt;br&gt;<br /> 
John Levine{{gray|, President, CAUCE North America}}&lt;br&gt;<br /> Virendra Rode{{gray|, founder and contributor, Outages.ORG}}&lt;br&gt;<br /> Stephen D. Crocker{{gray|, Edgemoor Research Institute}}&lt;br&gt;<br /> Job Snijders{{gray|, board member, RIPE NCC, PeeringDB, and Route Server Support Foundation}}&lt;br&gt;<br /> Moez Chakchouk{{gray|, Director of Policy, PCH, former ADG/CI UNESCO and former Tunisian minister}}&lt;br&gt;<br /> Doug Madory{{gray|, Director of Internet Analysis, Kentik}}&lt;br&gt;<br /> Ondrej Filip{{gray|, CEO, CZ.NIC}}&lt;br&gt;<br /> Greg Rattray{{gray|, Founder, Next Peak and former cybersecurity advisor to ICANN}}&lt;br&gt;<br /> Serge Droz{{gray|, in personal capacity, Director FIRST}}&lt;br&gt;<br /> Mark Tinka{{gray|, board member, FranceIX}}&lt;br&gt;<br /> Dmitry Kohmanyuk{{gray|, founder, Hostmaster Ltd.}}&lt;br&gt;<br /> Timothy Denton{{gray|, Chairman, Internet Society, Canada Chapter}}&lt;br&gt;<br /> Barry Greene&lt;br&gt;<br /> Perry E. Metzger{{gray|, Managing Member, Metzger, Dowdeswell &amp; Co. LLC}}&lt;br&gt;<br /> Roelof Meijer{{gray|, CEO, SIDN}}&lt;br&gt;<br /> Svitlana Matviyenko{{gray|, Associate Director, Digital Democracies Institute, Simon Fraser University}}&lt;br&gt;<br /> Rabbi Rob Thomas{{gray|, CEO, Team Cymru}}&lt;br&gt;<br /> Harald Summa{{gray|, CEO, DE-CIX}}&lt;br&gt;<br /> Chris Gibson{{gray|, in personal capacity, CEO FIRST}}&lt;br&gt;<br /> Tom Killalea&lt;br&gt;<br /> The Internet Archive&lt;br&gt;<br /> Philip Reiner{{gray|, CEO, Institute for Security and Technology}}&lt;br&gt;<br /> Megan Stifel{{gray|, Chief Security Officer, Institute for Security and Technology}}&lt;br&gt;<br /> Bart Stidham{{gray|, CEO, NAND Technologies}}&lt;br&gt;<br /> Rudolf van der Berg{{gray|, Programme Manager, Stratix Consulting}}&lt;br&gt;<br /> Alejandro Pisanty{{gray|, Professor, National Autonomous University of Mexico}}&lt;br&gt;<br /> Henrik Kramselund{{gray|, CEO Zencurity Aps}}&lt;br&gt;<br /> Stéphane Duguin{{gray|, CEO Cyber Peace Institute, in personal capacity}}<br /> <br /> ----<br /> <br /> ==Annex: &lt;br&gt;Technical Discussion of Internet Governance Sanction Measures==<br /> <br /> This statement is occasioned by the letter Andrii Nabok (Андрій Набок) of the Ukranian Ministry of Digital Transformation addressed to the Internet Corporation for Assigned Names and Numbers (ICANN) on the morning of Monday, February 28, 2022. ICANN and RIPE replied to Mr. Nabok’s letter directly, in the narrowest possible terms, and in the negative.<br /> <br /> In this annex, we discuss the technical specifics of each of the proposed sanctions, as well as of other possible Internet sanctions which we suggest are more effective, more precise, and carry fewer risks and lower costs.<br /> <br /> ===Analysis of Ukraine’s Request===<br /> We respect Mr. Nabok’s professional expertise and his inclusion of Ukraine’s Internet community in the drafting of his letter in the full spirit of the multistakeholder principles by which the Internet is governed, and we express our deepest sympathies for the indescribable trauma Ukraine is experiencing as a result of Russia’s invasion, which we condemn without reservation.<br /> <br /> Mr. Nabok’s letter requests the imposition of four Internet governance sanctions against Russia, namely:<br /> <br /> * Permanent or temporary revocation of the country code top-level domains “.ru”, “.рф” and “.su”.<br /> * Revocation of SSL certificates associated with those domains.<br /> * Disablement of DNS root servers situated within the Russian Federation.<br /> * Withdrawal of the right to use IPv4 and IPv6 addresses by Russian networks.<br /> <br /> We commend Mr. Nabok and the Ukrainian people and government for responding to bloodshed with diplomacy and seeking deescalatory sanctions. Internet governance sanctions must, however, be selected and implemented carefully, in order to achieve the greatest effect and to avoid unanticipated consequences. In the attached appendix, we discuss each of the proposed sanctions, as well as others we consider more effective, with lower costs and risks of unintended consequences.<br /> <br /> ===Revocation of country-code Top Level Domains (ccTLDs)===<br /> Every ISO-3166 Alpha-2 two-letter abbreviation of a national name is reserved for the use of the Internet community of that nation as a “country-code Top Level Domain,” or “ccTLD.” This reservation is made expressly for the Internet community of the nation and not the government of the nation. Geographic, political, and sociocultural allocations of “internationalized” top-level domains (such as “.рф” to the Russian Federation, or “.укр” to Ukraine) are made in parallel with the ISO-3166 mechanism.<br /> <br /> The primary users of any ccTLD are its civilian constituents, who may be distributed globally and may be united by linguistic or cultural identity rather than nationality or national identity. Removal of a ccTLD from the root zone of the domain name system (the sanction suggested by the letter) would make it very difficult for anyone, globally, within Russia or without, to contact users of the affected domains, a group that consists almost entirely of Russian-speaking civilians. At the same time, it would have relatively little effect upon Russian military networks, which are unlikely to rely upon DNS servers outside their own control.<br /> <br /> We therefore conclude that the revocation, whether temporary or permanent, of a ccTLD is '''not an effective sanction''' because it disproportionately harms civilians; specifically, it is ineffective against any government that has taken cyber-defense preparatory measures to alleviate dependence upon foreign nameservers for domain name resolution. In addition, any country against which this sanction was applied would likely immediately set up an “alternate root,” competing with the one administered by the Internet Assigned Numbers Authority, using any of a number of trivial means. If one country did so, others would likely follow suit, leading to an exodus from the consensus Internet that allows general interconnection.<br /> <br /> ===Revocation of certificates associated with domain names===<br /> At least two kinds of cryptographic certificates and signatures are potential mechanisms for sanction, and we discuss each independently. First, revocation of SSL certificates, as mentioned in Mr. Nabok’s letter:<br /> <br /> SSL (“Secure Socket Layer”), which has been succeeded by TLS (“Transport Layer Security”), is a certification mechanism principally used to authenticate and encrypt connections from web browsers to web servers. Such certificates are used in online commerce and banking, among other less visible roles. Certificates are issued by Certificate Authorities (“CAs”), of which there are many hundreds in existence, a significant number of them are controlled, directly or indirectly, by national governments or intelligence agencies. Any one of these organizations may issue a certificate to anyone, certifying that they are the authentic administrator of any domain.<br /> <br /> The revocation of certificates associated with governmental or military domains is '''not an effective sanction''', because the targeted government is likely already using a Certificate Authority under its own control, and if it is not it can easily cause any CA under its influence to issue a replacement certificate. The revocation of certificates associated with private subdomains (for instance, redcross.ru, citibank.ru) would render communications between these organizations and their constituencies insecure and vulnerable to cybercrime until they were able to get new certificates issued; decreasing law and order and rendering a civilian population more vulnerable to crime is '''not an effective sanction'''. Alternatively, adding existing certificates for propaganda outlets to Certificate Revocation Lists or using Online Certificate Status Protocol (OSCP) to flag them as revoked would warn casual users such websites are problematic and require them to take explicit action to proceed beyond the warning. These techniques are, however, limited: they must generally be done by the same CA that issued the original certificate, which may not be outside the influence of the sanctioned government. We thus believe this to be a '''moderately effective sanction''' in the cases where it is possible to invoke: it is specific, easily centrally implemented, and has little chance of unintended broader consequences. In X.509 public key infrastructures, certificate revocation cannot be rescinded; a new certificate must be issued and deployed.<br /> <br /> ===Revocation of DNSSEC signatures on DNS delegations===<br /> The cryptographic signatures used to authenticate domain names are known as DNSSEC, or DNS Security Extension signatures. Clients can evaluate the veracity of the mappings between domain names and IP addresses, which is what allows them to find and connect to resources on the Internet, by cryptographically validating the DNSSEC signature associated with a domain name.<br /> <br /> If a top-level domain were removed from the DNS root, the DNSSEC signature that validates the delegation of that domain would consequently be removed as well. DNS clients or resolvers still in possession of the old information could continue to reach the websites or email addresses identified by a domain, but they would be unable to validate that they had arrived at the right place. The DNSSEC signature validating the delegation of a top-level domain could also be removed while leaving the delegation itself in place. <br /> <br /> DNSSEC signatures prevent criminals from performing “man-in-the-middle” attacks, impersonating the website of a retail bank, for instance, to capture the user’s authentication information and empty their accounts. Military and high-security networks may use technical mechanisms to ensure that lack of a DNSSEC delegation above a signature under their control, in the DNS hierarchy, will not interfere with their resolution. Regular Internet users, however, either will be confronted with error messages indicating that their bank’s website is an impostor or will not be notified if an attacker stands between them and their bank. <br /> <br /> Removing the DNSSEC signature validating the delegation of a national top-level domain, whether in association with the removal of the delegation or not, may have little or no effect upon military and other high-security networks, but it would decrease law and order and make ordinary people much more susceptible to cybercrime. Tampering with DNSSEC signatures is thus '''not an effective sanction'''.<br /> <br /> ===Disablement of DNS root servers===<br /> Root nameservers are simply those nameservers that hold a static copy of the DNS “root zone,” which is, by its very nature, public information. Essentially any nameserver may be made a root nameserver, simply by telling it to retrieve and cache copies of the DNS root zone.<br /> <br /> Disabling specific root nameservers has no effect, since they are, by design, not uniquely privileged or in possession of unique information. Disabling all root nameservers is not feasible since it would disable the Internet for everyone, and anyone could, and would, establish new ones. Disabling root nameservers thus has '''no utility as a sanction'''.<br /> <br /> ===Withdrawal of the right to use Internet Protocol addresses===<br /> Internet Protocol (IP) addresses, the numeric identifiers by which Internet devices find each other, are allocated by the five Regional Internet Registries that together constitute the Number Resource Organization (NRO). Réseaux IP Européens (RIPE) is the Regional Internet Registry for Europe, the Middle East, and parts of Central Asia, with responsibility for allocating IP addresses to Russian entities. It is within RIPE’s power, if directed to do so by its member organizations through its multistakeholder governance process, to create policy that would effectively withdraw the allocations of IP addresses it has made to Russian organizations.<br /> <br /> This situation bears some similarities to the governance of domain names, yet it also contains crucial differences. ICANN’s authority extends no further into the DNS hierarchy than the root level, so actions taken by ICANN inherently affect entire top-level domains unitarily, without the possibility of “surgical” actions upon one subdomain and not another. By contrast, the Regional Internet Registries can affect policy on a per-organization (or even finer) basis. Yet rescinding an IP address allocation does not prevent its previous holder from continuing to use it. Indeed, “IP address hijacking” is a relatively commonplace problem on the Internet. Therefore, although it can be precisely targeted, simply rescinding the right to use an IP address allocation is '''not, by itself, an effective sanction'''. <br /> <br /> Note that this process of IP address revocation and RPKI attestation revocation would be a normal consequence of an address recipient (such as the Russian military) failing to pay annual registration fees to its Regional Internet Registry, something that may in fact come to pass as a consequence of financial and banking sanctions. But such a process might take years. Another negative consequence of revoking IP address allocations is that revoked addresses will likely be allocated to a different recipient subsequently, who will then find themselves competing with the original holder for their use. <br /> <br /> ===Manipulation of routing security attestations===<br /> A potential sanction not explicitly requested in Mr. Nabok’s letter is the manipulation of routing security attestations to produce the effect of a partial or complete disconnection from the Internet of specific networks, such as those of the Russian military or propaganda agencies. <br /> <br /> As with domain names, technical mechanisms exist to cryptographically verify the legitimacy of use of IP addresses. Routing Policy Specification Language (RPSL) and Routing Public Key Infrastructure (RPKI) are the two primary such mechanisms. To be used for communication on the Internet, IP addresses must be “announced” through the routing system, and the routers of the larger and better-secured networks utilize these two mechanisms to ensure that invalid routes are not used by their routers. Smaller and less-secured networks do not typically implement these mechanisms. <br /> <br /> A manipulation of RPSL and RPKI records in centralized registries would flow through to all networks employing these common routing security mechanisms, some of which would then automatically stop routing traffic to and from the specified networks, without affecting other “adjacent” civilian networks or being subject to trivial “work-arounds.” <br /> <br /> The manipulation of RPSL and RPKI routing security attestations could be an effective sanction measure, because it appears precise, easily and quickly implemented and reversed, and reasonably effective. However, the appropriation of preexisting routing security mechanisms for use in sanctions, likely unexpected by the participating networks, could conflict with the business or regulatory requirements of those networks, and, crucially, could risk the withdrawal of networks from the system entirely. Such an exodus would both make this potential sanction less effective in the future and have the far greater cost of eroding cybersecurity for the Internet as a whole, the purpose for which the routing security systems were built in the first place. This thus constitutes an '''unacceptable risk'''.<br /> <br /> ===Other Internet-associated, non-technical sanctions===<br /> Other sanctions related to the Internet’s operation and governance may be worth considering. These include, for example, the disallowance of sanctioned personnel from participation in Internet governance, policymaking, or standardization proceedings. Such nontechnical measures are outside the scope of this document.<br /> <br /> ===Blocklisting===<br /> Network operators and DNS resolver operators already make use of multistakeholder-governed lists, similar to the way financial lenders use credit scoring agencies, to determine what IP addresses to route and pass traffic between, and what domain names to resolve. This is the mechanism by which persistent spammers and address hijackers are excluded from the network, and by which Internet users are protected from malware and phishing attacks.<br /> <br /> The technical mechanisms by which such blocking information is passed are mature, robust, instantaneous, and globally standardized. Information related to IP addresses and Autonomous System Numbers is mostly carried over BGP feeds, while information related to domain names is mostly carried over RPZ feeds. Both mechanisms are implemented by essentially all large operators globally. Blocklisting IP addresses and Autonomous System Numbers has all of the advantages of address block revocation or manipulation of routing security attestations, without the drawbacks. It allows network operators to block both the acceptance of routes and the passage of traffic, each or both of which may be appropriate in different situations and in response to different threats. Blocklisting of domain names allows full precision and specificity, which is the problem that precludes action by ICANN. The system is opt-in, voluntary, consensual, and bottom-up, all values the Internet governance community holds dear. Yet, at the same time, it has achieved broad adoption.<br /> <br /> We conclude that the well-established methods of blocklisting provide the '''best mechanism for sanctioning both IP routes and traffic and domain names''', and that this mechanism, if implemented normally by subscribing entities, has no significant costs or risks.<br /> <br /> ===Conclusion===<br /> Our conclusion is that '''blocklisting''' of IP addresses, Autonomous Systems, and domain names upon which the multistakeholder community can establish consensus is effective and carries no inherent danger of being over-broad. Once decided upon, it is easily invoked—and equally easily rolled back once the problem is resolved. Most important, it carries no significant costs or risks and is aligned with the Internet’s multistakeholder governance values and principles.</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=301 2022-04-21T20:11:13Z

<p>Woody: /* Web Page */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one changing on a regular period, perhaps hourly.<br /> <br /> ==== Web Page ====<br /> The beacon should be visible to the public in the form of a web page which attempts to load a variety of web objects, testing for sanction enforcement and a variety of forms of over-compliance. The web page should also display to the client the client's apparent IP address, source port number, and a timestamp that can be used by the client to validate what if anything might be between it and the beacon web server.<br /> <br /> The web page should test:<br /> <br /> * Whether a sanctioned domain loads (green background indicates correct blocking, red overlay indicates failure to block)<br /> * Whether a subdomain loads (green background indicates correct blocking, red overlay indicates failure to block)<br /> * Whether a different domain hosted at the same IP address loads (red background indicates over-blocking, green overlay indicates correct non-blocking)<br /> * Whether a previously-but-no-longer-blocked domain loads (red background indicates over-blocking, green overlay indicates correct non-blocking)<br /> * Whether a blocked IP address loads (green background indicates correct blocking, red overlay indicates failure to block)<br /> * Whether a different IP address in the same subnet loads (red background indicates over-blocking, green overlay indicates correct non-blocking)<br /> * Whether a previously-but-no-longer-blocked IP address loads (red background indicates over-blocking, green overlay indicates correct non-blocking)<br /> * Whether a blocked Autonomous System Number loads (green background indicates correct blocking, red overlay indicates failure to block)<br /> <br /> Potentially, we could test over-blocking of ASNs by multi-homing a beacon on a blocked and an un-blocked ASN, and testing to make sure the multi-homed object was not blocked.<br /> <br /> ==== Domain Beacon ====<br /> As of March 27, 2022, we have two domain name beacons. They are:<br /> <br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']&lt;br&gt;<br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> <br /> Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net. We may also need two other (&quot;negative&quot;) domains, to host on the same IP addresses as these, which should '''not''' be blocked, to make sure that it's the domain, not the IP, that's being blocked.<br /> <br /> {{plainlist|<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> }}<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 11, 2022, we've received the two independent IPv4 /24 beacon subnets for which we performed an 8.4 inward transfer. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET-45-154-219-0-1 '''SANCTIONS-BEACON-IPV4-A''', 45.154.219.0/24]<br /> * [https://account.arin.net/public/secure/net/view/NET-185-203-207-0-1 '''SANCTIONS-BEACON-IPV4-B''', 185.203.207.0/24]<br /> }}<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:<br /> <br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/asn/view/AS13400 '''16-bit''': 13400]&lt;br&gt;<br /> * [https://account.arin.net/public/secure/asn/view/AS400603 '''32-bit''': 400603]<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=300 2022-04-21T20:00:59Z

<p>Woody: </p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one changing on a regular period, perhaps hourly.<br /> <br /> ==== Web Page ====<br /> The beacon should be visible to the public in the form of a web page which attempts to load a variety of web objects, testing for sanction enforcement and a variety of forms of over-compliance. The web page should also display to the client the client's apparent IP address, source port number, and a timestamp that can be used by the client to validate what if anything might be between it and the beacon web server.<br /> <br /> <br /> ==== Domain Beacon ====<br /> As of March 27, 2022, we have two domain name beacons. They are:<br /> <br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']&lt;br&gt;<br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> <br /> Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net. We may also need two other (&quot;negative&quot;) domains, to host on the same IP addresses as these, which should '''not''' be blocked, to make sure that it's the domain, not the IP, that's being blocked.<br /> <br /> {{plainlist|<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> }}<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 11, 2022, we've received the two independent IPv4 /24 beacon subnets for which we performed an 8.4 inward transfer. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET-45-154-219-0-1 '''SANCTIONS-BEACON-IPV4-A''', 45.154.219.0/24]<br /> * [https://account.arin.net/public/secure/net/view/NET-185-203-207-0-1 '''SANCTIONS-BEACON-IPV4-B''', 185.203.207.0/24]<br /> }}<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:<br /> <br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/asn/view/AS13400 '''16-bit''': 13400]&lt;br&gt;<br /> * [https://account.arin.net/public/secure/asn/view/AS400603 '''32-bit''': 400603]<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=298 2022-04-18T09:42:31Z

<p>Woody: /* Domain Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> As of March 27, 2022, we have two domain name beacons. They are:<br /> <br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']&lt;br&gt;<br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> <br /> Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net. We may also need two other (&quot;negative&quot;) domains, to host on the same IP addresses as these, which should '''not''' be blocked, to make sure that it's the domain, not the IP, that's being blocked.<br /> <br /> {{plainlist|<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> }}<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 11, 2022, we've received the two independent IPv4 /24 beacon subnets for which we performed an 8.4 inward transfer. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET-45-154-219-0-1 '''SANCTIONS-BEACON-IPV4-A''', 45.154.219.0/24]<br /> * [https://account.arin.net/public/secure/net/view/NET-185-203-207-0-1 '''SANCTIONS-BEACON-IPV4-B''', 185.203.207.0/24]<br /> }}<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:<br /> <br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/asn/view/AS13400 '''16-bit''': 13400]&lt;br&gt;<br /> * [https://account.arin.net/public/secure/asn/view/AS400603 '''32-bit''': 400603]<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Operations_Group&diff=297 2022-04-18T08:19:36Z

<p>Woody: /* Goals */</p> <hr /> <div>The '''operations group''' is responsible for the functioning of this web site (which is MediaWiki, reskinned by [https://opentechstrategies.com Open Tech Strategies]) and mailing lists, the operational mechanism of the BGP and RPZ data feeds, and liaison with the Internet network operators who use them.<br /> <br /> The work of the operations group is done on the operations mailing list (which you're [https://lists.sanctions.net/mailman/listinfo/operations welcome to join], or you can consult its [https://lists.sanctions.net/pipermail/operations/ archives of past discussion]) and documentation will be published here.<br /> <br /> == Goals ==<br /> The long-term goal of the operations group is to provide a two-factor authenticated interface for each subscribing network operator, allowing them to select the specific jurisdictions in which they need to ensure sanctions compliance, such that the BGP and RPZ feeds they receive will contain exactly what's needed, and nothing more. The goal is to ensure compliance, without falling into ''over''compliance.<br /> <br /> Because some jurisdictions issue partial exemptions, we currently imagine that the user interface will allow, for each jurisdiction, compliance selections of &quot;full,&quot; &quot;minimum,&quot; or &quot;none.&quot;</div>

Woody https://wiki.sanctions.net/index.php?title=Frequently_Asked_Questions&diff=296 2022-04-18T07:55:26Z

<p>Woody: </p> <hr /> <div>=== What is the purpose of this project? ===<br /> This project allows Internet organizations to enact precisely-targeted sanctions which affect only the military and propaganda agencies of sanctioned countries, rather than sweeping sanctions which principally effect the civilian populations of those countries.<br /> <br /> === Who is it for? ===<br /> This project is operated by and for Internet organizations which are required by governmental regulation to enact sanctions. Since this project is never inherently ''pro sanction'', we do not anticipate, nor advocate, that organizations which are not regulatorily required to enact sanctions automate action based on the project's data feeds.<br /> <br /> === How does it work? ===<br /> The project uses standardized protocols (BGP and RPZ) to distribute lists of Internet networks and domain names associated with sanctioned entities in ways that Internet network operators already use for blocking spam senders, DDoS attackers, malware distribution, and other threats against the Internet's infrastructure.<br /> <br /> === Who runs it? ===<br /> This is a typical Internet governance organization. It is operated by volunteers, and decisions are made by those who show up and do the work. There are no barriers to entry which would prevent any other organization from forming to perform the same function in a different way, or a competing effort in the same way.<br /> <br /> === Does this project advocate for sanctions? ===<br /> No, this project is agnostic with regard to whether sanctions should or should not exist, or should or should not be levied by any government against any party. Sanctions exist, have for thousands of years, and governments and society generally regard them as deescalatory and preferable to violent alternatives. The aim of this project is to assist governments which wish to impose sanctions, and network operators who wish to comply with governmental requirements, to reach a mutually-satisfactory state. If you don't like the idea of sanctions, you can take that up with the government of your choice, this is not a forum for debate on fundamental questions such as whether sanctions should exist.<br /> <br /> === Do Internet sanctions disconnect anyone from the Internet? ===<br /> No, Internet sanctions remove the societal subsidy from the cost of Internet access to sanctioned entities. In the same way that banking sanctions don't prevent sanctioned entities from using money, they just increase the friction and cost of doing so, Internet sanctions don't disconnect sanctioned parties from the Internet, they just ensure that they pay the full cost of using it, without the subsidies which would normally be provided as a function of societal cooperation.<br /> <br /> === Is anyone required to use this project? ===<br /> No, this project is entirely voluntary. The relationship between this project and Internet network operators is exactly the same as the relationship between many preexisting organizations which provide similar blocklists identifying spam, malware, phishing, DDoS, and other forms of abuse to network operators, and the functional mechanisms are identical. Network operators choose to subscribe to the data-feeds we provide, or not, and choose to act upon the data, or not. The obligation to implement sanctions imposed by the governments of the nations in which the network operators are incorporated, however, is not voluntary, it's mandatory under law. This project gives network operators a mechanism for complying with those mandatory requirements, in countries which have accepted this mechanism as sufficient.<br /> <br /> === What is the beacon? ===<br /> The beacon is a set of artificial IP addresses and domain names which are not associated with any real-world organization or users, which will always be &quot;sanctioned&quot; and can thus be used by researchers to measure the reach and effect of the system. If the beacon is visible to you, the Internet sanctioning feeds are not being consumed by your transit providers or DNS recursive resolver operators. Beacons are a frequently-implemented diagnostic feature of Internet routing security systems.<br /> <br /> === Is that really supposed to be a logo in the top left corner? ===<br /> Yes, well, it wasn't the highest priority at the time, and these things are always stickier than you hope. A better project logo would be very welcome. Consensus is, as always in open projects, the difficult part.</div>

Woody https://wiki.sanctions.net/index.php?title=Frequently_Asked_Questions&diff=295 2022-04-18T07:53:20Z

<p>Woody: </p> <hr /> <div>=== What is the purpose of this project? ===<br /> This project allows Internet organizations to enact precisely-targeted sanctions which affect only the military and propaganda agencies of sanctioned countries, rather than sweeping sanctions which principally effect the civilian populations of those countries.<br /> <br /> === Who is it for? ===<br /> This project is operated by and for Internet organizations which are required by governmental regulation to enact sanctions. Since this project is never inherently ''pro sanction'', we do not anticipate, nor advocate, that organizations which are not regulatorily required to enact sanctions automate action based on the project's data feeds.<br /> <br /> === How does it work? ===<br /> The project uses standardized protocols (BGP and RPZ) to distribute lists of Internet networks and domain names associated with sanctioned entities in ways that Internet network operators already use for blocking spam senders, DDoS attackers, malware distribution, and other threats against the Internet's infrastructure.<br /> <br /> === Who runs it? ===<br /> This is a typical Internet governance organization. It is operated by volunteers, and decisions are made by those who show up and do the work. There are no barriers to entry which would prevent any other organization from forming to perform the same function in a different way, or a competing effort in the same way.<br /> <br /> === Does this project advocate for sanctions? ===<br /> No, this project is agnostic with regard to whether sanctions should or should not exist, or should or should not be levied by any government against any party. Sanctions exist, have for thousands of years, and governments and society generally regard them as deescalatory and preferable to violent alternatives. The aim of this project is to assist governments which wish to impose sanctions, and network operators who wish to comply with governmental requirements, to reach a mutually-satisfactory state. If you don't like the idea of sanctions, you can take that up with the government of your choice, this is not a forum for debate on fundamental questions such as whether sanctions should exist.<br /> <br /> === Do Internet sanctions disconnect anyone from the Internet? ===<br /> No, Internet sanctions remove the societal subsidy from the cost of Internet access to sanctioned entities. In the same way that banking sanctions don't prevent sanctioned entities from using money, they just increase the friction and cost of doing so, Internet sanctions don't disconnect sanctioned parties from the Internet, they just ensure that they pay the full cost of using it, without the subsidies which would normally be provided as a function of societal cooperation.<br /> <br /> === Is anyone required to use this project? ===<br /> No, this project is entirely voluntary. The relationship between this project and Internet network operators is exactly the same as the relationship between many preexisting organizations which provide similar blocklists identifying spam, malware, phishing, DDoS, and other forms of abuse to network operators, and the functional mechanisms are identical. Network operators choose to subscribe to the data-feeds we provide, or not, and choose to act upon the data, or not. The obligation to implement sanctions imposed by the governments of the nations in which the network operators are incorporated, however, is not voluntary, it's mandatory under law. This project gives network operators a mechanism for complying with those mandatory requirements, in countries which have accepted this mechanism as sufficient.<br /> <br /> === What is the beacon? ===<br /> The beacon is a set of artificial IP addresses and domain names which are not associated with any real-world organization or users, which will always be &quot;sanctioned&quot; and can thus be used by researchers to measure the reach and effect of the system. If the beacon is visible to you, the Internet sanctioning feeds are not being consumed by your transit providers or DNS recursive resolver operators. Beacons are a frequently-implemented diagnostic feature of Internet routing security systems.</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=294 2022-04-11T14:16:17Z

<p>Woody: </p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> As of March 27, 2022, we have two domain name beacons. They are:<br /> <br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']&lt;br&gt;<br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> <br /> Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net.<br /> <br /> {{plainlist|<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> }}<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 11, 2022, we've received the two independent IPv4 /24 beacon subnets for which we performed an 8.4 inward transfer. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET-45-154-219-0-1 '''SANCTIONS-BEACON-IPV4-A''', 45.154.219.0/24]<br /> * [https://account.arin.net/public/secure/net/view/NET-185-203-207-0-1 '''SANCTIONS-BEACON-IPV4-B''', 185.203.207.0/24]<br /> }}<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:<br /> <br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/asn/view/AS13400 '''16-bit''': 13400]&lt;br&gt;<br /> * [https://account.arin.net/public/secure/asn/view/AS400603 '''32-bit''': 400603]<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Conflict_with_Privacy_Law&diff=293 2022-04-10T20:18:05Z

<p>Woody: Created page with &quot;We should probably begin a conversation with governments over exempting sanctioned entities from the protections of privacy law which would prohibit the sharing of personally...&quot;</p> <hr /> <div>We should probably begin a conversation with governments over exempting sanctioned entities from the protections of privacy law which would prohibit the sharing of personally identifiable information (such as IP addresses) used in the sanction implementation process.</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Policy_Group&diff=292 2022-04-10T20:16:41Z

<p>Woody: /* Open Issues */</p> <hr /> <div>{{TOC right}}<br /> The '''policy group''' monitors the political situation and the sanction initiatives of national governments, and evaluates proposed sanctions in light of the project's [[Policy:Guiding Principles|guiding principles]] and precedents in [[Policy:International Law and Norms|international law and norms]], including those governing fundamental human rights of [[Policy:Freedom of Expression and Access to Information|freedom of expression and access to information]]. If a sanction is deemed in-scope, the policy group defines the sanctioned entities and passes them to the OSINT group. The policy group is also responsible for determining when existing sanctions should be repealed.<br /> <br /> The work of the policy group is done on the discussion mailing list (which you're [https://lists.sanctions.net/mailman/listinfo/discuss welcome to join], or you can consult its [https://lists.sanctions.net/pipermail/discuss/ archives of past discussion]) and its results are published here.<br /> ----<br /> == Thoughts and Articles ==<br /> * [[Policy:The Goals of Sanctions|The goals of sanctions]]<br /> <br /> == Open Issues ==<br /> * [[Policy:The &quot;Human Shield&quot; Problem|The &quot;human shield&quot; problem]]<br /> * [[Policy:More Specific Domains|The &quot;more specific domain&quot; question]]<br /> * [[Policy:Data Formatting Issues|Data formatting issues]]<br /> * [[Policy:Intake Database|Intake database]]<br /> * [[Policy:Conflict with Privacy Law|Conflict with Privacy Law]]<br /> <br /> ----<br /> <br /> == Specific Sanction Reviews ==<br /> === 2022 ===<br /> ==== Multiple vs. Russia and Belarus ====<br /> Near the end of February 2022, many countries began levying sanctions against more than a thousand entities in Russia and Belarus, in connection with Russia's military invasion of Ukraine. In some cases, the sanctions were additive with preexisting ones associated with Russia's 2014 military invasion of Ukraine. [[Policy:Multiple vs. Russia and Belarus, 2022 |Discussion of these sanctions can be found here.]]<br /> <br /> ==== Afghanistan vs. United States et al. ====<br /> In March, 2022, the Afghan government sanctioned Voice of America, the British Broadcasting Corporation, and Deutsche Welle. [[Policy:Afghanistan vs. Western Broadcasters, 2022|Discussion of these sanctions can be found here.]]<br /> <br /> ==== United States vs. Iran ====<br /> In March, 2022, the United States government added Iranian procurement agent Mohammad Ali Hosseini and his associated companies to existing sanctions aimed at Iran's ballistic missile development program. [[Policy: United States vs. Iranian Ballistic Missile Program, 2022|Discussion of these sanctions can be found here.]]</div>

Woody https://wiki.sanctions.net/index.php?title=Operations_Group&diff=291 2022-04-09T20:00:51Z

<p>Woody: </p> <hr /> <div>The '''operations group''' is responsible for the functioning of this web site (which is MediaWiki, reskinned by [https://opentechstrategies.com Open Tech Strategies]) and mailing lists, the operational mechanism of the BGP and RPZ data feeds, and liaison with the Internet network operators who use them.<br /> <br /> The work of the operations group is done on the operations mailing list (which you're [https://lists.sanctions.net/mailman/listinfo/operations welcome to join], or you can consult its [https://lists.sanctions.net/pipermail/operations/ archives of past discussion]) and documentation will be published here.<br /> <br /> == Goals ==<br /> The long-term goal of the operations group is to provide a two-factor authenticated interface for each subscribing network operator, allowing them to select the specific jurisdictions in which they need to ensure sanctions compliance, such that the BGP and RPZ feeds they receive will contain exactly what's needed, and nothing more. The goal is to ensure compliance, without falling into ''over''compliance.</div>

Woody https://wiki.sanctions.net/index.php?title=The_Open_Letter&diff=290 2022-04-08T06:21:15Z

<p>Woody: </p> <hr /> <div>{{TOC right}}<br /> On March 10, 2022, members of the Multistakeholder Internet governance community published the following open letter:<br /> {{clear}}<br /> ----<br /> {{right|Thursday, March 10, 2022}}&lt;br&gt;<br /> {{right|The Hague}}<br /> ==Multistakeholder Imposition of Internet Sanctions==<br /> <br /> ===Executive Summary===<br /> The invasion of Ukraine poses a new challenge for multistakeholder Internet infrastructure governance. In this statement, we discuss possible sanctions and their ramifications, lay out principles that we believe should guide Internet sanctions, and propose a multistakeholder governance mechanism to facilitate decision-making and implementation. <br /> <br /> ===Introduction===<br /> The Internet is in its thirtieth year of transition from national to multistakeholder governance. As we encounter pivotal moments, we must decide as a community whether Internet self-governance has matured sufficiently to address such newly encountered issue. Governments have imposed sanctions throughout history, but the global Internet governance community has not yet established a process dedicated to this task. <br /> <br /> We believe it is now incumbent upon the Internet community to deliberate and make decisions in the face of humanitarian crises. We may not responsibly dismiss such crises without consideration, nor with consideration only for the self-interest of our community’s own direct constituents; instead, maturity of governance requires that self-interests be weighed in the balance with broader moral and societal considerations. This document is the beginning of a global Internet governance conversation about the appropriate scope of sanctions, the feasibility of sanctions within the realm of our collective responsibility, and our moral imperative to minimize detrimental consequences.<br /> <br /> ===Principles for Internet Infrastructure Governance Sanctions===<br /> We, the undersigned, agree to the following principles:<br /> <br /> * Disconnecting the population of a country from the Internet is a disproportionate and inappropriate sanction, since it hampers their access to the very information that might lead them to withdraw support for acts of war and leaves them with access to only the information their own government chooses to furnish.<br /> <br /> * The effectiveness of sanctions should be evaluated relative to predefined goals. Ineffective sanctions waste effort and willpower and convey neither unity nor conviction. <br /> <br /> * Sanctions should be focused and precise. They should minimize the chance of unintended consequences or collateral damage. Disproportionate or over-broad sanctions risk fundamentally alienating populations.<br /> <br /> * Military and propaganda agencies and their information infrastructure are potential targets of sanctions.<br /> <br /> * The Internet, due to its transnational nature and consensus-driven multistakeholder system of governance, currently does not easily lend itself to the imposition of sanctions in national conflicts.<br /> <br /> * It is inappropriate and counterproductive for governments to attempt to compel Internet governance mechanisms to impose sanctions outside of the community’s multistakeholder decision-making process.<br /> <br /> * There are nonetheless appropriate, effective, and specific sanctions the Internet governance community may wish to consider in its deliberative processes.<br /> <br /> ===Recommendations===<br /> We believe it is the responsibility of the global Internet governance community to weigh the costs and risks of sanctions against the moral imperatives that call us to action in defense of society, and we must address this governance problem now and in the future. '''We believe the time is right for the formation of a new, minimal, multistakeholder mechanism, similar in scale to NSP-Sec or Outages, which after due process and consensus would publish sanctioned IP addresses and domain names in the form of public data feeds in standard forms (BGP and RPZ), to be consumed by any organization that chooses to subscribe to the principles and their outcome.''' This process should use clearly documented procedures to assess violations of international norms in an open, multistakeholder, and consensus-driven process, taking into account the principles of non-overreach and effectiveness in making its determinations. This system mirrors existing systems used by network operators to block spam, malware, and DDoS attacks, so it requires no new technology and minimal work to implement.<br /> <br /> We call upon our colleagues to participate in a multistakeholder deliberation using the mechanism outlined above, to decide whether the IP addresses and domain names of the Russian military and its propaganda organs should be sanctioned, and to lay the groundwork for timely decisions of similar gravity and urgency in the future.<br /> <br /> ===Signed,===<br /> Bart Groothuis{{gray|, Member of the European Parliament, Netherlands}}&lt;br&gt;<br /> Bill Woodcock{{gray|, Executive Director, Packet Clearing House}}&lt;br&gt;<br /> Ihab Osman{{gray|, Non-Executive Director, Internet Corporation for Assigned Names and Numbers}}&lt;br&gt;<br /> Mike Roberts{{gray|, founding President and CEO, Internet Corporation for Assigned Names and Numbers}}&lt;br&gt;<br /> Jeff Moss{{gray|, President, DEFCON}}&lt;br&gt;<br /> Niels ten Oever{{gray|, Postdoctoral Researcher, University of Amsterdam}}&lt;br&gt;<br /> Marina Kaljurand{{gray|, Member of the European Parliament, Estonia, former ambassador to Russia and the United States}}&lt;br&gt;<br /> Eva Kaili{{gray|, Member of the European Parliament, Greece}}&lt;br&gt;<br /> Runa Sandvik{{gray|, security researcher}}&lt;br&gt;<br /> Kurt Opsahl{{gray|, Electronic Frontier Foundation (affiliation for identification purposes only)}}&lt;br&gt;<br /> 
John Levine{{gray|, President, CAUCE North America}}&lt;br&gt;<br /> Virendra Rode{{gray|, founder and contributor, Outages.ORG}}&lt;br&gt;<br /> Stephen D. Crocker{{gray|, Edgemoor Research Institute}}&lt;br&gt;<br /> Job Snijders{{gray|, board member, RIPE NCC, PeeringDB, and Route Server Support Foundation}}&lt;br&gt;<br /> Moez Chakchouk{{gray|, Director of Policy, PCH, former ADG/CI UNESCO and former Tunisian minister}}&lt;br&gt;<br /> Doug Madory{{gray|, Director of Internet Analysis, Kentik}}&lt;br&gt;<br /> Ondrej Filip{{gray|, CEO, CZ.NIC}}&lt;br&gt;<br /> Greg Rattray{{gray|, Founder, Next Peak and former cybersecurity advisor to ICANN}}&lt;br&gt;<br /> Serge Droz{{gray|, in personal capacity, Director FIRST}}&lt;br&gt;<br /> Mark Tinka{{gray|, board member, FranceIX}}&lt;br&gt;<br /> Dmitry Kohmanyuk{{gray|, founder, Hostmaster Ltd.}}&lt;br&gt;<br /> Timothy Denton{{gray|, Chairman, Internet Society, Canada Chapter}}&lt;br&gt;<br /> Barry Greene&lt;br&gt;<br /> Perry E. Metzger{{gray|, Managing Member, Metzger, Dowdeswell &amp; Co. LLC}}&lt;br&gt;<br /> Roelof Meijer{{gray|, CEO, SIDN}}&lt;br&gt;<br /> Svitlana Matviyenko{{gray|, Associate Director, Digital Democracies Institute, Simon Fraser University}}&lt;br&gt;<br /> Rabbi Rob Thomas{{gray|, CEO, Team Cymru}}&lt;br&gt;<br /> Harald Summa{{gray|, CEO, DE-CIX}}&lt;br&gt;<br /> Chris Gibson{{gray|, in personal capacity, CEO FIRST}}&lt;br&gt;<br /> Tom Killalea&lt;br&gt;<br /> The Internet Archive&lt;br&gt;<br /> Philip Reiner{{gray|, CEO, Institute for Security and Technology}}&lt;br&gt;<br /> Megan Stifel{{gray|, Chief Security Officer, Institute for Security and Technology}}&lt;br&gt;<br /> Bart Stidham{{gray|, CEO, NAND Technologies}}&lt;br&gt;<br /> Rudolf van der Berg{{gray|, Programme Manager, Stratix Consulting}}&lt;br&gt;<br /> Alejandro Pisanty{{gray|, Professor, National Autonomous University of Mexico}}&lt;br&gt;<br /> Henrik Kramselund{{gray|, CEO Zencurity Aps}}&lt;br&gt;<br /> Stéphane Duguin{{gray|, CEO Cyber Peace Institute, in personal capacity}}<br /> <br /> ----<br /> <br /> ==Annex: &lt;br&gt;Technical Discussion of Internet Governance Sanction Measures==<br /> <br /> This statement is occasioned by the letter Andrii Nabok (Андрій Набок) of the Ukranian Ministry of Digital Transformation addressed to the Internet Corporation for Assigned Names and Numbers (ICANN) on the morning of Monday, February 28, 2022. ICANN and RIPE replied to Mr. Nabok’s letter directly, in the narrowest possible terms, and in the negative.<br /> <br /> In this annex, we discuss the technical specifics of each of the proposed sanctions, as well as of other possible Internet sanctions which we suggest are more effective, more precise, and carry fewer risks and lower costs.<br /> <br /> ===Analysis of Ukraine’s Request===<br /> We respect Mr. Nabok’s professional expertise and his inclusion of Ukraine’s Internet community in the drafting of his letter in the full spirit of the multistakeholder principles by which the Internet is governed, and we express our deepest sympathies for the indescribable trauma Ukraine is experiencing as a result of Russia’s invasion, which we condemn without reservation.<br /> <br /> Mr. Nabok’s letter requests the imposition of four Internet governance sanctions against Russia, namely:<br /> <br /> * Permanent or temporary revocation of the country code top-level domains “.ru”, “.рф” and “.su”.<br /> * Revocation of SSL certificates associated with those domains.<br /> * Disablement of DNS root servers situated within the Russian Federation.<br /> * Withdrawal of the right to use IPv4 and IPv6 addresses by Russian networks.<br /> <br /> We commend Mr. Nabok and the Ukrainian people and government for responding to bloodshed with diplomacy and seeking deescalatory sanctions. Internet governance sanctions must, however, be selected and implemented carefully, in order to achieve the greatest effect and to avoid unanticipated consequences. In the attached appendix, we discuss each of the proposed sanctions, as well as others we consider more effective, with lower costs and risks of unintended consequences.<br /> <br /> ===Revocation of country-code Top Level Domains (ccTLDs)===<br /> Every ISO-3166 Alpha-2 two-letter abbreviation of a national name is reserved for the use of the Internet community of that nation as a “country-code Top Level Domain,” or “ccTLD.” This reservation is made expressly for the Internet community of the nation and not the government of the nation. Geographic, political, and sociocultural allocations of “internationalized” top-level domains (such as “.рф” to the Russian Federation, or “.укр” to Ukraine) are made in parallel with the ISO-3166 mechanism.<br /> <br /> The primary users of any ccTLD are its civilian constituents, who may be distributed globally and may be united by linguistic or cultural identity rather than nationality or national identity. Removal of a ccTLD from the root zone of the domain name system (the sanction suggested by the letter) would make it very difficult for anyone, globally, within Russia or without, to contact users of the affected domains, a group that consists almost entirely of Russian-speaking civilians. At the same time, it would have relatively little effect upon Russian military networks, which are unlikely to rely upon DNS servers outside their own control.<br /> <br /> We therefore conclude that the revocation, whether temporary or permanent, of a ccTLD is '''not an effective sanction''' because it disproportionately harms civilians; specifically, it is ineffective against any government that has taken cyber-defense preparatory measures to alleviate dependence upon foreign nameservers for domain name resolution. In addition, any country against which this sanction was applied would likely immediately set up an “alternate root,” competing with the one administered by the Internet Assigned Numbers Authority, using any of a number of trivial means. If one country did so, others would likely follow suit, leading to an exodus from the consensus Internet that allows general interconnection.<br /> <br /> ===Revocation of certificates associated with domain names===<br /> At least two kinds of cryptographic certificates and signatures are potential mechanisms for sanction, and we discuss each independently. First, revocation of SSL certificates, as mentioned in Mr. Nabok’s letter:<br /> <br /> SSL (“Secure Socket Layer”), which has been succeeded by TLS (“Transport Layer Security”), is a certification mechanism principally used to authenticate and encrypt connections from web browsers to web servers. Such certificates are used in online commerce and banking, among other less visible roles. Certificates are issued by Certificate Authorities (“CAs”), of which there are many hundreds in existence, a significant number of them are controlled, directly or indirectly, by national governments or intelligence agencies. Any one of these organizations may issue a certificate to anyone, certifying that they are the authentic administrator of any domain.<br /> <br /> The revocation of certificates associated with governmental or military domains is '''not an effective sanction''', because the targeted government is likely already using a Certificate Authority under its own control, and if it is not it can easily cause any CA under its influence to issue a replacement certificate. The revocation of certificates associated with private subdomains (for instance, redcross.ru, citibank.ru) would render communications between these organizations and their constituencies insecure and vulnerable to cybercrime until they were able to get new certificates issued; decreasing law and order and rendering a civilian population more vulnerable to crime is '''not an effective sanction'''. Alternatively, adding existing certificates for propaganda outlets to Certificate Revocation Lists or using Online Certificate Status Protocol (OSCP) to flag them as revoked would warn casual users such websites are problematic and require them to take explicit action to proceed beyond the warning. These techniques are, however, limited: they must generally be done by the same CA that issued the original certificate, which may not be outside the influence of the sanctioned government. We thus believe this to be a '''moderately effective sanction''' in the cases where it is possible to invoke: it is specific, easily centrally implemented, and has little chance of unintended broader consequences. In X.509 public key infrastructures, certificate revocation cannot be rescinded; a new certificate must be issued and deployed.<br /> <br /> ===Revocation of DNSSEC signatures on DNS delegations===<br /> The cryptographic signatures used to authenticate domain names are known as DNSSEC, or DNS Security Extension signatures. Clients can evaluate the veracity of the mappings between domain names and IP addresses, which is what allows them to find and connect to resources on the Internet, by cryptographically validating the DNSSEC signature associated with a domain name.<br /> <br /> If a top-level domain were removed from the DNS root, the DNSSEC signature that validates the delegation of that domain would consequently be removed as well. DNS clients or resolvers still in possession of the old information could continue to reach the websites or email addresses identified by a domain, but they would be unable to validate that they had arrived at the right place. The DNSSEC signature validating the delegation of a top-level domain could also be removed while leaving the delegation itself in place. <br /> <br /> DNSSEC signatures prevent criminals from performing “man-in-the-middle” attacks, impersonating the website of a retail bank, for instance, to capture the user’s authentication information and empty their accounts. Military and high-security networks may use technical mechanisms to ensure that lack of a DNSSEC delegation above a signature under their control, in the DNS hierarchy, will not interfere with their resolution. Regular Internet users, however, either will be confronted with error messages indicating that their bank’s website is an impostor or will not be notified if an attacker stands between them and their bank. <br /> <br /> Removing the DNSSEC signature validating the delegation of a national top-level domain, whether in association with the removal of the delegation or not, may have little or no effect upon military and other high-security networks, but it would decrease law and order and make ordinary people much more susceptible to cybercrime. Tampering with DNSSEC signatures is thus '''not an effective sanction'''.<br /> <br /> ===Disablement of DNS root servers===<br /> Root nameservers are simply those nameservers that hold a static copy of the DNS “root zone,” which is, by its very nature, public information. Essentially any nameserver may be made a root nameserver, simply by telling it to retrieve and cache copies of the DNS root zone.<br /> <br /> Disabling specific root nameservers has no effect, since they are, by design, not uniquely privileged or in possession of unique information. Disabling all root nameservers is not feasible since it would disable the Internet for everyone, and anyone could, and would, establish new ones. Disabling root nameservers thus has '''no utility as a sanction'''.<br /> <br /> ===Withdrawal of the right to use Internet Protocol addresses===<br /> Internet Protocol (IP) addresses, the numeric identifiers by which Internet devices find each other, are allocated by the five Regional Internet Registries that together constitute the Number Resource Organization (NRO). Réseaux IP Européens (RIPE) is the Regional Internet Registry for Europe, the Middle East, and parts of Central Asia, with responsibility for allocating IP addresses to Russian entities. It is within RIPE’s power, if directed to do so by its member organizations through its multistakeholder governance process, to create policy that would effectively withdraw the allocations of IP addresses it has made to Russian organizations.<br /> <br /> This situation bears some similarities to the governance of domain names, yet it also contains crucial differences. ICANN’s authority extends no further into the DNS hierarchy than the root level, so actions taken by ICANN inherently affect entire top-level domains unitarily, without the possibility of “surgical” actions upon one subdomain and not another. By contrast, the Regional Internet Registries can affect policy on a per-organization (or even finer) basis. Yet rescinding an IP address allocation does not prevent its previous holder from continuing to use it. Indeed, “IP address hijacking” is a relatively commonplace problem on the Internet. Therefore, although it can be precisely targeted, simply rescinding the right to use an IP address allocation is '''not, by itself, an effective sanction'''. <br /> <br /> Note that this process of IP address revocation and RPKI attestation revocation would be a normal consequence of an address recipient (such as the Russian military) failing to pay annual registration fees to its Regional Internet Registry, something that may in fact come to pass as a consequence of financial and banking sanctions. But such a process might take years. Another negative consequence of revoking IP address allocations is that revoked addresses will likely be allocated to a different recipient subsequently, who will then find themselves competing with the original holder for their use. <br /> <br /> ===Manipulation of routing security attestations===<br /> A potential sanction not explicitly requested in Mr. Nabok’s letter is the manipulation of routing security attestations to produce the effect of a partial or complete disconnection from the Internet of specific networks, such as those of the Russian military or propaganda agencies. <br /> <br /> As with domain names, technical mechanisms exist to cryptographically verify the legitimacy of use of IP addresses. Routing Policy Specification Language (RPSL) and Routing Public Key Infrastructure (RPKI) are the two primary such mechanisms. To be used for communication on the Internet, IP addresses must be “announced” through the routing system, and the routers of the larger and better-secured networks utilize these two mechanisms to ensure that invalid routes are not used by their routers. Smaller and less-secured networks do not typically implement these mechanisms. <br /> <br /> A manipulation of RPSL and RPKI records in centralized registries would flow through to all networks employing these common routing security mechanisms, some of which would then automatically stop routing traffic to and from the specified networks, without affecting other “adjacent” civilian networks or being subject to trivial “work-arounds.” <br /> <br /> The manipulation of RPSL and RPKI routing security attestations could be an effective sanction measure, because it appears precise, easily and quickly implemented and reversed, and reasonably effective. However, the appropriation of preexisting routing security mechanisms for use in sanctions, likely unexpected by the participating networks, could conflict with the business or regulatory requirements of those networks, and, crucially, could risk the withdrawal of networks from the system entirely. Such an exodus would both make this potential sanction less effective in the future and have the far greater cost of eroding cybersecurity for the Internet as a whole, the purpose for which the routing security systems were built in the first place. This thus constitutes an '''unacceptable risk'''.<br /> <br /> ===Other Internet-associated, non-technical sanctions===<br /> Other sanctions related to the Internet’s operation and governance may be worth considering. These include, for example, the disallowance of sanctioned personnel from participation in Internet governance, policymaking, or standardization proceedings. Such nontechnical measures are outside the scope of this document.<br /> <br /> ===Blocklisting===<br /> Network operators and DNS resolver operators already make use of multistakeholder-governed lists, similar to the way financial lenders use credit scoring agencies, to determine what IP addresses to route and pass traffic between, and what domain names to resolve. This is the mechanism by which persistent spammers and address hijackers are excluded from the network, and by which Internet users are protected from malware and phishing attacks.<br /> <br /> The technical mechanisms by which such blocking information is passed are mature, robust, instantaneous, and globally standardized. Information related to IP addresses and Autonomous System Numbers is mostly carried over BGP feeds, while information related to domain names is mostly carried over RPZ feeds. Both mechanisms are implemented by essentially all large operators globally. Blocklisting IP addresses and Autonomous System Numbers has all of the advantages of address block revocation or manipulation of routing security attestations, without the drawbacks. It allows network operators to block both the acceptance of routes and the passage of traffic, each or both of which may be appropriate in different situations and in response to different threats. Blocklisting of domain names allows full precision and specificity, which is the problem that precludes action by ICANN. The system is opt-in, voluntary, consensual, and bottom-up, all values the Internet governance community holds dear. Yet, at the same time, it has achieved broad adoption.<br /> <br /> We conclude that the well-established methods of blocklisting provide the '''best mechanism for sanctioning both IP routes and traffic and domain names''', and that this mechanism, if implemented normally by subscribing entities, has no significant costs or risks.<br /> <br /> ===Conclusion===<br /> Our conclusion is that '''blocklisting''' of IP addresses, Autonomous Systems, and domain names upon which the multistakeholder community can establish consensus is effective and carries no inherent danger of being over-broad. Once decided upon, it is easily invoked—and equally easily rolled back once the problem is resolved. Most important, it carries no significant costs or risks and is aligned with the Internet’s multistakeholder governance values and principles.</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=282 2022-04-07T15:15:48Z

<p>Woody: /* IPv4 Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> As of March 27, 2022, we have two domain name beacons. They are:<br /> <br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']&lt;br&gt;<br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> <br /> Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net.<br /> <br /> {{plainlist|<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> }}<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 7, 2022, ARIN's 8.4 transfer group has acknowledged that the transfer of our two /24s is approved, but has not yet completed the transfer.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:<br /> <br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/asn/view/AS13400 '''16-bit''': 13400]&lt;br&gt;<br /> * [https://account.arin.net/public/secure/asn/view/AS400603 '''32-bit''': 400603]<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=281 2022-04-07T15:15:30Z

<p>Woody: /* IPv4 Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> As of March 27, 2022, we have two domain name beacons. They are:<br /> <br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']&lt;br&gt;<br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> <br /> Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net.<br /> <br /> {{plainlist|<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> }}<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 7, ARIN's 8.4 transfer group has acknowledged that the transfer of our two /24s is approved, but has not yet completed the transfer.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:<br /> <br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/asn/view/AS13400 '''16-bit''': 13400]&lt;br&gt;<br /> * [https://account.arin.net/public/secure/asn/view/AS400603 '''32-bit''': 400603]<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=280 2022-04-07T15:12:30Z

<p>Woody: /* Domain Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> As of March 27, 2022, we have two domain name beacons. They are:<br /> <br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']&lt;br&gt;<br /> [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> <br /> Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net.<br /> <br /> {{plainlist|<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a '''sanctions-beacon.net''']<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a '''sanctions-beacon.com''']<br /> }}<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 5, RIPE has contacted ARIN's 8.4 transfer group and initiated the transfer of our two /24s.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:<br /> <br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/asn/view/AS13400 '''16-bit''': 13400]&lt;br&gt;<br /> * [https://account.arin.net/public/secure/asn/view/AS400603 '''32-bit''': 400603]<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=279 2022-04-07T15:09:50Z

<p>Woody: /* Domain Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> As of March 27, 2022, we have two domain name beacons. They are:<br /> {{plainlist|<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.net&amp;t=a sanctions-beacon.net]<br /> * [https://lookup.icann.org/lookup?q=sanctions-beacon.com&amp;t=a sanctions-beacon.com]<br /> }}<br /> <br /> Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net.<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 5, RIPE has contacted ARIN's 8.4 transfer group and initiated the transfer of our two /24s.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:<br /> <br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/asn/view/AS13400 '''16-bit''': 13400]&lt;br&gt;<br /> * [https://account.arin.net/public/secure/asn/view/AS400603 '''32-bit''': 400603]<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=278 2022-04-07T15:04:31Z

<p>Woody: /* IPv6 Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net.<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 5, RIPE has contacted ARIN's 8.4 transfer group and initiated the transfer of our two /24s.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:<br /> <br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/asn/view/AS13400 '''16-bit''': 13400]&lt;br&gt;<br /> * [https://account.arin.net/public/secure/asn/view/AS400603 '''32-bit''': 400603]<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=277 2022-04-07T15:04:18Z

<p>Woody: /* ASN Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net.<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 5, RIPE has contacted ARIN's 8.4 transfer group and initiated the transfer of our two /24s.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:<br /> <br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/asn/view/AS13400 '''16-bit''': 13400]&lt;br&gt;<br /> * [https://account.arin.net/public/secure/asn/view/AS400603 '''32-bit''': 400603]<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=276 2022-04-07T15:01:21Z

<p>Woody: /* IPv6 Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net.<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 5, RIPE has contacted ARIN's 8.4 transfer group and initiated the transfer of our two /24s.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> The 16-bit beacon ASN is [https://account.arin.net/public/secure/asn/view/AS13400 13400]&lt;br&gt;<br /> The 32-bit beacon ASN is [https://account.arin.net/public/secure/asn/view/AS400603 400603]</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=275 2022-04-07T15:00:50Z

<p>Woody: /* IPv6 Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net.<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 5, RIPE has contacted ARIN's 8.4 transfer group and initiated the transfer of our two /24s.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 7, we've received both of the IPv6 /48 beacon subnets that we applied for. They are:<br /> {{plainlist|<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A9-2000-1 '''SANCTIONS-BEACON-IPV6-A''', 2620:A9:2000::/48]<br /> * [https://account.arin.net/public/secure/net/view/NET6-2620-A8-E000-1 '''SANCTIONS-BEACON-IPV6-B''', 2620:A8:E000::/48]<br /> }}<br /> <br /> ==== ASN Beacon ====<br /> The 16-bit beacon ASN is [https://account.arin.net/public/secure/asn/view/AS13400 13400]&lt;br&gt;<br /> The 32-bit beacon ASN is [https://account.arin.net/public/secure/asn/view/AS400603 400603]</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:More_Specific_Domains&diff=274 2022-04-07T14:57:21Z

<p>Woody: Created page with &quot;If a domain name (for instance &quot;badperson.net&quot;) is sanctioned, should all subdomains of that domain (for instance &quot;www.badperson.net&quot;) be automatically sanctioned as well? Or...&quot;</p> <hr /> <div>If a domain name (for instance &quot;badperson.net&quot;) is sanctioned, should all subdomains of that domain (for instance &quot;www.badperson.net&quot;) be automatically sanctioned as well? Or should each specific domain be sanctioned individually, recognizing that the operator of the sanctioned domain is then free to create additional as-yet-unsanctioned subdomains at will?</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=273 2022-04-07T14:55:19Z

<p>Woody: /* Domain Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name ''and not'' by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should ''not'' be visible). Depending upon the decision of the policy group on the matter of [[Policy:More Specific Domains|more specific domain names]], we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net.<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 5, RIPE has contacted ARIN's 8.4 transfer group and initiated the transfer of our two /24s.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 1, we've submitted requests to ARIN for two independent /48s of IPv6 space, and they are not yet approved.<br /> <br /> ==== ASN Beacon ====<br /> The 16-bit beacon ASN is [https://account.arin.net/public/secure/asn/view/AS13400 13400]&lt;br&gt;<br /> The 32-bit beacon ASN is [https://account.arin.net/public/secure/asn/view/AS400603 400603]</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Policy_Group&diff=272 2022-04-07T14:54:40Z

<p>Woody: /* Open Issues */</p> <hr /> <div>{{TOC right}}<br /> The '''policy group''' monitors the political situation and the sanction initiatives of national governments, and evaluates proposed sanctions in light of the project's [[Policy:Guiding Principles|guiding principles]] and precedents in [[Policy:International Law and Norms|international law and norms]], including those governing fundamental human rights of [[Policy:Freedom of Expression and Access to Information|freedom of expression and access to information]]. If a sanction is deemed in-scope, the policy group defines the sanctioned entities and passes them to the OSINT group. The policy group is also responsible for determining when existing sanctions should be repealed.<br /> <br /> The work of the policy group is done on the discussion mailing list (which you're [https://lists.sanctions.net/mailman/listinfo/discuss welcome to join], or you can consult its [https://lists.sanctions.net/pipermail/discuss/ archives of past discussion]) and its results are published here.<br /> ----<br /> == Thoughts and Articles ==<br /> * [[Policy:The Goals of Sanctions|The goals of sanctions]]<br /> <br /> == Open Issues ==<br /> * [[Policy:The &quot;Human Shield&quot; Problem|The &quot;human shield&quot; problem]]<br /> * [[Policy:More Specific Domains|The &quot;more specific domain&quot; question]]<br /> * [[Policy:Data Formatting Issues|Data formatting issues]]<br /> * [[Policy:Intake Database|Intake database]]<br /> <br /> ----<br /> <br /> == Specific Sanction Reviews ==<br /> === 2022 ===<br /> ==== Multiple vs. Russia and Belarus ====<br /> Near the end of February 2022, many countries began levying sanctions against more than a thousand entities in Russia and Belarus, in connection with Russia's military invasion of Ukraine. In some cases, the sanctions were additive with preexisting ones associated with Russia's 2014 military invasion of Ukraine. [[Policy:Multiple vs. Russia and Belarus, 2022 |Discussion of these sanctions can be found here.]]<br /> <br /> ==== Afghanistan vs. United States et al. ====<br /> In March, 2022, the Afghan government sanctioned Voice of America, the British Broadcasting Corporation, and Deutsche Welle. [[Policy:Afghanistan vs. Western Broadcasters, 2022|Discussion of these sanctions can be found here.]]<br /> <br /> ==== United States vs. Iran ====<br /> In March, 2022, the United States government added Iranian procurement agent Mohammad Ali Hosseini and his associated companies to existing sanctions aimed at Iran's ballistic missile development program. [[Policy: United States vs. Iranian Ballistic Missile Program, 2022|Discussion of these sanctions can be found here.]]</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=271 2022-04-05T14:02:21Z

<p>Woody: /* ASN Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well.<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 5, RIPE has contacted ARIN's 8.4 transfer group and initiated the transfer of our two /24s.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 1, we've submitted requests to ARIN for two independent /48s of IPv6 space, and they are not yet approved.<br /> <br /> ==== ASN Beacon ====<br /> The 16-bit beacon ASN is [https://account.arin.net/public/secure/asn/view/AS13400 13400]&lt;br&gt;<br /> The 32-bit beacon ASN is [https://account.arin.net/public/secure/asn/view/AS400603 400603]</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=270 2022-04-05T14:02:07Z

<p>Woody: /* ASN Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well.<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 5, RIPE has contacted ARIN's 8.4 transfer group and initiated the transfer of our two /24s.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 1, we've submitted requests to ARIN for two independent /48s of IPv6 space, and they are not yet approved.<br /> <br /> ==== ASN Beacon ====<br /> The 16-bit beacon ASN is [https://account.arin.net/public/secure/asn/view/AS13400 AS13400]&lt;br&gt;<br /> The 32-bit beacon ASN is [https://account.arin.net/public/secure/asn/view/AS400603 AS400603]</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=269 2022-04-05T13:31:00Z

<p>Woody: </p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well.<br /> <br /> ==== IPv4 Beacon ====<br /> As of April 5, RIPE has contacted ARIN's 8.4 transfer group and initiated the transfer of our two /24s.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 1, we've submitted requests to ARIN for two independent /48s of IPv6 space, and they are not yet approved.<br /> <br /> ==== ASN Beacon ====<br /> As of April 4, we've received the 16-bit ASN, which is [https://account.arin.net/public/secure/asn/view/AS13400 AS13400], but we're still waiting on the 32-bit ASN.</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=268 2022-04-05T01:04:45Z

<p>Woody: /* ASN Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well.<br /> <br /> ==== IPv4 Beacon ====<br /> As of March 31, we have secured a donor for two independent IPv4 /24s, our new ARIN OrgID, SANCT-7, is active, the transfer has been initiated, and we're waiting for RIPE to contact ARIN's 8.4 transfer group.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 1, we've submitted requests to ARIN for two independent /48s of IPv6 space.<br /> <br /> ==== ASN Beacon ====<br /> As of April 4, we've received the 16-bit ASN, which is [https://account.arin.net/public/secure/asn/view/AS13400 AS13400], but we're still waiting on the 32-bit ASN.</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=258 2022-04-01T07:09:38Z

<p>Woody: /* IPv6 Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well.<br /> <br /> ==== IPv4 Beacon ====<br /> As of March 31, we have secured a donor for two independent IPv4 /24s, our new ARIN OrgID, SANCT-7, is active, the transfer has been initiated, and we're waiting for RIPE to contact ARIN's 8.4 transfer group.<br /> <br /> ==== IPv6 Beacon ====<br /> As of April 1, we've submitted requests to ARIN for two independent /48s of IPv6 space.<br /> <br /> ==== ASN Beacon ====<br /> As of March 31, we've been approved for both a 16-bit and a 32-bit ASN, and we're waiting to receive the invoices for them before they can be issued.</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=257 2022-04-01T07:08:50Z

<p>Woody: /* ASN Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well.<br /> <br /> ==== IPv4 Beacon ====<br /> As of March 31, we have secured a donor for two independent IPv4 /24s, our new ARIN OrgID, SANCT-7, is active, the transfer has been initiated, and we're waiting for RIPE to contact ARIN's 8.4 transfer group.<br /> <br /> ==== IPv6 Beacon ====<br /> As of March 30, we're waiting for the completion of the ARIN account setup, but have an informal confirmation that we'll be approved for two IPv6 /48s.<br /> <br /> ==== ASN Beacon ====<br /> As of March 31, we've been approved for both a 16-bit and a 32-bit ASN, and we're waiting to receive the invoices for them before they can be issued.</div>

Woody https://wiki.sanctions.net/index.php?title=Research:Beacon&diff=256 2022-04-01T07:08:00Z

<p>Woody: /* IPv4 Beacon */</p> <hr /> <div>__NOTOC__<br /> The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.<br /> <br /> Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one strobing on a one-hour period.<br /> <br /> ==== Domain Beacon ====<br /> We have registered two domain names for this purpose: [http://sanctions-beacon.net sanctions-beacon.net] and [http://sanctions-beacon.com sanctions-beacon.com]. Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well.<br /> <br /> ==== IPv4 Beacon ====<br /> As of March 31, we have secured a donor for two independent IPv4 /24s, our new ARIN OrgID, SANCT-7, is active, the transfer has been initiated, and we're waiting for RIPE to contact ARIN's 8.4 transfer group.<br /> <br /> ==== IPv6 Beacon ====<br /> As of March 30, we're waiting for the completion of the ARIN account setup, but have an informal confirmation that we'll be approved for two IPv6 /48s.<br /> <br /> ==== ASN Beacon ====<br /> As of March 30, we're waiting for the completion of the ARIN account setup, but have an informal confirmation that we'll be approved for two independent ASNs, one 16-bit, the other 32-bit.</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:The_Goals_of_Sanctions&diff=255 2022-03-31T14:42:21Z

<p>Woody: </p> <hr /> <div>Experts in the field of sanctions categorize the goals which sanctions can achieve as [https://www.iss.europa.eu/sites/default/files/EUISSFiles/cp155.pdf signaling, constraint, and coercion].<br /> <br /> '''Signaling''' is an attempt to communicate a community's strong disapproval to the sanctioned entity and the public: to convey to the world that army is operating outside the bounds of legal armed conflict and this should not be tolerated, for instance.<br /> <br /> '''Constraint''' is an attempt to directly curtail the actions of the sanctioned party: to stop a DDoS by blocking resolution of the domain name by which it locates its command and control, for instance.<br /> <br /> '''Coercion''' is an attempt to influence the voluntary behavior of the sanctioned party: to convince an arms manufacturer to stop selling to a third party, for instance.<br /> <br /> The success of a sanction may not be directly quantifiable, but it may be directed toward any or all of these goals simultaneously, and need only succeed in one of them in order to be effective. Signaling is the easiest of these goals to achieve. Constraint requires effective implementation to be successful, but is well within the realm of possibility for Internet sanctions, as it differs little from existing constraints placed by the community upon the actions of spammers, booters, phishers, and the like. Coercion is generally understood to be the most difficult goal to achieve, particularly with respect to a concerted adversary; in the case of Internet sanctions, it depends both upon the degree to which the sanctioned entity depends upon the Internet and the degree to which a sanction effectively constrains or increases the cost of such access.</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:The_Goals_of_Sanctions&diff=254 2022-03-31T14:36:04Z

<p>Woody: Created page with &quot;Experts in the field of sanctions categorize the goals which sanctions can achieve as [https://www.iss.europa.eu/sites/default/files/EUISSFiles/cp155.pdf coercion, constraint,...&quot;</p> <hr /> <div>Experts in the field of sanctions categorize the goals which sanctions can achieve as [https://www.iss.europa.eu/sites/default/files/EUISSFiles/cp155.pdf coercion, constraint, and signaling].<br /> <br /> '''Coercion''' is an attempt to influence the voluntary behavior of the sanctioned party: to convince an arms manufacturer to stop selling to a third party, for instance.<br /> <br /> '''Constraint''' is an attempt to directly curtail the actions of the sanctioned party: to stop a DDoS by blocking resolution of the domain name by which it locates its command and control, for instance.<br /> <br /> '''Signaling''' is an attempt to communicate a community's strong disapproval to the sanctioned entity and the public: to convey to the world that army is operating outside the bounds of legal armed conflict and this should not be tolerated, for instance.<br /> <br /> The success of a sanction may not be directly quantifiable, but it may be directed toward any or all of these goals simultaneously, and need only succeed in one of them in order to be effective.</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Policy_Group&diff=253 2022-03-31T14:26:59Z

<p>Woody: </p> <hr /> <div>{{TOC right}}<br /> The '''policy group''' monitors the political situation and the sanction initiatives of national governments, and evaluates proposed sanctions in light of the project's [[Policy:Guiding Principles|guiding principles]] and precedents in [[Policy:International Law and Norms|international law and norms]], including those governing fundamental human rights of [[Policy:Freedom of Expression and Access to Information|freedom of expression and access to information]]. If a sanction is deemed in-scope, the policy group defines the sanctioned entities and passes them to the OSINT group. The policy group is also responsible for determining when existing sanctions should be repealed.<br /> <br /> The work of the policy group is done on the discussion mailing list (which you're [https://lists.sanctions.net/mailman/listinfo/discuss welcome to join], or you can consult its [https://lists.sanctions.net/pipermail/discuss/ archives of past discussion]) and its results are published here.<br /> ----<br /> == Thoughts and Articles ==<br /> * [[Policy:The Goals of Sanctions|The goals of sanctions]]<br /> <br /> == Open Issues ==<br /> * [[Policy:The &quot;Human Shield&quot; Problem|The &quot;human shield&quot; problem]]<br /> * [[Policy:Data Formatting Issues|Data formatting issues]]<br /> * [[Policy:Intake Database|Intake database]]<br /> <br /> ----<br /> == Specific Sanction Reviews ==<br /> === 2022 ===<br /> ==== Multiple vs. Russia and Belarus ====<br /> Near the end of February 2022, many countries began levying sanctions against more than a thousand entities in Russia and Belarus, in connection with Russia's military invasion of Ukraine. In some cases, the sanctions were additive with preexisting ones associated with Russia's 2014 military invasion of Ukraine. [[Policy:Multiple vs. Russia and Belarus, 2022 |Discussion of these sanctions can be found here.]]<br /> <br /> ==== Afghanistan vs. United States et al. ====<br /> In March, 2022, the Afghan government sanctioned Voice of America, the British Broadcasting Corporation, and Deutsche Welle. [[Policy:Afghanistan vs. Western Broadcasters, 2022|Discussion of these sanctions can be found here.]]<br /> <br /> ==== United States vs. Iran ====<br /> In March, 2022, the United States government added Iranian procurement agent Mohammad Ali Hosseini and his associated companies to existing sanctions aimed at Iran's ballistic missile development program. [[Policy: United States vs. Iranian Ballistic Missile Program, 2022|Discussion of these sanctions can be found here.]]</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Policy_Group&diff=252 2022-03-31T14:24:26Z

<p>Woody: </p> <hr /> <div>{{TOC right}}<br /> The '''policy group''' monitors the political situation and the sanction initiatives of national governments, and evaluates proposed sanctions in light of the project's [[Policy:Guiding Principles|guiding principles]] and precedents in [[Policy:International Law and Norms|international law and norms]], including those governing fundamental human rights of [[Policy:Freedom of Expression and Access to Information|freedom of expression and access to information]]. If a sanction is deemed in-scope, the policy group defines the sanctioned entities and passes them to the OSINT group. The policy group is also responsible for determining when existing sanctions should be repealed.<br /> <br /> The work of the policy group is done on the discussion mailing list (which you're [https://lists.sanctions.net/mailman/listinfo/discuss welcome to join], or you can consult its [https://lists.sanctions.net/pipermail/discuss/ archives of past discussion]) and its results are published here.<br /> ----<br /> == Open Policy Questions ==<br /> * [[Policy:The &quot;Human Shield&quot; Problem|The &quot;human shield&quot; problem]]<br /> * [[Policy:Data Formatting Issues|Data formatting issues]]<br /> * [[Policy:Intake Database|Intake database]]<br /> <br /> == Specific Sanction Reviews ==<br /> === 2022 ===<br /> ==== Multiple vs. Russia and Belarus ====<br /> Near the end of February 2022, many countries began levying sanctions against more than a thousand entities in Russia and Belarus, in connection with Russia's military invasion of Ukraine. In some cases, the sanctions were additive with preexisting ones associated with Russia's 2014 military invasion of Ukraine. [[Policy:Multiple vs. Russia and Belarus, 2022 |Discussion of these sanctions can be found here.]]<br /> <br /> ==== Afghanistan vs. United States et al. ====<br /> In March, 2022, the Afghan government sanctioned Voice of America, the British Broadcasting Corporation, and Deutsche Welle. [[Policy:Afghanistan vs. Western Broadcasters, 2022|Discussion of these sanctions can be found here.]]<br /> <br /> ==== United States vs. Iran ====<br /> In March, 2022, the United States government added Iranian procurement agent Mohammad Ali Hosseini and his associated companies to existing sanctions aimed at Iran's ballistic missile development program. [[Policy: United States vs. Iranian Ballistic Missile Program, 2022|Discussion of these sanctions can be found here.]]</div>

Woody https://wiki.sanctions.net/index.php?title=Welcome_to_the_Internet_Sanctions_Project&diff=251 2022-03-31T13:30:00Z

<p>Woody: /* Why does this project exist? */</p> <hr /> <div>__NOTOC__<br /> This is an [https://en.wikipedia.org/wiki/Open_standard open], [https://en.wikipedia.org/wiki/Internet_governance Internet community governed], project which produces real-time [https://en.wikipedia.org/wiki/Border_Gateway_Protocol BGP] and [https://en.wikipedia.org/wiki/Response_policy_zone RPZ] data feeds of network resources ([https://en.wikipedia.org/wiki/IP_address IP addresses], [https://en.wikipedia.org/wiki/Autonomous_system_(Internet) Autonomous System numbers], and [https://en.wikipedia.org/wiki/Domain_name domain names]) associated with [https://en.wikipedia.org/wiki/Economic_sanctions sanctioned] entities. These data feeds facilitate [https://en.wikipedia.org/wiki/Internet_service_provider Internet network operators] in complying with governmentally-mandated sanctions against violators of international and human rights law.<br /> <br /> === Why does this project exist? ===<br /> National governments have used sanctions as a deescalatory punitive measure for [https://foreignpolicy.com/2012/04/23/smart-sanctions-a-short-history/ thousands of years]. The private sector within each nation is responsible for enacting sanctions defined by their government. This has historically worked well with banking, since banks (which may superficially appear to be multinational) are actually collections of individual, autonomous, independently-regulated entities, each existing within a single country, though they may share a common brand. But the &quot;flat&quot; global, transnational nature of the Internet makes compliance with diverse sanctions regimes much more difficult for Internet organizations. Large Internet networks operate as single networks spanning the world, with unitary policy and technical choices implemented globally. Thus a policy imposed by a single government on a global network, if implemented, has [https://en.wikipedia.org/wiki/Extraterritorial_jurisdiction extraterritorial effects] in every other country, violating those countries' [https://en.wikipedia.org/wiki/Westphalian_sovereignty Westphalian] rights of [https://en.wikipedia.org/wiki/Self-determination self-determination]. And conflicting policies imposed by different governments cannot be resolved without breaking the fundamental nature of Internet connectivity.<br /> <br /> At the same time, broadly-defined Internet sanctions tend to disproportionately affect the civilian population of sanctioned countries; this is both counterproductive and violates their human rights to freedom of communication and access to information as recognized by [[Policy:Freedom of Expression and Access to Information|the United Nations, the European Union, the Council of Europe, the Organization of American States, the African Union, and others]]. <br /> <br /> This project brings together governments, Internet organizations, civil society, and academia to provide a globally-harmonized Internet sanctions imposition mechanism that combines the expertise and perspectives of different stakeholders to develop proportional and effective sanctions that aim to not impinge upon civilians' access to information and communications. '''This project is neither pro-sanction nor anti-sanction'''; it exists to facilitate public-sector/private-sector coordination while ensuring that the human rights of civilians are protected.<br /> <br /> === Origin of the project ===<br /> This project originated in an [[The Open Letter|open letter]] from leaders of the multistakeholder Internet governance community, calling for constructive dialog about the imposition of Internet-related sanctions, and for a principled, structured, and transparent approach to sanctions, with the explicit aim of maintaining connectivity to civilian populations. <br /> <br /> === Structure ===<br /> The project is implemented by five working groups:<br /> <br /> * A [[Policy:Policy Group|'''policy group''']] monitors the political situation and the sanction initiatives of national governments, and evaluates whether a situation or proposed sanctions is relevant in light of the project's principles. If a sanction is deemed in-scope, the policy group defines the situation and (potentially) sanctioned entities and passes them to the [[Open Source Intelligence|OSINT group]]. The policy group is responsible for determining the limited scope of measures, analyzing when existing sanctions should be repealed, and for liaising with governments which are considering declaring this mechanism to be sufficient compliance with their nationally-defined sanctions.<br /> <br /> * An [[Open Source Intelligence|'''intelligence group''']] investigates and catalogs the Internet resources (IP addresses, Autonomous System numbers, and domain names) held by sanctioned entities. This helps the [[Policy Group|policy group]] understand the (potential) impact of measures and assess their proportionality. <br /> <br /> * An [[Oversight Board|'''oversight board''']] provides a final check on which resources are included in the blocking feed, verifying its conformity with international and human rights law. When anything is added to the feed, an announcement will be posted to the (read-only) [https://lists.sanctions.net/mailman/listinfo/announce announcement email list], which you're welcome to subscribe to, to keep track of the project's outcomes.<br /> <br /> * An [[Operations Group|'''operations group''']] keeps the BGP and RPZ feed publishing mechanisms working and gather feedback from implementers.<br /> <br /> * A [[Research Group|'''research group''']] is responsible for metrics and monitoring of the system and its effectiveness, and liaises with the academic community.<br /> <br /> === Participation ===<br /> This is a community volunteer effort, and your participation is welcome! Please consider [[Frequently Asked Questions|reading the FAQ]] and subscribing to the [[E-Mail Discussion Lists|email discussion lists]] as starting-points.<br /> <br /> <br /> &lt;!--<br /> == Getting started ==<br /> * Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]<br /> * [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]<br /> --&gt;</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Afghanistan_vs._Western_Broadcasters,_2022&diff=250 2022-03-31T09:59:43Z

<p>Woody: </p> <hr /> <div>[https://www.state.gov/media-access-and-fundamental-freedoms-in-afghanistan/ U.S. State Department complaint].<br /> <br /> {{Blockquote<br /> |text=&quot;It is with alarm and deep concern we learned of the Taliban’s decision to stifle the Afghan people’s access to independent, objective, international media sources. Media outlets such as the '''Voice of America''', the '''British Broadcasting Corporation''', and '''Deutsche Welle''' have reported that their local broadcasting partners have been prevented from airing their programming in the country due to new, restrictive, and unpublished guidelines from the Taliban.&quot;<br /> }}<br /> <br /> We do not yet have documentation of this from the Afghan government side.</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:Afghanistan_vs._Western_Broadcasters,_2022&diff=249 2022-03-31T09:59:12Z

<p>Woody: Created page with &quot;[https://www.state.gov/media-access-and-fundamental-freedoms-in-afghanistan/ U.S. State Department complaint]. {{Blockquote |text=&quot;It is with alarm and deep concern we learne...&quot;</p> <hr /> <div>[https://www.state.gov/media-access-and-fundamental-freedoms-in-afghanistan/ U.S. State Department complaint].<br /> <br /> {{Blockquote<br /> |text=&quot;It is with alarm and deep concern we learned of the Taliban’s decision to stifle the Afghan people’s access to independent, objective, international media sources. Media outlets such as the '''Voice of America''', the '''British Broadcasting Corporation''', and '''Deutsche Welle''' have reported that their local broadcasting partners have been prevented from airing their programming in the country due to new, restrictive, and unpublished guidelines from the Taliban.&quot;<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:United_States_vs._Iranian_Ballistic_Missile_Program,_2022&diff=248 2022-03-31T09:56:03Z

<p>Woody: </p> <hr /> <div>[https://home.treasury.gov/news/press-releases/jy0689 US Treasury Department announcement].<br /> <br /> {{Blockquote<br /> |text=&quot;'''Mohammad Ali Hosseini''' is being designated for having provided, or attempted to provide, financial, material, technological or other support for, or goods or services in support of, the IRGC RSSJO and PCI.<br /> <br /> '''Sina Composite''' is being designated for having provided, or attempted to provide, financial, material, technological or other support for, or goods or services in support of, the IRGC RSSJO.<br /> <br /> '''Sepehr Delijan''' and '''Jestar Sanat''' are being designated for being owned or controlled by, directly or indirectly, Mohammad Ali Hosseini.<br /> <br /> Today’s action also targets '''P.B. Sadr Co.''' which has acted on behalf of Parchin Chemical Industries as a key intermediary to procure parts that are used to develop missile propellant.&quot;<br /> }}</div>

Woody https://wiki.sanctions.net/index.php?title=Policy:United_States_vs._Iranian_Ballistic_Missile_Program,_2022&diff=247 2022-03-31T09:53:19Z

<p>Woody: Created page with &quot;[https://home.treasury.gov/news/press-releases/jy0689 US Treasury Department announcement].&quot;</p> <hr /> <div>[https://home.treasury.gov/news/press-releases/jy0689 US Treasury Department announcement].</div>

Woody