Last Call Review of draft-ietf-softwire-map-10
review-ietf-softwire-map-10-secdir-lc-weis-2014-10-16-00

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.

Brian