[secdir] Security Review of draft-ietf-v6ops-siit-eam-01

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 25 September 2015 00:24 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F141B42CC for <secdir@ietfa.amsl.com>; Thu, 24 Sep 2015 17:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq86hLUzyi_Q for <secdir@ietfa.amsl.com>; Thu, 24 Sep 2015 17:24:50 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB63E1B33DE for <secdir@ietf.org>; Thu, 24 Sep 2015 17:24:49 -0700 (PDT)
Received: by lacdq2 with SMTP id dq2so26470868lac.1 for <secdir@ietf.org>; Thu, 24 Sep 2015 17:24:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=O+BxD70blJm/tW95h/TMSaAwktxSoeqL5vtVnsIssIE=; b=rIGTOyCJFUbpK51wferIkd6AOnYjFY9q0cHbhEGvEA6KsPljHthtfz/bRF4Iin1Ivn hxEY3qrv8LwdfyWAbpaxNK9iImNxl2fVOo0DdtsG1PmXE32WfMoBi1KINzLoRqmd9wsm XIwSdeoYF3oLTSAX/U0QnSd2VJAfjcsEyKZk/WfHTxhjHzqME6o+wL0VX+KoGXKgdOPX FUDiPiLnTQZFcWr/9xk9RqY+qAQpV5xNoh0tT0BM5eJbmF4QMsf2RNeyCw5xwdL9KQZr /RUVeIyF50+d0Zn7fl+KtHvZZTL0gtgGcsHWRbs60IZYgL1uivdWv252VJifmd6+Ogho N9/A==
MIME-Version: 1.0
X-Received: by 10.112.168.194 with SMTP id zy2mr730808lbb.79.1443140687943; Thu, 24 Sep 2015 17:24:47 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.2.163 with HTTP; Thu, 24 Sep 2015 17:24:47 -0700 (PDT)
Date: Thu, 24 Sep 2015 20:24:47 -0400
X-Google-Sender-Auth: pHGcZN2WFLRoLjmrTc30DMDTr_M
Message-ID: <CAMm+LwgR_rJ0F-e9Xk7x6brAmLXPNdmspcYsDtNGvzAjdo7d2w@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "secdir@ietf.org" <secdir@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c333f210e0a205208760a0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/vN1xU8lbJ3tItJMfuqJNV-v3Duo>
Subject: [secdir] Security Review of draft-ietf-v6ops-siit-eam-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Fri, 25 Sep 2015 00:24:52 -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.

The draft is essentially describing an extension to the IPv4/6 mapping
mechanism to allow a mixture of mappings determined by fixed function and
mappings determined by an address table.

7 <https://tools.ietf.org/html/draft-ietf-v6ops-siit-eam-01#section-7>.
Security Considerations

   The EAM algorithm does not introduce any new security issues beyond
   those that are already discussed in Section 7 of [RFC6145]
<https://tools.ietf.org/html/rfc6145#section-7>.


Which points to.


7 <https://tools.ietf.org/html/rfc6145#section-7>.  Security Considerations

   The use of stateless IP/ICMP translators does not introduce any new
   security issues beyond the security issues that are already present
   in the IPv4 and IPv6 protocols and in the routing protocols that are
   used to make the packets reach the translator.



Both statements are incorrect.


If we were to write out a modern Internet architecture we would no
doubt decide that addresses have no significance above the transport
layer and should not be visible to applications. But that isn't the
Internet architecture we have today.


Further most Internet services  make use of IP addresses for various
types of abuse mitigation. This is something that these mapping
functions will have a significant impact on.


Adding an address table capability provides even more potential to
play various types of application layer routing games.



This needs a comprehensive analysis.