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

Tom Taylor <> Tue, 28 October 2014 18:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F1A31AC406; Tue, 28 Oct 2014 11:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xtjKctc9g-Qr; Tue, 28 Oct 2014 11:53:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 691231AC40A; Tue, 28 Oct 2014 11:53:38 -0700 (PDT)
Received: by with SMTP id x19so1360238ier.2 for <multiple recipients>; Tue, 28 Oct 2014 11:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EG5BpZarLHTX61yD2AWUYyq9ouY4pZGnIaSi8zG6YI4=; b=deP3YKtscWyOoizejrrMFScchjFdVLWQGKBv0n5I+0+a/nBmKuDuxSsZM6lZRzexsX g2Ja28oNg+isYvhtSN9Sp3x0GswiFG7R0n+6q+aGf8rfDme3R6fEWYg5I7btGFRqTNsi volCpR+sM+b42YXese8LD7JhKMC77k0VhvRwhF+n+28amYIjf+tTBKxCvRoujdRl/l6n kM5VUDhLYeeypkWAhX/a5sewCQuSX6hfOZhpd7BGP60FqCbJ9j88zIkGLbdfW3XOfREG 9bUGapx1DbfsmPKR0S1qPO0zou9zQf0kUUlXtV2OJxDrNTYDwX5uDCKqGQ0z8ONlxc42 Jphg==
X-Received: by with SMTP id 1mr6070985iol.18.1414522417776; Tue, 28 Oct 2014 11:53:37 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id v8sm996290ioe.16.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 11:53:37 -0700 (PDT)
Message-ID: <>
Date: Tue, 28 Oct 2014 14:53:38 -0400
From: Tom Taylor <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian Weis <>,, The IESG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] Secdir review of draft-ietf-softwire-map-11
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Oct 2014 18:53:42 -0000

On 14/10/2014 9:51 PM, Brian Weis wrote:
> 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.

[PTT] We'll do that.
> 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.

[PTT] The proof of correctness of the algorithm as presented in Appendix 
B is very simple. The PSID as a set of bits is embedded in port value, 
for all port values derived from it. Every PSID is in the same position 
(offset = a in Figure 9). Hence each different PSID must provide a 
different set of port values. We can add this statement in Appendix B if 
that's OK.

[PTT] Technically it remains to prove that the presentation in section 
5.1 reproduces the algorithm in Appendix B, but I think that is fairly 
clear from Figure 2 despite the extraneous material introduced in the 
subsequent text.

[PTT] The PSID is either provisioned or it is the set of bits left over 
from the concatenation of the Basic Mapping Rule IPv4 prefix with the EA 
bits after the high-order 32 bits have been removed. That's a fairly 
simple operation, not sure what we can tell implementers, and I don't 
think it affects the proof of disjoint port sets. I think the 
operational challenge is more interesting -- making sure each subscriber 
gets a different PSID.
> 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.
> Brian