Dropping signed packets on transports that don't guarantee packet order

Ground Control Software MAVLink
1

There is a discussion here about the fact that signed packets with “old” timestamps must be dropped, but over UDP you can’t guarantee packet order: https://groups.google.com/forum/#!msg/mavlink/ILdSjQrUIaI/NQaHdpjFAAAJ

They propose that allowing 10 seconds (say) of “out of date” packets would remove the issue of packet ordering being mucked up, without presumably greatly increasing chance of replay attacks.

Thoughts?

2

Speed vs security is basically the issue.
For wired or highly secure transport, buffering and reordering would be fine.
For general Over The Air links (wifi or SiK radios), it’s safer to maintain the reference behaviour of discarding out-of-sequence messages. Messages that require guaranteed delivery should have an ack and timeout/resend mechanism anyhow, but I think it’s definitely worth considering supporting both discarding and reordering, depending on the application.

3

Thanks. Makes sense to me except:

it’s definitely worth considering supporting both discarding and reordering, depending on the application.

If at the library level we discard on receiving, so reordering after-the-fact is impossible. So not quite sure what you are proposing there.

Key point helpful though - we discard for security and any message that must be received should be implementing resending at the higher level microservice layer.

4

If at the library level we discard on receiving, so reordering after-the-fact is impossible. So not quite sure what you are proposing there.

I meant that it might be worth considering an opt-in change to the spec and library, if there are applications where this functionality is important. Personally I think the autopilot should always discard, but a router or gcs might want to pass, log, discard or re-order. I’m not convinced it’s worth it though.

Regards,

James

5

Thanks for clarification.
Just as a “FYI” the C library does allow a router or whatever to accept all packets, and I hope to add support for it to forward messages it doesn’t understand (which would also forward these packets), so there are ways this sort of thing could be done by an “end user”. As you say though, not convinced either.