Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt
All, Working primarily from the HTML diff, towards the end of Section 3, the draft -03 text says in part: The IPsec community generally prefers ESP with NULL encryption over AH, but AH is required in some protocols; further, AH is more appropriate when there are security-sensitive options in the IP header The 1st part of this assumes that IP-layer options aren't in the packet (which most commonly is true) and that the deployment threat model does not consider option insertion attacks to be a major threat (a widely held belief for the commercial portions of the Internet). The 2nd part of this is vague, unclear, and a bit misleading. It could be read as indicating that ESP with NULL encryption is able to protect IP header options, but AH is preferred for that case. In fact, ESP is *NEVER CAPABLE* of (A) protecting IPv4 options or (B) of protecting IPv6 options that are seen processed by intermediate systems (e.g. routers, security gateways, other middleboxes). ESP also NEVER can prevent option insertion attacks. Lastly, it is ALWAYS possible for an intermediate system (e.g. router with ACLs) to parse past the AH to see transport-layer headers, but even the best of the heuristics for parsing past an ESP header are not 100% reliable. [IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers with forwarding silicon that could parse AH and any other IPv4/IPv6 options - at wire-speed for 10 Gbps interfaces - 10 years ago. I am aware of 2 other very widely deployed implementations with the same ability to parse past AH to read TCP/UDP ports and apply ACLs at wire-speed. So this is a widely deployed capability, rather than theory. :-] We owe it to readers to be crisp, clear, complete, and accurate with the text in this draft. Candidate new text: When no IPv4 options or IPv6 optional headers are present, and in environments without concerns about attacks based on option insertion (e.g. inserting a source routing header to facilitate pervasive eavesdropping), the IPsec community generally prefers ESP with NULL encryption over AH. However, some protocols require AH. Also, AH always protects all IPv4 options and IPv6 optional headers, while ESP NULL is unable to protect any IPv4 options or to protect IPv6 options that are seen processed by intermediate systems (e.g. routers, security gateways, other middle-boxes). Some IP-layer options, for example IPSO [RFC-1108] and CALIPSO [RFC-5570], today are deployed in some environments while using AH to provide both integrity protection authentication. Further, deployed routers from multiple vendors are able to parse past an AH header in order to read upper-layer protocol (e.g. TCP) header information (e.g. to apply port-based router ACLs) at wire-speed. By contrast, there is no 100% reliable way to parse past an ESP header, although some ESP header parsing heuristics have been documented [RFC-5879] that work in some cases. Yours, Ran Atkinson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt
On 02 Apr 2014, at 13:25 , Paul Hoffman wrote: That was certainly not the intention. OK. [IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers with forwarding silicon that could parse AH and any other IPv4/IPv6 options - at wire-speed for 10 Gbps interfaces - 10 years ago. I am aware of 2 other very widely deployed implementations with the same ability to parse past AH to read TCP/UDP ports and apply ACLs at wire-speed. So this is a widely deployed capability, rather than theory. :-] That's not an important note for this discussion, ... Ah, but it is important, because it talks about deployed reality, and many many users and implementers DO care about the ability to apply ACLs. which is about what the IPsec community has expressed as a general preference. You are mis-characterising the VPN community (e.g. VPNC) as being the whole IPsec community. This I-D supposedly is NOT a VPN-focused draft, but instead claims to address the whole audience of IPsec implementers, users, and usages. You feel that preference is wrong, and you have stated that in earlier WG discussions. No. That is not what I believe or feel, NOR is the quote a correct summary what I have expressed in past discussions. Instead, that is a mis-apprehension of what I have said. In fact, I don't think that the preference for ESP with an integrated transform is wrong or bad - for VPN uses. Indeed, there are well-understood and broadly agreed reasons why - for VPNs - ESP with an integrated transform is preferable. Further, we all agree and understand that VPN is the most widely deployed use case. However, it is not the only deployed IPsec use case. A general IPsec Requirements document ought to be addressing all deployed use cases, and ought not be limited to VPN uses. We owe it to readers to be crisp, clear, complete, and accurate with the text in this draft. Yes, but: Candidate new text: When no IPv4 options or IPv6 optional headers are present, and in environments without concerns about attacks based on option insertion (e.g. inserting a source routing header to facilitate pervasive eavesdropping), the IPsec community generally prefers ESP with NULL encryption over AH. However, some protocols require AH. Also, AH always protects all IPv4 options and IPv6 optional headers, while ESP NULL is unable to protect any IPv4 options or to protect IPv6 options that are seen processed by intermediate systems (e.g. routers, security gateways, other middle-boxes). Some IP-layer options, for example IPSO [RFC-1108] and CALIPSO [RFC-5570], today are deployed in some environments while using AH to provide both integrity protection authentication. Further, deployed routers from multiple vendors are able to parse past an AH header in order to read upper-layer protocol (e.g. TCP) header information (e.g. to apply port-based router ACLs) at wire-speed. By contrast, there is no 100% reliable way to parse past an ESP header, although some ESP header parsing heuristics have been documented [RFC-5879] that work in some cases. That is neither crisp nor clear; it is more complete; it is inaccurate about the parameters that the IPsec community cares about. Precisely HOW is it inaccurate ? I believe that everything in my text is accurate. If there is something inaccurate, please do say precisely what. The proposed text comes off as an advertisement for AH, but that's exactly the opposite direction that the WG has been leaning for this document. I'm open to having you or others propose some alternative text, provided that text makes clear that ESP can't protect IP options in transit, while AH can. This difference in the provided security properties is entirely factual. For VPN deployments, this might not matter, but for other existing IPsec deployments it is known to matter. Again, this document is not about a VPN profile of IPsec, it is about the entirety of IPsec. 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. This does not make clear that ESP can't protect the IP options, which is an important-to-document limitation of ESP. 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. Yours, Ran ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt
Yaron obviously gets to call consensus on this. On Apr 2, 2014, at 12:33 PM, RJ Atkinson rja.li...@gmail.com wrote: On 02 Apr 2014, at 13:25 , Paul Hoffman wrote: That was certainly not the intention. OK. [IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers with forwarding silicon that could parse AH and any other IPv4/IPv6 options - at wire-speed for 10 Gbps interfaces - 10 years ago. I am aware of 2 other very widely deployed implementations with the same ability to parse past AH to read TCP/UDP ports and apply ACLs at wire-speed. So this is a widely deployed capability, rather than theory. :-] That's not an important note for this discussion, ... Ah, but it is important, because it talks about deployed reality, and many many users and implementers DO care about the ability to apply ACLs. You have not said why that is important for *this discussion* which is about the document on cryptographic algorithm implementation requirements. If an implementer cares about what your previous employer shipped and so on, they are welcome to implement AH; nothing in the wording of this document says otherwise. which is about what the IPsec community has expressed as a general preference. You are mis-characterising the VPN community (e.g. VPNC) as being the whole IPsec community. No, I'm talking about what has been said in the WG on this topic to date. This WG is the best representation of the IPsec community that we have. This I-D supposedly is NOT a VPN-focused draft, but instead claims to address the whole audience of IPsec implementers, users, and usages. Correct. If it was VPN focused, it would probably not even mention AH. You feel that preference is wrong, and you have stated that in earlier WG discussions. No. Actually, yes. Looking in the archives, I see you stating it in a few different threads. That is not what I believe or feel, NOR is the quote a correct summary what I have expressed in past discussions. Instead, that is a mis-apprehension of what I have said. In fact, I don't think that the preference for ESP with an integrated transform is wrong or bad - for VPN uses. Indeed, there are well-understood and broadly agreed reasons why - for VPNs - ESP with an integrated transform is preferable. Further, we all agree and understand that VPN is the most widely deployed use case. However, it is not the only deployed IPsec use case. That is what you have said on earlier threads, so I'm not sure how you could say that what I said is wrong. 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. We owe it to readers to be crisp, clear, complete, and accurate with the text in this draft. Yes, but: Candidate new text: When no IPv4 options or IPv6 optional headers are present, and in environments without concerns about attacks based on option insertion (e.g. inserting a source routing header to facilitate pervasive eavesdropping), the IPsec community generally prefers ESP with NULL encryption over AH. However, some protocols require AH. Also, AH always protects all IPv4 options and IPv6 optional headers, while ESP NULL is unable to protect any IPv4 options or to protect IPv6 options that are seen processed by intermediate systems (e.g. routers, security gateways, other middle-boxes). Some IP-layer options, for example IPSO [RFC-1108] and CALIPSO [RFC-5570], today are deployed in some environments while using AH to provide both integrity protection authentication. Further, deployed routers from multiple vendors are able to parse past an AH header in order to read upper-layer protocol (e.g. TCP) header information (e.g. to apply port-based router ACLs) at wire-speed. By contrast, there is no 100% reliable way to parse past an ESP header, although some ESP header parsing heuristics have been documented [RFC-5879] that work in some cases. That is neither crisp nor clear; it is more complete; it is inaccurate about the parameters that the IPsec community cares about. Precisely HOW is it inaccurate ? There has been no one on the list other than you who has given those parameters for the statement the IPsec community generally prefers... I believe that everything in my text is accurate. If there is something inaccurate, please do say precisely what. Done so, now twice. The proposed text comes off as an advertisement for AH, but that's exactly the opposite direction that the WG has been leaning for this document. I'm open to having you or others propose some alternative text, provided that text makes clear that ESP can't protect IP options in transit, while AH can. This difference in the provided security properties is entirely factual.
Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt
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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt
On Wed, 2 Apr 2014, RJ Atkinson wrote: 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. This does not make clear that ESP can't protect the IP options, which is an important-to-document limitation of ESP. In my 15 years of IPsec work, I've hardly seen requests for AH. When our KLIPS stack per default disabled AH support in the kernel module, no one complained. 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. There are people that still accept source routing? How archaic I'm with Paul Hoffman here. I think the current text is fine. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
