Difference between revisions of "Research:Beacon"
| Line 2: | Line 2: | ||
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. | 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. | ||
| − | Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one | + | 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. |
| + | |||
| + | ==== Web Page ==== | ||
| + | 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. | ||
| + | |||
==== Domain Beacon ==== | ==== Domain Beacon ==== | ||
Revision as of 20:00, 21 April 2022
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.
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.
Web Page
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.
Domain Beacon
As of March 27, 2022, we have two domain name beacons. They are:
sanctions-beacon.net
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 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 ("negative") 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.
IPv4 Beacon
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:
IPv6 Beacon
As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:
ASN Beacon
As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:
