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

[Tom Taylor <[e-mail]>]

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
>
>