Last Call Review of draft-ietf-ipsecme-traffic-visibility-
review-ietf-ipsecme-traffic-visibility-secdir-lc-turner-2009-12-09-00

Request Review of draft-ietf-ipsecme-traffic-visibility
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-12-15
Requested 2009-10-16
Authors Manav Bhatia, Ken Grewal, Gabriel Montenegro
Draft last updated 2009-12-09
Completed reviews Secdir Last Call review of -?? by Sean Turner
Assignment Reviewer Sean Turner
State Completed
Review review-ietf-ipsecme-traffic-visibility-secdir-lc-turner-2009-12-09
Review completed: 2009-12-09

Review
review-ietf-ipsecme-traffic-visibility-secdir-lc-turner-2009-12-09

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.




Document Abstract:



This document describes the Wrapped Encapsulating Security Payload 


(WESP) protocol, which builds on the Encapsulating Security Payload 


(ESP) [RFC4303], and is designed to allow intermediate devices to (1) 


ascertain if data confidentiality is being employed within ESP and if 


not, (2) inspect the IPsec packets for network monitoring and access 


control functions.




I don't have any comments on the technical contents of the ID.



But, I do have a comment w.r.t. the approach.*  It seems to me that what 


you're looking for is an indication early on that the coming packets are 


encrypted or not.  Don't we already have that with the 50/51 value in 


the protocol header (IPv4, IPv6, or Extension) immediately preceding the 


ESP/AH header.  Why don't we use that as the indication, prohibit those 


NULL encryption algorithms, and then we're done?  We don't have to worry 


about implementing this protocol, the heuristics algorithm in the other 


I-D, and we don't have to complicate the adoption of ESP/AH?




spt



* The only rationale I saw was in the 3rd paragraph of the introduction 


that says AH doesn't work in NAT environments.  Is that really the 


entire reason?  I thought we were trying to kill NATS?