Re: [secdir] Security review of draft-ietf-tsvwg-behave-requirements-update-06

[<[e-mail]>]

Dear Ben,

Thank you for the review.

Please see inline.

Cheers,
Med

De : Ben Laurie [mailto:[e-mail]]
Envoyé : lundi 15 février 2016 13:44
À : The IESG; [e-mail]; [e-mail]
Objet : Re: Security review of draft-ietf-tsvwg-behave-requirements-update-06

Resending to correct address:

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?

[Med] The text does not discuss this point because it is implementation and deployment-specific. This can be, for example, set by an application, a user, a global system parameter, etc. We can add this NEW sentence if you think it is helpful:

NEW:
How a host updates its filtering is implementation-specific.

"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.

[Med] It is true that the update in this draft is more restrictive compared to RFC4787 but still this is EIF. Because some may argue filtering is desired, hosts that need more restricted filtering should enforce some policies either locally or by interacting with an in-path device. What about changing “security-dedicated features” to “dedicated policies”?

BTW, small typo: "only if packets are to be sen to distinct destination addresses."
sen -> sent
[Med] Thank you for catching it. Fixed in my local copy.