[secdir] Secdir review of draft-ietf-softwire-map-11

Brian Weis <bew@cisco.com> Wed, 15 October 2014 01:51 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id B9E5A1A0119; Tue, 14 Oct 2014 18:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eeIsHrSbSuIn; Tue, 14 Oct 2014 18:51:50 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9D61A0114; Tue, 14 Oct 2014 18:51:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2326; q=dns/txt; s=iport; t=1413337910; x=1414547510; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=MUlKc+oYXqH+JDN0QXIP8nsBUw/v4kRtLCtgAo56ZPE=; b=EPbyBTCFmeDFOtlKIWtBWzu9xXc34N4YvRIe4Xbi9Gt5mIc+GmyoUnEn CC9FSJAT79ZUMIoHx6HzpkGBrsVzA2Jy+boy5ge/DPsm5TwhBsfOOyGDZ 0hXWI48pGXDCosbfcMtOIndP0StIleztCEr2aRIgp3LmELJrEDJbJRzNn 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,720,1406592000"; d="scan'208";a="87021295"
Received: from rcdn-core-9.cisco.com ([]) by alln-iport-7.cisco.com with ESMTP; 15 Oct 2014 01:51:49 +0000
Received: from [] ([]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9F1pmrd001226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 01:51:49 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 14 Oct 2014 18:51:47 -0700
Message-Id: <8432EC17-777A-452D-82DB-CC0BD41CAAD9@cisco.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_Y0xZKl7FTa-Q6EcBxga302eTNA
Cc: draft-ietf-softwire-map.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-softwire-map-11
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: <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: Wed, 15 Oct 2014 01:51:51 -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 describes a method of mapping IPv4 unicast packets across an IPv6 network, providing both address and port mapping of the IPv4 packets within the IPv6 network. In other words, a user's packet begins as an IPv4 packet, is translated into a public IPV4 address by a NAPT44, is mapped to an IPv6 address (the "MAP domain") and delivered across the IPv6 network to a border relay. The border relay converts the packet back to an IPv4 packet with the NAPT44 source address and relays it to an IPv4 public network. The border relay uses the same mapping function to turn return packets back into IPv6 packets with the correct IPv6 destination address for delivery back to the original user.

The Security Considerations section lists several attacks. The text seems reasonable. It would be helpful if there was a reference to "Address-Dependent Filtering", which might be RFC 4787.

The main risk to the mapping method seems to be a threat of overlapping address mappings, such that return packets are delivered to the wrong user. This would be a security consideration if users received other users traffic. The algorithm seems designed to avoid this, at least Appendix B indicates this as a requirement. If this is in fact believed to guarantee non-overlapping mappings then this should be stated in this section. The only statement I can find is in Section 5.1, where it is stated that "Different PSIDs guarantee non-overlapping port-sets." But if I'm not mistaken, the PSIDs are also computed so this might not actually be a guarantee. If there was a proof of correctness ensuring that a correct implementation will ensure non-overlapping mappings then this should be mentioned as well. 

The mapping algorithm is a bit complicated, and I do worry about implementation errors that might be hard to detect. If there was any advice you could give to implementors, it would be helpful.