Hi Pasi, Thanks for the detailed review (again).
On 4/28/09 1:10 AM, "pasi.ero...@nokia.com" wrote: > 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: You are right. I guess I kept adding small amounts of text over multiple versions. Your rewrite of section 3 is fine with me. I made one change. > 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, Changed this to "... information about the selected VPN gateway", since you can send the FQDN of the new gateway instead of the IP address. But the original text already had this bug. > 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), the > MN MAY pass the new address to Mobile IPv6 and treat it in similar > fashion as information from the Home Agent Switch Message > [RFC5142]. > > Gateway-initiated REDIRECT notifications exchanged in INFORMATIONAL > exchanges (see Section 5) MUST NOT result in updating any Mobile > IPv6 state. In such cases, the Home Agent Switch Message specified > in [RFC5142] are used instead. > > (I haven't fully thought through all the details, so comments are > welcome...) I like the above text. Couldn't think of anything else that might have been missed. > And the security considerations text needs something, too. I added the following text... The redirect mechanism MUST NOT update any state on the client apart from the VPN gateway information. When used with Mobile IPv6, care must be taken to ensure that the home agent information that the mobile node has configured is not modified wrongly by the redirect message. > 3) Section 6, 1st paragraph: I think this text needs to be clearer > about whether an IKE_SA is created or not (current the SHOULDs > etc. make this somewhat unclear). IMHO if the client will always just > close the IKE_SA, it doesn't make much sense to create it in the first > place? But it looks like the intent of the current text might have > been that the IKE_SA *is* created... If that's the case, then the > message diagram below this paragraph should also show the > INFORMATIONAL exchange with Delete payload. The current text assumes that the IKE SA is created and needs to be deleted. I don't think we need to show the INFORMATIONAL exchange. We are not modifying anything in the delete procedure. We currently have the following text When the client receives the IKE_AUTH response with the REDIRECT payload, it SHOULD delete the existing IKEv2 security association with the gateway. Isn't this sufficient? > 4) Section 6, last paragraph: > >> In such cases, the gateway should send the REDIRECT notification >> payload in the final IKE_AUTH response message that carries the AUTH >> payload and the traffic selectors. The gateway MUST NOT send and >> the client MUST NOT accept a redirect in an earlier IKE_AUTH >> message. > > This is a bit confusing, since the first sentence says "should", and > in this particular case, the final IKE_AUTH response does not > actually have the traffic selectors! Also, if the intent was to allow > redirect in the 1st IKE_AUTH response, this text doesn't do it. > Perhaps something like this? > > In such cases, the gateway can include the REDIRECT notification > either in the first IKE_AUTH response, or the last IKE_AUTH > response. The gateway MUST NOT send, and the client MUST NOT > accept, the REDIRECT notification in any other IKE_AUTH response. The gateway can always include the REDRIECT notification in the first IKE_AUTH response. The text that you quoted follows the text that says the redirect decision may be done based on the interaction with the AAA server or an external authentication server. But Yoav also had a comment on the same paragraph. This means it is not clear. So I am fine with adopting your text above. > 5) Section 9, last paragraph, is a bit confusing (even if the redirect > message was always authenticated, we still wouldn't want to modify the > PAD based on it), and in the wrong place (it's important part of the > protocol, not just a security consideration). The proposed text for > Section 3 included the essential parts, I think. Ok, removed the last paragraph in section 9. Vijay > > Best regards, > Pasi > >> -----Original Message----- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of ext Yaron Sheffer >> Sent: 16 April, 2009 10:38 >> To: IPsecme WG >> Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 >> >> This is a 2 week working group last call for >> draft-ietf-ipsecme-ikev2-redirect-08. The target status for this >> document is >> Proposed Standard. This is the document's second last call, following >> comments by a number of people and several document revisions. >> >> Please send your comments to the ipsec list by April 30, 2009, as >> follow-ups >> to this message. >> >> Please clearly indicate the position of any issue in the Internet >> Draft, and >> if possible provide alternative text. Please also indicate the nature >> or >> severity of the error or correction, e.g. major technical, minor >> technical, >> nit, so that we can quickly judge the extent of problems with the >> document. >> >> The document can be accessed here: >> http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-08. >> >> Thanks, >> Yaron > _______________________________________________ > 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
