[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [209.85.214.172]) 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 10.231.149.202 with SMTP id u10mr4500243ibv.56.1277678168227; Sun, 27 Jun 2010 15:36:08 -0700 (PDT)
Received: by 10.231.79.149 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.
- [secdir] Secdir review of draft-ietf-nsis-applica… Radia Perlman