Can't identify erring node when failure_message is unparseable

[pm47]

It seems that when receiving a failure for a payment, the origin payer can currently identify the erring node only when it successfully parses the message.

This is not great, because if any node in the route just answers with garbage instead of a valid failure+hmac, other nodes higher in the route will happily add their encryption layer, and the origin payer won't be able to find the culprit; in case it wants to retry, the origin payer will either have to try all combinations, or exclude all nodes in the previous route, which may significantly reduce its chances of finding an alternate path.

From an attacker point of view, this creates a costless attack vector on the routing layer. I'm not sure how effective it could be.

[Roasbeef]

This will always be the case unless each node in the backwards route is able to check the MAC. If we made a quadratic amount of HORNET circuits in the future for a route, then this would be possible, but it blows up the size of packets to a significant degree (and also makes establishing the initial payment circuit slower, tho that can be pipelined to a degree).

Aside from that let's say there's a way for node n-1 to detect that node n just used garbage as the error message. What recourse does node n-1 currently have? Currently it can't do anything but continue to pass backwards and encrypt the error.

[pm47]

This will always be the case unless each node in the backwards route is able to check the MAC.

Why would each node have to check the MAC? If they just add their own MAC on top of w/e data they received, then that's enough for the origin payer to find out who is putting bad data, I think. Yes it does take more space.

Aside from that let's say there's a way for node n-1 to detect that node n just used garbage as the error message. What recourse does node n-1 currently have?

I don't think we need or want the n-1 node to know or do anything though. What matters is that the origin payer does?

[t-bast]

See #1044 for a potential solution.