On 02 Apr 2014, at 16:17 , Paul Hoffman wrote: > Actually, yes. Looking in the archives, > I see you stating it in a few different threads.
Again, that's not what I said, but instead what you have mis-read. >> A general IPsec Requirements document ought to be addressing >> all deployed use cases, and ought not be limited to VPN uses. > > If that's what the WG wants, great. In me reading the > list as a document author, I don't see people agreeing with that. If this I-D is NOT addressing all IPsec use cases, then why isn't this I-D titled the "IPsec VPN Requirements" document ? > Good catch. Proposed improvement: > > The IPsec community generally prefers ESP with NULL encryption over AH. > AH is still required in some protocols and operational environments when > there are security-sensitive options in the IP header, such as source > routing headers; ESP inherently cannot those IP options. I assume you meant to write: s/cannot those/cannot protect those/ If I understand the intended text, that is an important and very helpful improvement, and I very much appreciate it being added. >> It also should mention IP sensitivity label options, such as RFC-1108 >> and RFC-5570 as a use case for AH, in addition to source-routing headers. > > Having this document listing all of the IP options from Informational RFCs > would undermine the value of this document. Adding s/source routing headers;/source routing headers or sensitivity label options;/ plus adding those 2 RFC citations to your "proposed improvement" text above could not possibly "undermine the value of this document", particularly since both RFCs are examples of currently deployed use cases. Please re-consider applying the brief text edits I've provided just above and the corresponding citations to those 2 RFCs. Yours, Ran _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
