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 rev. 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
Draft last updated 2010-06-29
Completed reviews Secdir Last Call review of -?? by Radia Perlman
Assignment Reviewer Radia Perlman
State Completed
Review review-ietf-nsis-applicability-mobility-signaling-secdir-lc-perlman-2010-06-29
Review completed: 2010-06-29

Review
review-ietf-nsis-applicability-mobility-signaling-secdir-lc-perlman-2010-06-29

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.