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
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)
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)
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)
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)
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)
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
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)
RSS Feed15 | |
|---|---|
1 | |
1 | |
1 | |
4 | |
2 | |
5 | |
4 | |
4 | |
3 | |
28 | |
13 | |
18 | |
63 | |
24 | |
78 | |
160 | |
137 | |
46 | |
74 | |
20 | |
55 | |
29 | |
75 | |
27 | |
31 | |
92 | |
66 | |
79 | |
33 | |
54 | |
14 | |
61 | |
22 | |
33 | |
4 |
