{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-06-29\n📝 Original message:\nDuring the recent Oakland Dev Summit, some lightning engineers got\ntogether to discuss DoS\nprotection for onion messages. Rusty proposed a very simple\nrate-limiting scheme that\nstatistically propagates back to the correct sender, which we describe\nin details below.\n\nYou can also read this in gist format if that works better for you [1].\n\nNodes apply per-peer rate limits on _incoming_ onion messages that\nshould be relayed (e.g.\nN/seconds with some burst tolerance). It is recommended to allow more\nonion messages from\npeers with whom you have channels, for example 10/seconds when you\nhave a channel and 1/second\nwhen you don't.\n\nWhen relaying an onion message, nodes keep track of where it came from\n(by using the `node_id` of\nthe peer who sent that message). Nodes only need the last such\n`node_id` per outgoing connection,\nwhich ensures the memory footprint is very small. Also, this data\ndoesn't need to be persisted.\n\nLet's walk through an example to illustrate this mechanism:\n\n* Bob receives an onion message from Alice that should be relayed to Carol\n* After relaying that message, Bob stores Alice's `node_id` in its\nper-connection state with Carol\n* Bob receives an onion message from Eve that should be relayed to Carol\n* After relaying that message, Bob replaces Alice's `node_id` with\nEve's `node_id` in its\nper-connection state with Carol\n* Bob receives an onion message from Alice that should be relayed to Dave\n* After relaying that message, Bob stores Alice's `node_id` in its\nper-connection state with Dave\n* ...\n\nWe introduce a new message that will be sent when dropping an incoming\nonion message because it\nreached rate limits:\n\n1. type: 515 (`onion_message_drop`)\n2. data:\n   * [`rate_limited`:`u8`]\n   * [`shared_secret_hash`:`32*byte`]\n\nWhenever an incoming onion message reaches the rate limit, the\nreceiver sends `onion_message_drop`\nto the sender. The sender looks at its per-connection state to find\nwhere the message was coming\nfrom and relays `onion_message_drop` to the last sender, halving their\nrate limits with that peer.\n\nIf the sender doesn't overflow the rate limit again, the receiver\nshould double the rate limit\nafter 30 seconds, until it reaches the default rate limit again.\n\nThe flow will look like:\n\nAlice                      Bob                      Carol\n  |                         |                         |\n  |      onion_message      |                         |\n  |------------------------\u003e|                         |\n  |                         |      onion_message      |\n  |                         |------------------------\u003e|\n  |                         |    onion_message_drop   |\n  |                         |\u003c------------------------|\n  |    onion_message_drop   |                         |\n  |\u003c------------------------|                         |\n\nThe `shared_secret_hash` field contains a BIP 340 tagged hash of the\nSphinx shared secret of the\nrate limiting peer (in the example above, Carol):\n\n* `shared_secret_hash = SHA256(SHA256(\"onion_message_drop\") ||\nSHA256(\"onion_message_drop\") || sphinx_shared_secret)`\n\nThis value is known by the node that created the onion message: if\n`onion_message_drop` propagates\nall the way back to them, it lets them know which part of the route is\ncongested, allowing them\nto retry through a different path.\n\nWhenever there is some latency between nodes and many onion messages,\n`onion_message_drop` may\nbe relayed to the incorrect incoming peer (since we only store the\n`node_id` of the _last_ incoming\npeer in our outgoing connection state). The following example highlights this:\n\n Eve                       Bob                      Carol\n  |      onion_message      |                         |\n  |------------------------\u003e|      onion_message      |\n  |      onion_message      |------------------------\u003e|\n  |------------------------\u003e|      onion_message      |\n  |      onion_message      |------------------------\u003e|\n  |------------------------\u003e|      onion_message      |\n                            |------------------------\u003e|\nAlice                       |    onion_message_drop   |\n  |      onion_message      |                    +----|\n  |------------------------\u003e|      onion_message |    |\n  |                         |--------------------|---\u003e|\n  |                         |                    |    |\n  |                         |                    |    |\n  |                         |                    |    |\n  |    onion_message_drop   |\u003c-------------------+    |\n  |\u003c------------------------|                         |\n\nIn this example, Eve is spamming but `onion_message_drop` is\npropagated back to Alice instead.\nHowever, this scheme will _statistically_ penalize the right incoming\npeer (with a probability\ndepending on the volume of onion messages that the spamming peer is\ngenerating compared to the\nvolume of legitimate onion messages).\n\nIt is an interesting research problem to find formulas for those\nprobabilities to evaluate how\nefficient this will be against various types of spam. We hope\nresearchers on this list will be\ninterested in looking into it and will come up with a good model to\nevaluate that scheme.\n\nTo increase the accuracy of attributing `onion_message_drop`, more\ndata could be stored in the\nfuture if it becomes necessary. We need more research to quantify how\nmuch accuracy would be\ngained by storing more data and making the protocol more complex.\n\nCheers,\nBastien\n\n[1] https://gist.github.com/t-bast/e37ee9249d9825e51d260335c94f0fcf\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220629/513b6829/attachment.html\u003e"}