Be lenient with errors in incoming DPR

To avoid having the peer interpret the error as meaning the connection
shouldn't be closed, which probably does more harm than ignoring
syntactic errors in the DPR.

Note that RFC 6733 says this about incoming DPR, in 5.4 Disconnecting
Peer Connections:

  Upon receipt of the message, the Disconnect-Peer-Answer message is
  returned, which SHOULD contain an error if messages have recently been
  forwarded, and are likely in flight, which would otherwise cause a race
  condition.

The race here is presumably between answers to forwarded requests and
the outgoing DPA, but we have no handling for this: whether or not there
are pending answers is irrelevant to how DPR is answered. It's
questionable that a peer should be able to prevent disconnection in any
case: it has to be the node sending DPR that decides if it's approriate,
and the peer should take it as an indication of what's coming.

Incoming DPA is already treated leniently: the only error that's not
ignored is mismatching End-to-End and Hop-by-Hop Identifiers, since
there's no distinguishing an erroneous value from an unsolicited DPA.
This mismatch could also be ignored, which is the case for DWA for
example, but this problem is already dealt with by dpa_timeout, which
causes a connection to be closed even when the expected DPA isn't
received.

0 files changed, 0 insertions, 0 deletions