Skip to main content

Last Call Review of draft-ietf-mboned-64-multicast-address-format-
review-ietf-mboned-64-multicast-address-format-secdir-lc-lepinski-2012-06-19-00

Request Review of draft-ietf-mboned-64-multicast-address-format
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-05-02
Requested 2012-04-22
Authors Mohamed Boucadair , Jacni Qin , Yiu Lee , Stig Venaas , Xing Li , Mingwei Xu
I-D last updated 2012-06-19
Completed reviews Secdir Last Call review of -?? by Matt Lepinski
Assignment Reviewer Matt Lepinski
State Completed
Request Last Call review on draft-ietf-mboned-64-multicast-address-format by Security Area Directorate Assigned
Result Ready
Completed 2012-06-19
review-ietf-mboned-64-multicast-address-format-secdir-lc-lepinski-2012-06-19-00
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 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.

This document specifies an embedding (for use by IPv4 to IPv6 translation
devices) as an IPv4 multicast address within an IPv6 address. (This is a
companion document to RFC 6052, which specifies an embedding for IPv4 unicast
addresses.)

The Security Considerations section claims that the relevant security
considerations are identical to those in RFC 6052. (That is, the security
considerations for translating IPv4 multicast addresses are the same as those
for translating unicast addresses.) I believe this is essentially true.

However, the first security consideration discussed in RFC 6052 is source
address spoofing. Although quite relevant for unicast address translation,
source address spoofing does not seem (to me) to be an issue for multicast
addresses translation because multicast addresses are typically not used as
source addresses for IP datagrams. In situations such as this where the authors
wish to incorporate security considerations by reference, I think it is helpful
to the reader to add a couple sentences explaining which considerations in the
referenced document (i.e., RFC 6052) are relevant to the current draft.

Minor editorial note:
It would be helpful if you define the acronyms ASM and SSM in the terminology
section. (As someone who doesn't frequently think about multicast, it wasn't
immediately obvious to what these two acronyms referred.)