[Sanctions-Research] Beacon resource accumulation complete.

[John Kristoff]

On Mon, 11 Apr 2022 16:20:02 +0200
Bill Woodcock <woody at pch.net> wrote:

> I believe we need input now from the research community as to exactly
> how you’d like the strobe function of the beacon configured.  Please
> bear in mind that we’d like to serve web objects from the beacons, so
> that an end-user-visible web page can be loaded, showing the status
> of each beacon… If we strobe, we need the underlying web page to
> update on the same frequency, such that the expected state of each
> beacon is correct relative to the page.

Ideally there would exist a set of stable names and addresses that are
always in the block lists, a set never in the block lists, and a set
that "cycles" in and out of the block list.  As much as possible, the
ability to perform unique look ups or access a unique destination is
beneficial to avoid caching effects and to evaluate change over time.  A
set of proposals to measure those sort of things is below, but we are
certainly open to adjustments required for operations or enhancements to
streamline:

For DNS

* Create a default "allow" RR that is never added to the
  block lists. For example:

  ; allow 
  *.sanctions-beacon.net   300 IN A 192.0.2.1

* Create a "blocked" zone.  Everything at the apex or below the zone
  should go in your block lists.  The zone should have a wildcard A RR
  in order to perform one-time unique queries in the blocked zone.  For
  example:

  ; block all names with regex /block\.sanctions\-beacon\.net$/
  block.sanctions-beacon.net   300 IN A 192.0.2.1
  *.block.sanctions-beacon.net 300 IN A 192.0.2.1

* Once-a-day, add and remove a unique name from the block lists.
  Encode the date into each day's blocked name.  For example:

  ; If date == 1970-01-01
  ;     block19700101.sanctions-beacon.net and only in RPZ
  block19700101.sanctions-beacon.net 300 IN A 192.0.2.1
  block19700102.sanctions-beacon.net 300 IN A 192.0.2.1
  ; ...

For IPv4/IPv6 addresses

Create a "blocked" address/prefix.  This should go in your block
lists.  For example:

  45.154.219.254/32 next-hop /dev/null
  2620:a9:2000:254::/64 next-hop /dev/null

Create an "allowed" address/prefix that is never added to the block
lists.  For example:

  45.154.219.253/32
  2620:a9:2000:253::/64

* Once-a-day, add and remove a unique address/prefix from the block
  lists. Encode the month's day number into the address.  For example:

  ; if day of month = DD
  ;   add only these to block list, remove other DD combinations.
  ; IPv4: 45.154.219.DD/32
  ; IPv6: 2620:19:2000:DD::/64
  45.154.219.15/32 next-hop /dev/null
  2620:a9:2000:15::/64 next-hop /dev/null

Lastly, the web destination should minimally include a generated current
timestamp and the client IP address of the access request. Other
HTTP header information would be useful for analysis or debugging as
well. Note, we may not always use this returned information where
experiments would consider it to be PII.

The names and addresses can all point to the same web systems.

John