Last Call Review of draft-ietf-nsis-applicability-mobility-signaling-
review-ietf-nsis-applicability-mobility-signaling-secdir-lc-perlman-2010-06-29-00
Request | Review of | draft-ietf-nsis-applicability-mobility-signaling |
---|---|---|
Requested revision | No specific revision (document currently at 20) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2010-06-29 | |
Requested | 2010-06-09 | |
Authors | Hannes Tschofenig , Seong-Ho Jeong , Jukka Manner , Xiaoming Fu , Takako Sanda | |
I-D last updated | 2010-06-29 | |
Completed reviews |
Secdir Last Call review of -??
by Radia Perlman
|
|
Assignment | Reviewer | Radia Perlman |
State | Completed | |
Request | Last Call review on draft-ietf-nsis-applicability-mobility-signaling by Security Area Directorate Assigned | |
Completed | 2010-06-29 |
review-ietf-nsis-applicability-mobility-signaling-secdir-lc-perlman-2010-06-29-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 is sufficiently abstract that it’s not clear how one would explicitly state “Security Considerations”. It is targeting informational status and essentially lists example scenarios where mobility protocols and NSIS protocols might interact and what problems one might face in trying to resolve them. An example (perhaps the simplest case) might be where a mobile node has reserved bandwidth to some server for the streaming of a video and then the mobile node moves. While a simple solution would be to tear down the old connection and set up a new one, the handover potentially be faster and more efficient if there were a way to avoid updating routers that were along both the old and new paths. This requires, for example, that routers be able to identify the connection by something other than the Source and Destination IP addresses and ports (since those will change). While the integration will undoubtedly introduce security challenges, it’s not obvious whether there will be new ones or whether they are the same security challenges faced by mobility protocols and NSIS independently. Section 3.7 explicitly mentions authorization issues if the required state changes are determined by a different entity that was involved before. As the designs become more concrete (in future standards track RFCs), they will face more concrete problems, but for now I believe their “no new security issues” claim is probably right.