Skip SSI-Type byte when parsing Type-4 Basic ID UAS IDs - #3
Open
erkki wants to merge 1 commit into
Open
Conversation
RFC 9374 section 4: for UAS ID type 4 (Specific Session ID) the 20-byte UAS ID field is [SSI Type (1)] [DET (16)] [padding (3)], SSI Type 1 = IETF DET. parseBasicId copied field bytes 0..15 as the DET, so every SSI-prefixed DET was stored shifted by one byte and isDET(), manifest DET comparison, and DNS lookup all operated on a corrupted value. Detect SSI Type 0x01 and extract the DET at offset 1; a field not starting with 0x01 is still read as a raw 16-byte DET (legacy transmitters). Other ID types keep the full 20-byte field. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
methodmissing
left a comment
methodmissing
left a comment
There was a problem hiding this comment.
👀 LGTM - just had a comment on the legacy / backwards compat path
| if (basicId.idType == Identification.IdTypeEnum.Specific_Session_ID.ordinal()) { | ||
| // RFC 9374 section 4: the 20-byte UAS ID field is | ||
| // [SSI Type (1)] [DET (16)] [padding (3)]. SSI Type 1 = IETF DET. | ||
| // Raw 16-byte DETs (no SSI Type byte) are accepted for legacy transmitters. |
There was a problem hiding this comment.
Backwards compatibility, but still not correct though - I'm 🆗 with the temporal fallback, but there's also nothing as permanent as the temporary.
Author
There was a problem hiding this comment.
yep agreed maybe this should be tighter, depends on if any legacy transmitters exist or assumptions made originally
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Per RFC 9374 §4, the 20-byte UAS ID field of a Type-4 (Specific Session ID) Basic ID
is
[SSI Type (1)][DET (16)][padding (3)], SSI Type 1 = IETF DET.parseBasicIdcopied field bytes 0..15 as the DET, so every SSI-prefixed DET was stored shifted by
one byte;
isDET(), the manifest DET comparison, and the DNS lookup then operated ona corrupted value and DRIP authentication could never bind to the aircraft.
Change: detect SSI Type
0x01and extract the DET at offset 1; a field not startingwith
0x01is still read as a raw 16-byte DET (legacy transmitters). Other ID typeskeep the full 20-byte field.
parseBasicIdwidened to package-private for the test.Tests: synthetic DET round-trips for SSI-prefixed, raw, and serial-number fields.
Device-verified: DNS reverse name and
isDEToperate on the exact 16-byte DET.against drip-hardening but could be rebased against main too