Skip to main content

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 revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-03-01
Requested 2016-02-04
Authors Reinaldo Penno , Simon Perreault , Mohamed Boucadair , Senthil Sivakumar , Kengo Naito
I-D 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
Request Last Call review on draft-ietf-tsvwg-behave-requirements-update by Security Area Directorate Assigned
Reviewed revision 06 (document currently at 08)
Result Has issues
Completed 2016-02-17
review-ietf-tsvwg-behave-requirements-update-06-secdir-lc-laurie-2016-02-17-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.

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