Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility
Thanks -- I've asked the secretariat to start the IETF Last Call! Here are the first IETF Last Call comments (none of them major): - The text about 8-octet alignment probably needs some small clarifications. For IPv6, 8-octet alignment is not optional, so SHOULD is not really correct. And there's an exception: if you're doing UDP encapsulation, the 0x0002 SPI/protocol identifier takes four octets, so the IPv6Padding field isn't included in that case. - The bit numbers in Figure 4 aren't aligned. - [RFC3948] and [RFC5226] should be normative references, not informative. Best regards, Pasi -Original Message- From: ext gabriel montenegro [mailto:g_e_montene...@yahoo.com] Sent: 14 October, 2009 00:07 To: Yaron Sheffer; Tero Kivinen; Grewal, Ken Cc: ipsec@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic- visibility Just to make sure this does not fall through the cracks: we've submitted rev 09 last week to address the AD review comments per discussion on the mailing list and at the virtual interim. - Original Message From: Yaron Sheffer yar...@checkpoint.com To: Tero Kivinen kivi...@iki.fi; Grewal, Ken ken.gre...@intel.com Cc: ipsec@ietf.org ipsec@ietf.org; pasi.ero...@nokia.com pasi.ero...@nokia.com Sent: Mon, September 21, 2009 5:40:19 AM Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme- traffic-visibility Hi Tero, Given that the existing ESP header is integrity-protected, I don't see the downside to adding the same protection for the new header. On the other hand, this would eliminate a whole class of vulnerabilities. We still have a few reserved bits in the WESP header, and you don't want to find out years down the road that they cannot be used because they're not protected in transit. Thanks, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen Sent: Monday, September 21, 2009 14:14 To: Grewal, Ken Cc: ipsec@ietf.org; pasi.ero...@nokia.com Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme- traffic- visibility Grewal, Ken writes: - A question: did the WG discuss the pros and cons of integrity protecting the WESP header? (This does make WESP more complex to implement, and currently the WESP header does not contain any data that would benefit from integrity protection in any way.) [Ken] This change was the result of a discussion on threats posed by 'malware', which could modify the WESP headers to obfuscate the payload from inspection by intermediate nodes such as IDS/IPS systems. The issue (ticket #104) was raised and closed some time back after lengthy discussions on the topic. http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104 As everything in the WESP header is something that can be verified by the recipient node why is the integrity protection needed? I think it would make implementation WESP much easier if it can be done as post processing step after ESP has been applied, in a similar way UDP encapsulation can be done to the ESP packet. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Email secured by Check Point Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01
Nicolas Williams writes: - Section 7, 1st paragraph: MOBIKE is mentioned without a reference. - Section 7, 2nd paragraph: s/avare/aware/ - Section 8.1, next to last sentence: this sentence is grammatically incorrect, I think. How about: If the protocol (also known as the, next header) of thepacket is one that is not supported by the heuristics, then detecting the IV length is impossible, thus the heuristics cannot finish. - Section 8.2, 2nd paragraph: s/shorted/shortest/ - Section 8.2, 2nd paragraph, 2nd sentence: s/implementation/the implementation/ - Section 8.2, 2nd paragraph, 2nd sentence: s/valid looking/valid-looking/ - Section 8.2, bottom of page 15: s/insure/ensure/ (yes, nowadays your use if 'insure' in this way is quite common) All fixed. - Section 8.2, next to last paragraph, next to last sentence: I'm not sure what is meant. Can you try to re-write this sentence? How about: By counting how many unsure returns obtained via heuristics, and after the receipt of a consistent, but unknown, next-header number in same location (i.e., likely with the same ICV length), the node can conclude that that flow has a high probability of being ESP-NULL (since it's unlikely that so many packets would pass the integrity check at the destination unless they were legitimate). (The key change is the addition of a comma and moving a clause into a parenthetical.) Changed to: tAn intermediate node's policy, however, can aid in detecting an ESP-NULL flow even when the protocol is not a common-case one. By counting how many unsure returns obtained via heuristics, and after the receipt of a consistent, but unknown, next-header number in same location (i.e. likely with the same ICV length), the node can conclude that the flow has high probability of being ESP-NULL (since it is unlikely that so many packets would pass the integrity check at the destination unless they are legitimate). The flow can be classified as ESP-NULL with a known ICV length, but an unknown IV length./t - Section 8.3, 1st paragraph, 2nd sentence: this sentence is grammatically incorrect, and I'm unsure as to what is meant. This was commented already by others and was changed to: For example, when many TCP / UDP flows are established over one SA, a rekey produces a new SA which needs heuristics and will benefit from the existing flows. I think what is meant is that if an intermediate node has seen a stateful ULP flow over an ESP-NULL flow, and later the SA is changed and the new flow looks like ESP-NULL and appears to contain a next protocol header that matches that previously-seentateful ULP flow, then chances are very good that the old ESP-NULL flow is abandoned and replaced by the new one. In such situations the intermediate node can simply change the old ESP-NULL state's lookup key. Yes. That was what I tried to say. Do you think my already changed sentence is ok, or do we need to explain it more. - Section 8.3.1, 1st paragraph, 1st sentence: s/feed/fed/ Fixed. - Section 8.3.1, third paragraph: are you suggesting that intermediate nodes drop TCP-looking packets to elicit retransmission? It says that if a packets is dropped, i.e. it does not say whether the intermediate node does or does not do it, as that depends on the policy. If the intermediate node's policy is that no packets go through before they can be inspected meaning ESP-NULL detection needs to finish first before they can be inspected, that will cause all packets to be dropped while heuristics is in progress. This will cause next packets to be retransmissions. If the policy is so that packets are passed, even when we cannot yet inspect them, then the next packet still might be to the same flow. - Section 9, 1st paragraph, 1st sentence, I think you may want to make this change: s/unless that is not/unless that is/ Yes. Fixed that. - Section 9, 1st paragraph, 1st sentence: this is an odd sentence construction. How about: Attackers can always bypass ESP-NULL deep packet inspection by using encrypted ESP (or some other encryption or tunneling method) instead, unless the intermediate node's policy requires dropping of packets that it cannot inspect. - Section 9, 1st paragraph, 2nd sentence, rewrite: Ultimately the responsibility for performing deep inspection, or allowing intermediate nodes to perform deep inspection, must rest on the end nodes. - Section 9, 1st paragraph, last sentence: s/but in that/in which/ Ok, took all of those in, here is the current version of section 9: tAttackers can always bypass ESP-NULL deep packet inspection by using encrypted ESP (or some other encryption or tunneling method) instead, unless the intermediate node's policy requires dropping of
Re: [IPsec] Difference between IPv4 and IPv6 IPsec
On Sun, Oct 11, 2009 at 6:15 PM, Yoav Nir y...@checkpoint.com wrote: Hi Hui I think there is very little difference between IPv4 and IPv6 as regards to IPsec. See below On Oct 11, 2009, at 9:50 AM, Hui Deng wrote: Dear IPsec forks, May I get advice about the differnce between them: 1) IPv4 doesn't mandate the support IPsec, IPv6 also doesn't mandate it based on RFC? IPv4 does not mandate it, because IPv4 predates IPsec. RFC 4294 says in section 8.1: Security Architecture for the Internet Protocol [RFC-4301] MUST be supported. 2) Most IPv4 hosts have(Linux, BSD, Windows) by default implemented IPsec(IKE), but don't launch it, need more configuration? Most IPv6 hosts haven't by default implemented IPsec(IKE), it need further download and configuration? IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With most of them, the latest versions support IPv6 for IKE and IPsec. I guess we do not need tunnel model for IPv6 ipsec? 3) IPv4 IPsec need traversal NAT, but IPv6 don't need it, so it could support more about end to end other than site to site. That is assuming that IPv6 does not have NAT. I don't think we have enough implementation experience to say that for sure. Can it be at-least considered one advantage of IPv6 IPSEC? Another point is: One possible advantage for IPv6 IPsec is that IPv6’s extension header chaining feature, which is not present in IPv4, could be used to authenticate a secure host-to-host scenario exchange to a third party gateways which would provide authorized access into and out of secure enclaves. -quote from http://www.commandinformation.com/blog/?p=98. Is this valid? Thanks for discussion. 4) IPv6 IPsec support is based on extension header which is different from IPv4, it may more closer to the kernal level implementation. I don't see why this would necessarily be true. thanks for the discussion. best regards, -Hui ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Difference between IPv4 and IPv6 IPsec
At 11:29 PM +0800 10/14/09, Zhen Cao wrote: O... IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With most of them, the latest versions support IPv6 for IKE and IPsec. I guess we do not need tunnel model for IPv6 ipsec? what makes you say that? unnelT mode is still needed for SG-SG SAs, or host-SG SAs. 3) IPv4 IPsec need traversal NAT, but IPv6 don't need it, so it could support more about end to end other than site to site. That is assuming that IPv6 does not have NAT. I don't think we have enough implementation experience to say that for sure. Can it be at-least considered one advantage of IPv6 IPSEC? Not really. Another point is: One possible advantage for IPv6 IPsec is that IPv6's extension header chaining feature, which is not present in IPv4, could be used to authenticate a secure host-to-host scenario exchange to a third party gateways which would provide authorized access into and out of secure enclaves. -quote from http://www.commandinformation.com/blog/?p=98. Is this valid? I think that is an unlikely scenario, if only due to key management issues. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Difference between IPv4 and IPv6 IPsec
I would also add a few cents. At 11:29 PM +0800 10/14/09, Zhen Cao wrote: O... IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With most of them, the latest versions support IPv6 for IKE and IPsec. I guess we do not need tunnel model for IPv6 ipsec? what makes you say that? unnelT mode is still needed for SG-SG SAs, or host-SG SAs. Also tunnel mode will still be required for IPv6 to 4 tunnels as long as IPv4 addresses exist and IPv6 nodes need to be interoperable with them. 3) IPv4 IPsec need traversal NAT, but IPv6 don't need it, so it could support more about end to end other than site to site. That is assuming that IPv6 does not have NAT. I don't think we have enough implementation experience to say that for sure. Can it be at-least considered one advantage of IPv6 IPSEC? Not really. Further motivations for NAT in IPv6 includes need for private networks i.e. a company wants to only have one machine to communicate with external world so every computer on that private network goes through that single machine. Also, cost of owning a live ip vs. hosting a private network behind a single live ip would still be attractive, even for security reasons too. Another point is: One possible advantage for IPv6 IPsec is that IPv6's extension header chaining feature, which is not present in IPv4, could be used to authenticate a secure host-to-host scenario exchange to a third party gateways which would provide authorized access into and out of secure enclaves. -quote from http://www.commandinformation.com/blog/?p=98. Is this valid? I think that is an unlikely scenario, if only due to key management issues. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01
On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote: Nicolas Williams writes: - Section 8.3, 1st paragraph, 2nd sentence: this sentence is grammatically incorrect, and I'm unsure as to what is meant. This was commented already by others and was changed to: For example, when many TCP / UDP flows are established over one SA, a rekey produces a new SA which needs heuristics and will benefit from the existing flows. I think what is meant is that if an intermediate node has seen a stateful ULP flow over an ESP-NULL flow, and later the SA is changed and the new flow looks like ESP-NULL and appears to contain a next protocol header that matches that previously-seentateful ULP flow, then chances are very good that the old ESP-NULL flow is abandoned and replaced by the new one. In such situations the intermediate node can simply change the old ESP-NULL state's lookup key. Yes. That was what I tried to say. Do you think my already changed sentence is ok, or do we need to explain it more. Well, the heuristics will benefit from the information cached for the TCP/UDP flow over the previous SA. ...benefit from the existing flows doesn't quite get that point across (though it's the only realistic meaning). - Section 8.3.1, third paragraph: are you suggesting that intermediate nodes drop TCP-looking packets to elicit retransmission? It says that if a packets is dropped, i.e. it does not say whether the intermediate node does or does not do it, as that depends on the policy. If the intermediate node's policy is that no packets go through before they can be inspected meaning ESP-NULL detection needs to finish first before they can be inspected, that will cause all packets to be dropped while heuristics is in progress. This will cause next packets to be retransmissions. But surely actively trying to elicit retransmissions could be used as a way to get enough information to classify a flow... The retransmissions should have different MACs, thus retransmissions help resolve ambiguities, even if the policy isn't to drop packets that cannot be inspected. If the policy is so that packets are passed, even when we cannot yet inspect them, then the next packet still might be to the same flow. I see. Having a policy that says drop packets that can't be inspected actually helps resolve ambiguities if the end nodes retransmit. - Section 9, 1st paragraph, 1st sentence: this is an odd sentence construction. How about: Attackers can always bypass ESP-NULL deep packet inspection by using encrypted ESP (or some other encryption or tunneling method) instead, unless the intermediate node's policy requires dropping of packets that it cannot inspect. - Section 9, 1st paragraph, 2nd sentence, rewrite: Ultimately the responsibility for performing deep inspection, or allowing intermediate nodes to perform deep inspection, must rest on the end nodes. - Section 9, 1st paragraph, last sentence: s/but in that/in which/ Ok, took all of those in, here is the current version of section 9: tAttackers can always bypass ESP-NULL deep packet inspection by using encrypted ESP (or some other encryption or tunneling method) instead, unless the intermediate node's policy requires dropping of packets that it cannot inspect. Ultimately the responsibility for performing deep inspection, or allowing intermediate nodes to perform deep inspection, must rest on the end nodes. I.e. if a server allows encrypted connections also, then attacker who wants to attack the server and wants to bypass deep inspection device in the middle, will use encrypted traffic. This means that the protection of the whole network is only as good as the policy enforcement and protection of the end node. One way to enforce deep inspection for all traffic, is to forbid encrypted ESP completely, in which case ESP-NULL detection is easier, as all packets must be ESP-NULL based on the policy, and further restriction can eliminate ambiguities in ICV and IV sizes./t ^ s Great! - Section 10.2, an informative reference to MOBIKE is needed. What about multicast IPsec? Added reference to MOBIKE. I do not think multicast IPsec requires any special handling as the level what we need for them is already in the RFC4301/RFC4303. We do not really care about the keying protocols, we only care about the ESP packets and we use source address, destination address and SPI to indicate IPsec flow as specified in the RFC4301 and RFC4303. Thanks. A few more comments: - Should there be an explicit threat model in the document? I think the threat model is this: - End nodes trying to access inappropriate data, end nodes trying sneak confidential data out, but without collusion with other end
Re: [IPsec] Difference between IPv4 and IPv6 IPsec
I would also add a few cents. At 11:29 PM +0800 10/14/09, Zhen Cao wrote: O... IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With most of them, the latest versions support IPv6 for IKE and IPsec. I guess we do not need tunnel model for IPv6 ipsec? what makes you say that? unnelT mode is still needed for SG-SG SAs, or host-SG SAs. Also tunnel mode will still be required for IPv6 to 4 tunnels as long as IPv4 addresses exist and IPv6 nodes need to be interoperable with them. 3) IPv4 IPsec need traversal NAT, but IPv6 don't need it, so it could support more about end to end other than site to site. That is assuming that IPv6 does not have NAT. I don't think we have enough implementation experience to say that for sure. Can it be at-least considered one advantage of IPv6 IPSEC? Not really. Further motivations for NAT in IPv6 includes need for private networks i.e. a company wants to only have one machine to communicate with external world so every computer on that private network goes through that single machine. Also, cost of owning a live ip vs. hosting a private network behind a single live ip would still be attractive, even for security reasons too. Another point is: One possible advantage for IPv6 IPsec is that IPv6's extension header chaining feature, which is not present in IPv4, could be used to authenticate a secure host-to-host scenario exchange to a third party gateways which would provide authorized access into and out of secure enclaves. -quote from http://www.commandinformation.com/blog/?p=98. Is this valid? I think that is an unlikely scenario, if only due to key management issues. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #22 Simultaneous IKE SA rekey text
Tero Wrote: RFC4718 is informational and tried to clarify things which are not clear in RFC4306. Now we are writing standard track document when revising RFC4306 and in that case we can even change things specified in RFC4306, if needed. In this case I do not think we need to change things from RFC4306, but I think the text in RFC4718 is not correct as it does not consider the case completely. I'm not sure this makes RFC4718 incorrect. It just makes it incomplete. This solution might cause peers to stay in live lock state, causing the whole IKE SA to be unusable. I.e. host A starts IKE SA rekey and host B starts Create Child SA. Host B replies NO_PROPOSAL_CHOSEN to host A's IKE SA rekey, and Host A replies NO_ADDITIONAL_SAS to Host B's Create Child SA request. Both ends process replies, and notices they failed, thus both start again, causing both ends to be trying these operations as fast as they can. This situation will stay as it is unless something kicks hosts out of sync. Or returning NO_ADDITIONAL_SAS might cause other end to delete the whole IKE SA and start from scratch. I do not like that RFC 4718 used NO_PROPOSAL_CHOSEN as the indicator that a rekey is being rejected because there are outstanding requests. To me a new notify would have made sense. Given that RFC 4718 did use NO_PROPOSAL_CHOSEN it seems to me that when HOST A is rekeying the IKE_SA it should assume the peer is busy when it receives NO_PROPOSAL_CHOSEN and should continue to attempt to periodically rekey the IKE SA again. I do not agree that when Host B receives NO_ADDITIONAL_SAS that it should retry the operation using the same IKE SA. As such I do not think there is a live lock state. What should be done is up to the implementation. An implementation could assume the other end is in the process of rekeying or deleting the IKE SA and delay taking any action or it could take immendiate action. If it takes immediate action it would need to do so on a new IKE SA. This is not in RFC4306, this is just one proposal given in RFC4718 which might be used, but as I noted above, it can cause live lock loop, thus it is not really acceptable. I think it is appropriate to add this to the new draft. If you are concerned about the lock state then a warning should be added stating that when you receive NO_ADDITIONAL_SAS that you should not attempt to retry that operation on the same IKE SA, although that seems self-evident. The proposed solution in RFC4718 does not really work, so I do not think we should include that to RFC4306 (yes, I know I should have noticed this when RFC4718 was being processed not now, but better now than never). I'm not convinced it is broken, I'm just convinced that if you attempt to retry an operation on the same IKE SA that you received NO_ADDITIONAL_SAS on that you can get into a lock state. To reduce that concern we can come up with a new REKEYING_IKE_SA notification, but that's likely to cause problems with old implementations, so better to stick with what RFC 4718 proposed. The text above implies that regardless what you do you should be able to allow other end to start exchanges and process them. I.e. IKEv2 protocol tries to be specified in such way that both ends can start exchanges at any times and expect them to either fail or succeed and get reply back, but not stay in situation where you do not know, whether other end processed your request or not. If you delete the IKE SA immediately that will happen. You can never guarantee you are going to get a response back to a request. I do not see what makes this situation any different. As the RFC4718 text can make situatuation much worse by causing live lock, I think that solution proposed there isn't usable as is. I do not agree. Informational RFC 4718 proposes much bigger change to the standard track RFC 4306 than what I want to do and also the solution has problems which needs to fixed first before it can be taken to IKEv2bis. I would propose much smaller change to the RFC4306, which says that wait a while before deleting the IKE SA after successful rekey so that exchanges from other end has time to finish before deleting the IKE SA. Those exchanges happening after the IKE SA was rekeyed should either be failed or if they are processed, they should be processed in such way that they are done on the Child SAs which are already moved to new IKE SA (i.e. creating IPsec SAs or rekeying IPsec SAs should be failed, and deleting IPsec SAs should be processed, so that IPsec SAs is deleted from the IKE SA where it was moved to). Everything in RFC 4718 is allowable in 4306. Both proposals may require an implementation to change their processing. I do not think these proposals are incompatible. That is not my reading of the text. But I think it is bit pointless to argue about this text as I think we can only agree that it is not clear. Agreed There is nothing there in RFC4306 to say that you cannot
