[secdir] Secdir review of draft-ietf-nsis-applicability-mobility-signaling-18

Radia Perlman <radiaperlman@gmail.com> Sun, 27 June 2010 22:36 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 413563A6A07; Sun, 27 Jun 2010 15:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.853
X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_50=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id mqMVvZPsQI+P; Sun, 27 Jun 2010 15:35:58 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com []) by core3.amsl.com (Postfix) with ESMTP id 8945A3A6A06; Sun, 27 Jun 2010 15:35:58 -0700 (PDT)
Received: by iwn35 with SMTP id 35so211228iwn.31 for <multiple recipients>; Sun, 27 Jun 2010 15:36:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=Lz3lCZuDcVvnXsJ5UsOlHmO+J4Ond+WCDd4GQveAm38=; b=O06jSEGo1djb6icPzilMyYnrjOEALyzwmGxfdeCnXNCaR2HzZEfMo2bPSGBr82SK29 xJRF2eDcvL2SuYvppm7OOtGCtGFpcVJ1wJcd1m6zqKEQusoBhJden6LrS4YKcjsXmfwm gLGwvliJBpLVv9igYcunp2fiZS1apRtoJ5iBg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=JYEnlXln46boBC4oo8S6tKp/p7OaIBmpQxgXkYF5jZVYgD57dXYSsMF0Te+hrJ6LHA KqvypGr6tnouIcOF6PIX43kUnt9ymbP4seqFjFEm52u/4kK0bvRHwCKjp1HcAjYtJ77/ etYGzYGdWkHwB2elCDbCnWRy8DUrDGoDN3p+M=
MIME-Version: 1.0
Received: by with SMTP id u10mr4500243ibv.56.1277678168227; Sun, 27 Jun 2010 15:36:08 -0700 (PDT)
Received: by with HTTP; Sun, 27 Jun 2010 15:36:08 -0700 (PDT)
Date: Sun, 27 Jun 2010 15:36:08 -0700
Message-ID: <AANLkTik9ktQZRRIQPv3-Qd3CtBLIb_nt4-hDwlAcvRj0@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-nsis-applicability-mobility-signaling@tools.ietf.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: [secdir] Secdir review of draft-ietf-nsis-applicability-mobility-signaling-18
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Jun 2010 22:36:00 -0000

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.