We'd like to know the path that a given ILP payment took or would take.
We add a header which lets you define a IPv6 UDP address and port and a unique ID.
{
"target_ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7334",
"target_port": 8273,
"unique_id": "52a6461e-2753-47b0-8dd4-a8d970c716ff"
}Each connector that forwards the payment will also send a UDP packet during fulfillment to that IP+port containing:
- Incoming transfer
- Connector's ILP address
- Amount the connector received
- Local source address
- Outgoing transfer
- Connector's ILP address
- Amount the connector is sending out
- Local destination address
- Timestamps
- Preparation time
- Fulfillment time
- Geographic location
All fields are optional. Connectors MAY decide not to respond, omit or spoof any of the fields.
This mechanism could be abused as a DDoS vector. I make lots of payments and designate the victim's IP address as the pingback destination. However, by pinging only when a payment is fulfilled, we make it a relatively expensive DDoS vector that is likely not too attractive compared to other alternatives.
As for using this as an attack on the connector: Sending an extra UDP packet per payment is not enough work to cause the connector to be overloaded. Also, the connector is getting compensated for each payment.
The timestamps (if precise enough) could enable timing attacks (e.g. cryptographic timing attacks) by providing detailed enough information about the processing delays between connectors. This would have to be carefully audited by connector operators and ILP protocol designers.