Skip to main content

Last Call Review of draft-ietf-v6ops-cpe-slaac-renum-04
review-ietf-v6ops-cpe-slaac-renum-04-secdir-lc-wood-2020-09-09-00

Request Review of draft-ietf-v6ops-cpe-slaac-renum
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-09-09
Requested 2020-08-26
Authors Fernando Gont , Jan Zorz , Richard Patterson , Bernie Volz
Draft last updated 2020-09-09
Completed reviews Secdir Last Call review of -04 by Christopher A. Wood (diff)
Genart Last Call review of -04 by Pete Resnick (diff)
Iotdir Telechat review of -05 by Suresh Krishnan (diff)
Intdir Telechat review of -05 by Sheng Jiang (diff)
Assignment Reviewer Christopher A. Wood
State Completed
Review review-ietf-v6ops-cpe-slaac-renum-04-secdir-lc-wood-2020-09-09
Posted at https://mailarchive.ietf.org/arch/msg/secdir/JjJjEJim2DU7auNV1j90VGNUyZU
Reviewed revision 04 (document currently at 08)
Result Has Nits
Completed 2020-09-09
review-ietf-v6ops-cpe-slaac-renum-04-secdir-lc-wood-2020-09-09-00
Summary: Has Nits

Comments:

- Section 3: is it possible for an attacker to send DHCPv6 Prefix Delegations
with lifetime=0 to CE routers that support LAN-side DHCPv6 and amplify
Reconfigure messages to supporting clients? (I don't know if this is a concern
or part of the threat model, but this did seem to be a case of possible
request/response asymmetry.) - Section 4: rationale for these default values,
if available, might be worth including. (Why not make them shorter? What are
the tradeoffs?) - Section 6: it might be worth noting what happens if stable
storage is unavailable or otherwise compromised when trying to store prefix
information. What happens if the "A" or "L" bits are modified? (I suspect
nothing dangerous, but it's not clear to me whether or not integrity is
important.)

Nits:

- In some places "\"Valid Lifetime\"" is written as "valid-lifetime" -- should
these be made consistent?