Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
This is a reminder that we are having a last call for the Redirect document. Even if you support advancing this document, but have no other comments, please state your opinion on the list. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Yaron Sheffer > Sent: Monday, February 16, 2009 11:46 > To: IPsecme WG > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > > This is a 2 week working group last call for draft-ietf-ipsecme-ikev2- > redirect-04. The target status for this document is Proposed Standard. > > Please send your comments to the ipsec list by March 2, 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-04. > > Please note that one issue is currently open against this draft: > http://tools.ietf.org/wg/ipsecme/trac/ticket/82. > > Thanks, > Yaron > > Email secured by Check Point > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
I support advancing this. I preferred allowing the redirect in IKE_AUTH as well, but it seems like the group consensus went against that. One textual comment: since we have section 7 describing a symmetric case (redirect by either peer), section 6.1 should be chagned to reflect that the REDIRECT_SUPPORTED may be in either or both of the request and reply of the Initial exchange, and perhaps a picture can be added to section 7. Even without this, the text is clear and useful. > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of Yaron Sheffer > Sent: Wednesday, February 25, 2009 2:34 PM > To: IPsecme WG > Subject: Re: [IPsec] WG Last Call: > draft-ietf-ipsecme-ikev2-redirect-04 > > This is a reminder that we are having a last call for the > Redirect document. Even if you support advancing this > document, but have no other comments, please state your > opinion on the list. > > Thanks, > Yaron > > > -Original Message- > > From: ipsec-boun...@ietf.org > [mailto:ipsec-boun...@ietf.org] On Behalf > > Of Yaron Sheffer > > Sent: Monday, February 16, 2009 11:46 > > To: IPsecme WG > > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > > > > This is a 2 week working group last call for > draft-ietf-ipsecme-ikev2- > > redirect-04. The target status for this document is > Proposed Standard. > > > > Please send your comments to the ipsec list by March 2, 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-04. > > > > Please note that one issue is currently open against this draft: > > http://tools.ietf.org/wg/ipsecme/trac/ticket/82. > > > > Thanks, > > Yaron > > > > Email secured by Check Point > > ___ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. > > > > Scanned by Check Point Total Security Gateway. > > Email secured by Check Point > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. > Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Hi, I am ok with moving this draft forward. However, I strongly prefer allowing redirection in the IKE_AUTH as well. As you may know, last week on the 3GPP SA2 meeting, the SA2 working group adopted the solution that uses the IKEv2 signaling message for gateway redirection/reallocation when the mobile terminal performs attach. Sincerely, fan On Wed, Feb 25, 2009 at 5:02 AM, Yoav Nir wrote: > I support advancing this. > > I preferred allowing the redirect in IKE_AUTH as well, but it seems like the > group consensus went against that. > > One textual comment: since we have section 7 describing a symmetric case > (redirect by either peer), section 6.1 should be chagned to reflect that the > REDIRECT_SUPPORTED may be in either or both of the request and reply of the > Initial exchange, and perhaps a picture can be added to section 7. > > Even without this, the text is clear and useful. > >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] >> On Behalf Of Yaron Sheffer >> Sent: Wednesday, February 25, 2009 2:34 PM >> To: IPsecme WG >> Subject: Re: [IPsec] WG Last Call: >> draft-ietf-ipsecme-ikev2-redirect-04 >> >> This is a reminder that we are having a last call for the >> Redirect document. Even if you support advancing this >> document, but have no other comments, please state your >> opinion on the list. >> >> Thanks, >> Yaron >> >> > -Original Message- >> > From: ipsec-boun...@ietf.org >> [mailto:ipsec-boun...@ietf.org] On Behalf >> > Of Yaron Sheffer >> > Sent: Monday, February 16, 2009 11:46 >> > To: IPsecme WG >> > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >> > >> > This is a 2 week working group last call for >> draft-ietf-ipsecme-ikev2- >> > redirect-04. The target status for this document is >> Proposed Standard. >> > >> > Please send your comments to the ipsec list by March 2, 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-04. >> > >> > Please note that one issue is currently open against this draft: >> > http://tools.ietf.org/wg/ipsecme/trac/ticket/82. >> > >> > Thanks, >> > Yaron >> > >> > Email secured by Check Point >> > ___ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> > Scanned by Check Point Total Security Gateway. >> > >> > Scanned by Check Point Total Security Gateway. >> >> Email secured by Check Point >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> >> Scanned by Check Point Total Security Gateway. >> > Email secured by Check Point > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
I join Yoav and Fan in supporting this draft, even in its current form. However I also agree with them that the protocol will be cleaner (and subsequently, implementations will be simpler), if we allow redirection in IKE_AUTH, specifically only in the last message of the exchange. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > fan zhao > Sent: Thursday, February 26, 2009 3:58 > To: Yoav Nir > Cc: IPsecme WG > Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > > Hi, > > I am ok with moving this draft forward. However, I strongly prefer > allowing > redirection in the IKE_AUTH as well. As you may know, last week > on the 3GPP SA2 meeting, the SA2 working group adopted the solution > that uses the IKEv2 signaling message for gateway redirection/reallocation > when the mobile terminal performs attach. > > Sincerely, > fan > > > > On Wed, Feb 25, 2009 at 5:02 AM, Yoav Nir wrote: > > I support advancing this. > > > > I preferred allowing the redirect in IKE_AUTH as well, but it seems like > the group consensus went against that. > > > > One textual comment: since we have section 7 describing a symmetric case > (redirect by either peer), section 6.1 should be chagned to reflect that > the REDIRECT_SUPPORTED may be in either or both of the request and reply > of the Initial exchange, and perhaps a picture can be added to section 7. > > > > Even without this, the text is clear and useful. > > > >> -Original Message- > >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > >> On Behalf Of Yaron Sheffer > >> Sent: Wednesday, February 25, 2009 2:34 PM > >> To: IPsecme WG > >> Subject: Re: [IPsec] WG Last Call: > >> draft-ietf-ipsecme-ikev2-redirect-04 > >> > >> This is a reminder that we are having a last call for the > >> Redirect document. Even if you support advancing this > >> document, but have no other comments, please state your > >> opinion on the list. > >> > >> Thanks, > >> Yaron > >> > >> > -Original Message- > >> > From: ipsec-boun...@ietf.org > >> [mailto:ipsec-boun...@ietf.org] On Behalf > >> > Of Yaron Sheffer > >> > Sent: Monday, February 16, 2009 11:46 > >> > To: IPsecme WG > >> > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > >> > > >> > This is a 2 week working group last call for > >> draft-ietf-ipsecme-ikev2- > >> > redirect-04. The target status for this document is > >> Proposed Standard. > >> > > >> > Please send your comments to the ipsec list by March 2, 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-04. > >> > > >> > Please note that one issue is currently open against this draft: > >> > http://tools.ietf.org/wg/ipsecme/trac/ticket/82. > >> > > >> > Thanks, > >> > Yaron > >> > > >> > Email secured by Check Point > >> > ___ > >> > IPsec mailing list > >> > IPsec@ietf.org > >> > https://www.ietf.org/mailman/listinfo/ipsec > >> > > >> > Scanned by Check Point Total Security Gateway. > >> > > >> > Scanned by Check Point Total Security Gateway. > >> > >> Email secured by Check Point > >> ___ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > >> Scanned by Check Point Total Security Gateway. > >> > >> Scanned by Check Point Total Security Gateway. > >> > > 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 > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
I have one somewhat substantial concern with the document: it needs to be much clearer about what information is updated by the received REDIRECT messages, and what is not. While selecting the right peer when a new ESP/AH SA needs to be created is not specified in RFC 4301 (see RFC 4555 Appendix A.2 for some discussion), PAD definitely is in scope, and redirect could interact with PAD in multiple ways. For example, suppose the client decides that the right peer for the ESP/AH SA is gw1.example.com. If after doing a DNS lookup and contacting gw1.example.com it receives IDr/CERT payloads for gw2.foobar.example, the client would report error and abort (at least unless "the right peer for the SA" is actually a set of possible peers, and gw2 happens to be in that set). Now, suppose contacting gw1.example.com results in REDIRECT to gw2.foobar.example (GW Identity Type=FQDN). When the client contacts gw2, and receives IDr/CERT for gw2.foobar.example, does it accept it? One possible answer would be that REDIRECT is interpreted just as data received from DNS, so all the gateways (redirecting among each other) would send same IDr value. Another possible answer would be that if gw2.foobar.example is already in client's local "set of right peers for this SA", then it would be accepted (and the client would have accepted IDr/CERT with gw2.foobar.example also in the beginning, before it got the redirect), otherwise not. (And the client will also accept IDr/CERT gw1.example.com even after the redirect, when contacting gw2 ---that would be the sensible behavior if the redirect was with GW Identity Type=IPv4/6.) (Other answers than these two might be possible, too -- I have not explored this in detail.) Now, it's quite obvious the intent was to do redirect securely, but we need to spell out what the correct behavior is: do all the gateways have a single identity (IDr), or do they have distinct PAD entries? (In the latter case, IKE_SA creation (with or without redirects) succeeds only if the IDr has an entry in the PAD, and the peer is successfully authenticated as required by the PAD. If the client accepts IDr/CERT gw2.foobar.example, it would have also accepted it in the first place (when trying to contact the IP address found by doing DNS lookup for gw1.example.com, before it got any redirects). However, in general there's no guarantee that the CHILD_SA authorization data for the PAD entries "gw1.example.com" and "gw2.foobar.example" is exactly the same, so although setting up the IKE_SA succeeds, creating CHILD_SA with the intended selectors might not -- so by sending a redirect, the gateway really assumes that the client has identical CHILD_SA authorization data for the target.) The situation gets tricker when we consider Mobile IPv6, though, because we're also updating some data outside IPsec. What exactly is being updated by the received REDIRECT, and is this secure? Also, the SPD entries in RFC 4877 contain the HA address -- are we updating SPD entries based on unauthenticated REDIRECT? It seems some of this problem is already present in current MIP6 bootstrapping documents (if we e.g. discover Home Agent IPv6 address by DNS query, somehow the SPD entries must get there, based on usually unauthenticated DNS response), and it's possible we could refer to that work. But "treat REDIRECT just as it would have come from DNS" is not without security issues, since MN might not use DNS to get the HA address (we could be overwriting manually configured data known to be secure), the DNS reply could have been protected by DNSSEC, or the attacker might be on MN<->GW1 path (and can spoof redirects) but not on MN/DNS server paths (so can't spoof the DNS reply). Minor clarifications and nits: - Section 4 says "If an anycast address is returned in response to DNS resolution of an FQDN, the IKEv2 transaction between the VPN client and the VPN gateway is slightly modified." It seems the transaction is actually *not* modified at all -- it's exactly identical to the unicast case (and VPN client can't tell which case occurred)? - Section 5: I don't think treating REDIRECT+"sufficient time period" as implicit delete is a good idea. RFC 4306 requires sending delete payloads whenever possible, and if the VPN GW wants to close the IKE_SA, it could include the Delete payload in the same message as the REDIRECT notification... - Section 6.1/6.2/6.3: should say that Protocol ID is set to zero. - Section 6.2 says this message is included in IKE_SA_INIT response; also INFORMATIONAL request, right? - Section 7: I'm a bit skeptical if this actually works. The rest of the document certainly does not describe how it would work, and in many places, assumes the client-gateway case (e.g. Section 6.1 says REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the responder can't actually tell the initiator it supports this feature, etc.) Also, the "what is actually updated by REDIRECT and what is not" may get even mor
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Pasi, I agree with your observations/concerns. Any host/SG to which one is redirected needs to be subject to the same controls as an initial SA target. I see this as a PAD (and SPD) issue. I would suggest that maybe the only safe approach is to reevaluate the redirected target against the PAD entry for the initial target. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Hi, The last call was completed. There were two major issues and some additional comments, as well as one outstanding open issue. 1. Redirect during IKE_AUTH: this was reopened, several people expressed unease with the solution as stated in -04. 2. Interaction of Redirect with IPsec authorization (the PAD), this is definitely important, and requires a clarification. Re: #1, I suggest that the authors review this issue in view of the opinions expressed on the list, and post their decision to the list. Re: #2, the authors are requested to post new text on the list for discussion. As soon as these issues are resolved, I would like to start a new LC, based on version -05 of the draft. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
pasi.ero...@nokia.com writes: > I have one somewhat substantial concern with the document: it needs to > be much clearer about what information is updated by the received > REDIRECT messages, and what is not. Never really thought that issue. I myself assumed that both GWs are identical, i.e. they return same ID, and use same authentication data (i.e. if PSK, both use same PSK, if certs, both authenticate against same trust anchor and use same identity in cert, but not necessarely same private key). > One possible answer would be that REDIRECT is interpreted just as data > received from DNS, so all the gateways (redirecting among each other) > would send same IDr value. I think this is the easiest way to make sure redirect is secure. > - Section 5: I don't think treating REDIRECT+"sufficient time period" > as implicit delete is a good idea. RFC 4306 requires sending delete > payloads whenever possible, and if the VPN GW wants to close the > IKE_SA, it could include the Delete payload in the same message as the > REDIRECT notification... I think it said that it can delete it without client sending any packets, but that delete is not implicit, it is explicit, and gateway will then send delete payload to delete the IKE SA. The sufficient time is used when the client has been talking to the gateway for longer already, and has multiple IPsec SAs up and in use. Then when gateway decides to redirect client somewhere else it sends N(REDIRECT) and client acks that. After that client starts recreating existing IKE SA and Child SAs with the new gateway, and after finishing that the client will delete the IKE SA with delete payload. If server runs out of resources before that it can send delete payload even before client finishes its redirection process but as that causes disruption of the flow of packets (if client didn't have time to set up new Child SAs), server should allow some time for that. I agree that the text could be written in more clear way, i.e. explictly say that the "delete the securition association" does mean the normal IKEv2 way, i.e. sending delete payload. > - Section 7: I'm a bit skeptical if this actually works. The rest of > the document certainly does not describe how it would work, and in > many places, assumes the client-gateway case (e.g. Section 6.1 says > REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the > responder can't actually tell the initiator it supports this feature, > etc.) Also, the "what is actually updated by REDIRECT and what is not" > may get even more complex in peer-to-peer case. My personal > preference would be to restrict the scope to client-gateway unless > someone really has the energy needed to specify how the peer-to-peer > case works in detail. Also the current text says "the responder MUST NOT respond to re-direct message from the initiator, if it has already decided to re-direct the initiator." and that is impossible with IKEv2. If node receives some request, it must reply with response, it cannot leave that response out, as if he does that then the IKE SA will be teared down when the other end times out the exchange. I think the original idea was that even when we talk about VPN client and gateway, this could be used as building block for other things too, and even this document uses terms like "VPN client" and "VPN gateway", this could also be used even when the IKE peers are not VPN client/gateway. This includes cases where for example SIP/MobileIP client connects to SIP/MobileIP server using IPsec. I do not think this can be used as generic gateway to gateway redirection mechinism (MOBIKE can be used for that too). I.e. I would simply change the section 7. to contain: -- 7. Use of the Redirect Mechanism between IKEv2 Peers The Re-direct mechanism described in this document is mainly intended for use in client-gateway scenarios. However, the mechanism can also be used between any two IKEv2 peers, but this protocol is asymmetric, meaning that only the responder can redirect initiator to some other server. -- And leave everything else out, including changing the protocol so it can be used in both directions. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
At 5:30 PM +0200 3/3/09, Tero Kivinen wrote: >pasi.ero...@nokia.com writes: >> I have one somewhat substantial concern with the document: it needs to >> be much clearer about what information is updated by the received >> REDIRECT messages, and what is not. > >Never really thought that issue. I myself assumed that both GWs are >identical, i.e. they return same ID, and use same authentication data >(i.e. if PSK, both use same PSK, if certs, both authenticate against >same trust anchor and use same identity in cert, but not necessarely >same private key). I think both views are reasonable, but the document must be much clearer about which is being discussed. If it is the former, the doc should also explicitly say that the latter is an acceptable setup. > > One possible answer would be that REDIRECT is interpreted just as data >> received from DNS, so all the gateways (redirecting among each other) >> would send same IDr value. > >I think this is the easiest way to make sure redirect is secure. I initially didn't agree with this idea, but I can see how it would make the security properties much easier to define. However, I don't think that was the intention of the current document. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Hi Pasi, Responding to the minor comments first... On Mon, Mar 2, 2009 at 12:04 PM, wrote: > Minor clarifications and nits: > > - Section 4 says "If an anycast address is returned in response to DNS > resolution of an FQDN, the IKEv2 transaction between the VPN client > and the VPN gateway is slightly modified." It seems the transaction is > actually *not* modified at all -- it's exactly identical to the > unicast case (and VPN client can't tell which case occurred)? Fixed this. What I wanted to say was that the IKE_SA_INIT might get routed to a different VPN gateway that is part of the anycast group. The client is of course not aware of this. > - Section 5: I don't think treating REDIRECT+"sufficient time period" > as implicit delete is a good idea. RFC 4306 requires sending delete > payloads whenever possible, and if the VPN GW wants to close the > IKE_SA, it could include the Delete payload in the same message as the > REDIRECT notification... The draft currently requires the client to delete the SA once it receives the REDIRECT message from the gateway. I do not want the gateway to delete the SA right away. The gateway should allow the client to setup the necessary security associations with the new gateway before deleting the SA with the existing gateway, if that is what the client wants to do. The current text is to handle the case where for some reason the gateway does not receive the DELETE payload from the client. Note that this shouldn't happen normally. The gateway garbage collects the SA after a certain time period. I don't think the gateway needs to send a DELETE payload at this point. > - Section 6.1/6.2/6.3: should say that Protocol ID is set to zero. Fixed. > - Section 6.2 says this message is included in IKE_SA_INIT response; > also INFORMATIONAL request, right? Thanks for catching. This is from the initial versions where the REDIRECT was only happening during the IKE_SA_INIT exchange. Fixed this. > - Section 7: I'm a bit skeptical if this actually works. The rest of > the document certainly does not describe how it would work, and in > many places, assumes the client-gateway case (e.g. Section 6.1 says > REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the > responder can't actually tell the initiator it supports this feature, > etc.) I am fine with restricting the scope as Tero suggested. My interest has always been in client-gateway scenarios anyway. I am cc'ing Rich Graveman who wanted this feature. Rich? Vijay ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Hi, I have a slight preference to keeping the protocol symmetric. But even if we choose not to do that, I think Tero's text (quoted below) leaves too much room for interpretation. --- 7. Use of the Redirect Mechanism between IKEv2 Peers The Re-direct mechanism described in this document is mainly intended for use in client-gateway scenarios. However, the mechanism can also be used between any two IKEv2 peers, but this protocol is asymmetric, meaning that only the responder can redirect initiator to some other server. --- The protocol supports using an Informational exchange for redirect at any time during the SA lifetime, and this is inherently symmetric. And of course, following an IKE SA rekey, the initiator/responder roles might change. If we go for the restricted option, the new text should cover both of these issues. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Friday, March 06, 2009 3:26 > To: pasi.ero...@nokia.com > Cc: ipsec@ietf.org; rfgrave...@gmail.com > Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > > Hi Pasi, > [snip] > > > - Section 7: I'm a bit skeptical if this actually works. The rest of > > the document certainly does not describe how it would work, and in > > many places, assumes the client-gateway case (e.g. Section 6.1 says > > REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the > > responder can't actually tell the initiator it supports this feature, > > etc.) > > I am fine with restricting the scope as Tero suggested. My interest > has always been in client-gateway scenarios anyway. I am cc'ing Rich > Graveman who wanted this feature. Rich? > > Vijay > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. ___ 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 writes: > The draft currently requires the client to delete the SA once it > receives the REDIRECT message from the gateway. I do not want the > gateway to delete the SA right away. The gateway should allow the > client to setup the necessary security associations with the new > gateway before deleting the SA with the existing gateway, if that is > what the client wants to do. The current text is to handle the case > where for some reason the gateway does not receive the DELETE payload > from the client. Note that this shouldn't happen normally. The gateway > garbage collects the SA after a certain time period. I don't think the > gateway needs to send a DELETE payload at this point. I disagree with that. If gateway decides to delete the IKE SA, it needs to send DELETE payload in that case. The only case where you do not send DELETE payload is when you delete the IKE SA because some exchange over the IKE SA timed out (i.e. other end didn't respond). In that timeout case there is no point of sending DELETE payload, as most likely that will not reach the other end any better than the original exchange, thus it will also timeout. In this redirect case the client might just be slow, or it might be that the gateway where client was redirected to does not respond, and client does not delete the old IKE SA before it gets new one up and running. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Yaron Sheffer writes: > I have a slight preference to keeping the protocol symmetric. But > even if we choose not to do that, I think Tero's text (quoted below) > leaves too much room for interpretation. Redirect is not really symmetric ever. If it would be used in symmetric way, then each end would simply create the connection using the address they want whenever they want. I.e. if server wanted to redirect client to somewhere else later, it would simply inform that new gateway to make connection to the client and close the local connection. That new gateway would then simply initiate new connection to the client and move traffic to there. The reason we cannot do that is that client-server connections are very often asymmetric, i.e. we are using EAP, or client is behind NAT or similar problems. > 7. Use of the Redirect Mechanism between IKEv2 Peers > >The Re-direct mechanism described in this document is mainly intended >for use in client-gateway scenarios. However, the mechanism can also >be used between any two IKEv2 peers, but this protocol is >asymmetric, meaning that only the responder can redirect initiator >to some other server. > --- > > The protocol supports using an Informational exchange for redirect > at any time during the SA lifetime, and this is inherently > symmetric. No, it does not make it symmetric. If the original initiator wants to use other local address when connecting, he will simply switch to that new address and initiate new connection. Original responder cannot do that, as most likely the connection using new address does not work because of NATs or because of asymmetric authentication type used (EAP). > And of course, following an IKE SA rekey, the > initiator/responder roles might change. If we go for the restricted > option, the new text should cover both of these issues. I should have used "original responder" and "original initiator". -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Hi Tero, We are thinking of different use cases. You are thinking VPN client - VPN server (and similar client/server cases). I agree that client-side redirect is useless in this case. MOBIKE takes care very well of the multihomed case (one address on WLAN, another on GPRS). So I don't care if the current draft doesn't work for that case. I am thinking of symmetric IKE peers (gateways, or endpoints using transport mode ESP; no EAP, rarely any NAT). Is there any reason why the current draft cannot support this case in a symmetric manner? Thanks, Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Friday, March 06, 2009 15:52 > To: Yaron Sheffer > Cc: Vijay Devarapalli; pasi.ero...@nokia.com; ipsec@ietf.org; > rfgrave...@gmail.com > Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > > Yaron Sheffer writes: > > I have a slight preference to keeping the protocol symmetric. But > > even if we choose not to do that, I think Tero's text (quoted below) > > leaves too much room for interpretation. > > Redirect is not really symmetric ever. If it would be used in > symmetric way, then each end would simply create the connection using > the address they want whenever they want. I.e. if server wanted to > redirect client to somewhere else later, it would simply inform that > new gateway to make connection to the client and close the local > connection. That new gateway would then simply initiate new connection > to the client and move traffic to there. > > The reason we cannot do that is that client-server connections are > very often asymmetric, i.e. we are using EAP, or client is behind NAT > or similar problems. > > > 7. Use of the Redirect Mechanism between IKEv2 Peers > > > >The Re-direct mechanism described in this document is mainly intended > >for use in client-gateway scenarios. However, the mechanism can also > >be used between any two IKEv2 peers, but this protocol is > >asymmetric, meaning that only the responder can redirect initiator > >to some other server. > > --- > > > > The protocol supports using an Informational exchange for redirect > > at any time during the SA lifetime, and this is inherently > > symmetric. > > No, it does not make it symmetric. If the original initiator wants to > use other local address when connecting, he will simply switch to that > new address and initiate new connection. Original responder cannot do > that, as most likely the connection using new address does not work > because of NATs or because of asymmetric authentication type used > (EAP). > > > And of course, following an IKE SA rekey, the > > initiator/responder roles might change. If we go for the restricted > > option, the new text should cover both of these issues. > > I should have used "original responder" and "original initiator". > -- > kivi...@iki.fi > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Tero Kivinen wrote: Vijay Devarapalli writes: The draft currently requires the client to delete the SA once it receives the REDIRECT message from the gateway. I do not want the gateway to delete the SA right away. The gateway should allow the client to setup the necessary security associations with the new gateway before deleting the SA with the existing gateway, if that is what the client wants to do. The current text is to handle the case where for some reason the gateway does not receive the DELETE payload from the client. Note that this shouldn't happen normally. The gateway garbage collects the SA after a certain time period. I don't think the gateway needs to send a DELETE payload at this point. I disagree with that. If gateway decides to delete the IKE SA, it needs to send DELETE payload in that case. The only case where you do not send DELETE payload is when you delete the IKE SA because some exchange over the IKE SA timed out (i.e. other end didn't respond). In that timeout case there is no point of sending DELETE payload, as most likely that will not reach the other end any better than the original exchange, thus it will also timeout. In this redirect case the client might just be slow, or it might be that the gateway where client was redirected to does not respond, and client does not delete the old IKE SA before it gets new one up and running. The timeout on the gateway can be quite large. The gateway should give sufficient time for the client to delete the SA. If the client does not for some reason, (note that the client is required to delete the SA), the SAs are just removed. The gateway has already sent a REDIRECT message to the client. Sending yet another INFORMATIONAL message with the DELETE payload after a certain time period, is just an overhead, IMHO. Vijay ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Hi Vijay, I'd rather be consistent with IKE, i.e. send an explicit DELETE. I suggest to change the -04 text: Once the client sends an acknowledgement to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE payload. The gateway MAY also decide to delete the security associations without any signaling from the client. To: Once the client sends an acknowledgement to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE payload. The gateway MAY also decide to delete the security associations without any signaling from the client, again by sending an Informational message with a DELETE payload. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Saturday, March 07, 2009 1:23 > To: Tero Kivinen > Cc: ipsec@ietf.org; pasi.ero...@nokia.com; rfgrave...@gmail.com; Vijay > Devarapalli > Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > > Tero Kivinen wrote: > > Vijay Devarapalli writes: > >> The draft currently requires the client to delete the SA once it > >> receives the REDIRECT message from the gateway. I do not want the > >> gateway to delete the SA right away. The gateway should allow the > >> client to setup the necessary security associations with the new > >> gateway before deleting the SA with the existing gateway, if that is > >> what the client wants to do. The current text is to handle the case > >> where for some reason the gateway does not receive the DELETE payload > >> from the client. Note that this shouldn't happen normally. The gateway > >> garbage collects the SA after a certain time period. I don't think the > >> gateway needs to send a DELETE payload at this point. > > > > I disagree with that. If gateway decides to delete the IKE SA, it > > needs to send DELETE payload in that case. The only case where you do > > not send DELETE payload is when you delete the IKE SA because some > > exchange over the IKE SA timed out (i.e. other end didn't respond). In > > that timeout case there is no point of sending DELETE payload, as most > > likely that will not reach the other end any better than the original > > exchange, thus it will also timeout. > > > > In this redirect case the client might just be slow, or it might be > > that the gateway where client was redirected to does not respond, and > > client does not delete the old IKE SA before it gets new one up and > > running. > > The timeout on the gateway can be quite large. The gateway should give > sufficient time for the client to delete the SA. If the client does not > for some reason, (note that the client is required to delete the SA), > the SAs are just removed. The gateway has already sent a REDIRECT > message to the client. Sending yet another INFORMATIONAL message with > the DELETE payload after a certain time period, is just an overhead, IMHO. > > Vijay > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Yaron Sheffer writes: > I am thinking of symmetric IKE peers (gateways, or endpoints using > transport mode ESP; no EAP, rarely any NAT). Is there any reason why > the current draft cannot support this case in a symmetric manner? Why do you need any protocol for that. Why does not normal IKEv2 be enough for that. I.e. if node A wants the node B to move to use some other location, it can simply connect to node B using that new location, and remove the old IKE SA. I.e. if scenario is really symmetric, there is no need to have any IKEv2 redirect protocol at all, everything can be done by the node by directly connecting using new location. It is quite hard to explain this thing as I have no idea what kind of scenario you are talking about. Can you give real example, what the nodes are and why do they want to redirect other end. MOBIKE is not restricted to the VPN client <-> VPN server situation, but is limited that node must stay same. I.e. it is moving between multiple addresses of node A and moving between multiple address of node B. It cannot ask node B to move from node A to node C. But if node A wants node B to use node C instead of node A, it can simply inform node C to make connection to B and delete its own IKE SA. It can also do this by just changing the back end routing or similar, so that return packets go to node C instead of node A and then node C will initiate connection to node B immediately when first packet arrives (if the situation is really symmetric). If we are talking about client and server situations where server wants to redirect client to some other server, then situation is no longer symmetric. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Yaron Sheffer wrote: Hi Vijay, I'd rather be consistent with IKE, i.e. send an explicit DELETE. Ok, I made this change, since there seems to be consensus for an explicit message when the gateway decides to remove the SA. Vijay I suggest to change the -04 text: Once the client sends an acknowledgement to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE payload. The gateway MAY also decide to delete the security associations without any signaling from the client. To: Once the client sends an acknowledgement to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE payload. The gateway MAY also decide to delete the security associations without any signaling from the client, again by sending an Informational message with a DELETE payload. Thanks, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Vijay Devarapalli Sent: Saturday, March 07, 2009 1:23 To: Tero Kivinen Cc: ipsec@ietf.org; pasi.ero...@nokia.com; rfgrave...@gmail.com; Vijay Devarapalli Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Tero Kivinen wrote: Vijay Devarapalli writes: The draft currently requires the client to delete the SA once it receives the REDIRECT message from the gateway. I do not want the gateway to delete the SA right away. The gateway should allow the client to setup the necessary security associations with the new gateway before deleting the SA with the existing gateway, if that is what the client wants to do. The current text is to handle the case where for some reason the gateway does not receive the DELETE payload from the client. Note that this shouldn't happen normally. The gateway garbage collects the SA after a certain time period. I don't think the gateway needs to send a DELETE payload at this point. I disagree with that. If gateway decides to delete the IKE SA, it needs to send DELETE payload in that case. The only case where you do not send DELETE payload is when you delete the IKE SA because some exchange over the IKE SA timed out (i.e. other end didn't respond). In that timeout case there is no point of sending DELETE payload, as most likely that will not reach the other end any better than the original exchange, thus it will also timeout. In this redirect case the client might just be slow, or it might be that the gateway where client was redirected to does not respond, and client does not delete the old IKE SA before it gets new one up and running. The timeout on the gateway can be quite large. The gateway should give sufficient time for the client to delete the SA. If the client does not for some reason, (note that the client is required to delete the SA), the SAs are just removed. The gateway has already sent a REDIRECT message to the client. Sending yet another INFORMATIONAL message with the DELETE payload after a certain time period, is just an overhead, IMHO. Vijay ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Hi Pasi, I spent about three days thinking about this, but still couldn't conclude on anything. I am cc'ing Jari, since I thought he would interested in this topic and have some comments. As you observed, Mobile IPv6 does allows the mobile node to discover a Home Agent dynamically (See RFC 5026, RFC 4877 and draft-ietf-mip6-bootstrapping-integrated-dhc) and then create the corresponding PAD and SPD entries. We obviously do not convey what sort of authentication mechanism should be used with the gateway. It is assumed that the mobile node knows which authentication mechanism to use (based on the deployment) and store this information in the newly created PAD entry. The use of DNS and DHCPv6 is allowed for discovering a home agent's address/FQDN. The discovery mechanisms based on DNS and DHCPv6 can be secured, but the secure form of these mechanisms might not be used always. So it is possible that you do end up with an insecure discovery mechanism creating new PAD and SPD entries on the mobile node. I never considered this a big deal, since the mobile node does authenticate the newly discovered home agent anyway. I also think the policy on the mobile node should be such that this discovery of a home agent should not modify existing PAD/SPD entries created using manual configuration, or some other configuration that results in persistent config state on the mobile node. I don't agree with the restriction that the original gateway and the new gateway should have the same IDr. That is too restrictive. For example, it should be possible for gw1 to redirect the client to gw2, with the two gateways having two distinct FQDNs. It is okay with me to recommend similar authentication mechanisms for the original and new gateways. But I would prefer not use a 'MUST' here. There could be scenarios where a different gateway means a different authentication mechanism. We should of course add some text in the security considerations section warning about REDIRECTs resulting in lower security with the new gateway. Note that gateway-initiated redirect (section 5) is protected by the IKEv2 SA. It is not the same as the REDIRECT message that the client receives in the IKE_SA_INIT response. So we can't say that all REDIRECT messages are insecure. I will not be able to resolve this in the version I am going to be submitting in the next couple of hours. I hope we can resolve this in the next few days. I will post another temporary version of the draft once we conclude on this issue. Regards, Vijay > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of pasi.ero...@nokia.com > Sent: Monday, March 02, 2009 12:04 PM > To: ipsec@ietf.org > Subject: Re: [IPsec] WG Last Call: > draft-ietf-ipsecme-ikev2-redirect-04 > > > > I have one somewhat substantial concern with the document: it needs to > be much clearer about what information is updated by the received > REDIRECT messages, and what is not. > > While selecting the right peer when a new ESP/AH SA needs to be > created is not specified in RFC 4301 (see RFC 4555 Appendix A.2 for > some discussion), PAD definitely is in scope, and redirect could > interact with PAD in multiple ways. > > For example, suppose the client decides that the right peer for the > ESP/AH SA is gw1.example.com. If after doing a DNS lookup and > contacting gw1.example.com it receives IDr/CERT payloads for > gw2.foobar.example, the client would report error and abort (at least > unless "the right peer for the SA" is actually a set of possible > peers, and gw2 happens to be in that set). > > Now, suppose contacting gw1.example.com results in REDIRECT to > gw2.foobar.example (GW Identity Type=FQDN). When the client contacts > gw2, and receives IDr/CERT for gw2.foobar.example, does it accept it? > > One possible answer would be that REDIRECT is interpreted just as data > received from DNS, so all the gateways (redirecting among each other) > would send same IDr value. > > Another possible answer would be that if gw2.foobar.example is already > in client's local "set of right peers for this SA", then it would be > accepted (and the client would have accepted IDr/CERT with > gw2.foobar.example also in the beginning, before it got the redirect), > otherwise not. (And the client will also accept IDr/CERT > gw1.example.com even after the redirect, when contacting gw2 ---that > would be the sensible behavior if the redirect was with GW Identity > Type=IPv4/6.) > > (Other answers than these two might be possible, too -- I have > not explored this in detail.) > > Now, it's quite obvious the intent was to do redirect securely, but we > need to spell out what the correct behavior is: do all the gateways > have a single identity (IDr), or do t
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Vijay Devarapalli wrote: > > - Section 6.1/6.2/6.3: should say that Protocol ID is set to zero. > > Fixed. One nit: the text in version -05 says "Protocol ID should be set to 0". I think this should be just "is set to 0" (or perhaps "MUST be set to 0") 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
Tero Kivinen wrote: > > I have one somewhat substantial concern with the document: it > > needs to be much clearer about what information is updated by the > > received REDIRECT messages, and what is not. > > Never really thought that issue. I myself assumed that both GWs are > identical, i.e. they return same ID, and use same authentication > data (i.e. if PSK, both use same PSK, if certs, both authenticate > against same trust anchor and use same identity in cert, but not > necessarely same private key). I think that's roughly what I initially assumed, too. In this case, the REDIRECT payload is redirecting the VPN client from one IP address to another, but within the same "responder identity" (not from one responder identity to another) . (Here "responder identity" can be single physical box with several addresses, or multiple physical boxes configured to "look like one" -- the client doesn't have to know which.) > > One possible answer would be that REDIRECT is interpreted just as > > data received from DNS, so all the gateways (redirecting among > > each other) would send same IDr value. > > I think this is the easiest way to make sure redirect is secure. I agree -- and if we settle on this approach, we might want to rename the "New Responder GW Identity" field (in REDIRECT payload) to something like "New Responder Transport Address" -- since the IKE identity is not changed, only the address used for transporting IKE messages. I spent some time in trying to figure out how to specify the other approach (redirect to different "responder identity") securely, but couldn't really come up with anything that would work and be consistent with the RFC 4301 model... so at the very least, taking that approach will mean more work before we're done. 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
pasi.ero...@nokia.com wrote: Vijay Devarapalli wrote: - Section 6.1/6.2/6.3: should say that Protocol ID is set to zero. Fixed. One nit: the text in version -05 says "Protocol ID should be set to 0". I think this should be just "is set to 0" (or perhaps "MUST be set to 0") Changed it to "... MUST be set to 0 ..." Vijay ___ 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: > I don't agree with the restriction that the original gateway and the > new gateway should have the same IDr. That is too restrictive. For > example, it should be possible for gw1 to redirect the client to > gw2, with the two gateways having two distinct FQDNs. 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.) (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.) > It is okay with me to recommend similar authentication mechanisms > for the original and new gateways. But I would prefer not use a > 'MUST' here. I think this needs to be phrased in terms of the RFC 4301 PAD (and possibly the "selecting right peer for SA function"). 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
pasi.ero...@nokia.com wrote: > > Vijay Devarapalli wrote: > > > I don't agree with the restriction that the original > gateway and the > > new gateway should have the same IDr. That is too restrictive. For > > example, it should be possible for gw1 to redirect the > client to gw2, > > with the two gateways having two distinct FQDNs. > > 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.) I agree that we have to assume that gw2 is in the PAD. It could be the same entry as gw1, or it could be different, but it has to be in the PAD. If gw1 redirects the client to a gateway that is not in the PAD, then the client must log or report, and fail. > (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.) > > > It is okay with me to recommend similar authentication > mechanisms for > > the original and new gateways. But I would prefer not use a 'MUST' > > here. > > I think this needs to be phrased in terms of the RFC 4301 PAD > (and possibly the "selecting right peer for SA function"). RFC 4301 does not require that each SPD entry be associated with a single PAD entry. It's a many-to-many relationship. The section on named SPDs specifically says that an SPD entry may have multiple names. Section 4.4.3.3 says that "If the entry indicates that child SAs traffic selectors are to be used, then an additional data element is required, in the form of IPv4 and/or IPv6 address ranges." It does not say that two entries cannot have the same IDs. This works fine if two gateways (at different addresses) protect the same networks (an example would be two geographically distinct sites, each with its own gateway, and an MPLS link between them). If the redirect-to gateway is in the PAD, but either does not protect the same networks at all, or has a partial overlap in protected networks, then we have a problem, because if the client is setting up a child SA in order to reach host A, protected by gw1 but not by gw2, then it's not clear what selectors should be used with gw2, and whether the whole exercise has any value. Perhaps instead of requiring "having the same Idr" we need to require "having the same SPD entries", except maybe SPDs that cover the gateways themselves. Yoav Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
At 12:44 PM +0100 3/11/09, wrote: >Vijay Devarapalli wrote: > >> I don't agree with the restriction that the original gateway and the >> new gateway should have the same IDr. That is too restrictive. For >> example, it should be possible for gw1 to redirect the client to >> gw2, with the two gateways having two distinct FQDNs. > >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.) Co-chair-hat on: Right, we are not considering that currently. If we do consider it, it is a significant change to the document and we would want to do (at least) another WG last call. Co-chair-hat off: Right, and we should not consider that, given the difficulty of bounding the security considerations if we do so. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
On Wed, Mar 11, 2009 at 12:35:36PM -0700, Paul Hoffman wrote: > At 12:44 PM +0100 3/11/09, 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.) > Co-chair-hat off: > > Right, and we should not consider that, given the difficulty of bounding > the security considerations if we do so. I agree with Paul regardless of which hat he's wearing, but my reason for agreeing with him is more along the lines of his sans-hat look. :) Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
pasi.ero...@nokia.com wrote: Vijay Devarapalli wrote: I don't agree with the restriction that the original gateway and the new gateway should have the same IDr. That is too restrictive. For example, it should be possible for gw1 to redirect the client to gw2, with the two gateways having two distinct FQDNs. 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. (* 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? It is okay with me to recommend similar authentication mechanisms for the original and new gateways. But I would prefer not use a 'MUST' here. I think this needs to be phrased in terms of the RFC 4301 PAD (and possibly the "selecting right peer for SA function"). Ok. Once we agree on a way forward, I can propose some text. Vijay ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Paul Hoffman wrote: At 12:44 PM +0100 3/11/09, wrote: Vijay Devarapalli wrote: I don't agree with the restriction that the original gateway and the new gateway should have the same IDr. That is too restrictive. For example, it should be possible for gw1 to redirect the client to gw2, with the two gateways having two distinct FQDNs. 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.) Co-chair-hat on: Right, we are not considering that currently. If we do consider it, it is a significant change to the document and we would want to do (at least) another WG last call. Co-chair-hat off: Right, and we should not consider that, given the difficulty of bounding the security considerations if we do so. There are environments where the client (e.g, Mobile IPv6 MN, 3GPP I-WLAN client) always discovers the gateways they need to attach to. They might get assigned different gateways based on what service they want to access, what their subscription profile is, etc.. In such environments, the PAD entries are created dynamically, but of course bound by the configuration on the mobile node. I think the REDIRECT mechanism is of limited use if you can only redirect to another gateway for which the mobile node already has a PAD entry. Note that Mobile IPv6 already allows the mobile node to discover home agents dynamically and then create PAD and SPD entries. These are already standards track documents. On starting another WG last call for the document if we make this change, I am fine with it. Vijay ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
At 1:07 PM -0800 3/11/09, Vijay Devarapalli wrote: >There are environments where the client (e.g, Mobile IPv6 MN, 3GPP I-WLAN >client) always discovers the gateways they need to attach to. They might get >assigned different gateways based on what service they want to access, what >their subscription profile is, etc.. In such environments, the PAD entries are >created dynamically, but of course bound by the configuration on the mobile >node. Of course. I was proposing that we do not add this mechanism to the list, but instead have it reflect the settings that were made by the other mechanisms. >I think the REDIRECT mechanism is of limited use if you can only redirect to >another gateway for which the mobile node already has a PAD entry. Hmm. That was not clear to me from the document, but I could have missed it. What do others think about this statement? --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Paul Hoffman wrote: > > At 1:07 PM -0800 3/11/09, Vijay Devarapalli wrote: > >There are environments where the client (e.g, Mobile IPv6 > MN, 3GPP I-WLAN client) always discovers the gateways they > need to attach to. They might get assigned different gateways > based on what service they want to access, what their > subscription profile is, etc.. In such environments, the PAD > entries are created dynamically, but of course bound by the > configuration on the mobile node. > > Of course. I was proposing that we do not add this mechanism > to the list, but instead have it reflect the settings that > were made by the other mechanisms. > > >I think the REDIRECT mechanism is of limited use if you can > only redirect to another gateway for which the mobile node > already has a PAD entry. > > Hmm. That was not clear to me from the document, but I could > have missed it. What do others think about this statement? Strongly disagree. The REDIRECT in the Initial exchange is unauthenticated. The mobile node has not idea where this message has come from. I don't think it makes any sense to alter the PAD based on an unauthenticated notification. If we allow this, then REDIRECT says "go to this address on the Internet, and give them your user name and password". A fake REDIRECT could lead you to the attacker's gateway. You will accept any IDr it presents (because you don't have a PAD entry to authenticate that gateway). That gateway can then mount a MitM attack with the real gateway. No. I would hesitate to change the PAD based on an authenticated message from a trusted peer. I would never alter the PAD based on an unauthenticated message. gw2 MUST be in the PAD (either the same entry or a different one) Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Paul Hoffman writes: > >I think the REDIRECT mechanism is of limited use if you can only > >redirect to another gateway for which the mobile node already has a > >PAD entry. > > Hmm. That was not clear to me from the document, but I could have > missed it. What do others think about this statement? I didn't get that from the draft. The current draft does not mention anything about PAD, and doing dynamic updates to PAD (or SPD) is something that must be explicitly mentioned if such things are supposed to happen, as they have lots of security implications (overwriting existing rules, to which location dynamic rules are added in the ordered PAD/SPD, what information is exactly put there). On the other hand I do not think the REDIRECT mechanism will be that much in limited use, even if the PAD entries must be configured. The mobile node requires PAD entry for the first gateway anyways, and if that PAD entry identifies the group of peers instead that one peer, and provides authentication data for each peer (for example say that they are authenticated using certificates signed by CA X). Depending on the configuration this can still be done quite easily. Example could be that PAD define ID must be *.sgw.example.com. and the peer must authenticate itself using certificate signed by CA X. Then first gateway can provide ID sgw1.sgw.example.com and it can redirect client to server, which then will use ID sgw2.sgw.example.com, and that will still match the same PAD entry. Both gateways will use certificates provided by the same CA so their authentication information is same. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Hi Tero, Apologies for my late reply. My interpretation of redirect is that Gateway A is telling Client C: "go talk to Gateway B instead of me. I am overloaded, or going down for maintenance, and Gateway B can do the same things that I can do." Which in particular means that routing was configured so that GW B can *really* act like GW A. A and B are not "the same gateway", they do not share state, so MOBIKE cannot be used. The exact same thing applies to the gateway-to-gateway situation. Suppose Gateway C initiated an IKE SA with gateway A. Two hours later GW C goes into maintenance, so it asks GW A to redirect into Gateway D. GW A cannot just initiate a connection to D, because it doesn't know that it needs to until told by GW C. And it doesn't matter who initiated the SA in the first place. Yes, there is some routing/tunneling magic going on "behind" the gateways, but why should we rely on it to initiate the IKE redirection, when we have the mechanism defined in the current draft? Thanks, Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Monday, March 09, 2009 15:11 > To: Yaron Sheffer > Cc: Vijay Devarapalli; pasi.ero...@nokia.com; ipsec@ietf.org; > rfgrave...@gmail.com > Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > > Yaron Sheffer writes: > > I am thinking of symmetric IKE peers (gateways, or endpoints using > > transport mode ESP; no EAP, rarely any NAT). Is there any reason why > > the current draft cannot support this case in a symmetric manner? > > Why do you need any protocol for that. Why does not normal IKEv2 be > enough for that. > > I.e. if node A wants the node B to move to use some other location, it > can simply connect to node B using that new location, and remove the > old IKE SA. > > I.e. if scenario is really symmetric, there is no need to have any > IKEv2 redirect protocol at all, everything can be done by the node by > directly connecting using new location. > > It is quite hard to explain this thing as I have no idea what kind of > scenario you are talking about. Can you give real example, what the > nodes are and why do they want to redirect other end. > > MOBIKE is not restricted to the VPN client <-> VPN server situation, > but is limited that node must stay same. I.e. it is moving between > multiple addresses of node A and moving between multiple address of > node B. It cannot ask node B to move from node A to node C. > > But if node A wants node B to use node C instead of node A, it can > simply inform node C to make connection to B and delete its own IKE > SA. It can also do this by just changing the back end routing or > similar, so that return packets go to node C instead of node A and > then node C will initiate connection to node B immediately when first > packet arrives (if the situation is really symmetric). > > If we are talking about client and server situations where server > wants to redirect client to some other server, then situation is no > longer symmetric. > -- > kivi...@iki.fi > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Yaron Sheffer writes: > The exact same thing applies to the gateway-to-gateway situation. Suppose > Gateway C initiated an IKE SA with gateway A. Two hours later GW C goes into > maintenance, so it asks GW A to redirect into Gateway D. GW A cannot just > initiate a connection to D, because it doesn't know that it needs to until > told by GW C. And it doesn't matter who initiated the SA in the first place. When C goes to the maintenance, it will also change routing so that packets which used to come to him, will go to D. Immediately when first such packet gets to D, the D will initiate connection to A, so C can simply change the routing, and then delete all IKE SAs. > Yes, there is some routing/tunneling magic going on "behind" the gateways, > but why should we rely on it to initiate the IKE redirection, when we have > the mechanism defined in the current draft? Mostly because redirections gets very complicated if both ends can move at will... For example what happens if the gateway A is rebooted, while C is still down. Now C will not reply with redirect to D, thus we still need to rely on some other external mechanism to redirect stuff from C to D, i.e. most likely both of them are configured in the configuration, so A will know that it can connect either C or D. When we were writing MOBIKE, we noticed that things gets very complicated very quickly if such scenarios are allowed, and in that case you cannot really expect the systems to just work, you still need to write new document profiling how nodes should be configured and used in such cases. If we are going to need such profile anyways to get usable protocol, we can write protocol extension at the same time which profiles redirect to be used in gw-gw scenarios and also extends and defines how it should be used in that case. We have way too many protocols already where the actual protocol document does not provide interoperability. The documents are so wide open, that nobody implements all the optional things (or not even all the mandatory to implement things), thus you cannot just take two implementations and assume they work together on your specific scenario. In those cases you need to write profile that tells what features are required, and then you might get interoperability (provided you will find any implementations fulfilling those requirements). My proposal was to say that we do not define that usage in this document, but it is not explicitly forbidden either, so we assume that if such usage is needed, new document extending this one will be written. -- kivi...@iki.fi ___ 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
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Yoav Nir wrote: > If the redirect-to gateway is in the PAD, but either does not > protect the same networks at all, or has a partial overlap in > protected networks, then we have a problem, because if the client is > setting up a child SA in order to reach host A, protected by gw1 but > not by gw2, then it's not clear what selectors should be used with > gw2, and whether the whole exercise has any value. > > Perhaps instead of requiring "having the same Idr" we need to > require "having the same SPD entries", except maybe SPDs that cover > the gateways themselves. Hmm -- something along these lines might work; but should it be "having same Child SA Authorization Data in the PAD"? Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
