Last Call Review of draft-ietf-mipshop-pfmipv6-
review-ietf-mipshop-pfmipv6-secdir-lc-weis-2009-10-03-00

Request Review of draft-ietf-mipshop-pfmipv6
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-10-06
Requested 2009-09-10
Authors Hidetoshi Yokota, Kuntal Chowdhury, Rajeev Koodli, Basavaraj Patil, Frank Xia
Draft last updated 2009-10-03
Completed reviews Secdir Last Call review of -?? by Brian Weis
Assignment Reviewer Brian Weis
State Completed
Review review-ietf-mipshop-pfmipv6-secdir-lc-weis-2009-10-03
Review completed: 2009-10-03

Review
review-ietf-mipshop-pfmipv6-secdir-lc-weis-2009-10-03

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 adds Proxy-based Fast Handover to Mobile IPv6 (MIPv6).  


It allows fast handover of a mobile device between mobile access  


gateway's without the mobile node itself being involved.






The document primarily reuses messages flows from a previously defined  


handover method (RFC 5568), and Proxy Mobile IPv6 (RFC 5213). It also  


depends on the Security Considerations from RFC 5213 and RFC 5568,  


which seems appropriate given that the same message flows are used  


between the same network entities. These existing RFCs describe IPsec  


ESP as the method for protecting messages, and include details in  


setting up the SPD and PAD. I believe pointing to those documents for  


security consideration guidance is generally acceptable.






There is one new message flow, which is the forwarding of data packet  


from the previous mobile access gateway (PMAG) to the next mobile  


access gateway (NMAG) during transition. The last paragraph in the  


security considerations section notes that these packets MAY be  


encrypted with IPsec "if protection of data traffic is required". A  


better statement might be that they SHOULD be encrypted if the link  


between the PMAG and NMAG exposes the MN packets to more threats than  


if they had followed their normal routed path.






(One miscellaneous comment: It would be helpful to readers if you  


added a definition of "Local Mobility Anchor" to the Terminology  


section.)




Brian

--
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew at cisco.com