Hi Benoit, Would it make sense to have a statement in the draft that says as much? Thanks. Mahesh Jethanandani mjethanandani@xxxxxxxxx > On Jul 19, 2025, at 10:30 AM, Benoit Claise <benoit.claise=40huawei.com@xxxxxxxxxxxxxx> wrote: > > Hi Linda, > > Thanks for your review. > You highlighted a valid security considerations issue, which is covered in the IPFIX protocol specifications. See https://datatracker.ietf.org/doc/html/rfc7011#section-11 > Since we use the IPFIX protocol to export, we don't need to repeat this in draft that only specify IPFIX Information Elements. > > Regards, Benoit (as draft author) > >> On 7/19/2025 4:21 AM, Linda Dunbar via Datatracker wrote: >> Document: draft-ietf-opsawg-ipfix-on-path-telemetry >> Title: Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) >> Reviewer: Linda Dunbar >> Review result: Has Nits >> >> I have reviewed this document as part of the SEC area directorate's ongoing >> effort to review all IETF documents being processed by the IESG. These >> comments were written primarily for the benefit of the Security area directors. >> Document editors and WG chairs should treat these comments just like any other >> last-call comments. >> >> Summary: This document is well-written and nearly ready for publication. >> >> One issue: >> The Security Considerations section does not explicitly mention the risk of >> accepting spoofed IPFIX messages from unauthenticated exporters. Since IPFIX >> collectors may receive telemetry data from multiple sources, there is a risk >> that a malicious or misconfigured node could inject false or misleading data. >> >> It would be useful to add something like: Collectors MUST ensure that telemetry >> originates from trusted sources. Accepting IPFIX messages from unauthenticated >> sources could lead to data spoofing, policy misapplication, or denial of >> service. >> >> Best Regards, >> Linda Dunbar >> >> > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
