Last Call Review of draft-ietf-tsvwg-behave-requirements-update-06
review-ietf-tsvwg-behave-requirements-update-06-secdir-lc-laurie-2016-02-17-00

Request Review of draft-ietf-tsvwg-behave-requirements-update
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-03-01
Requested 2016-02-04
Draft last updated 2016-02-17
Completed reviews Genart Last Call review of -06 by Dan Romascanu (diff)
Genart Telechat review of -07 by Dan Romascanu (diff)
Secdir Last Call review of -06 by Ben Laurie (diff)
Opsdir Last Call review of -06 by Mahesh Jethanandani (diff)
Assignment Reviewer Ben Laurie
State Completed
Review review-ietf-tsvwg-behave-requirements-update-06-secdir-lc-laurie-2016-02-17
Reviewed rev. 06 (document currently at 08)
Review result Has Issues
Review completed: 2016-02-17

Review
review-ietf-tsvwg-behave-requirements-update-06-secdir-lc-laurie-2016-02-17

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.

Summary: ready with issues

This document updates the behavioural requirements for NAT, and as noted in the very comprehensive (thankyou!) security considerations section,  introduces at least two requirements that might have security consequences.

The ADs should probably consider whether these new requirements are worth the additional risk.

Also, "Hosts which require a restricted filtering behavior should enable security-dedicated features (e.g., access control list (ACL)) either locally or by soliciting a dedicated security device (e.g., firewall)." is concerning - how will hosts know that they need to update their policies?

"security-dedicate features" is not very informative - it would be helpful to explain what new behaviour may need to be counteracted. Looking at sections 5 and 6, to which this text refers, they appear to make NAT more restrictive, not less, so its unclear why there might be security impact.

BTW, small typo: "only if packets are to be sen to distinct destination addresses."

sen -> sent