htlcswitch+lnwire: invalid onion payload #3470
Conversation
cfromknecht
force-pushed
the
invalid-onion-payload
branch
from
70af0ff to
700180a
Compare
cfromknecht
changed the title
cfromknecht
force-pushed
the
invalid-onion-payload
branch
from
700180a to
5c72497
Compare
|
Do you want to make the change to |
cfromknecht
force-pushed
the
invalid-onion-payload
branch
from
5c72497 to
017eb23
Compare
Done |
cfromknecht
force-pushed
the
invalid-onion-payload
branch
from
017eb23 to
9516e4a
Compare
joostjager
left a comment
joostjager
left a comment
There was a problem hiding this comment.
Figuring out how to map to the failure message isn't very simple. I see a cost now and in the future for keeping that working as good as possible. Why don't we just return no info in the failure message and only add it when this type of debugging becomes essential to have. So many things can't go wrong that you can't find out during dev.
cfromknecht
force-pushed
the
invalid-onion-payload
branch
from
ace3037 to
ebae32f
Compare
htlcswitch/hop/payload.go
Outdated
There was a problem hiding this comment.
Required and Omitted sound like the same thing. Is the real difference that one happens during tlv decode and the other one on the higher level? If that is indeed the case, maybe the names should reflect that. Or just have one of the two.
There was a problem hiding this comment.
no they are different, required means that the sender required us to understand a record, but we don't. omitted means that the receiver expected a field that the sender didn't include.
htlcswitch/hop/payload.go
Outdated
There was a problem hiding this comment.
Isn't this a bit too much? Always returning RequiredViolation here doesn't seem to be bad. Especially because it also requires changes to the tlv parser.
There was a problem hiding this comment.
it is in some sense overkill, but i think an accurate log message will help debug if things go wrong. perhaps another solution is to not log the final/intermediate info when encountering a required violation? however, many of the new records being added are specific to the hop type, which would make that information more useful.
guggero
left a comment
guggero
left a comment
There was a problem hiding this comment.
I did a high-level pass of the PR, mainly focusing on code quality aspects. Only found a few minor nits.
Nice to see that there are multiple test cases around the changes and the coverage actually increase slightly.
The changes look solid to me though I cannot speak to the possible implications this has in routing.
cfromknecht
force-pushed
the
invalid-onion-payload
branch
from
ebae32f to
2d34bae
Compare
|
thanks for the review @guggero! |
cfromknecht
force-pushed
the
invalid-onion-payload
branch
from
2d34bae to
eabcda4
Compare
Previously we would not mark a success for the first hop if the fail source index was 2. We also add a test to assert this behavior.
This commit adds a hop.PayloadViolation enum which encompasses the cases where the sender omits, includes, or requires a type that causes an ErrInvalidPayload faiulre. The existing Omitted bool is converted to this PayloadViolation, and NewPayloadFromReader is updated to return such a failure with a RequiredViolation when an unknown required type is detected. The unit tests are updated to cover the three possible cases of RequiredViolations, as well as included valid intermediate and final hop tests.
This commit modifies the link return an InvalidOnionPayload failure when it cannot parse a TLV payload. The offset is left at zero, since its unclear how useful it will be in practice and would require some significant reworkings of the abstractions in the tlv package. TODO: add unit tests. currently none of the test unit infrastructure is setup to handle TLV payloads, so this would require implementing a separate mock iterator for TLV payloads that also supports injecting invalid payloads. Deferring this non-trival effor till a later date
An InvalidOnionPayload implies that the onion was successfully received by the reporting node, but that they were unable to extract the contents. Since we assume our own behavior is correct, this mostly likely poins to an error in the reporter's implementation or that we sent an unknown required type. Therefore we only penalize that single hop, and consider the failure terminal if the receiver reported it.
This commit modifies the NewPayloadFromReader to apply known presence/omission contraints in the event that the tlv parser returns an unknown required type failure. Now that the parser has been modified to finished parsing the stream to obtain a proper parsed type set, we can accurately apply these higher level validation checks. This overrides required type failures, such that they are only returned if the sender properly abided by the constraints on fields for which we know. The unit tests are updated to create otherwise valid payloads that then return unknown required type failures. In one case, a test which previously returned an unknown required type failure is made to return an included failure for the sid, indicating the unknown required type 0 is being overruled.
cfromknecht
force-pushed
the
invalid-onion-payload
branch
from
eabcda4 to
cba523a
Compare
4 participants
Builds on #3465
Modifies the link to return an
InvalidOnionPayloadfailure when it is unable to process a TLV onion payload. In the process, we unify thehop.ErrInvalidPayloadfailure to include required type failures, and propagate the type back to the caller in theInvalidOnionPayload.