Skip to main content

Last Call Review of draft-ietf-pals-ple-09
review-ietf-pals-ple-09-secdir-lc-huitema-2024-10-19-00

Request Review of draft-ietf-pals-ple
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2024-10-23
Requested 2024-10-09
Authors Steven Gringeri , Jeremy Whittaker , Nicolai Leymann , Christian Schmutzer , Chris Brown
I-D last updated 2024-10-19
Completed reviews Rtgdir Last Call review of -06 by Tal Mizrahi (diff)
Genart Last Call review of -08 by Joel M. Halpern (diff)
Secdir Last Call review of -08 by Christian Huitema (diff)
Opsdir Last Call review of -10 by Tony Li (diff)
Tsvart Last Call review of -09 by Tommy Pauly (diff)
Secdir Last Call review of -09 by Christian Huitema (diff)
Secdir Telechat review of -12 by Christian Huitema (diff)
Assignment Reviewer Christian Huitema
State Completed
Request Last Call review on draft-ietf-pals-ple by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/I_ODExqB_plD68kXELP4HnBQ23w
Reviewed revision 09 (document currently at 13)
Result Has nits
Completed 2024-10-19
review-ietf-pals-ple-09-secdir-lc-huitema-2024-10-19-00
Draft 09 addresses many of the issues noted in my review of draft 08, but I am
a bit puzzled by some additions in the security section, such as:

                           Misconnection detection using the SSRC of the RTP
                           header can increase the resilience to
                           misconfiguration and some types of denial-of-
                           service (DoS) attacks.

Yes, that's probably true, but the description of how this will work in section
5.2.2 is pretty minimal. In the threat model, we may distinguish on path
attackers, who can examine the traffic, and off path attackers, who may only
try to inject spoofed packets. The offpath attackers will have to guess the
value of the 32 bit SSRC, and will be reduced to guessing. The success of
failure of this guessing depends a lot on how the SSRC is set. If the sender
uses randomly allocated values, the guessing is hard. But if the sender uses a
fixed value (e.g., 0), or sequentially allocated values (e.g., 0, 1, 2, ..),
then the guessing is not so hard. I would feel better if 5.2.2 explained a bit
how the SSRC is generated, and what to do if a received value does not match
the previous ones.

Another good addition to the security consideration is the paragraph stating
that "One of the requirements for protecting the data plane is that the PLE
packets be accepted only from valid interfaces." My only doubt is that
"interface" is a bit ambiguous in the case of IPv6 routing -- physical
interface or source IP address? Are you assuming that all routers in the AS are
implementing BCP 38?