Hi, RFC4555 only allows updates to tunnel endpoint addresses and not selectors, etc. Does anyone know why TS updates are not permitted? If MOBIKE allowed what an SA rekey would allow, what is the problem? Thanks, Vidya
Narayanan, Vidya writes: > RFC4555 only allows updates to tunnel endpoint addresses and not > selectors, etc. Yes, as that was outside the charter of the mobike. > Does anyone know why TS updates are not permitted? It is already done by the IKEv2 protocol, with fast and efficient exchange called CREATE_CHILD_SA... I.e. if you need it simply, create new SA with new traffic selectors, and delete the old one. > If MOBIKE allowed what an SA rekey would allow, what is the problem? All traffic going through the SA would usually stop, as it would not know it needs to change the IP addresses, thus it would still be using the original addresses, and it wouldn't fit to the new SA. I.e. as the idea is that the for example TCP streams running inside the IPsec SA using mobike, keeps exactly same IP addresses all the time, so the TCP do not notice the movement at all. When outer addresses change, the inner addresses stay same, and TCP will only see those inner addresses it will stay happy. If those inner addresses would change then TCP streams running on old addresses would be broken and connections would be lost unless the TCP stack was also modified to update the addresses. So in mobike case there is no need to update the inner addresses, and if someone makes some real world scenario where such thing is needed CREATE_CHILD_SA will solve the problem for him...(Continue reading)
Presumably because MOBIKE is a mobility and multihoming facility for IPsec clients and gateways, i.e., you can change the outer IP addresses. Its not a general SA renegotiation facility. Yes, it could be done, but I'm not sure that's really within the scope of the feature. Unless we are talking about extension to deal with transport mode, which has been something at least a few people were interested in. Jari Narayanan, Vidya kirjoitti: > Hi, > RFC4555 only allows updates to tunnel endpoint addresses and not > selectors, etc. Does anyone know why TS updates are not permitted? If > MOBIKE allowed what an SA rekey would allow, what is the problem? > > Thanks, > Vidya > _______________________________________________ > Mobike mailing list > Mobike <at> machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > > >
Hi Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko <at> piuha.net] > Sent: Thursday, November 01, 2007 10:26 PM > To: Narayanan, Vidya > Cc: mobike <at> machshav.com; ipsec <at> ietf.org > Subject: Re: [Mobike] TS updates in MOBIKE > > Presumably because MOBIKE is a mobility and multihoming > facility for IPsec clients and gateways, i.e., you can change > the outer IP addresses. Its not a general SA renegotiation facility. > Yes, I understand that that is the purpose of MOBIKE. But, I don't see a good reason to prevent other updates from happening as part of that same exchange. For e.g., let's say that when my address changes, I want to update the SA (or rekey) to start encrypting some additional traffic (fitting different selector criteria) using the same SA - the initiator now has to do separate MOBIKE and rekeying exchanges, which is not really efficient. > Yes, it could be done, but I'm not sure that's really within > the scope of the feature. Unless we are talking about > extension to deal with transport mode, which has been > something at least a few people were interested in. > I think the above point of updating the SAs applies equally to transport and tunnel mode, but, extending MOBIKE for transport mode is(Continue reading)
At 10:43 AM -0700 11/2/07, Narayanan, Vidya wrote: >Hi Jari, > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko <at> piuha.net] >> Sent: Thursday, November 01, 2007 10:26 PM >> To: Narayanan, Vidya >> Cc: mobike <at> machshav.com; ipsec <at> ietf.org >> Subject: Re: [Mobike] TS updates in MOBIKE >> >> Presumably because MOBIKE is a mobility and multihoming >> facility for IPsec clients and gateways, i.e., you can change >> the outer IP addresses. Its not a general SA renegotiation facility. >> > >Yes, I understand that that is the purpose of MOBIKE. But, I don't see >a good reason to prevent other updates from happening as part of that >same exchange. For e.g., let's say that when my address changes, I want >to update the SA (or rekey) to start encrypting some additional traffic >(fitting different selector criteria) using the same SA - the initiator >now has to do separate MOBIKE and rekeying exchanges, which is not >really efficient. > >> Yes, it could be done, but I'm not sure that's really within >> the scope of the feature. Unless we are talking about >> extension to deal with transport mode, which has been >> something at least a few people were interested in. >> > >I think the above point of updating the SAs applies equally to transport(Continue reading)
Efficiency is overrated. But all joking aside, the UPDATE_SA notify payload is part of an informational exchange. Informationals do not contain the necessary payloads to "update an SA" such as TS, KE, and even SA payloads. The alternative is to allow the UPDATE_SA notify payload to be part of a CREATE_CHILD_SA message. If so, it must be further specified that there are now 2 ways to UPDATE_SA: a regular end-point update via an informational, and a end-point + TS + [etc.] update via a create child sa. Since this is a reasonably major change to the MOBIKE spec, which is already an RFC, you may need a compelling use-case scenario. A saving of 2 additional packets (for the extra rekey to change the TS) may not be sufficient reason to blur the current functional boundaries. Chinh -- http://www.certicom.com Narayanan, Vidya wrote: > Hi Jari, > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko <at> piuha.net] >> Sent: Thursday, November 01, 2007 10:26 PM >> To: Narayanan, Vidya >> Cc: mobike <at> machshav.com; ipsec <at> ietf.org(Continue reading)
Chinh, Steve, Tero, Thanks for all the responses. I'm just taking Chinh's email here to make a few observations. > -----Original Message----- > From: Chinh Nguyen [mailto:cnguyen <at> certicom.com] > Sent: Friday, November 02, 2007 12:34 PM > To: Narayanan, Vidya > Cc: Jari Arkko; ipsec <at> ietf.org; mobike <at> machshav.com > Subject: Re: [IPsec] RE: [Mobike] TS updates in MOBIKE > > Efficiency is overrated. > Well, not that overrated over licensed wireless spectrum :) > But all joking aside, the UPDATE_SA notify payload is part of > an informational exchange. Informationals do not contain the > necessary payloads to "update an SA" such as TS, KE, and even > SA payloads. > Yes, that is true. I guess what I was really asking was what you were getting at immediately below. > The alternative is to allow the UPDATE_SA notify payload to > be part of a CREATE_CHILD_SA message. If so, it must be > further specified that there are now 2 ways to UPDATE_SA: a > regular end-point update via an informational, and a > end-point + TS + [etc.] update via a create child sa.(Continue reading)
Narayanan, Vidya writes: > The use case that I presently have in mind is the following. IPsec is > used in some cases to protect Mobile IPv6 (MIP6) signaling. Some > systems differentiate between trusted accesses and untrusted accesses > and while IPsec is always used for MIP6 signaling protection in both > cases, additional data protection using IPsec may be needed over > untrusted access networks (between the same endpoints). When a mobile > is moving from a trusted to untrusted access, its IP address changes, > but, it also, at the same time, needs to update its SA to start > protecting all traffic. At the moment, the mobile, just to handle this > handoff case, needs to do a MIP6 signaling exchange, a MOBIKE exchange > and a CREATE_CHILD_SA exchange. The first two are unavoidable and can > happen in parallel, while the third one has to occur after the MOBIKE > exchange completes. This is a latency hit in the critical path that can > be avoided if the UPDATE_SA notify payload can be part of the > CREATE_CHILD_SA exchange. Why it cannot happen in paralleal with UPDATE_SA exchange? IKEv2 already has mechanisms defined for using bigger window for IKEv2, so you just need to enable using of window size of 2 or larger in the IKEv2, to be able to do UPDATE_SA and CREATE_CHILD_SA in paralleal, thus now latency hit at all. Or is there some other reason they cannot be done in paralleal? > Well, depending on the environment we are talking about, byte savings > and particularly latency becomes important. There is no latency problem, so the only problem is the extra 80 bytes sent and received.(Continue reading)
Tero Kivinen wrote: > Narayanan, Vidya writes: >> The use case that I presently have in mind is the following. IPsec is >> used in some cases to protect Mobile IPv6 (MIP6) signaling. Some >> systems differentiate between trusted accesses and untrusted accesses >> and while IPsec is always used for MIP6 signaling protection in both >> cases, additional data protection using IPsec may be needed over >> untrusted access networks (between the same endpoints). When a mobile >> is moving from a trusted to untrusted access, its IP address changes, >> but, it also, at the same time, needs to update its SA to start >> protecting all traffic. At the moment, the mobile, just to handle this >> handoff case, needs to do a MIP6 signaling exchange, a MOBIKE exchange >> and a CREATE_CHILD_SA exchange. The first two are unavoidable and can >> happen in parallel, while the third one has to occur after the MOBIKE >> exchange completes. This is a latency hit in the critical path that can >> be avoided if the UPDATE_SA notify payload can be part of the >> CREATE_CHILD_SA exchange. > > Why it cannot happen in paralleal with UPDATE_SA exchange? IKEv2 > already has mechanisms defined for using bigger window for IKEv2, so > you just need to enable using of window size of 2 or larger in the > IKEv2, to be able to do UPDATE_SA and CREATE_CHILD_SA in paralleal, > thus now latency hit at all. Or is there some other reason they cannot > be done in paralleal? A IKEv2 peer may choose to reject a CREATE_CHILD_SA if it arrives from an "unknown" endpoint (SPIs + src/dst addresses are used to track IKEv2 exchanges). In such case, the CREATE_CHILD_SA will fail if a. the CREATE_CHILD_SA arrives before the UPDATE_SA exchange or b. the CREATE_CHILD_SA arrives while the peer is doing a route check to(Continue reading)
Chinh Nguyen writes: > A IKEv2 peer may choose to reject a CREATE_CHILD_SA if it arrives from > an "unknown" endpoint (SPIs + src/dst addresses are used to track IKEv2 > exchanges). In such case, the CREATE_CHILD_SA will fail if a. the > CREATE_CHILD_SA arrives before the UPDATE_SA exchange or b. the > CREATE_CHILD_SA arrives while the peer is doing a route check to > complete the UPDATE_SA exchange. With proper mobike implementations there should not be any such problems. The outer addresses should not be used for policy enforcements, as it is using valid IKE SA to send that CREATE_CHILD_SA. If the CREATE_CHILD_SA arrives while doing return routability check, that should not cause any problems either. > However, this can be mitigated by having the IKEv2 peer use only the > SPIs to track IKEv2 exchanges and ignore src/dst addresses. If you are using mobike, you do ingore outer src/dst addresses anyways (or at least do not use them to enforce any kind of policy, you of course use them to detect movement etc). -- -- kivinen <at> safenet-inc.com
> > > > Why it cannot happen in paralleal with UPDATE_SA exchange? IKEv2 > > already has mechanisms defined for using bigger window for > IKEv2, so > > you just need to enable using of window size of 2 or larger in the > > IKEv2, to be able to do UPDATE_SA and CREATE_CHILD_SA in paralleal, > > thus now latency hit at all. Or is there some other reason > they cannot > > be done in paralleal? > > A IKEv2 peer may choose to reject a CREATE_CHILD_SA if it > arrives from an "unknown" endpoint (SPIs + src/dst addresses > are used to track IKEv2 exchanges). In such case, the > CREATE_CHILD_SA will fail if a. the CREATE_CHILD_SA arrives > before the UPDATE_SA exchange or b. the CREATE_CHILD_SA > arrives while the peer is doing a route check to complete the > UPDATE_SA exchange. > Yes, this is what I was getting at. > However, this can be mitigated by having the IKEv2 peer use > only the SPIs to track IKEv2 exchanges and ignore src/dst addresses. > This gives the impression that the IP address to which the IKE_SA is tied is not important. That is the address that is going to serve as the tunnel endpoint for tunnel mode SAs and hence, has some consequence. I would think that typical implementations reject CREATE_CHILD_SA requests for rekeying an SA, sent from a different IP address than to(Continue reading)
Narayanan, Vidya writes: > This gives the impression that the IP address to which the IKE_SA is > tied is not important. That is the address that is going to serve as > the tunnel endpoint for tunnel mode SAs and hence, has some consequence. > I would think that typical implementations reject CREATE_CHILD_SA > requests for rekeying an SA, sent from a different IP address than to > which the IKE_SA is currently tied - is that not true? RFC4306 is not > clear about this. Check the RFC4555 instead of RFC4306. With mobike all existing IPsec SAs do get updated with new outer addresses with UPDATE_SA_ADDRESSES, so it does not matter what the outer IP adresses were when the IPsec SA was created. Also it is normal operation to get packets in with different outer address to IKE SA when using MOBIKE. This happens for example when you start to do UPDATE_SA_ADDRESSES, but can happen also with any other IKEv2 packet. This is because other end might not be able to send UPDATE_SA_ADDRESSES because it first needs to finish other ongoing exchange on the IKEv2 SA in case the window size is only 1. -- -- kivinen <at> safenet-inc.com
>> However, this can be mitigated by having the IKEv2 peer use >> only the SPIs to track IKEv2 exchanges and ignore src/dst addresses. >> > > This gives the impression that the IP address to which the IKE_SA is > tied is not important. That is the address that is going to serve as > the tunnel endpoint for tunnel mode SAs and hence, has some consequence. > I would think that typical implementations reject CREATE_CHILD_SA > requests for rekeying an SA, sent from a different IP address than to > which the IKE_SA is currently tied - is that not true? RFC4306 is not > clear about this. From a MOBIKE view, IKE_SA cannot be tied to IP addresses. The entire premise of an UPDATE_SA is that it may originate from a new endpoint, different from the endpoints stored in the current IKE_SA. As such, a MOBIKE peer should allow this for all IKEv2 exchanges, including CREATE_CHILD_SA (as noted by Pasi RFC 4555 section 3.3). Whether or not a non-MOBIKE IKEv2 implementation should do the same is another question. I vote for yes as the SPIs and successful authentication/decryption (correct IKE_SA) is sufficient to validate "peer identity".
Vidya Narayanan wrote: > This gives the impression that the IP address to which the IKE_SA is > tied is not important. That is the address that is going to serve > as the tunnel endpoint for tunnel mode SAs and hence, has some > consequence. I would think that typical implementations reject > CREATE_CHILD_SA requests for rekeying an SA, sent from a different > IP address than to which the IKE_SA is currently tied - is that not > true? RFC4306 is not clear about this. We faced this question when designing MOBIKE, and resolved it as follows (RFC 4555, Section 3.3): When an IPsec SA is created, the tunnel header IP addresses (and port, if doing UDP encapsulation) are taken from the IKE_SA, not the IP header of the IKEv2 message requesting the IPsec SA. The addresses in the IKE_SA are initialized from the IP header of the first IKE_AUTH request. In other words: the CREATE_CHILD_SA request is not rejected, and the reply is still sent back to the address the packet came from; but the tunnel endpoints are initialized from stored information (which can be updated by UPDATE_SA_ADDRESSES). Best regards, Pasi
Vidya Narayanan wrote: > The use case that I presently have in mind is the following. IPsec > is used in some cases to protect Mobile IPv6 (MIP6) signaling. Some > systems differentiate between trusted accesses and untrusted > accesses and while IPsec is always used for MIP6 signaling > protection in both cases, additional data protection using IPsec may > be needed over untrusted access networks (between the same > endpoints). When a mobile is moving from a trusted to untrusted > access, its IP address changes, but, it also, at the same time, > needs to update its SA to start protecting all traffic. At the > moment, the mobile, just to handle this handoff case, needs to do a > MIP6 signaling exchange, a MOBIKE exchange and a CREATE_CHILD_SA > exchange. The first two are unavoidable and can happen in parallel, > while the third one has to occur after the MOBIKE exchange > completes. This is a latency hit in the critical path that can be > avoided if the UPDATE_SA notify payload can be part of the > CREATE_CHILD_SA exchange. If the IKE implementation supports window size larger than 1, can't the Informational exchange (with UPDATE_SA notify payload) and CREATE_CHILD_SA exchange occur in parallel, too? Best regards, Pasi
RSS Feed