Last Call Review of draft-ietf-multimob-pmipv6-source-07
review-ietf-multimob-pmipv6-source-07-secdir-lc-perlman-2014-03-20-00

Request Review of draft-ietf-multimob-pmipv6-source
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-03-25
Requested 2014-02-13
Authors Thomas Schmidt, Shuai Gao, Hong-Ke Zhang, Matthias Wählisch
Draft last updated 2014-03-20
Completed reviews Genart Last Call review of -07 by David Black (diff)
Genart Telechat review of -08 by David Black (diff)
Secdir Last Call review of -07 by Radia Perlman (diff)
Assignment Reviewer Radia Perlman
State Completed
Review review-ietf-multimob-pmipv6-source-07-secdir-lc-perlman-2014-03-20
Reviewed rev. 07 (document currently at 09)
Review result Has Issues
Review completed: 2014-03-20

Review
review-ietf-multimob-pmipv6-source-07-secdir-lc-perlman-2014-03-20

On Tue, Dec 17, 2013 at 7:11 PM, Radia Perlman 

<

radiaperlman at gmail.com

>

 wrote:





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 combines mobile IPv6 with multicast.  It's unnecessarily difficult to read.  There should be a section upfront expanding all the acronyms, at the very least.  For instance, MLD, PMIPv6, PIM, MAG, HNP.  Some of these (like MAG) are expanded in the text the first time they are used, but most are not, and people aren't necessarily going to remember it because of seeing it once, and there's no downside to having a section in the introduction called "acronyms".




It also wouldn't hurt to explain "proxy mobile IPv6 domains"  (not just expand the acronym PMIPv6).

I admit I don't completely understand this document, because I didn't want to have to read all the other documents that this thing assumes you understand, but I think I get the general idea.




I think the security considerations section covers most of the downsides, but it doesn't talk about how multicast in general can amplify DOS packets.  And with mobility, there are two problems with having a proxy sending the multicast (unless it's tunneled, which would be OK).  If packets with an IP source address can come from a different location, then loops won't be detected (the security considerations section mentions that), but also, it's harder for the infrastructure to filter out packets from forged IP addresses.




Radia