tirumal reddy <[email protected]> wrote: > Nits and comment below:
> 1. While the text already covers buffer overreads due to truncated
> captures, I suggest broadening that to mention unbounded copies, where
> unverified length fields or captured lengths are used directly in memory
> allocations. Implementations will have to bound allocation sizes based on
> the actual buffer length and defined protocol limits.
I don't think that this belongs in *pcaplinktypes*
> 2. Implementations will have to handle unknown/not-registered LinkType
> values.
Maybe. They can exit/error.
> 3. LinkType metadata can reveal deployment details. For example, the
> presence of LINKTYPE_IEEE802_11 indicates wireless capture, while
> vendor-specific LinkTypes (e.g., LINKTYPE_JUNIPER_ATM1) disclose equipment
> type. When capture files are shared outside the organization, network
> administrators will have to review and, if necessary, anonymize LinkType
> values and related metadata to avoid leaking information about network
> topology and network vendor details.
I don't think that this advice belongs in pcaplinktypes.
It's not correct. You can anonymize *linktype* values with the "rm" command!
If the contents of a network are sensitive (they almost always are), then
don't share it. If you remove the type, then you can't decode anything, so
the file has no further use.
If you'd like to write Security Considerations about contents of packets, it
probably belongs in the pcapng document.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
