Re: [IPsec] New draft posted
Jitender Arora wrote: The application where it is required now is the load balancing of the IPSEC tunnels. Suppose in a network there are 10 Security-Gateways and each of these security gateways can handle 20 IPSEC tunnels using the IKEv2 signaling. Now for this network if we need a load balancer device which can balance the tunnels across these security gateways, this load balancer device will be handling the IKEv2 signaling coming from the 10 *20 clients which is 2 Million clients. In addition to handling the IKEv2 signaling from these clients, this will also have to handle the bidirectional IPSEC traffic between the clients and security gateways. So in this case this load balancing device needs to be very scalable and also high performance box. This might not be practical. So to solve this problem, this draft proposes that if we can allow the IPSEC traffic on the different addresses than the IKEv2 signaling, the load balancer can handle only the IKEv2 signaling and chose the right security gateway, and this security gateway can tell the client to send the IPSEC traffic directly to the security gateway without going through the Load Balancer. This way the load balancer does not need to worry about the IPSEC traffic and this will not put a lot of strain on these boxes. You are right, the IKEv2 SA and the CHILD SA will still be on the same machine, but will be using the different addresses. If the IKEv2 SA and Child SAs are on the same box, why isn't RFC 5685 sufficient to solve this problem? RFC 5685 doesn't support using different IP addresses for IKEv2 and ESP/AH, but it would allow bypassing the load balancer for established IKE SAs, precisely they way you describe. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Response to Pasi's AD comments on the roadmap draft
Paul Hoffman wrote: - Section 5.7.4: It also includes 3 EC DH groups (groups 19-21) that were previously defined in [RFC4753]. The normative specification for groups 19-21 in IKE is still 4753/5753bis, so I would propose just omitting this sentence. OK - but won't people be confused if they look at RFC 5114 and see that there are additional groups defined there? The situation of RFC 5114 is quite confusing, I agree (because it's IMHO not totally clear whether the errata for RFC 4753 would apply to RFC 5114 too). Perhaps It also includes 3 EC DH groups (groups 19-21) for information; however, the normative specification for these groups is [4753bis].? It is inappropriate for this document to say what the normative specification for another document is, particularly one that is as confusing as RFC 5114. Assuming 4753bis gets approved by IESG before the roadmap (which seems very likely), I think we can say this. Or perhaps we could say current instead normative? RFC 5114 also included 3 EC DH groups (groups 19-21) that were originally defined in [RFC4753]; however, the current specification for these groups is [4753bis]. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #176: What to do with a proposal of NONE
Tero Kivinen wrote: The last sentence is the one that is misleading. All of the rest of the paragraph is just repeation of the text from elsewhere. The last sentence should be saying: If one of the proposals offered is for the Diffie-Hellman group of NONE, and the responder selects that Diffie-Hellman group, then it MUST ignore the initiator's KE payload and omit the KE payload from the response. I.e. the MUST ignore, and omit the KE payload is only applicable if responder actually selects the Diffie-Hellman group NONE. This looks correct to me. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08
Paul Hoffman wrote: - One of the changes is listed in Section 1.7 twice. I'd suggest combining In section 1.3.2, changed The KEi payload SHOULD be included to be The KEi payload MUST be included. This also led to changes in section 2.18. and Section 2.18 requires doing a Diffie-Hellman exchange when rekeying the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- Hellman exchange was optional, but this was not useful (or appropriate) when rekeying the IKE_SA. as follows: This document requires doing a Diffie-Hellman exchange when rekeying the IKE_SA (and thus requires including the KEi/KEr payloads). In theory, RFC 4306 allowed a policy where the Diffie-Hellman exchange was optional (and KEi/KEr payloads could be omitted), this was not useful (or appropriate) when rekeying the IKE_SA. Disagree. Where possible, I tried to list the actual sections where changes were made, and your proposed rewording loses the two places. The current text is more explicit than the proposed change. Well, this depends on whether you think Section 1.7 should list textual changes in the document, or clarification/changes to the protocol. IMHO, it should be the latter, but I see that currently it's really listing the textual changes (even when they clearly don't have any impact on the protocol); so perhaps listing these separately is consistent with that... Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08
I've gone through changes from 06 to 07/08, and my earlier comments, and found one minor bug and couple of small editorial suggestions/nits. The bug first: - Section 3.3.6 says If one of the proposals offered is for the Diffie-Hellman group of NONE, the responder MUST ignore the initiator's KE payload and omit the KE payload from the response. This seems wrong: it seems to say that if the initiator proposes DH group NONE, the responder must select it. However, negotiation of DH groups and KE payload is already well described in Sections 1.2 and 1.3 (paragraphs mentioning INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is completely redundant. Thus, I'd propose just deleting the whole paragraph. Editorial suggestions/nits: - Section 2.7, last paragraph, is in wrong place; rest of 2.7 has nothing to do with this topic, which is in 2.6. Suggested place: 2.6, end of paragraph starting with In the first message. Also, the responder's SPI will be zero should be the responder's SPI will be zero also in the response message (since the responder's SPI is always zero in the IKE_SA_INIT request, but that's not what this paragraph is about). - One of the changes is listed in Section 1.7 twice. I'd suggest combining In section 1.3.2, changed The KEi payload SHOULD be included to be The KEi payload MUST be included. This also led to changes in section 2.18. and Section 2.18 requires doing a Diffie-Hellman exchange when rekeying the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- Hellman exchange was optional, but this was not useful (or appropriate) when rekeying the IKE_SA. as follows: This document requires doing a Diffie-Hellman exchange when rekeying the IKE_SA (and thus requires including the KEi/KEr payloads). In theory, RFC 4306 allowed a policy where the Diffie-Hellman exchange was optional (and KEi/KEr payloads could be omitted), this was not useful (or appropriate) when rekeying the IKE_SA. - Section 2.8.2, last paragraph: it's not quite obvious why this should be negotiated (the reason is that this notification was not included in RFC 4306, but this section never says that). Suggested rephrasing The TEMPORARY_FAILURE notification was not included in RFC 4306, and support of the TEMPORARY_FAILURE notification is not negotiated. Thus, older peers (implementing RFC 4306) may receive [... rest of the paragraph unchanged...] - Section 2.23, paragraph starting: An initiator can use IKEv2 packets are always over UDP, so IMHO the text would benefit from some more precision when talking about UDP encapsulation. Suggested edits: OLD: An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE. When either side is using port 4500, sending with UDP encapsulation is not required, but understanding received IKE and ESP packets with UDP encapsulation is required. UDP encapsulation MUST NOT be done on port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. Either side can decide whether or not to use UDP encapsulation irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST send UDP encapsulated packets. NEW: An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE. When either side is using port 4500, sending ESP with UDP encapsulation is not required, but understanding received UDP encapsulated ESP packets is required. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated ESP and non-UDP encapsulated ESP packets at any time. Either side can decide whether or not to use UDP encapsulation for ESP irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST use UDP encapsulation for ESP. - Section 3.5: ID_IPV6_ADDR instead of ID_IPV6_ADDR should be ...instead of ID_IPV4_ADDR? - Reference [PKIX] should be updated from RFC 3280 to 5280. - Section 2.23.1, hve - have Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] AD review comments for draft-ietf-ipsecme-roadmap-05
I've now done my AD review for draft-ietf-ipsecme-roadmap-05, and have bunch of comments (most of them minor). Most important first: - I'm not very happy about the use of MUST, SHOULD, etc. in this document. This is supposed to be a purely informational guide to other documents, not something that sets requirements (of any level) for anyone. For cryptographic algorithms, we already have separate documents that specify the requirement levels. IMHO repeating them here just means the two places will soon be inconsistent (which is not helpful for the audience here). If the WG has considered this and decided the repeating them here is useful, I would strongly suggest just having the tables in Appendix B (with explicit note that they're probably out of date by the time the reader finds them), and removing them from Section 5.x. For things other than cryptographic algorithms, I'm not sure if talking about requirements levels even makes that much sense. Consider, for example, Section 4.2.4.2 (IKEv2 redirect): Requirements levels for RFC5685: IKEv1 - N/A IKEv2 - optional This is not really specifying any requirement level; a phrasing like This extension applies only to IKEv2, not IKEv1 would IMHO be more accurate. Text in most other sections (than crypto algs) could be rephrased similarly. - Appendix B: I'm trying to match table B against RFC 4307/4835 and I can't quite get them to match. For example, RFC 4307 lists AUTH_AES_XCBC_96 as SHOULD+, while the column IKEv2 here says optional. This suggests that perhaps even including this table isn't such a good idea... - Section 5.4: Since combined mode algorithms are not a feature of IPsec-v2, these IKEv1 implementations are used in conjunction with IPsec-v3. I'm not sure if this is really a good way to describe the situation; after all, GCM-for-ESP (RFC 4106) predates IPsec-v3... I'd suggest something like Although IPsec-v2 ESP [RFC2406] did not originally include combined mode algorithms, some IKEv1 implementations have added the capability to negotiate combined mode algorithms for use in IPsec SAs; these implementations do not include the capability to use combined mode algorithms to protect IKE SAs. Analogous changes are needed in 5.4.1, 5.4.2, 5.4.3, and 5.6.2. - Section 5.4.1: [RFC4309] includes IANA values for use in ESP-v3; ESP doesn't have any IANA registries; IKEv1 and IKEv2 do. RFC 4309 is included in both. - Quite many IETF protocols use (or can use) IPsec to protect their traffic, so we have *lot* of RFCs that specify how to configure IPsec for use X (ranging from RADIUS and Diameter to iSCSI and TGREP). I don't think these belong in the IPsec document roadmap, unless they modify/extend how IPsec works (e.g. define new payloads/something for IKEv1/v2, or change the IPsec processing somehow). With this in mind, I'd suggest deleting 8.1.1, 8.1.2, and 8.2; rephrasing 8.1.3 and 8.1.4 to explain their impact on IPsec; deleting 8.1.5/8.1.6/8.1.7 and adding RFC 5026 (text below). Proposed new text for 8.1.3: This document specifies the use of IPsec in securing Mobile IPv6 traffic between mobile nodes and home agents. Mobile IPv6 requires considering the Home Address destination option and Routing Header in IPsec processing. Also, IPsec and IKE security association addresses can be updated by Mobile IPv6 signaling messages. Proposed new text for 8.1.4: This document updates [RFC3776] in order to work with the revised IPsec architecture [RFC4301]. Since the revised IPsec architecture expands the list of selectors to include the Mobility Header message type, it becomes much easier to differentiate between different mobility header messages. This document also specifies the use of IKEv2 configuration payloads for dynamic home address configuration. Proposed text for RFC 5026: This document extends [RFC4877] to support dynamic discovery of home agents and the home network prefix; for the latter purpose, it specifies a new IKEv2 configuration attribute and notificatio7n. - Section 5.x: IMHO lines like ESP-v2 - undefined (no IANA #) are a bit confusing, because ESP does not have any IANA registries; the registries are specific to a key management protocol (IKEv1, IKEv2, Photuris, KINK, HIP, ...). - Section 5.7.4: It also includes 3 EC DH groups (groups 19-21) that were previously defined in [RFC4753]. The normative specification for groups 19-21 in IKE is still 4753/5753bis, so I would propose just omitting this sentence. - I would suggest moving 3.2/3.3 somewhere later in the document -- as the document already says, this is not really deployed stuff, and might fit better in e.g. Section 7. - IMHO MOBIKE would belong together with other IKEv2 remote access extensions in Section 4.2.4? - Should RFC 2521 be mentioned? (it's largely obsolete, I guess, but for completeness..) - What about RFC 2709? (it's definitely obsolete, but things like this influenced the design of the
Re: [IPsec] IKEv2-bis comments: 2.17 and onwards (#170)
Tero Kivinen wrote: pasi.ero...@nokia.com writes: Paul Hoffman wrote: B.1 (Group 1): We may want to add: Use of this group is NOT RECOMMENDED. Please open a tracker issue for this. Even though this is obvious, it is a tad late to be suggesting new normative language. This NOT RECOMMENDED would belong in an update to RFC 4307, not this document. The current RFC4306 Security Considerations section already says: Group one is for historic purposes only and does not provide sufficient strength except for use with DES, which is also for historic use only. and I would think that group and algorithms which are historic use only, are also NOT RECOMMENDED... And yes, I agree it should really be in RFC4307, but the group is defined here, so word of it not being recommended, might be good idea in this document too. Hmm... I think the current security considerations text is quite sufficient to discourage people from using this, and repeating the same thing with upper-case RFC 2119 keywords doesn't seem to add anything (and we have earlier agreed those keywords belong in a separate document anyway). Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RFC5555 and Section 2.23.1 (was: IKEv2bis, comments about sections 1-2)
Hi Tero, RFC 4555 Appendix A.2 has more text discussing this topic (when you need to create a new ESP/AH SA, how do you know where to send the IKE packets). It basically concluded this is beyond the scope of the spec, and could be very simple (e.g. just configure a single IP address somewhere), or quite complex (e.g. multiple gateways to select from). So I think this is quite possible with RFC 4301 architecture... (but probably not supported by all implementations) Best regards, Pasi -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of ext Tero Kivinen Sent: 28 January, 2010 14:18 To: Eronen Pasi (Nokia-NRC/Helsinki) Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC and Section 2.23.1 (was: IKEv2bis, comments about sections 1-2) pasi.ero...@nokia.com writes: --- --- 2.11. Address and Port Agility IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. --- --- which usually means that for transport mode the addresses you expect to se on ESP packets are same as what they were for the IKE packet too, which is impossible now as the IKEv2 runs over IPv4, but ESP packets run over IPv6. Hmm... What exactly that text means is actually a good question. If you have a multi-homed host using SCTP, for example, it would make sense to create a transport mode SA whose traffic selectors include more than one IP address. If there are no NATs, this would work fine (even though only one of the addresses in TS payloads would be equal to the address used for sending the IKE packet). So I'm not so sure if this text really prohibits the situation where transport mode traffic selectors aren't exactly the same as the addresses used for sending the IKE packet... I agree that it does not explictly forbid having multiple addresses in transport mode SA, but I do not think it is possible. If we think this setup from the initiator point of view. He is sending packet from src1 to dst1. The packet will trigger IPsec negotiation which will then do SPD lookup. If entry is found from there, and this is transport mode then the SPD does not have local and remote tunnel addresses, but instead it assumes that src1 and dst1 are the address used when creating IKE (or selecting IKE). How do you plan to create such things using RFC4301 architecture? I do not think SPD have any other places to store that kind of information than in the local/remote tunnel addresses, and those are only used in tunnel mode: - (if tunnel mode) local tunnel address -- For a non-mobile host, if there is just one interface, this is straightforward; if there are multiple interfaces, this must be statically configured. For a mobile host, the specification of the local address is handled externally to IPsec. - (if tunnel mode) remote tunnel address -- There is no standard way to determine this. See 4.5.3, Locating a Security Gateway. Hmm.. it might be possible that if the PAD entry linked with that transport mode SPD contains peer gateway information field which indicates the security gateway, but the RFC4301 also says that: For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 [RFC2401] and this document do not specify how A determines the address of the IKE peer serving X. which would indicate that it might be possible to do this kind of things with RFC4301 architecture. On the other hand it is talking about security gateway, which usually indicates tunnel mode, as security gateway is defined to be: A security gateway is an intermediate system implementing IPsec, e.g., a firewall or router that has been IPsec-enabled. Well, this is not the only place where RFC may not work with just any IPsec implementation, and can require MIP-specific tweaks... (search for implementation in Section 5 if you really want to know) I think knowledge adds pain, so I rather not... every time I try read those MIP specific tweaks my heads start hurting, and I feel that those tweaks are not going to work ever with any real IPsec implementation. As there is no NAT for the IPv6 addresses, then the SPD lookup based on the traffic selectors would be fine, but there is no way to know whether there is NAT between the IPv6 address or not, as we only tested the presense of NAT for IPv4 addresses. Yes, that's true. (And even if you know there's NAT, you would not know what the mapped addresses are.) Yes. -- kivi...@iki.fi
Re: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
Ok, I will send new one now (hopefully I do not need to update xml2rfc again this time, I did it already yesterday :-) Thanks -- I've now asked the secretariat to start the IETF Last Call. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] AD review of draft-ietf-ipsecme-aes-ctr-ikev2-04
Now that traffic-visibility has progressed, I've finally done my AD review of draft-ietf-ipsecme-aes-ctr-ikev2-04. This document copies most of its text verbatim from RFC 3686, and does not even acknowledge the source (or have the disclaimer about pre-5378 text). However, it's been noted that people have already managed to implement AES CTR mode for IKEv2, because RFC 3686 and 4306 already contain 99% of the details, and people have guessed the remaining 1%. Instead of repeating several pages worth of complex technical text (such as the precise definitions of CTR modes and their security considerations), this document should focus on the remaining 1%. Here's a rough sketch what the edits should look like: - Keep the first two paragraphs of section 1, and whole 1.1 (and remove everything else) - Remove section 2. - Replace sections 3 and 4 with something like this: When using AES-CTR in the IKEv2 Encrypted Payload, the Initialization Vector is 8 octets. Requirements for this IV are specified in [RFC3686] Section 3.1; the counter block is constructed as specified in [RFC3686], Section 4. When AES-CTR is used in IKEv2, no padding is required; the Padding Length field of the Encrypted Payload SHOULD be set to zero. However, the recipient MUST accept any length. - Replace section 5 with something like this: The use of AES-CTR for the IKE SA is negotiated the same way as AES-CTR for ESP. The Transform ID (ENCR_AES_CTR) is the same; the key length transform attribute is used the same way; and the keying material (consisting of the actual key and the nonce) is derived the same way. - Replace section 6 with something like this: The security considerations for using AES-CTR in IKEv2 are similar to its use in ESP with fresh keys and integrity protection; see [RFC3686] for details. (Note that static keys are never used for the IKE SA, and the IKE_SA always uses integrity protection.) - Replace section 7 with something like this: The IKEv2 Encryption Transform ID ENCR_AES_CTR has already been assigned by IANA. IANA is asked to add a reference to this RFC in that entry. With these changes, the whole document (without boilerplate and reference list) should be probably less than two pages. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
I've now done my AD review for the heuristics draft. Mostly the draft looks good, and all my comments are relatively minor. Least-minor first: - Appendix A.1: The pseudocode has couple of places where it says Drop invalid packet; it seems these are wrong when the packet is UDP encapsulated (this could still be perfectly valid UDP traffic, just something else than ESP). - Section 8.1: AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 are not defined for IPsec ESP; these algorithms apply only to the FiberChannel security protocols. So they should be removed from this list (and since this was the only algorithm with 160-bit ICV, handling that case can be removed). - Section 8.1: AUTH_AES_128/192/256_GMAC cannot be used in ESP, only in AH; for ESP, the relevant algorithm is ENCR_NULL_AUTH_AES_GMAC. - Appendix A.1: shouldn't we also have tests for WESP here? If IP protocol is WESP, process as described in [traffic-visibility] If first 4 bytes of UDP packet are 0x0002, process as.. (the details of WESP don't belong there, though, and a pointer would be quite sufficient IMHO) - Appendix A.2, Verify TCP: the bits that are currently reserved might get allocated in the future (and half of the bits that were reserved in RFC 793 have been since allocated -- so it's not very clear exactly what TCP.reserved_bits means). - The document doesn't cover RSA authentication in ESP (RFC 4359). I guess this isn't really very relevant for environments where the heuristics might be used, so perhaps a sentence saying this is beyond the scope of this document would be sufficient. - Section 2.1, suggesting that AH might have more bugs doesn't sound like an argument that belongs in this document. - Section 2.3: the discussion about IPv6 and NATs does not belong in this document. - Section 3, 2nd para: state of the flows - ... IPsec flows Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #156: SHOULD generate and accept which types?
Valery Smyslov wrote: And I want to raise one more issue. Section 4 mandates support for both PKIX and preshared key for conformant implementation. Isnt't it too strong requirement? snip This requirement has been in the document for 4+ years. Unless there is concrete evidence of multiple implementors encountering difficulties with it (and not just hypothetical garage door openers), I would propose *not* re-visiting this topic at this time. Best regards, Pasi (not wearing any hats) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RFC5555 and Section 2.23.1 (was: IKEv2bis, comments about sections 1-2)
Tero Kivinen wrote: pasi.ero...@nokia.com writes: - Section 2.23.1: If the responder doesn't find SPD entry for transport mode with the modified traffic selectors, and does a lookup with the original selectors, if it finds an entry for transport mode, can it use it? I do not think it can use the transport mode SA using original selectors. This of course depends which traffic selectors are used when installing the SA data to SAD. If those original selectors are used then incoming packets will be dropped because they do not match the selectors for the SA (RFC4301 section 5.2, step 5). Actually, the incoming packets could actually match the selectors if they somehow take a different route than the IKEv2 packets, and bypass the NAT. (This is what's happening in RFC; see below) If modified selectors is used when installing SA then those selectors were not matched against the SPD, and this can cause spoofing attacks. I agree this would violate the policy. (And would that screw up the initiator processing of the reply? That again depends which traffic selectors are returned. If original traffic selectors are returned then initiator do not get information about the original addresses, thus it cannot do incremental checksum updating. Also depending what kind of checks initiator does, it might cause initiator to fail the reply processing. Unfortunately,this question is relevant for RFC ...) What kind of things does the RFC require? Basically, it's assuming that even if you're running IKEv2 over IPv4 (and that IPv4 address is NATted), you can still negotiate transport mode SAs for IPv6 addresses (which won't get NATted). Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] CHILD_SA_NOT_FOUND error (was: IKEv2bis, comments about sections 1-2) (#142)
Tero Kivinen wrote: pasi.ero...@nokia.com writes: - Section 2.25: A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA: Is this really necessary? I think this notification should only occur in cases where DELETE payload for this Child SA pair has already been sent, and probably has been processed already by the time the CHILD_SA_NOT_FOUND notification is received. I agree on that, and I proposed new wording for that: A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA (if it still exists, as most likely delete notification sent by the other hand has already deleted it) and send a request to create a new Child SA from scratch if such Child SA does not yet exists. Thanks -- this is much clearer. - Section 2.25.2, If a peer receives a request to delete a Child SA when it is currently rekeying the IKE SA, it SHOULD reply as usual, with a Delete payload. I noticed this is different from what RFC 4718 recommended, but this is probably OK, given the other text... (but I still hope this was intentional change :-) This was intentional change. snip OK; with this reply, I'm OK with closing issue #142. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #148: Historical cookie discussion
I don't find current 2.6 confusing, so the path of least effort would be to leave it as-is. (But I'm not opposed to some editing if someone is willing to propose text.) Best regards, Pasi -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of ext Paul Hoffman Sent: 20 January, 2010 23:02 To: IPsecme WG Subject: [IPsec] Issue #148: Historical cookie discussion In 2.6, first paragraph: the historical discussion going back to the previous century is very confusing to a newcomer: instead of saying what a cookie is, we tell a story. I suggest to remove this discussion or move it to the end of the section. Can we separate the cookie discussion into its own subsection? For two reasons: it is an implementation hint, rather than a specification (as opposed to the normative text on SPIs earlier in 2.6); and it is not very important, given the prevalence of DDos. --Paul Hoffman, Director --VPN Consortium ___ 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] IKEv2-bis comments: 2.17 and onwards (#170)
Paul Hoffman wrote: B.1 (Group 1): We may want to add: Use of this group is NOT RECOMMENDED. Please open a tracker issue for this. Even though this is obvious, it is a tad late to be suggesting new normative language. This NOT RECOMMENDED would belong in an update to RFC 4307, not this document. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IKEv2bis, comments about sections 3-
Somewhat substantial:
- Section 3.13.1: the paragraph about Mobility Header is very
confusing; suggested rephrasing:
Traffic selectors can use IP Protocol ID 135 to match the IPv6
mobility header [MIPV6]. As specified in [IPSECARCH], the IPv6
mobility header (MH) message type is placed in the most significant
eight bits of the 16-bit local port selector. The direction
semantics of TSi/TSr port fields are the same as for ICMP.
- Section 3.*: should we omit the UNSPECIFIED values? They don't
really help the reader here...
- Overall: The document uses 192.0.1.0/24 in examples (in addition to
the official 192.0.2.0/24 documentation block). Back in RFC 4306/4718
times, we didn't have much of a choice, but now
draft-iana-ipv4-examples (already approved) provides two additional
blocks. Suggest replacing 192.0.1 - 198.51.100 .
- Appendix C.5: brackets should be removed from [KEi]/[KEr]
- Section 1.7, suggest mentioning the new notifications explicitly;
i.e. rephrase the last paragraph
Section 2.25 was added to explain how to act when there are timing
collisions when deleting and/or rekeying SAs, and two new error
notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were
defined.
- Section 1.7: suggest adding
This document requires doing a Diffie-Hellman exchange when
rekeying the IKE_SA. In theory, RFC 4306 allowed a policy where
the Diffie-Hellman exchange was optional, this was not useful (or
appropriate) when rekeying the IKE_SA.
Editorial suggestions:
- Section 3.1: The bits are defined LSB first, so bit 0 would be the
least significant bit of the Flags octet. This seems to be exactly
the opposite of the bit numbering used in the figure above, which
sounds confusing. Instead of using numbers, we should just show a
diagram?
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X X|R|V|I|X X X|
+-+-+-+-+-+-+-+-+
- Section 3.1, the text about critical bit should have a pointer to
Section 2.5.
- Section 3.3.6: suggest removing the last paragraph (the
INVALID_KE_PAYLOAD case is already well described in 1.2 and 2.7),
and there's no need to repeat it here.
- Section 3.4, 2nd-to-last paragraph: suggest adding pointer to
Sections 1.2 and 2.7.
- Section 3.10.1: there's one {{ Demoted the SHOULD }} that
should be removed.
- Section 3.10.1: the list should contain CHILD_SA_NOT_FOUND
and TEMPORARY_FAILURE.
- Section 3.15.1: the table column header should be Multi-Valued
(like it is in RFC 4306) instead of Valued
- Section 3.5: MUST not - MUST NOT (twice)
- Section 1.6: the spelling in the 2nd paragraph isn't exactly
what RFC 2119 has (and this causes idnits to complain).
- From idnits: Duplicate reference: RFC4291, mentioned in 'IPV6ADDR',
was also mentioned in 'ADDRIPV6'.
- Appendix D: can be removed, since the changes from RFC 4306 are
now in Section 1.7
Best regards,
Pasi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] INVALID_IKE_SPI inside IKE SA (was: IKEv2bis, comments about sections 1-2)
Tero, I agree with your analysis (I hadn't noticed that this doesn't even work). Best regards, Pasi -Original Message- From: ext Tero Kivinen [mailto:kivi...@iki.fi] Sent: 19 January, 2010 11:25 To: Eronen Pasi (Nokia-NRC/Helsinki) Cc: ipsec@ietf.org Subject: INVALID_IKE_SPI inside IKE SA (was: [IPsec] IKEv2bis, comments about sections 1-2) pasi.ero...@nokia.com writes: - Section 1.5: I noticed the 1st paragraph nowadays (well, since -00 of the WG draft) allows sending INVALID_IKE_SPI notification inside an existing IKE_SA. This contradicts a MUST NOT in RFC 4306, and I'm not sure if it really brings any benefits? There is no way to send INVALID_IKE_SPI inside IKE SA, as the section 3.10 says that the IKE SPI is never sent inside the notification payload (For a notification concerning the IKE SA, the SPI Size MUST be zero and the field must be empty.) and the IKE SPI is taken from the packet. Sending INVALID_IKE_SPI inside IKE SA would mean that the IKE SA you are sending the packet inside is invalid... The section 2.21.4 is very clear that INVALID_IKE_SPI MUST NOT be cryptographically protected, i.e. it is sent outside the IKE SA. I think the 1st paragraph is quite wrong and the If the receiving node has an active IKE SA to the IP address from whence the packet came, it MAY send a notification of the wayward packet over that IKE SA in an INFORMATIONAL exchange. part should be removed. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #143: Rewrite of 1.5
Paul Hoffman wrote: Section 1.5 doesn't read well, and needs a rewrite. Pasi can provide text once the substantial issue re: INVALID_IKE_SPI is decided. That substantial issue is #137; assuming it's resolved the way Tero proposed (and I agree), I'm proposing the following text: There are couple of cases when a node receives a packet it cannot process, but may want to notify the sender about this situation: o If an ESP or AH packet arrives with an unrecognized SPI, it could be because the receiving node has recently crashed and lost state or because of some other system malfunction or attack. o If an encrypted IKE request packet arrives on port 500 or 4500 with an unrecognized SPI, it could be because the receiving node has recently crashed and lost state or because of some other system malfunction or attack. o If an IKE request packet arrives with a higher major version number than the implementation supports. (Note that the first and third cases apply only to IKE request packets, not response packets.) In the first case, if the receiving node has an active IKE SA to the IP address from whence the packet came, it MAY send an INVALID_SPI notification of the wayward packet over that IKE SA in an INFORMATIONAL exchange. The Notification Data contains the SPI of the invalid packet. The recipient of this notification cannot tell whether the SPI is for AH or ESP, but this is not important because the SPIs are supposed to be different for the two. If no suitable IKE SA exists, the node MAY send an INFORMATIONAL message without cryptographic protection to the source IP address. In this case, it should only be used by the recipient as a hint that something might be wrong (because it could easily be forged). This message is not part of an INFORMATIONAL exchange, and the receiving node MUST NOT respond to it (doing so could cause a message loop). The message is constructed as follows: There are no IKE SPI values that would be meaningful to the recipient of such a notification; using zero values or random values are both acceptable. The Initiator flag is set, the Response bit is set to 0, and the version flags are set in the normal fashion. In the second and third cases, the message is always sent without cryptographic protection (outside of an IKE SA), and includes either INVALID_IKE_SPI or INVALID_MAJOR_VERSION notification (with no notification data). The message is a response message, and thus it is sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID is copied. The Response bit is set to 1, and the version flags are set in the normal fashion. The responder SHOULD copy the Exchange Type from the request. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #143: Rewrite of 1.5
Tero Kivinen wrote: pasi.ero...@nokia.com writes: There are couple of cases when a node receives a packet it cannot process, but may want to notify the sender about this situation: o If an ESP or AH packet arrives with an unrecognized SPI, it could be because the receiving node has recently crashed and lost state or because of some other system malfunction or attack. o If an encrypted IKE request packet arrives on port 500 or 4500 with an unrecognized SPI, it could be because the receiving node has recently crashed and lost state or because of some other system malfunction or attack. o If an IKE request packet arrives with a higher major version number than the implementation supports. (Note that the first and third cases apply only to IKE request packets, not response packets.) The first case applies to ESP or AH packets, so this text should apply only to the last two cases. Quite right, this should be second and third. In the first case, if the receiving node has an active IKE SA to the IP address from whence the packet came, it MAY send an INVALID_SPI notification of the wayward packet over that IKE SA in an INFORMATIONAL exchange. The Notification Data contains the SPI of the invalid packet. The recipient of this notification cannot tell whether the SPI is for AH or ESP, but this is not important because the SPIs are supposed to be different for the two. If no suitable IKE SA exists, the node MAY send an INFORMATIONAL message without cryptographic protection to the source IP address. In this case, it should only be used by the recipient as a hint that something might be wrong (because it could easily be forged). This message is not part of an INFORMATIONAL exchange, and the receiving node MUST NOT respond to it (doing so could cause a message loop). The message is constructed as follows: There are no IKE SPI values that would be meaningful to the recipient of such a notification; using zero values or random values are both acceptable. The Initiator flag is set, the Response bit is set to 0, and the version flags are set in the normal fashion. This is against the text in the section 3.1 which says: o Initiator's SPI (8 octets) - A value chosen by the initiator to identify a unique IKE security association. This value MUST NOT be zero. Was that intentional, i.e. can both the Initiator's and responder's SPIs be zero? I didn't change this part; the text has been there since the first draft (and is also in RFC 4718, section 7.7). Here's what 4718 said: In case of INVALID_SPI, however, there are no IKE SPI values that would be meaningful to the recipient of such a notification. Also, the message sent is now an INFORMATIONAL request. A strict interpretation of the specification would require the sender to invent garbage values for the SPI fields. However, we think this was not the intention, and using zero values is acceptable. (References: INVALID_IKE_SPI thread, June 2005.) Since the value will be anyway meaningless to the recipient, I don't think it matters what it is; so I would propose we leave this as-is. In the second and third cases, the message is always sent without cryptographic protection (outside of an IKE SA), and includes either INVALID_IKE_SPI or INVALID_MAJOR_VERSION notification (with no notification data). The message is a response message, and thus it is sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID is copied. The Response bit is set to 1, and the version flags are set in the normal fashion. The responder SHOULD copy the Exchange Type from the request. Otherwise the text looked good. Thanks for checking this! Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Flags in header (was: IKEv2bis, comments about sections 3-)
Removing the whole bit numbering mess, and showing the flags in the main figure as you suggest, sounds good to me. (But since nobody has noticed this before -- AFAIK, at least -- perhaps leaving this as-is would also be acceptable...) Best regards, Pasi -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of ext Tero Kivinen Sent: 19 January, 2010 14:32 To: Eronen Pasi (Nokia-NRC/Helsinki) Cc: ipsec@ietf.org Subject: [IPsec] Flags in header (was: IKEv2bis, comments about sections 3-) pasi.ero...@nokia.com writes: - Section 3.1: The bits are defined LSB first, so bit 0 would be the least significant bit of the Flags octet. This seems to be exactly the opposite of the bit numbering used in the figure above, which sounds confusing. Instead of using numbers, we should just show a diagram? 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |X X|R|V|I|X X X| +-+-+-+-+-+-+-+-+ So you are suggesting that we change the bit order to use MSB instead of LSB as it is now? It might be better to get rid of bit numbers completely then and put the separate flags to the main figure: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IKE SA Initiator's SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IKE SA Responder's SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | MjVer | MnVer | Exchange Type |X|X|R|V|I|X|X|X| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: IKE Header Format and remove the whole bit numbering mess. Note, that this bit order thing has been inherited from the RFC2408 which also used MSB bit order when showing figures having 32 bits words, but used LSB bit order when actually counting bits inside the octect. BTW, your format confused me as I am so used to talking about bit 0 when I am talking about the lowest bit of the octect (i.e the one you get by doing (octect 1)). I would actually prefer to keep the text as it is now, even though it is not consistent with the bit order in 32-bit figures and the bit order in the text, but at least it clearly defines the bit order. -- kivi...@iki.fi ___ 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] Issue #135: Which IKE SA inherits a Child SA?
I agree. This was also noted in http://www.rfc-editor.org/errata_search.php?rfc=4718 Best regards, Pasi (not wearing any hats) -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of ext Paul Hoffman Sent: 17 January, 2010 18:07 To: IPsecme WG Subject: [IPsec] Issue #135: Which IKE SA inherits a Child SA? Section 2.8.2 seems to have quite fatal error: The new IKE SA containing the lowest nonce inherits the Child SAs. This is wrong. The one containing the lowest nonce, is the one that is going to be deleted, not the one that survives. This needs to be changed to: The new IKE SA containing the lowest nonce SHOULD be deleted by the node that created it and the other suriving new IKE SA MUST inherit all the Child SAs. Note, that I used words MUST here as this is one of the few cases where the correct behavior is really needed for interoperability reasons. It is not needed for simultaneous Child SA cases, as traffic continues to flow, even if they do not delete the loosing Child SA (we just have one extra Child SA). In this case it is important for the interoprability that both ends AGREE on which new IKE SA inherited the Child SAs from the old IKE SA. If they disagree then all IKE SAs are messed up and future rekeys, deletes etc will fail. Deleting the loosing IKE SA is not necessarely needed for interoperability so thats why that is SHOULD (just like it is in the child SA case), but moving Child SAs to correct IKE SA is MUST. --Paul Hoffman, Director --VPN Consortium ___ 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
[IPsec] IKEv2bis, comments about sections 1-2
I'm doing a yet another full review pass over the whole document (not just diff as I've usually done; to find issues/inconsistencies that diffs wouldn't necessarily show). So far, I've covered Sections 1 and 2. Substantial comments: - Section 1.5: I noticed the 1st paragraph nowadays (well, since -00 of the WG draft) allows sending INVALID_IKE_SPI notification inside an existing IKE_SA. This contradicts a MUST NOT in RFC 4306, and I'm not sure if it really brings any benefits? - Section 2.8.1, NO_PROPOSAL_CHOSEN near the end. This is probably left over from old versions, and should be something else now to align with Section 2.25? - Section 2.8.2: (already covered by issue #135) - Section 2.14: only the first 64 bits of Ni and the first 64 bits of Nr are used in the calculation. This section has two calculations involving Ni/Nr, but this sentence should only apply to the former. Suggested rephrasing: the calculation - when calculating SKEYSEED (but all bits are used when calculating SK_*) - Section 2.17: See http://www.ietf.org/mail-archive/web/ipsec/current/msg04673.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04681.html - Section 2.23, last bullet: MUST NOT be used when MOBIKE is used This is actually not exactly what Section 3.8 of [MOBIKE] says (it does allow using this for ESP). I would suggest just referring to Section 3.8 of [MOBIKE] for details. - Section 2.23.1: If the responder doesn't find SPD entry for transport mode with the modified traffic selectors, and does a lookup with the original selectors, if it finds an entry for transport mode, can it use it? (And would that screw up the initiator processing of the reply? Unfortunately,this question is relevant for RFC ...) - Section 2.25: A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA: Is this really necessary? I think this notification should only occur in cases where DELETE payload for this Child SA pair has already been sent, and probably has been processed already by the time the CHILD_SA_NOT_FOUND notification is received. - Section 2.25.2, If a peer receives a request to delete a Child SA when it is currently rekeying the IKE SA, it SHOULD reply as usual, with a Delete payload. I noticed this is different from what RFC 4718 recommended, but this is probably OK, given the other text... (but I still hope this was intentional change :-) Somewhat substantial: - Section 1.3.1: delete sentence When an IKE SA is not created... (this section is about CREATE_CHILD_SA, and the IKE_AUTH error messages are already well described in Section 1.2). - Section 1.5 doesn't read well, and needs a rewrite. I can provide text once the substantial issue re: INVALID_IKE_SPI is decided. - Section 2.6, paragraph beginning with In addition to cookies.., and Section 2.7, last paragraph, are both in very strange places (and basically say the same thing). Suggest combining both, and adding them to the end of paragraph In the first message.. in 2.6: When the exchange does not result in the creation of an IKE SA on the responder (due to, for example, COOKIE, INVALID_KE_PAYLOAD, or NO_PROPOSAL_CHOSEN), the responder's SPI will be zero also in the response message. However, if the responder does send a non-zero responder SPI, the initiator should not reject the response for only that reason. - There are two places that have very similar text about INVALID_KE_PAYLOAD: Section 1.3 (for CREATE_CHILD_SA exchange), and Section 2.7 (for IKE_SA_INIT exchange). Especially the latter seems a bit strange, everything else in that section applies to CREATE_CHILD_SA exchanges, too, but this paragraph explicitly applies to IKE_SA_INIT only (although INVALID_KE_PAYLOAD works roughly the same way in CREATE_CHILD_SA, too). Perhaps the text in 2.7 should be moved to 1.2? - Section 2.8, sentence: Note that, when rekeying... This is in wrong place; the rest of this paragraph is about IKE_SA rekeying, so it should be moved to the previous paragraph. - Section 2.18, last paragraph: suggest adding PRF to the list of things that come from the new exchange. - Section 2.23, paragraph starting: An initiator can float... needs some clarifications. Probably UDP encapsulation/encapsulated should be UDP encapsulation of ESP/UDP-encapsulated ESP (since at other places, the document also talks about IKE packets being UDP encapsulated). - Section 2.23.1: I would strongly suggest using the word original address (just like RFC 3947) instead real address (since both addresses are very real). - Section 2.23.1, - Store the original traffic selectors.. (occurs twice) I would suggest using received instead of original here. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
Ken Grewal wrote: The either-or on using an ICV or explicitly checking the WESP header on the recipient was based on the assumption that the threat does not come from the sender and only from some other malicious entity after the packet has been sent. This was the reason for simplifying the header check by using the ICV, instead of explicitly checking every field. Note that the current draft *does* explicitly check ever field. Are you proposing removing those checks? Best regards, Pasi (not wearing any hats) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Paul Hoffman wrote: - Add [IKEV2IANA] to the Normative References; it will point to the URL of the IANA registry. I don't like the idea of splitting the normative content of RFC 4306 to two different places. An informative reference would be very useful (and probably some of the tables may contain stuff that could be just removed). But if I'm writing code to send an IDi payload of type ID_FQDN, the numbers for IDi and ID_FQDN should be in this RFC (either somewhere near the text that describes IDi and ID_FQDN, or in a table -- that doesn't matter very much). Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question
Paul Hoffman wrote:
We earlier agreed in issue #50 to make the KEr in Section 1.3.2
(Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory:
-- HDR, SK {SA, Nr, KEr}
Note that this is not in the current draft, but will be in the next
one.
So, what happens if the responder does not include a KEr, following the
syntax in RFC 4306?
This would happen only if the responder's SA payload has value NONE
for transform type 4, right?
But the text in Section 2.18 already prohibits this...
Does the process revert back to using only the SK_d and the new
nonces, or does the responder reject the request and indicate its
preferred DH group in the INVALID_KE_PAYLOAD notification payload
(section 1.3)? The latter seems much more likely, given the text in
2.18. If so, we should say so explicitly.
Section 2.18 also states that in the case of the old and new IKE SA
selecting different PRFs, that the rekeying exchange (for SKEYSEED) is
done using the *old* IKE SA's PRF. What happens after that? The end
of section 2.18 says that SK_d, etc are computed from SKEYSEED as
specified in section 2.14. If the PRF changed, which PRF is used for
the prf+ calculations, the old PRF or the new PRF?
SK_* are computed from SKEYSEED using the new IKE SA's PRF.
Best regards,
Pasi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
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] Transform IDs for AES-GMAC in IKEv1
This took a bit longer than expected, but the IKEv1 transform IDs have now been allocated by IANA, and they're listed in errata for RFC 4543: http://www.iana.org/assignments/isakmp-registry http://www.rfc-editor.org/errata_search.php?rfc=4543eid=1821 (Big thanks to Tero for his help with the details!) Best regards, Pasi -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Eronen Pasi (Nokia-NRC/Helsinki) Sent: 30 April, 2009 12:28 To: ipsec@ietf.org Subject: [IPsec] Transform IDs for AES-GMAC in IKEv1 Hi, RFC 4543 specifies how to use AES-GMAC mode in AH and ESP and how to negotiate them in IKEv1 and IKEv2 (see Section 5, 1st paragraph). However, as Soo-Fei Chew pointed out, the IANA considerations text in the final document didn't actually ask IANA to assign the numbers for IKEv1. Here's my proposal for fixing the situation: (1) ask IANA to assign the four missing numbers (after IESG approval). (2) submit an RFC Editor errata, saying something like this: The following text should have been included in Section 9: For the negotiation of AES-GMAC in AH with IKEv1, the following values have been assigned in the IPsec AH Transform Identifiers registry (in isakmp-registry). Note that IKEv1 and IKEv2 use different transform identifiers. TBD1 for AH_AES_128_GMAC TBD2 for AH_AES_192_GMAC TBD3 for AH_AES_256_GMAC For the negotiation of AES-GMAC in ESP with IKEv1, the following value has been assigned from the IPsec ESP Transform Identifiers registry (in isakmp-registry). Note that IKEv1 and IKEv2 use a different transform identifier. TBD4 for ESP_NULL_AUTH_AES_GMAC (where we will in TBD1..4 after we know the numbers) (3) ask IANA to include a pointer to this errata in the isakmp-registry entries. Does this sound like a reasonable plan? Best regards, Pasi ___ 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
[IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility
I've now done my AD review for draft-ietf-ipsecme-traffic-visibility-08. I have two substantive comments, and a bunch of minor clarifications/nits. The substantive comments first: - 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.) - IPv6 requires extension headers to be aligned on 8-octet boundaries, and I believe this requirement applies to ESP, too (see e.g. RFC 4303 Section 2.3, 2nd paragraph). All current ESP specs (all encryption algorithms, UDP encapsulation, etc.) meet the 8-octet alignment requirement -- but adding a new four-octet header there obviously breaks it. Some minor clarifications/editorial nits: - The text currently uses using ESP-NULL [RFC2410] and unencrypted as synonyms. This was accurate before RFC4543, but is not any more. This needs some clarifying text somewhere (perhaps Section 1). - Section 1 needs a sentence or two motivating the existence of the E bit -- currently it comes as a surprise to the reader later. - Section 2/2.1: In Figures 1, 2, and 3, the bit numbers should be shifted one character to the right. - Section 2: In some parts of the text, the last 8 bits of the WESP header are called Flags; in other parts, the last 5 bits are called Flags. I'd suggest changing e.g. Figure 2 so that last 5 bits are called Rsvd or something. - Section 2: The bits are defined LSB first, so bit 0 would be the least significant bit of the flags octet. This doesn't match the bit numbering in Figure 2 (where bit 0 is the most significant bit). However, the bit numbers are not really used anywhere, so I would just suggest deleting this sentence. - Section 2: It would be helpful if the text explicitly said that HdrLen values less than 12 are invalid (and probably HdrLen values that are not multiple of 4 are invalid, and multiple of 8 for IPv6 case). - Section 2: the text about TrailerLen is a bit unclearly written -- the offset from the end of the packet to the last byte of the payload would be a negative number. I'd suggest phrasing this something like the The number of bytes following the payload data in the packet, in octets: i.e. the total length of TFC Padding (normally not present for unencrypted packets), ESP Trailer (Padding, Pad Length, Next Header), and ESP ICV. - Section 2: the packet must be dropped - the packet MUST be dropped - The figures in 2.2.1 and 2.2.2 are very confusing, since they suggest WESP could be applied as a separate step after ESP processing (that was possible in some earlier versions of the draft, but not any more since ICV covers the WESP header). Since they don't really present much new compared to the figures in RFC 4303 Section 3.1.1/3.1.2, perhaps they could be omitted? Or if we want to keep them, they probably should show the packet before applying ESP? - Section 3: s/IPSec/IPsec/ - Section 4: this section is missing the allocation of SPI value 2 to indicate WESP from the SPI Values registry. - Section 4 should say that for the WESP Version Number, the unassigned values are 1, 2, and 3. - Section 6: [RFC4306], [RFC3948], and [RFC5226] should be normative references, not informative. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Ikev2 HA message Id Issue
Kalyani Garigipati wrote: One obvious approach would be not to sync after every exchange (that could be a lot of messages), but sync, say, every N seconds (say, N=5) in one big batch (for all IKE_SAs that changed in the last N seconds). Kalyani If sync is done in batches and if active device crashes between the interval sync of the batches, then we again see the same message Id issue. Yes; so N can't be very large. If dpd is enabled then ikev2 counters keep updated frequently. This depends on how often you do DPD... Obviously, you want dead IKE_SAs to go away eventually, but e.g. 30 minute DPD interval would be sufficient for that. If your DPD interval was close to the value of N, that would not work well... but on the other hand, if you have lot of traffic going back and forth, IKEv2 DPD won't get triggered.. Hence we cannot rule out the possibility of out of sync between stand by and active device with the above approach. We cannot rule out this possibility with any approach, I think. Most of the time, almost all IKE_SAs are just sitting there idle (so IKEv2 message ID counters don't change). In case of failure, the stand-by device would have out-of-date information for some small percentage of IKE_SAs (those whose counters changed since last sync) , but that's always going to be the case (for exchanges where something more happened just before/during the failure). Kalyani With HA, we want to ensure the maximum avoidance of out of sync. In any case of out of sync, the retransmission of messages should take care of the exchanges. In the worst case the SA will have to deleted (which is the case Currently now for IKEV2 when windowing is used and some requests are lost ) Yes. But this worst case cannot be avoided (since the worst case can occur due to other reasons than message IDs) -- it can be just made less likely to happen. I haven't done the math, though, so I don't know what value of N would result in both acceptable bandwidth and acceptable failure rate for the stand-by (depends on how many messages your typical IKE_SAs have per hour on average)... Kalyani we might like the solution to work in all cases of exchange frequency, hence I think we cannot fix N. I agree; clearly N would be a configurable parameter, not something fixed in some spec. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #79: Remove CP from Create_Child_SA?
I would repeat my comment from April: http://www.ietf.org/mail-archive/web/ipsec/current/msg04245.html If we continue to allow CP in INFORMATIONAL exchange (and IMHO we should), it should be allowed in CREATE_CHILD_SA, too (with exactly same semantics). Best regards, Pasi From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of ext Yaron Sheffer Sent: 26 August, 2009 00:23 To: ipsec@ietf.org Subject: [IPsec] #79: Remove CP from Create_Child_SA? Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload. IMO the normal way of doing things is in this message 3, so rather than a parenthetical remark, it's really the only one anyone uses. I don't think it makes sense to assign a different IP address for each SA, and I don't think anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client needs to renew the address with the gateway (probably renew the lease with a DHCP server). With such an attribute, it made sense for the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked as RESERVED. Since we've done that, I suggest we remove the CP payload from the Create Child SA exchange in appendix A, and reword section 2.19 to reflect that requesting an IP address is only acceptable during IKE_AUTH. Everyone, please comment on the above, even if you support Yoav's proposal. This would be a protocol change (even if we don't understand what the current semantics is...), so we shouldn't do it unless we're quite sure. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #79: Remove CP from Create_Child_SA?
Yoav Nir wrote: I disagree. Payloads in a particular CREATE_CHILD_SA exchange should be specifically related to the SA being created. The IKE_AUTH exchange is different, because it is used to set up everything we need to get an IPsec SA going. If we were designing IKEv2 from scratch, I would agree with you. But we're not, so we're not discussing what would be the best design here, but rather whether this part of RFC 4306 is so horribly broken it absolutely needs to be changed (RFC 4306 is unambiguous that CPs are allowed in CREATE_CHILD_SA exchange). I think it's not broken, just somewhat ugly and inelegant... Best regards, Pasi (not wearing any hats) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption
Yaron Sheffer wrote: - Section A.1 should say that the notation used for the example ticket formats is intended to be pseudo-code, and does not specify exact octet-by-octet format. (And probably things like reserved[3] should be removed, since they don't really belong in pseudo-code like this.) This is an example only, but it can still be precise. It *does* specify an octet-by-octet format, except you're free to implement something else, or change whatever you feel like. In general, I think an implementer is better off starting from a precise definition than from a vague pseudo-code description. The text never specifies how e.g. opaque state_ref would be encoded (e.g. if it's variable length, there's probably some kind of length field somewhere), so IMHO it does not specify octet-by-octet format (two persons reading this would very likely end up with different octets). Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt
Yaron Sheffer wrote: Hi Pasi, Sorry for the late reply. I believe most people would NOT expect a properly terminated (deleted) IKE SA to be resumed. To give one example, suppose I downsize a user and revoke his access rights. Today I will simply terminate (=delete) all his existing SAs, and then will rely on the next IKE setup to revalidate the user with the AAA server, which will correctly fail. Resumption would bypass this check. If you want to make sure the downsized user doesn't come back and bypass the AAA server, you need either ticket-by-reference or some gateway-side state to prevent use of tickets that have been revoked. In either case, it seems the gateway could prevent resumption in cases where the gateway closed the IKE_SA, but still allow it if the client closed the IKE_SA, no? (BTW, in case of ticket-by-value, the gateway doesn't need per-ticket black list -- e.g. Eric Rescorla's stateless tokens draft suggested using a fixed-size Bloom filter to keep track of tickets that should not be accepted any more.) But it seems regardless of whether we allow resuming a properly closed IKE_SA or not, this is an issue that should be discussed in the Security Considerations section. If most people would expect revoking access rights to work the way you describe, it might come as a surprise that it does not, when using ticket-by-value... We could add a flag to the 2 notifications for the gateway to signal to the client that it implements a different semantics, i.e. it is willing to resume a previously deleted SA. Do you think this use case is worth the added complexity? It seems we're looking at this from quite different angles -- to me, *not* allowing resumption here is added complexity, since it's more difficult to implement than allowing resumption...? Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Final comments for ikev2-redirect-10
Vijay Devarapalli wrote: And having these two cases is more complex than having just one (IKE_SA is not used for any more exchanges). What benefits does this additional complexity (both in spec and in implementation) get us? If nothing, let's just remove it When the AUTH payloads are exchanged and verified, the IKEv2 SA is valid. This seems straightforward. We are not doing anything out of the ordinary here by not invalidating the IKEv2 SA just because the gateway sent the REDIRECT payload to the client. I can imagine extensions tomorrow that would let the client convey additional information using the IKEv2 SA to the gateway, after the gateway had sent a REDIRECT payload to the client. What do you mean by valid? So the client could potentially ignore the redirect (in the last IKE_AUTH response), and continue using the IKE_SA (at least for some time) for other exhanges? AFAIK, the current text is *not* supposed to allow that -- but it seems it is indeed quite unclear. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt
not wearing any hats 1) First, sending a comment I already sent to the mailing list on March 17: In TLS session resumption, resumption basically creates a new TLS connection (using information from local session cache, or ticket in case of RFC5077), and does *not* really resume the old connection. The old connection can still exist (and the session resumption handshake won't cause it to be closed), or it could have been interrupted earlier, or it could have been cleanly closed earlier. The current ikev2-resumption draft, on the other hand, seems to assume a quite different model, where resumption replaces the old connection, and can be done only if the old connection was interrupted. This would seem to preclude one case discussed earlier: I close my laptop (cleanly) at work, commute, and reconnect at home (without having to do EAP again; e.g. type in one-time password). Or switch off my phone (cleanly), fly to IETF meeting, and switch it back on. In case of IKEv2, having multiple parallel IKE connections is probably less common than with TLS (where it's very common), but to me it seems using the IKE_SESSION_RESUME handshake when the old IKE_SA was cleanly closed would be quite useful, and should be supported. (And making the new connection completely independent of the old one might simplify the protocol anyway.) (Or in other words: I'd propose changing Section 7.2, 1st paragraph, and making these MUSTs MAYs.) 2) The draft is currently very vague about the use cases for this mechanism. As the discussion has shown, there's more than one use case, and folks clearly have different opinions about which of them are important and which are not. However, being vague makes the draft quite difficult to understand for a reader that hasn't participated in the discussions. I think the draft should mention that there are several different use cases, and give concrete examples (but not take an opinion about which of them are important or not). Perhaps something like this (going somewhere in Section 1): Possible situations where the mechanism specified in this document could be useful include the following (note that this list is not meant to be exhaustive, and any particular deployment may not care about all of these): - If a client temporarily loses network connectivity (and the IKE SA times out), this mechanism could be used to re-establish the SA with less overhead (network, CPU, authentication infrastructure) and without requiring user interaction for authentication. - If the connectivity problems affect a large number of clients (e.g., a large remote access VPN gateway), when the connectivity is restored, all the clients might reconnect almost simultaneously. This mechanism could be used to reduce the load spike for cryptographic operations and authentication infrastructure. - Losing connectivity can also be predictable and planned; for example, putting a laptop to stand-by mode before travelling. This mechanisms could be used to re-establish the SA when the laptop is switch backed on (again, with less overhead and without requiring user interaction for authentication). 3) Section 1, 2nd paragraph should also mention one additional reason someone might have for using this mechanism (even if roundtrips or CPU time is not an issue): doing the authentication from scratch could require user interaction. 4) Some aspects of the protocol are described very thinly. For example: - Section 4.2 describes what message is sent by the gateway, but not what the client should do when it receives it - Section 4.3 just says the gateway accepts the ticket, but not all the steps involved in this (there's lot about this in Sections 5 and 6 though) - Section 4.3 says the client initiates an IKE_AUTH exchange, but doesn't say much about how this differs from an ordinary IKE_AUTH exchange (except for AUTH payload) - Section 4.4 it's possible to use N(COOKIE) in IKE_SESSION_RESUME, but nothing else (e.g. in IKE_SA_INIT request, N(COOKIE) must always be the first payload -- but the message diagram earlier puts other notifications at the end. Which is it?) For all of these, I'm sure the authors have some idea how this is supposed to work -- but I don't think the current text is very likely to lead to interoperable implementations. I'd recommend taking Sections 4.1...4.6, 4.8, 5 and 6 and doing a reorganization for that text (Section 4.7 could probably be separate). 5) Section 5 and 6 present roughly the same information, and need to be combined. Currently, the table I sent was just added to the end of the old text (and some of the old text was plain wrong -- for example, the client cannot obviously take the SA value from the ticket). 6) Section 6: The word Unspecified is probably wrong here -- this document has to specify these (but clearly an implementation doesn't have to include in the ticket any data it never uses). 7) Section
Re: [IPsec] Transform IDs for AES-GMAC in IKEv1
Thanks for looking into this, Tero! I would propose we just allocate both AH transform identifier and Authentication Algorithm numbers for AH_AES_128/192/256_GMAC. This is what e.g. RFC 3566 did for XCBC-PRF. While in theory it could be nice to have more text explaining how this works, compared to the other ambiguous places in IKEv1 specs, this one looks something implementors would quite likely get right even without the additional explanation Best regards, Pasi -Original Message- From: ext Tero Kivinen [mailto:kivi...@iki.fi] Sent: 28 May, 2009 16:09 To: Eronen Pasi (Nokia-NRC/Helsinki) Cc: ipsec@ietf.org Subject: [IPsec] Transform IDs for AES-GMAC in IKEv1 pasi.ero...@nokia.com writes: RFC 4543 specifies how to use AES-GMAC mode in AH and ESP and how to negotiate them in IKEv1 and IKEv2 (see Section 5, 1st paragraph). However, as Soo-Fei Chew pointed out, the IANA considerations text in the final document didn't actually ask IANA to assign the numbers for IKEv1. Here's my proposal for fixing the situation: (1) ask IANA to assign the four missing numbers (after IESG approval). (2) submit an RFC Editor errata, saying something like this: The following text should have been included in Section 9: For the negotiation of AES-GMAC in AH with IKEv1, the following values have been assigned in the IPsec AH Transform Identifiers registry (in isakmp-registry). Note that IKEv1 and IKEv2 use different transform identifiers. TBD1 for AH_AES_128_GMAC TBD2 for AH_AES_192_GMAC TBD3 for AH_AES_256_GMAC For the negotiation of AES-GMAC in ESP with IKEv1, the following value has been assigned from the IPsec ESP Transform Identifiers registry (in isakmp-registry). Note that IKEv1 and IKEv2 use a different transform identifier. TBD4 for ESP_NULL_AUTH_AES_GMAC (where we will in TBD1..4 after we know the numbers) When I was checking out this thing more I found that we need to do even more for GMAC. The reason is that In IKEv1 the AH_* Transform Identifiers MUST include Authentication Algorithm attribute also. I.e. it is not enough to just set AH Transform Identifier to AH_AES_128_GMAC, but in addition to that the proposal MUST include Authentication Algorithm attribute with suitable value. Text from RFC2407: -- 4.4.3 IPSEC AH Transform Identifiers ... Note: the Authentication Algorithm attribute MUST be specified to identify the appropriate AH protection suite. For example, AH_MD5 can best be thought of as a generic AH transform using MD5. To request the HMAC construction with AH, one specifies the AH_MD5 transform ID along with the Authentication Algorithm attribute set to HMAC-MD5. This is shown using the Auth(HMAC-MD5) notation in the following sections. Transform IDValue - RESERVED0-1 AH_MD5 2 AH_SHA 3 AH_DES 4 ... 4.4.3.1 AH_MD5 ... All implementations within the IPSEC DOI MUST support AH_MD5 along with the Auth(HMAC-MD5) attribute. This suite is defined as the HMAC-MD5-96 transform described in [HMACMD5]. The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH transform (Key/Pad/Data/Key) described in RFC-1826. Use of AH_MD5 with any other Authentication Algorithm attribute value is currently undefined. 4.4.3.2 AH_SHA The AH_SHA type specifies a generic AH transform using SHA-1. The actual protection suite is determined in concert with an associated SA attribute list. A generic SHA transform is currently undefined. All implementations within the IPSEC DOI MUST support AH_SHA along with the Auth(HMAC-SHA) attribute. This suite is defined as the HMAC-SHA-1-96 transform described in [HMACSHA]. Use of AH_SHA with any other Authentication Algorithm attribute value is currently undefined. ... Authentication Algorithm RESERVED0 HMAC-MD51 HMAC-SHA2 DES-MAC 3 KPDK4 Values 5-61439 are reserved to IANA. Values 61440-65535 are for private use. There is no default value for Auth Algorithm, as it must be specified to correctly identify the applicable AH or ESP transform, except in the following case. When negotiating ESP without authentication, the Auth Algorithm attribute MUST NOT be included in the proposal. When negotiating ESP without confidentiality, the Auth Algorithm attribute MUST be
Re: [IPsec] Final comments for ikev2-redirect-10
Vijay Devarapalli wrote: In the redirect-during-IKE_AUTH cases, the only time the IKEv2 SA is not valid is when EAP is used and the redirect is done based on the unauthenticated ID. In all other cases, the IKEv2 SA is valid and should be torn down with an INFORMATIONAL exchange. IMHO, this is clear enough and is captured in the current draft. Well.. I'm a bit skeptical about it being clear to folks who didn't participate in writing this draft. And having these two cases is more complex than having just one (IKE_SA is not used for any more exchanges). What benefits does this additional complexity (both in spec and in implementation) get us? If nothing, let's just remove it Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Final comments for ikev2-redirect-10
wearing AD hat FYI: Tim will be the responsible AD for this draft (since I was listed as a co-author in an earlier version); he will hopefully do his AD evaluation soon (and might consider these as IETF Last Call comments). not wearing any hats There's one remaining issue that was changed due to WGLC comments, but the result isn't quite what it IMHO should be. When doing redirection during IKE_AUTH, in some situations the IKE_AUTH response with the REDIRECT is the last message between the client and gateway (and the IKE_SA is not used, and cannot be used, for any other exchanges after that). In other situations, it *is* used for (at least) one additional exchange (Informational exchange with DELETE payload). When the Informational exchange is needed/allowed and when not is not totally random, but I don't expect that any readers would understand it (I do know Tero can explain it :-). It also creates room for confusion whether the REDIRECT is just a hint and the IKE_SA could still be used for other exchanges, too. I would suggest we get rid of this unnecessary complexity, and simply say that when you do REDIRECT during IKE_AUTH, no more exchanges are done (on that IKE_SA) after the REDIRECT is sent. There's also one place that is probably correct, but would benefit from some clarification. Section 5 says: When the client receives this message, it MUST send an empty message as an acknowledgement. Until the client responds with an acknowledgement, the gateway SHOULD re-transmit the redirect INFORMATIONAL message as described in [2]. The MUST and SHOULD here give the impression that this Informational exchange is somehow special, and treated differently from ordinary Informational exchanges. As far as I can tell, it's *not* meant to be special, and this text isn't meant to specify any new requirements. I'd suggest rephrasing this something like As in any other INFORMATIONAL exchange, the clients sends a response (usually empty), and the gateway retransmits the request if it doesn't receive a response. BTW, in Section 10, expert review probably should be Expert Review as specified in [RFC5226]. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #107
Yoav Nir wrote: You can: a) start using hash-and-url b) hope your peer has the sub-CA c) write an extension to 4306 that allows bundles in CERT Doing (a) is the most interoperable, but you're probably save with (b) in a typical closed network. Or I can go with option (d) and send multiple CERT payloads, as Pasi suggested here: http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html (thanks, Yaron) Either way, we should have it clear what is and is not allowed in section 3.6. I thought this was already clear in RFC 4306, but apparently it's not as clear as it should be. Section 1.2 says ...might also send its certificate(s) in CERT payload(s)... -- so multiple CERT payloads are allowed -- but Section 3.6 is indeed a bit silent about this. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
not wearing any hats
1) The new versions since the previous WGLC introduced a number of
additional steps (e.g. nonce payload, clarifying PAD etc.) to the
redirection process, but currently these are spread over the whole
document, or in some cases, partly missing (e.g. the document never
says what the client should do with the nonce data in the REDIRECT
notification). IMHO these should be included in the overall flow in
Section 3. Proposed text:
3. IKEv2 Initial Exchange with Redirect
This section describes the use of Redirect mechanism during the
IKE_SA_INIT exchange. Gateway-initiated redirect and the use of
redirect during IKE_AUTH exchange are explained in subsequent
sections.
The VPN client indicates support for the IKEv2 redirect mechanism
and the willingness to be redirected by including a
REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT
request. If the IKE_SA_INIT request did not include the
REDIRECT_SUPPORTED notification, the responder MUST NOT use the
redirect mechanism specified in this document.
To redirect the IKEv2 session to another VPN gateway, the VPN
gateway that initially received the IKE_SA_INIT request selects
another VPN gateway (how the selection is made is beyond the scope
of this document), and replies with an IKE_SA_INIT response
containing a REDIRECT notification message. The notification
includes the address of the selected VPN gateway, and the nonce
data from the Ni payload in the IKE_SA_INIT request.
Note that when the IKE_SA_INIT response includes the REDIRECT
notification, the exchange does not result in the creation of an
IKE_SA, and the responder SPI will be zero.
InitiatorResponder (initial VPN GW)
--
(IP_I:500 - Initial_IP_R:500)
HDR(A,0), SAi1, KEi, Ni, --
N(REDIRECT_SUPPORTED)
(Initial_IP_R:500 - IP_I:500)
-- HDR(A,0), N(REDIRECT, IP_R, nonce data)
When the client receives the IKE_SA_INIT response, it MUST verify
that the nonce data matches the value sent in the IKE_SA_INIT
request. If the values do not match, the client MUST silently
discard the response (and keep waiting for another response). This
prevents certain Denial-of-Service attacks on the initiator that
could be caused by an attacker injecting IKE_SA_INIT responses with
REDIRECT payloads.
Next, the client initiates a new IKE_SA_INIT exchange to the
address included in the REDIRECT payload. The VPN client includes
the IP address of the original VPN gateway that redirected the
client in the REDIRECTED_FROM notification. The IKEv2 exchange then
proceeds as it would have proceeded with the original VPN gateway.
Initiator Responder (Selected VPN GW)
- ---
(IP_I:500 - IP_R:500)
HDR(A,0), SAi1, KEi, Ni, --
N(REDIRECTED_FROM, Initial_IP_R)
(IP_R:500 - IP_I:500)
-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ]
(IP_I:500 - IP_R:500)
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
[IDr,]AUTH, SAi2, TSi, TSr} --
(IP_R:500 - IP_I:500)
-- HDR(A,B), SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
In particular, the client MUST use the same Peer Authorization
Database (PAD) and Security Policy Database (SPD) entries as it
would have used with the original gateway. Receiving a redirect
notification MUST NOT result in the modification of any PAD or SPD
entries. In practise, this means the new gateway either has to
either use the same responder identity (IDr) as the original
gateway, or the PAD entry must use wildcards (such as
gw*.example.com) that match multiple responder identities.
2) As I already noted in my March 2 email, the document does not say
exactly what information outside IPsec (i.e. Mobile IPv6) is being
updated by the redirect, and the security implications if it.
Perhaps something like this, added to the end of Section 3:
When running IKEv2 between a Mobile IPv6 Mobile Node (MN) and Home
Agent (HA), redirecting the IKEv2 exchange to another HA is not
enough; the Mobile IPv6 signalling also needs to be sent to the new
HA address. The MN MAY treat the information received in the
IKE_SA_INIT response in similar way as it would treat HA discovery
information received from other unauthenticated (and potentially
untrustworthy) sources (such as DNS lookups not protected with
DNSSEC). However, if the MN has authenticated information about its
Home Agent, it MUST NOT be updated based on the IKE_SA_INIT
response.
If the REDIRECT notification is received during the IKE_AUTH
exchange (after the HA has been authenticated; see Section 6),
Re: [IPsec] Issue #36: Interaction of IKE_SA_INIT retransmissions with specific notifies
Yaron Sheffer wrote:
{{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require
some special handling. When a responder receives an IKE_SA_INIT
request, it has to determine whether the packet is retransmission
belonging to an existing 'half-open' IKE_SA (in which case the
responder retransmits the same response), or a new request (in which
case the responder creates a new IKE_SA and sends a fresh response),
or it belongs to an existing IKE_SA where the IKE_AUTH request has
been already received (in which case the responder ignores it).
Tero:
There is also the case of the invalid KE and cookie notifies, i.e. we
need to add comment about those too:
... or it belongs to an existing IKE_SA where the IKE_AUTH request
has been already received (in which case the responder ignores it),
or it is INVALID_KE_PAYLOAD or COOKIE notify responses to the
IKE_SA_INIT request.
Paul: Not done. This is interesting, but should be discussed on the list.
The current text is about processing of IKE_SA_INIT *requests* by
the responder, so talking about IKE_SA_INIT responses (such as
INVALID_KE_PAYLOAD) in the same sentence would be IMHO very confusing.
I'd suggest we keep this paragraph as is.
Best regards,
Pasi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #54: PFKEY: categorization
Yaron Sheffer wrote: Yaron: 2.9: I believe it is more appropriate to describe PFKEY as an API, rather than protocol. Paul: Not done, for the list. I agree that API would be clearer here. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #79: Remove CP from Create_Child_SA ?
Yaron Sheffer wrote: Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload. IMO the normal way of doing things is in this message 3, so rather than a parenthetical remark, it's really the only one anyone uses. I don't think it makes sense to assign a different IP address for each SA, and I don't think anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client needs to renew the address with the gateway (probably renew the lease with a DHCP server). With such an attribute, it made sense for the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked as RESERVED. Since we've done that, I suggest we remove the CP payload from the Create Child SA exchange in appendix A, and reword section 2.19 to reflect that requesting an IP address is only acceptable during IKE_AUTH. Including a CP payload in CREATE_CHILD_SA request doesn't mean the CP applies to that particular CHILD_SA (just like CP during IKE_AUTH doesn't apply to that CHILD_SA only). IMHO it's semantics should be exactly the same as first doing an INFORMATIONAL exchange with the CP, immediately followed by a CREATE_CHILD_SA exchange without the CP. So if we would remove CP from the CREATE_CHILD_SA exchange, we should also remove it from the INFORMATIONAL exhange. But we do have an example in Section 2.20 where CP is used in INFORMATIONAL exchange... But perhaps we could add text saying that many implementations will probably support INTERNAL_IP_ADDRESS only during IKE_AUTH, and are likely to refuse it in any other exchange? Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #43: Validity period of addresses obtained with config payload
Yaron Sheffer wrote: [Sec. 3.15.1:] Tero: The text 'The requested address is valid until there are no IKE_SAs between the peers.' is incorrect, it most likely should say 'The requested address is valid as long as this IKE SA (or its rekeyed successors) requesting the address is valid.' I.e. even if another IKE SA is created between the peers that does not keep the address allocated in another IKE SA alive, unless it is also allocated in that IKE SA. This is especially the case where let's say multi user hosts do per user IKE SAs and want to allocate IP addresses separately for each user. Paul: Not done. This should be discussed on the mailing list. I think Tero is right; the scope of configuration payloads is this IKE SA *and* its continuations via rekeying. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Reopening issue #12
Tero Kivinen wrote: Paul Hoffman writes: It was pointed out that (a) this is a new MUST and Yes, but it can mostly be already deducted from the requirement that end node cannot violate its own policy, meaning it needs to delete Child SA which are not following his policy. If that is already done, there is no point for the new SA having narrower scope than old SA had, and making this MUST makes it simplier for implementations (i.e. they do not need to think what to do for the traffic which do not fit the rekeyed SA, and we do not need to add the traffic selectors from the packet parts). (b) this also assumes that the encryption algorithm and so on will be the same. No it does not. I do not see any text there saying anything about encryption algorithms. Those are negotiated as normally and again if policy has been changed so that the original algorithms are not valid anymore, then the child SA should have been deleted already. Hmm... narrowing and algorithm negotiation can interact. Consider the following situation: Alice's SPD: traffic on UDP ports 1000-1999 MUST use ESP w/3DES or AES (AES preferred) Bob's SPD: traffic on UDP ports 1000-1499 MUST use ESP w/3DES or AES (3DES preferred) traffic on UDP ports 1500-1999 MUST use ESP w/AES The old SA (OK to both Alice and Bob): UDP ports 1000-1999, AES Now, suppose Alice sends a CREATE_CHILD_SA exchange for rekeying this SA, proposing algorithms AES and 3DES, and traffic selectors for UDP ports 1000-1999. Bob prefers 3DES, and picks that. But now Bob cannot meet the requirement new SA MUST NOT be narrower than the old one, because it would violate his policy. So, I think the current text in 2.9.2 *does* assume that encryption algorithm negotiation behaves differently when rekeying (and IMHO this requirement is not in RFC 4306). Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Ticket #9
Tero Kivinen wrote:
I am not sure we reached the decision yet, but I think more text is
needed if that is allowed, thus creating that text might help moving
things forward (i.e send replacement text).
Here's a first sketch:
Section 1.3.1:
OLD:
Failure of an attempt to create a CHILD SA SHOULD NOT tear down the
IKE SA: there is no reason to lose the work done to set up the IKE
SA. When an IKE SA is not created, the error message return SHOULD
NOT be encrypted because the other party will not be able to
authenticate that message. [[ Note: this text may be changed in the
future. ]]
NEW:
If creating the CHILD SA fails for any reason, the IKE SA stays
up.
(This section is about CREATE_CHILD_SA exchange, so the text about
IKE_SA creation failures is in wrong place)
Section 1.2:
OLD:
{{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange
fails for some reason, the IKE SA is still created as usual. The
list of responses in the IKE_AUTH exchange that do not prevent an IKE
SA from being set up include at least the following:
NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
NEW:
{{ Clarif-4.2 }} During the IKE_AUTH exchange, two kinds of
failures can happen.
If the failure is related to creating the Child SA, the IKE SA is
still created as usual. The list of responses in the IKE_AUTH
exchange that do not prevent an IKE SA from being set up include at
least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE,
SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and
FAILED_CP_REQUIRED. In this case, the error notification is
included in the last IKE_AUTH response, and the SA/TSi/TSr payloads
are omitted from this message.
If the failure is related to creating the IKE SA (for example,
AUTHENTICATION_FAILED), the IKE_SA is not created. Note that
although the IKE_AUTH messages are encrypted and integrity
protected, if the peer receiving this notification has not
authenticated the other end yet, the information needs to be
treated with caution.
Best regards,
Pasi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Vijay Devarapalli wrote: Right... but if the client does not have a PAD entry for gw2's IDr, then the IKE negotiation will fail. (I guess we're not considering updating the PAD based on REDIRECTs.) Thats exactly what I am suggesting. :) This would be similar to a Mobile IPv6 mobile node creating a PAD entry for the home agent that it discovers using IETF-standardized mechanisms. I don't think we should require a Mobile IPv6 mobile node or a VPN client or a 3GPP client that uses I-WLAN and discovers a PDG [*] to have PAD entries configured for all the home agents/gateways/PDGs that it might attach to before hand. Why not? As Tero already commented, this specification could simply assume that if the discovery mechanism creates a PAD entry, it can also create a wildcard PAD entry (that matches e.g. all gateways that have certificate issued by CA X). (* Apologies for using 3GPP terminology in the above. Pasi knows what I am talking about. If anyone wants to know more about this, please let me know. You might regret it later though. :) (BTW, note that having same IDr is not exactly the same thing as having same FQDN -- gw1.example.com and gw2.foobar.example are clearly distinct FQDNs from DNS-point-of-view, but they might or might not be distinct principals from IPsec PAD point of view.) If you put the FQDN in the PAD entry, you do have an issue, right? Well... the FQDN in the PAD entry can be a wildcard (but the FQDN sent in DNS query obvious can't). Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
