I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document..........: draft-ietf-softwire-security-requirements-07
Reviewer..........: Christian Vogt
Review date.......: 2009-04-01 (no, not a joke)
IESG Telechat date: 2009-04-02
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!
- Christian
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
