Skip to main content

IETF Last Call Review of draft-ietf-opsawg-pcaplinktype-13
review-ietf-opsawg-pcaplinktype-13-secdir-lc-reddyk-2025-10-23-00

Request Review of draft-ietf-opsawg-pcaplinktype
Requested revision No specific revision (document currently at 18)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-10-06
Requested 2025-09-22
Authors Guy Harris , Michael Richardson
I-D last updated 2026-04-15 (Latest revision 2026-04-06)
Completed reviews Genart IETF Last Call review of -04 by Joel M. Halpern (diff)
Intdir IETF Last Call review of -05 by Carlos J. Bernardos (diff)
Artart IETF Last Call review of -10 by Julian Reschke (diff)
Tsvart IETF Last Call review of -10 by Michael Scharf (diff)
Opsdir IETF Last Call review of -10 by Luis M. Contreras (diff)
Secdir IETF Last Call review of -13 by Tirumaleswar Reddy.K (diff)
Assignment Reviewer Tirumaleswar Reddy.K
State Completed
Request IETF Last Call review on draft-ietf-opsawg-pcaplinktype by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/aYnx4PKhBO6J73S8EXdEfMc7_t4/
Reviewed revision 13 (document currently at 18)
Result Has nits
Completed 2025-10-19
review-ietf-opsawg-pcaplinktype-13-secdir-lc-reddyk-2025-10-23-00
Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving security requirements
and considerations in IETF drafts.  Comments not addressed in the last call
may be included in AD reviews during the IESG review.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

Reviewer: Tirumaleswar Reddy
Review result:  Ready with Nits

Summary:  It describes a set of LinkType values used in PCAP capture file
formats and to create an IANA registry for those values.

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.

2. Implementations will have to handle unknown/not-registered LinkType
values.

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.

Best Regards,
-Tiru