Document..........: draft-ietf-softwire-security-requirements-07 Reviewer..........: Christian Vogt Review date.......: 2009-04-01 (no, not a joke) IESG Telechat date: 2009-04-09 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. The document analyzes potential security issues and resulting security requirements for scenarios where softwire methods are used for IPv4/IPv6 co-existence. I think this type of analysis is important given the expected widespread existence of these scenarios. Below are a few recommended modifications that should be applied to the document prior to publication: - The document is partly about the security for data packets, and it concludes by requiring authentication, integrity, and reply protection for data packets. Why should this be a requirement given that the purpose of softwires is simply to provide interworking between IPv4 and IPv6? Certainly, there will be /some/ scenarios where one would want data packet protection, but generally such protection would be independent of the use of IPv4/IPv6 co-existence methods. Consequently, I would suggest to reduce the security requirements for data packets, perhaps from "MUST" to "MAY/SHOULD". - The document talks about hosts being mobile or nomadic in several places. This might lead a reader into falsely concluding that the described scenarios or vulnerabilities do not apply to stationary hosts. I would therefore suggest to either remove the attributes "mobile" and "nomadic", or to make clear that mobility and nomadicness is only used in the document for exemplification. - On page 9, the document refers to related security analyses, which relate to softwires as well, such as those for PANA, NSIS, and routing protocols. You could add to this list the security analysis for Mobile IP [RFC 4225], which considers similar issues. The similarity becomes obvious if you replace the softwire initiator with the mobile host and the softwire concentrator with the home agent. - On page 10, the document claims that address spoofing causes a DoS attack. I would soften this statement a bit. It is true that address spoofing can be used as a tool in a DoS attack, yet address spoofing does not consistute a DoS attack by itself. - To prevent address spoofing, the document recommends the use of authentication. This should be elaborated on. Authentication alone does not prevent the authenticated entity from spoofing its address. What is needed in addition is a binding between the legitimate address and the authenticated identity. Hope this helps. Wish everyone involved a smooth publication process!