I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

More prop. 167 updates

Browse Source
This commit is contained in:
zzz
2024-06-28 17:14:17 -04:00
parent ec05e9bdbc
commit 748e9a682b
1 changed files with 18 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
i2p2www/spec/proposals/167-service-records.rst
View File

@@ -116,7 +116,8 @@ Defined as follows:
- optionvalue := self | srvrecord[,srvrecord]* - optionvalue := self | srvrecord[,srvrecord]*
- self := "0" ttl port [appoptions] - self := "0" ttl port [appoptions]
- srvrecord := "1" ttl priority weight port target [appoptions] - srvrecord := "1" ttl priority weight port target [appoptions]
- ttl := time to live, integer seconds. Positive integer. Example: "85400" - ttl := time to live, integer seconds. Positive integer. Example: "86400".
A minimum of 86400 (one day) is recommended, see Recommendations section below for details.
- priority := The priority of the target host, lower value means more preferred. Non-negative integer. Example: "0" - priority := The priority of the target host, lower value means more preferred. Non-negative integer. Example: "0"
Only useful if more than one record, but required even if just one record. Only useful if more than one record, but required even if just one record.
- weight := A relative weight for records with the same priority. Higher value means more chance of getting picked. Non-negative integer. Example: "0" - weight := A relative weight for records with the same priority. Higher value means more chance of getting picked. Non-negative integer. Example: "0"
@@ -189,6 +190,12 @@ or, maybe, just do a lookup for "_service._proto.xxx.b32.i2p" and the router fig
But no way to pass ttl and port back without changes. But no way to pass ttl and port back without changes.
See Recommendations section below. See Recommendations section below.
Additional MessageStatusMessage and/or HostReplyMessage error codes related to service lookup
may be required and must be added to the [I2CP]_ document.
Configuration is implementation-dependent. We may define standard I2CP options
for i2ptunnel and SAM, to be documented in [I2CP-OPTIONS]_.
TODO TODO
@@ -273,6 +280,9 @@ Naming service subsystems must check for a leading "_", strip off the first two
look up the leaseset for the remaining part of the hostname, and then lookup the look up the leaseset for the remaining part of the hostname, and then lookup the
two labels in the options field of the leaseset. two labels in the options field of the leaseset.
Lookups must also lookup the target leaseset and verify it contains a "self" record
before returning the target destination to the client.
Security Analysis Security Analysis
================= =================
@@ -282,6 +292,13 @@ As the leaseset is signed, any service records within it are authenticated by th
The service records are public and visible to floodfills, unless the leaseset is encrypted. The service records are public and visible to floodfills, unless the leaseset is encrypted.
Any router requesting the leaseset will be able to see the service records. Any router requesting the leaseset will be able to see the service records.
A SRV record other than "self" (i.e., one that points to a different hostname/b32 target)
does not require the consent of the targeted hostname/b32.
It's not clear if a redirection of a service to an arbitrary destination could facilitate some
sort of attack, or what the purpose of such an attack would be.
However, this proposal mitigates such an attack by requiring that the target
also publish a "self" SRV record. Implementers must check for a "self" record
in the leaseset of the target.
Compatibility Compatibility