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