Thank you for the dissection. To make it simple, let’s say a letter from the authorities (not the service provider) arrives at a farmer. What would such a letter have as information to identify that there is illicit content on the device, and how does this letter connect the device to the farmer?
Before we think in creating a technology solution let’s get the requirements clear of what we are trying to solve. Let’s brainstorm (list is not meant to be exhaustive, us the first things that come to mind):
Identify the node / farmer:
“authorities were monitoring the network traffic of the ISP of the farmer and have found, unencrypted traffic that contains something that cannot be.”
Ok - so that seems reasonable and possible. But only if the farmer provides public IP addresses. Because all traffic between (VM’s) on nodes that do not have public IP addresses to rent (so in other words all devices behind a NAT) use encrypted, tunnelled, point-to-point wireguard / planetary networking. So this cannot be intercepted (and read) by the authorities. So we are talking about a subset of farmers that are potentially going to see this.
So the letter can be addressed to the owner of the IP address as traffic from his IP address contains (unencrypted) illicit content. How do we match IP addresses to specific farmers? IPaddresses are bought and owned or rented. So in the end (with more steps in between here the owner of the IP addresses will receive this letter, and this might be the owner of the IP addresses or the person renting them.
Good - so the letter arrives. What does it state with regards to what was monitored.
- a username of the person doing illicit online activities?
- an IPv4 address of the application that “processed” the illicit content?
- an IPv4 address of the VM on which the application ran “processing” illicit content.
There is really nothing more that they can see when they monitor / filter network traffic. So now the farmer/someone needs to go and see which contract is using that specific IP address.
So we have a query tool to query TF Chain, and this has a lot of functionality to query the chain. For example to query what contracts are active for a specific node (8
) and are using 1 or more IP addresses:
query MyQuery {
nodeContracts(where: {numberOfPublicIPs_gt: 0, nodeId_eq: 8}) {
contractId
numberOfPublicIPs
}
}
presenting:
{
"data": {
"nodeContracts": [
{
"contractId": 97,
"numberOfPublicIPs": 1
},
{
"contractId": 159,
"numberOfPublicIPs": 1
},
{
"contractId": 202,
"numberOfPublicIPs": 1
},
{
"contractId": 284,
"numberOfPublicIPs": 1
},
{
"contractId": 289,
"numberOfPublicIPs": 1
},
{
"contractId": 291,
"numberOfPublicIPs": 1
},
{
"contractId": 737,
"numberOfPublicIPs": 1
},
{
"contractId": 850,
"numberOfPublicIPs": 1
},
{
"contractId": 861,
"numberOfPublicIPs": 1
},
{
"contractId": 883,
"numberOfPublicIPs": 1
},
{
"contractId": 879,
"numberOfPublicIPs": 1
},
{
"contractId": 885,
"numberOfPublicIPs": 1
},
{
"contractId": 882,
"numberOfPublicIPs": 1
},
{
"contractId": 891,
"numberOfPublicIPs": 1
},
{
"contractId": 892,
"numberOfPublicIPs": 1
}
]
}
}
And per contract you can find out the IP’s used:
{
"data": {
"publicIps": [
{
"contractId": 885,
"ip": "185.69.166.150/24"
}
]
}
}
So if IP 185.69.166.150
was mentioned in the letter we now know that contract 885
is the one breaking the rules.
Finding out more about the contract:
query MyQuery {
nodeContracts(where: {contractId_eq: 885}) {
resourcesUsed {
cru
mru
hru
sru
}
createdAt
createdById
id
nodeId
deploymentData
state
twinId
updatedAt
updatedById
version
contractId
}
This provides us with:
{
"data": {
"nodeContracts": [
{
"resourcesUsed": {
"cru": "4",
"mru": "8589934592",
"hru": 0,
"sru": "53687091200"
},
"createdAt": "2022-04-05T11:54:36.000Z",
"createdById": "SddLDONB-l",
"id": "X9idA_uWF",
"nodeId": 8,
"deploymentData": "0x",
"state": "Created",
"twinId": 3983,
"updatedAt": "2022-04-05T11:55:32.159Z",
"updatedById": null,
"version": 4,
"contractId": 885
}
]
}
}
Which presents twin 3983
as the contract owner. we also see that the contract is for
"cru": "4",
"mru": "8589934592",
"hru": 0,
"sru": "53687091200"
which is 2CU and 50GB of SSD space. So sherlocking our way from the IP address we now know 3983
is doing it.
query MyQuery {
twins(where: {twinId_eq: 3983}) {
accountId
createdAt
createdById
deletedAt
deletedById
gridVersion
id
ip
twinId
updatedAt
updatedById
version
}
}
provides
{
"data": {
"twins": [
{
"accountId": "5DZrBLxL3XKA2DAefpxZbRpTgQ64egGDV86AkTitSvTqujsF",
"createdAt": "2022-04-05T09:16:48.000Z",
"createdById": "gvMlq7xSwV",
"deletedAt": null,
"deletedById": null,
"gridVersion": 1,
"id": "JhBnEeFCQ",
"ip": "127.0.0.1",
"twinId": 3983,
"updatedAt": "2022-04-05T09:16:48.000Z",
"updatedById": null,
"version": 1
}
]
}
}
So we can find which contract and which twin (individual) is involved in the detected activities, now we need to look at what to do with that info.
- contact
3983
?
- cancel contract
885
without notifying 3983
- cancel contract
885
with notifying 3983
- send information to the authorities that
3983
is the one to send the letter to.