Add DLT_/LINKTYPE_ values for DECT_NR_TAP

[ekhadiev]

Add DLT_/LINKTYPE_ values for DECT_NR_TAP

Description
I submitted a request to tcpdump-workers@lists.tcpdump.org two weeks ago to add a new link-layer type (DLT_DECT_NR_TAP) for DECT-2020 New Radio (NR) TAP header, but haven't received a response yet.

This PR adds the necessary support DLT_DECT_NR_TAP and LINKTYPE_DECT_NR_TAP with a value of 304, as requested.

[guyharris]

I submitted a request to tcpdump-workers@lists.tcpdump.org two weeks ago to add a new link-layer type (DLT_DECT_NR_TAP) for DECT-2020 New Radio (NR) TAP header, but haven't received a response yet.

The registry is in the process of being moved to an IANA registry - https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/ - so the process of getting a new LINKTYPE_ value is in a state of flux.

@mcr - would it make sense to use the tcpdump.org pages as a temporary holding tank, and have the requester go through the official IANA process once the registry is established, and with the Designated Experts either copying from the tcpdump.org pages if there are no further discussion points or continue the discussion if there are? Or should the process be suspended until the RFC comes out and the registry is officially in operation?

[mcr]

-------- Guy Harris ***@***.***> wrote: > I submitted a request to > ***@***.******@***.***) > two weeks ago to add a new link-layer type (DLT_DECT_NR_TAP) for > DECT-2020 New Radio (NR) TAP header, but haven't received a response > yet. The registry is in the process of being moved to an IANA registry - https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/ - so the process of getting a new LINKTYPE_ value is in a state of flux. Yes. @mcr - would it make sense to use the tcpdump.org pages as a temporary holding tank, and have the requester go through the official IANA process once the registry is established, and with the Designated Experts either copying from the tcpdump.org pages if there are no further discussion points or continue the discussion if there are? Or should the process be suspended until the RFC comes out and the registry is officially in operation? My preference is to merge these pull requests, but mark them with a tag like "post-approval-pre-iana", and then we'll get IANA updated at the end of the AUTH48 step. The might result in us ghostwriting the IANA request on behalf of requestors like Edem. That way, he'll be the listed controller.

…

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] ***@***.*** http://www.sandelman.ca/ | ruby on rails [ ] My working hours and your working hours may be different. [ ] Please do not feel obligated to reply outside your normal working hours [

[infrastation]

If you intend to document the encoding rather than just allocate a code point, note that the current revision of the document does not specify the byte order for multi-byte fields.

[guyharris]

If you intend to document the encoding rather than just allocate a code point, note that the current revision of the document does not specify the byte order for multi-byte fields.

It says "All fields are little-endian". in both sections 1 and 2.

[guyharris]

How should the "Simulator‑specific string index" be interpreted? Just as an opaque number? From "simulator-specific", it sounds as if it won't be present in hardware captures of signals, and its meaning as a number depends on which simulator generated the traffic, so it'd be up to the provider of the simulator to provide a map of indices to strings in its documentation.

[guyharris]

The description of LINKTYPE_DECT_NR says:

Packets are DECT-2020 New Radio (NR) MAC layer frames, as per DECT-2020 New Radio (NR); Part 4: MAC layer; Release 2 (ETSI TS 103 636-4). The Physical Header Field is always encoded using 80 bits (10 octets). Broadcast transmissions using 40 bits (5 octets) is padded with 40 zero bits (5 octets). When padding is used the Receiver Identity value 0x0000 (reserved address) is used to detect broadcast transmissions

Is that also the description of the "After the TLVs" field? That page refers to ETSI TS 103 636-4 "DECT-2020 New Radio (NR); Part 4: MAC layer; Release 1" (it doesn't link to it, as there doesn't seem to be a page that always goes to the latest version or to a list of all versions). That describes Protocol Data Units, starting on page 38, as having the Physical Header Field followed by the MAC PDU.

[infrastation]

I see "little-endian" now.

[ekhadiev]

The description of LINKTYPE_DECT_NR says:

Packets are DECT-2020 New Radio (NR) MAC layer frames, as per DECT-2020 New Radio (NR); Part 4: MAC layer; Release 2 (ETSI TS 103 636-4). The Physical Header Field is always encoded using 80 bits (10 octets). Broadcast transmissions using 40 bits (5 octets) is padded with 40 zero bits (5 octets). When padding is used the Receiver Identity value 0x0000 (reserved address) is used to detect broadcast transmissions

Is that also the description of the "After the TLVs" field? That page refers to ETSI TS 103 636-4 "DECT-2020 New Radio (NR); Part 4: MAC layer; Release 1" (it doesn't link to it, as there doesn't seem to be a page that always goes to the latest version or to a list of all versions). That describes Protocol Data Units, starting on page 38, as having the Physical Header Field followed by the MAC PDU.

Yes, that's correct, "After the TLVs" means exactly that. Should I link to the LINKTYPE_DECT_NR page instead of the ETSI TS standards page?

[ekhadiev]

How should the "Simulator‑specific string index" be interpreted? Just as an opaque number? From "simulator-specific", it sounds as if it won't be present in hardware captures of signals, and its meaning as a number depends on which simulator generated the traffic, so it'd be up to the provider of the simulator to provide a map of indices to strings in its documentation.

"Simulator‑specific string index" is an opaque index that maps a packet to a simulator trace-string and document the mapping outside of the capture format (the simulator vendor provides the index→string table).

[infrastation]

A few things still look off in the current revision of the encoding specification:

1. Individual data items after the header are fixed-size structures where the Value field always comprises 4 octets. These structures are in fact not TLVs and to skip such pseudo-TLV, one does not need to know the value of Length. To interpret the Value field of a pseudo-TLV, the value of Length is irrelevant as well: how many of the 4 bytes of the Value field carry signal and in which format is a matter of the value of Type. This way, if the value of Length is correct for the value of Type, it is equal to the length specific to the value of Type, and if the two lengths are not equal, this is a violation of the encoding. This way, in the pseudo-TLV structure the Length field does not convey any useful information, but does increase the attack surface because it supplies an alternative value of the pseudo-TLV length in the [0, 65535] range, which has potential for leading parsers into out-of-bounds memory access. A trivial way to avoid this problem space by design is to lose the Length field altogether and to make it clear the data structures are not TLVs.
2. Since pseudo-TLVs are always 8 bytes long, in the initial custom header the "TLVs length" field must be a multiple of 8, therefore only 12.5% of all possible values are not immediately invalid, which demands respective validation in every parser. A trivial way to avoid this problem space by design is to give the number of pseudo-TLVs instead (e.g. 4 instead of 32).
3. In the initial custom header the Length field is "Total length of header + TLVs + modem data", which creates two opportunities for things to go wrong if a parser fails to validate the input: first, if the value of Length is less than the header length (8), second, if it is at least 8, but is less than 8 plus "TLVs length". A trivial way to avoid this problem space by design is to encode the "modem data" length only, which then would be guaranteed to be non-negative.

It would be a good idea to consider that before setting version 1 in stone.

[ekhadiev]

@infrastation
Thanks for the review -- good points.

Spec updated: replaced TLVs-length with entries count, replaced total length with modem data length, clarified fixed 8‑byte pseudo‑TLVs (per-item Length removed).