What are the consequences if I spoof an IP address in the node_announcment message?

Question

According to BOLT 07 the node accountment message looks like this:

1. type: 257 (node_announcement)
2. data:
   • [64:signature]
   • [2:flen]
   • [flen:features]
   • [4:timestamp]
   • [33:node_id]
   • [3:rgb_color]
   • [32:alias]
   • [2:addrlen]
   • [addrlen:addresses]

where the addresses are of the following form:

• The following address descriptor types are defined:
  • 1: ipv4; data = [4:ipv4_addr][2:port] (length 6)
  • 2: ipv6; data = [16:ipv6_addr][2:port] (length 18)
  • 3: Tor v2 onion service; data = [10:onion_addr][2:port] (length 12)
    • version 2 onion service addresses; Encodes an 80-bit, truncated SHA-1 hash of a 1024-bit RSA public key for the onion service (a.k.a. Tor hidden service).
  • 4: Tor v3 onion service; data = [35:onion_addr][2:port] (length 37)
    • version 3 (prop224) onion service addresses; Encodes: [32:32_byte_ed25519_pubkey] || [2:checksum] || [1:version], where checksum = sha3(".onion checksum" | pubkey || version)[:2].

taking this into consideration I could announce my node to have the IP address of another existing lightning node or even some arbitrary IP address. While it is clear that no one could connect to me as I don't control the IP address I wonder how the implementations would cope with such a behavior.

Even if implementations do not struggle with such spoofing an attacker could probably use this for fishing to trick a user into paying an invoice as it comes from a node_id that is connected to an IP-address from a well known service where the attacked person might even be a customer.

Is there anything else that could go wrong with such a spoofing behavior? Maybe there would even be benefits from it?

Answer 1

I don't see the attack here. You cannot claim you are a different node, because you cannot sign for that. All you can do is give a false IP address FOR YOUR OWN NODE. Which probably just leads to people not being able to reach you.

I guess the only interesting case is where the IP you give is already known as another node. Maybe the spec should spell out what an implementation should do then. But I guess not doing anything is probably fine, since you could still reach the known node under its IP adress (node lookup being per ID, I guess), and whenever you try to reach the spoofing node under the fake address, it just won't respond.