BOLT #7: Can receiving node requirements in channel_update message give rise to malicious attacks?

Question

Following requirements have been placed on the receiving nodes related to the channel_update message in BOLT #7.

• if timestamp is NOT greater than that of the last-received channel_update for this short_channel_id AND for node_id:
  • SHOULD ignore the message.
• otherwise:
  • if the timestamp is equal to the last-received channel_update AND the fields (other than signature) differ:
    • MAY blacklist this node_id.
    • MAY forget all channels associated with it.

According to my understanding the receiving node will first check the signature of related the dsha256 of the entire message before verifying the timestamp and not check the remainder of the message if the signature is invalid. So if other fields apart from signature are changed, then the signature will not be valid (as the message has changed) and the node will not process the message further.

Now here's the thing I'm wrestling with: If the node still plans to check the message (as shown in the quoted text above) even though the signature is invalid and then go forward to blacklist the node, it can give rise to DoS attacks. A malicious nodes will just take a channel_update message that it received in the past from a node, change some fields like htlc_minimum_msat and rebroadcast to other nodes. Those receiving nodes will then simply blacklist the node_id without any wrongdoing from its part as (1) the timestamp is equal to the one it received in the past, (2) signature is same AND (3) other fields have changed.

So I feel that this check is simply not needed and if the software goes on to process this message despite checking the signature then it can give rise to attacks from malicious parties. Where am I incorrect in my thought process?

Answer 1

According to my understanding the receiving node will first check the signature of related the dsha256 of the entire message before verifying the timestamp and not check the remainder of the message if the signature is invalid. So if other fields apart from signature are changed, then the signature will not be valid (as the message has changed) and the node will not process the message further.

This is the correct understanding. It is stated earlier on in the receiving rules. Although the client implementation must read at least the chain_hash and short_channel_id from the message in order to retrieve the public key associated with that channel from its storage (if it exists), in order to perform the signature check.

if signature is not a valid signature, using node_id of the double-SHA256 of the entire message following the signature field (including unknown fields following fee_proportional_millionths):

• MUST NOT process the message further.

• SHOULD fail the connection.

The checks on the timestamp and other field are performed only if the signature is valid, and the purpose of the check is to prevent spam from a valid signer. It is assumed that more than one channel_update in the same second is a DoS attempt, and therefore, the node responsible for signing such messages ought to be blacklisted.

Answer 2

if you look at the format of the channel_update message you will realize there is no field node_id in the message. c.f.:

type: 258 (channel_update)
data:
[64:signature]
[32:chain_hash]
[8:short_channel_id]
[4:timestamp]
[1:message_flags]
[1:channel_flags]
[2:cltv_expiry_delta]
[8:htlc_minimum_msat]
[4:fee_base_msat]
[4:fee_proportional_millionths]
[8:htlc_maximum_msat] (option_channel_htlc_max)

Thus the way I read the rfc is that the peer might decide to blacklist the node_id of their peer (the one who propagates the forged / wrongful channel_update message) In this way one would not create a DoS attack to some random node_id (the victim) but for oneself which is exactly how it i should work.