< draft-xu-ike-sa-sync-00.txt		draft-xu-ike-sa-sync-01.txt >
	Network Working Group Y. Xu		Network Working Group Y. Xu
	Internet-Draft Tsinghua Univ.		Internet-Draft Tsinghua Univ.
	Intended status: Standards Track P. Yang		Intended status: Standards Track P. Yang
	Expires: January 8, 2009 Y. Ma		Expires: April 10, 2009 Y. Ma
	Hitachi (China) R&D Corporation		Hitachi (China) R&D Corporation
	H. Deng		H. Deng
	China Mobile		China Mobile
	K. Xu		K. Xu
	Tsinghua University		Tsinghua University
	July 7, 2008		October 7, 2008
	IKE SA Synchronization		IKEv2 SA Synchronization for session resumption
	draft-xu-ike-sa-sync-00		draft-xu-ike-sa-sync-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 8, 2009.		This Internet-Draft will expire on April 10, 2009.
	Abstract		Abstract
	It will take a long time to do security association syncronization		It will take a long time and mass computation to do session
	among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/		resumption among IKE/IPsec gateways possibly maintaining huge numbers
	IPsec SAs. The major reason is that the prcocedure of IKEv2 SA re-		of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded.
	establishment will incur a time-consuming computation especially in		The major reason is that the prcocedure of IKEv2 SA re-establishment
	the Diffie-Hellman exchange. In this draft, a new IKE security		will incur a time-consuming computation especially in the Diffie-
	associations synchronization solution is proposed to reduce the		Hellman exchange. In this draft, a new IKE security associations
	computation by directly transferring the indexed IKE SA from old		synchronization solution is proposed to do fast IKE SA session
	gateway to new gateway, wherein the most expensive Diffie-Hellman		resumption by directly transferring the indexed IKE SA (named stub)
	calculation can be avoided. Without some time-consuming IKEv2		from old gateway to new gateway, wherein the most expensive Diffie-
	exchanges, the huge amount of IKE/IPsec SA synchronization procedures		Hellman calculation can be avoided. Without some time-consuming
	can be finished in a short time.		IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption
			procedures can be finished in a short time.
	Table of Contents		Table of Contents
	1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Application scenarios . . . . . . . . . . . . . . . . . . . . 4		2. Application scenarios of IKEv2 Session Resumption . . . . . . 4
	2.1. Scenario of failover . . . . . . . . . . . . . . . . . . . 4		2.1. Scenario of IKEv2 Gateway fail . . . . . . . . . . . . . . 4
	2.2. Scenario of load-balance . . . . . . . . . . . . . . . . . 5		2.2. Scenario of load-balance . . . . . . . . . . . . . . . . . 5
	3. Details on Proposed solution . . . . . . . . . . . . . . . . . 6		3. Details on Proposed solution . . . . . . . . . . . . . . . . . 6
	3.1. Overview of the Proposed solution . . . . . . . . . . . . 6		3.1. Overview of the Proposed solution . . . . . . . . . . . . 6
	3.2. Key data structure . . . . . . . . . . . . . . . . . . . . 6		3.2. data structure of stub . . . . . . . . . . . . . . . . . . 7
	3.3. Consideration on Stub handling . . . . . . . . . . . . . . 7		3.3. Consideration on building IKE SA in session resumption . . 7
	3.4. Consideration on location of Stub . . . . . . . . . . . . 8		3.4. Consideration on Stub handling . . . . . . . . . . . . . . 7
	3.5. When should Gateways download/update Stub . . . . . . . . 9		3.5. Consideration on location of Stub . . . . . . . . . . . . 9
	3.6. Related new messages . . . . . . . . . . . . . . . . . . . 9		3.6. When should Gateways download/update Stub . . . . . . . . 10
	4. Modification on the base IKEv2 protocol . . . . . . . . . . . 11		3.7. Related new messages . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4. Modification on the base IKEv2 protocol . . . . . . . . . . . 12
	6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 14		6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		7. Normative References . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
			Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Background		1. Background
	IKEv2 protocol which has been defined by rfc4306[1] provides us a		IKEv2 protocol which has been defined by [RFC4306] provides us a
	method to negotiate ipsec's key automatically between ipsec clients		method to negotiate ipsec's key automatically between ipsec clients
	and gateway. Before negotiating ipsec's key, they should negotiate		and gateway. Before negotiating ipsec's key, they should negotiate
	IKE's SA first. Usually, ipsec client sends IKE_INIT message to		IKE's SA first. Usually, ipsec client sends IKE_INIT message to
	gateway with SAi1, KEi, Ni, then gateway chooses some proposal of		gateway with SAi1, KEi, Ni, then gateway chooses some proposal of
	SAi1 which come to the algorithm for encryption and decryption, also		SAi1 which come to the algorithm for encryption and decryption, also
	proposal for Diffie-Hellman, and then calculates the Diffie-Hellman,		proposal for Diffie-Hellman, and then calculates the Diffie-Hellman,
	sends IKE_INIT respond message back to ipsec client. At this time,		sends IKE_INIT respond message back to ipsec client. At this time,
	the most important keyring can be generated. After other IKE_AUTH		the most important keyring can be generated. After other IKE_AUTH
	exchange, each other has verified the identity. IKE SA has		exchange, The identity has verified. IKE SA has completely been
	completely been established.		established. The timing overhead of IKEv2 protocol, including some
			computation and signaling round-trips, is rather big especially when
			the Extensible Authentication Protocol (EAP) is used for third-party
			authentication. The picture below is the typical procedure for IKEv2
			SA establishment.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SAi1, KEi, Ni -->		HDR, SAi1, KEi, Ni -->
	< -- HDR, SAr1, KEr, Nr, [CERTREQ]		< -- HDR, SAr1, KEr, Nr, [CERTREQ]
	HDR, SK {IDi, [CERT,]		HDR, SK {IDi, [CERT,]
	[CERTREQ,] [IDr,],AUTH,		[CERTREQ,] [IDr,],AUTH,
	SAi2, TSi, TSr} -->		SAi2, TSi, TSr} -->
	< -- HDR, SK {IDr, [CERT,] AUTH,		< -- HDR, SK {IDr, [CERT,] AUTH,
	SAr2, TSi, TSr}		SAr2, TSi, TSr}
	Figure 1: IKE_INIT and IKE_AUTH exchanges		Figure 1: IKE_INIT and IKE_AUTH exchanges
	But it seems too time consuming to establish an IKE SA in these first		The establishment of an IKE SA in the first two exchanges of IKEv2
	two exchanges, especially Diffie-Hellman computation, as we know it		procedure in [RFC4306] (especially Diffie-Hellman computation), is
	is too slow to compute, so it is a challenge to the new gateway when		rather time-consuming. Normally, the IKEv2/IPsec gateway embodyment
	thousands of, even more, ipsec clients are transfered from old		(like IPsec VPN gateway, Mobile IPv6 Home Agent, etc) keeps a large
	gateway to new the gateway.		number of IKE/IPsec sessions. So in some scenarios (see Section 2),
			it will take a very time to re-establish all the IKE SA for session
			resumption of IKEv2/IPsec clients.
	2. Application scenarios		2. Application scenarios of IKEv2 Session Resumption
	2.1. Scenario of failover		2.1. Scenario of IKEv2 Gateway fail
	IPsec old new/old		IPsec old new/old
	client Gateway gateway		client Gateway gateway
	| | |		| | |
	| IKE/IPsec SAs | |		| IKE/IPsec SAs | |
	|< ========================== >| |		|< ========================== >| |
	| | |		| | |
	| | |		| | |
	| O Fail of old GW |		| O Fail of old GW |
	| | |		| | |
	O detect the fail | |		O detect the fail | |
	| of old GW | |		| of old GW | |
	| | |		| | |
	| new IKE init procedure |		| new IKE init procedure |
	|< =================================================== >|		|< =================================================== >|
	| | |		| | |
	| set up other child IPsec SAs |		| set up other child IPsec SAs |
	|< =================================================== >|		|< =================================================== >|
	| | |		| | |
	Figure 2: failover scenarios		Figure 2: scenarios of IKEv2 Gateway fail
	In this scenario, ipsec clients has established IKE connections with		In this scenario, IPsec clients has established IKE/IPsec connections
	old gateway, then for some reason, old gateway fails, after a short		with old gateway with tunnel mode or transporation mode. Because of
	time, ipsec client knows old gateway has failed(how to know gateway		some reason, the old gateway may fail. In this case, IPsec client
	fail is out of our scope), and reconnect to the old gateway or		can know old gateway has failed(how to know gateway fail is out of
	another new gateway. It must be a rush hour, so many ipsec clients		our scope in this draft), and re-establish the IKEv2/IPsec sessions
	connect to the gateway in the same time, as we know, re-establish IKE		with the old gateway or another new gateway. While a large number of
	security associations(SAs) is too slow to compute because of Diffie-		IPsec clients try to make the IKEv2/IPsec connections at the same
	Huffman(DH). The problem statement and goals for a failover solution		moment, it will take a rather long time due to the reason mentioned
	are described in [2].		in Section 1. And, the target gateway may have problem to response
			some clients in this case as well. The problem statement and goals
			for a failover solution are described in [Narayanan06].
	2.2. Scenario of load-balance		2.2. Scenario of load-balance
	IPsec old new		IPsec old new
	client Gateway gateway		client Gateway gateway
	| | |		| | |
	| IKE/IPsec SAs | |		| IKE/IPsec SAs | |
	|< ========================== >| |		|< ========================== >| |
	| | |		| | |
	| | |		| | |
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	| | |		| | |
	| new IKE init procedure |		| new IKE init procedure |
	|< =================================================== >|		|< =================================================== >|
	| | |		| | |
	| set up other child IPsec SAs |		| set up other child IPsec SAs |
	|< =================================================== >|		|< =================================================== >|
	| | |		| | |
	Figure 3: load-balance scenarios		Figure 3: load-balance scenarios
	In this scenario, after establishing IKE connections between ipsec		In this scenario, after establishing IKE connections between IPsec
	clients and old gateway, old gateway may not fail, owing to traffic		clients and old gateway, the old gateway may be over-loading. then,
	engineer or old gateway is over-loading, ipsec clients knows they		some of the IPsec clients should stop the connection with old gateway
	should stop the connection with old gateway and establish the		and establish the connection with new gateway(how to know new gateway
	connection with new gateway(how to know new gateway is also out of		is also out of our scope). Again, while many IKE/IPsec sessions are
	our scope). If many ipsec clients are transferd from old gateway to		transferred from old gateway to new gateway, it is a challenge to new
	new gateway, as same as failover, it is a challenge to new gateway to		gateway to re-establish bunch of IKE SAs at the same time.
	establish IKE SA in the same time.
	3. Details on Proposed solution		3. Details on Proposed solution
	3.1. Overview of the Proposed solution		3.1. Overview of the Proposed solution
	In this section, we define a new data structure stub which has the		In this section, a new data structure is named as "stub", which has
	most important information of IKE SA, and gateway can use this data		the most important information of IKE SA. And gateway can use this
	structure to fast rebuild IKE SA. We expand the IKE_INIT exchange,		data structure to accelerate the rebuilding of IKE SA. IKE_INIT
	and add a payload called IKE_SA_SYN. because old gateway's IP address		message is extended with a new payload called IKE_SA_SYN. Since the
	and SPI can index the unique stub of IKE SA, so we make them in SYN		gateway's IP address and SPI can uniquely index the stub of IKE SA,
	payload to index stub.		these two information are mandatory in the IKE_SA_SYN payload in
			order to retrieve the stub of IKE SA by the target gateway. The
			detailed data structure of Stub is introduced in Section 3.2.
			The IKE SA session resumption procedure in this draft is depicted
			below:
	Initiator Responder		Initiator Responder
	----------- --------------		----------- --------------
	HDR, SAi1, KEi, Ni, [SYN] --->		HDRGBP[not]SAr1, KEi, Ni, [SYN] --->
	< -- HDR, Nr		< -- HDR, Nr
	Figure 4: IKE SA synchronization exchange		Figure 4: IKE SA synchronization exchange
	Once ipsec client has to be transfer from old gateway to new gateway,		o While the IPsec client notices that it has to be transfer from old
	it can send IKE_INIT which is extended a SYN payload as optional, the		gateway to target gateway and want to pursue the fast session
	IKE SYN payload has some index informatin such as old gateway ip		resumption, it sends IKE_INIT message with the SYN payload. The stub
	address and old gateway's SPI, if old/new gateway finds IKE_SA_SYN		indexing information like old gateway IP address and old gateway's
	payload in the IKE_INIT message, it can fast re-establish IKE SA		SPI shall be enclosed in the IKE SYN payload.
	without DH computation and IKE_AUTH exchange, and IKE_INIT respond
	with olny Nr to ipsec client to tell it IKE_SA has been re-
	established. If new gateway does not support IKE_SA_SYN or not find
	the proper stub, it can establish IKE SA by IKE_INIT and IKE_AUTH
	exchanges, or just drop the packet.
	3.2. Key data structure		o Upon receiving the IKE_INIT message with the IKE_SA_SYN payload,
			the target gateway uses the information inside to retrieve the the
			stub of previous IKE SA in the stub bank. if the retrieved stub is
			qualified for IKE SA re-building, the target gateway will choose the
			new SPI, derive the new set of keyring and re-establish the IKE
			session for the related client. Lastly, it sends IKE_INIT response
			with new SPI in the IKEv2 header and Nr. The new IKE_SA has been re-
			established successfully.
	the stub data structure should conclude all these informations. (We		If the taget gateway does not support IKE_SA_SYN or not find the
	have referenced "ticket" proposal[3].)		proper stub, it can establish IKE SA by normal IKE_INIT and IKE_AUTH
			exchanges as specified in [RFC4306], or just drop the packet based on
			the local policy configured by network operator.
			The stub can be stored in an independent stub bank, co-located with
			target gateway or even co-located with the corresponding IPsec
			client. This is discussed in Section 3.5. However, the case of stub
			co-located with IPsec client is only optional in this draft.
			3.2. data structure of stub
			the stub data structure should conclude all these informations.
	o IDi, IDr.		o IDi, IDr.
	o SPIi, SPIr.		o SPIi, SPIr.
	o SAr (the accepted proposal).		o SAr (the accepted proposal).
	o SK_d.		o SK_d_old.
	o shared secret.		o shared secret.
	o old gateway's ip address.		o old gateway's ip address.
			o lifetime
	We propose using c++ STL map data structure to store this stub		In the data structure of stub, the old gateway's ip address and SPI
	message, use old gateway's ip address and SPI as key, and the other		are used as the index for retrieval of stub.
	properties as value. You also can use other data structure to hash
	old gateway's ip address and SPI to other properties.
	SAr have the encrypt and decrypt algorithm, and shared secrect is the		SAr have the encrypt and decrypt algorithm, and shared secrect is the
	DH exchange's result, we can calculate the IKE SA's keyring as rekey		DH exchange's result, we can calculate the IKE SA's keyring as rekey
	process. It will be very quick.		process. It will be very quick.
	3.3. Consideration on Stub handling		3.3. Consideration on building IKE SA in session resumption
	1) generation		After the stub index has been presented by IKE client in the gateway,
			it will retrieve the stub from the stub bank. The way to get the
			stub from the stub bank can be found in Section 3.4.
	When IKE SA has been established(after first two exchanges), the		As shown in Section 3.2, IDi, SA value can be obtained directly from
	gateway extracts the stub from IKE SA and store it.		the retrieved stub. The target gateway shall choose the new SPIr
			(called SPIr_new in this draft) for the key derivation of session
			resumption. The nounce values, Ni and Nr, are from the current IKE
			SYNC exchange.
			So, the new value of SKEYSEED is calculated as below (SK_d_old value
			is from the stub):
			SKEYSEED = prf (SK_d_old, Ni | Nr)
			And the keyring set are derived by the way of generic IKEv2
			{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+
			(SKEYSEED, Ni | Nr | SPIi | SPIr_new )
			The prf (pseudo-random function) of the cryptographic algorithms is
			specified in the SA value of stub.
			3.4. Consideration on Stub handling
			1) generation
			After IKE SA has been established(after first two exchanges), the
			IKE/IPsec gateway extracts the stub from IKE SA.
	2) propagation		2) propagation
	After extrcted from IKE SA, stubs should be updated to infrastructure		After extracted from IKE SA, stubs should be updated to
	such as stub bank(we will define next section) or other gateway.		infrastructure such as stub bank. The stub bank can be independent
			entity in the network or co-located with the gateways (see
			Section 3.5).
	3) look-up		3) Retrieve
	As the old gateway's ip address and spi can index the unique stub.		The gateway can use the the old gateway's ip address and spi can
	Such as map data structure, hash operation is very light-weighted,		index the unique stub.
	you can find it very fast.
	4) usage		4) Expire
	In some senarios, the ipsec clients want to synchrinazation IKE SA		The stub may be invalid when the lifetime expires. The value of
	with a gateway. Then the ipsec clients send IKE_INIT message with		lifetime is recommended to be same as the one in the IKE SA. The
	SYN payload to old/new gateway, gateway will get old gateway's IP		gateway may set different lifetime in stub.
	address and SPI from IKE_SA SYN payload, and find the stub in local
	machine database (maybe download the stub from other gateway or stub		5) Delete
	bank before), then rebuild the IKE SA. If IKE SA has been
	established, gateway sends IKE_INIT respond(only conclude HDR and Nr)		When the IKEv2/IPsec session is deleted, the gateway shall delete the
	to ipsec client. then create-child-sa exchanges, and so on.		related stubs in the stub bank.
	The following signaling shall be supported by IKE/IPsec gateways to		The following signaling shall be supported by IKE/IPsec gateways to
	communicate with Stub.		communicate with Stub bank.
			o Initiate Stub:
			Gateway initiates the stub in the stub bank once new stub has been
			established. The index shall at least include the gateway's IP
			address and SPI.
	o Update Stub:		o Update Stub:
	Gateway updates its stub to infrastructure once new stub has been		Gateway updates its stub to infrastructure once the related IKE SA
	established, and the infrastructure store them by gateway's IP		has been changed
	address and SPI in a hash data structure.
	o GET Stub:		o GET Stub:
	Gateway receives IKE_SA SYN payload, then it send GET Stub to ask for		Gateway uses this message to receives stub by the information in
	some stubs, the infrastructure index the stubs.		IKE_SA SYN payload from IKE client.
	o Download Stub:		o Download Stub:
	After infrastructure finds the stubs, it pushs the stubs to gateway.		The stub bank can use this message to push the stubs to gateway.
	3.4. Consideration on location of Stub		o Delete Stub:
			The Gateway can delete the stubs while the related IKE SAs are no
			longer available.
			3.5. Consideration on location of Stub
	1. Centralized infrastructure		1. Centralized infrastructure
	ipsec old/new stub		IPsec old Target stub
	client gateway bank		client GW GW bank
	|| || Update Stub ||		| | | |
	|| HDR,SAi1,KEi,Ni,SYN||------------------->||		| IKE/IPsec | | |
	||------------------->|| GET Stub ||		|< ================= >| | Update Stub |
	||< ------------------||------------------->||		| | ------------------------>|
	|| HDR,Nr || Download Stub ||		| o Fail | |
	|| ||< ------------------||		| | | |
	|| || ||		| HDR,SAr1,KEi,Ni,SYN | |
			|----------------------------->| GET Stub |
			| | |---------------->|
			| | | Download Stub |
			| | |< ---------------|
			| HDR,Nr | | |
			|< --------------------------- | |
			| | | |
	Figure 5: centralized structure		Figure 5: centralized structure
	This proposal has a centralized Stub Bank server, gateway doesn't		This proposal has a centralized Stub Bank server, gateway doesn't
	need local stub database.		need local stub database.
	a) After IKE connection has been established, old gateway update the		a) After IKE connection has been established, old gateway set up the
	stub to stub bank.		stub to stub bank.
	b) Once transferring ipsec from old gateway to old/new gateway, ipsec		b) Once the fast session resumption is started, IPsec client sends
	client send IKE_INIT with SYN payload.		IKE_INIT with SYN payload.
	c) When old/new gateway receives IKE_INIT with SYN payload, it ask		c) When the target gateway receives IKE_INIT with SYN payload, it
	Stub Bank for stub via GET Stub signaling.		asks Stub Bank for stub via GET Stub signaling.
	d) stub bank push proper stub to old/new gateway.		d) stub bank push proper stub to target gateway.
	old/new gateway find the proper stub and rebuild IKE SA, then send		e) Target gateway gets the stub and rebuild IKE SA, then send HDR, Nr
	HDR, Nr to tell ipsec client that it has accepted the stub.		to Notify IPsec client that the new IKE SA has been set up by IKE
			SYNC session resumption.
	2. Distributed infrastructure		2. Distributed infrastructure
			IPsec Target Old GW
	ipsec old/new Old GW
	client gateway Stub		client gateway Stub
	|| || ||		| | |
	|| HDR,SAi1,KEi,Ni,SYN|| Update Stub ||		| HDR,SAr1,KEi,Ni,SYN| Update Stub |
	||------------------->||< ------------------||		| ------------------->| < ------------------|
	||< ------------------|| ||		| < ------------------| |
	|| HDR,Nr || ||		| HDR,Nr | |
	Figure 6: distributed structure		Figure 6: distributed structure
	This structure doesn't have centralized Stub Bank, and all gateway		This structure doesn't have centralized Stub Bank, and all gateway
	must have local stub database, if there is stub in local database, it		must have local stub database. if there is stub in local database, it
	will find the stub in local database, otherwise, it will GET the stub		will find the stub in local database, otherwise, it will GET the stub
	from other gateway.		from other gateways.
	a) After IKE connection has been established, old gateway update the		a) After IKE connection has been established, old gateway initiates
	stub to stub bank.		the stub to the potential target gateway.
	b) Once transferring ipsec from old gateway to old/new gateway, ipsec		b) Once session resumption is initiated, IPsec client send IKE_INIT
	client send IKE_INIT with SYN payload.		with SYN payload.
	c) old/new gateway find the proper stub and rebuild IKE SA, then send		c) Target gateway finds the proper stub and rebuild IKE SA, then send
	HDR, Nr to tell ipsec client that it has accepted the stub.		HDR, Nr to IPsec client.
	Gateway has to store stubs in distributed structure, but it seems		Gateway has to store stubs in distributed structure, but it seems
	more simple than centralized structure. Also, these two proposals		more simple than centralized structure. Also, these two proposals
	can mix together, other gateway also can be Stub Bank.		can mix together, other gateway also can be Stub Bank.
	3.5. When should Gateways download/update Stub		3. Full distributed in IKEv2/IPsec Client
	Because of the stub is not sensitive with time, we can assemble the		There is also the possibility that the Gateway or Stub bank push the
	stub messages to reduce the message number in update event.		stub to the corresponding client. During the session resumption
			process, the target gateway can have another option to retrieve the
			stub from the corresponding client by the way specified in
			Section 3.4. But, this way of stub co-located with IPsec client is
			ONLY OPTIONAL. if the operator wants to use this case, the stub MUST
			be protected perfectly by strong encryption and integrity protection.
			So, in this draft, it is only optional to co-locate the stub in the
			client.
			3.6. When should Gateways download/update Stub
			Because of the stub is not sensitive with time, the gateways assemble
			the stub messages to reduce the message number in initiate event.
	The single gateway can get many stubs at a time in download event.		The single gateway can get many stubs at a time in download event.
	The gateway may also update the stubs in bundles whenever it was		The gateway may also update the stubs in bundles whenever it was
	thought to be necessary		thought to be necessary
	3.6. Related new messages		3.7. Related new messages
	1)IKE_SA_SYN Payload format		1)IKE_SA_SYN Payload format
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GateWay's SPI |		| GateWay's SPI |
	| |		| |
	skipping to change at page 10, line 4 ¶		skipping to change at page 11, line 26 ¶
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GateWay's IP Address |		| GateWay's IP Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	C bit is the direction of this message.		C bit is the direction of this message.
	2) Stub related signaling		2) Stub related signaling
	Header Format		Header Format
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload| type | Payload Length |		| Next Payload| type | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	type number		type number
	update 01		Init 0x01
	get 10		update 0x02
	download 11		get 0x03
	reserved 00		download 0x04
			delete 0x05
			reserved 0x00
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload| RESERVED | Payload Length |		| Next Payload| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| PAYLOAD CONTENT |		| PAYLOAD CONTENT |
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	4. Modification on the base IKEv2 protocol		4. Modification on the base IKEv2 protocol
	As our principle, The base IKEv2 protocol should be changed as little		As the core principle of this draft, the base IKEv2 protocol should
	as possible. In the proposal, three aspects require slight		be changed as little as possible. In the proposal, three aspects
	modification on IKEv2 protocol		require slight modification on IKEv2 protocol in [RFC4306]
	1) new IKE message: IKE_SA_SYN		1) new IKE payload in the IKE_INIT message: IKE_SA_SYN
	2) modification on the state machine		2) Modification on the state machine
	As ipsec client, it can send IKE_INIT message with SYN payload as		IPsec client can send generic IKE_INIT message with SYN payload, if
	usual, and if it receives IKE_INIT respond only have Nr, it will		it decides to use the session resumption. Upon receiving IKE_INIT
	calculate the new ike sa like rekey. And set state to ike sa has		response only with the Nr and SPIr_new, it will calculate the new IKE
	been established.		SA as IKE SA rekey. And set state to IKE SA has been established. if
			the session resumption can not be accepted by the target gateway, the
			client will receive the usual IKE_INIT response as in [RFC4306] and
			continue the usual IKE_AUTH procedure afterwards
	As gateway, once receives IKE_SA_SYN payload, will firstly find the		The target gateway, once receives IKE_SA_SYN payload, will firstly
	proper stub, if find the stub, it will fast re-establish IKE SA, send		find the proper stub. if the stub can be found successfully, it will
	IKE_INIT respond with Nr only to ipsec client, and set state to ike		follow the session resumption proecedure as specified in this draft:
	sa has been established.		re-establish IKE SA, send IKE_INIT respond with Nr only to ipsec
			client, and set state to IKE SA has been established. if the session
			resumption can not be accepted by target gateway, it just follows the
			usual IKEv2 initiation procedure as in [RFC4306]
	3) The gateway should support the Stub related functions like		3) The gateway should support the Stub related functions as specified
	extract_stub, update_stub and get_stub		in Section 3.4
	5. Security Considerations		5. Security Considerations
	the security framework of IKEv2 protocol will not be compromised in		the security framework of IKEv2 protocol will not be compromised in
	this solution.		this solution.
	1) index is a light-weighted operation, and no stub, no response.		1) The stub index (Old gateway's IP address and SPI) in IKE_SA_SYN is
			a light-weighted information, which can be transported without
			encryption. And it relies on IKE_INIT message to handle the replay
			protection and DoS attack.
	2) The Gateway can use SAr1, KEi to verify the identity, such as ID		2) The Gateway can use SAr1, KEi to verify the identity, such as ID
	property. But it depends on the configuration of operators.		property.
	3) Even if the index is right, ipsec client cannot rebuild IKE_SA,		3) Even if the index is right and IPsec client cannot rebuild IKE_SA
	the communication can't last, after a little time, the IKE_SA in		because of some reason, the newly re-built IKE SA in gateway will be
	gateway will be deleted.		deleted after somewhile.
			4) In the case of stub co-located with IPsec Client, the stub MUST be
			perfected protected to prevent the malicious attackers from cracking
			the stub, if they can obtain the stub on the network. Actually, even
			if the stub is strongly encrypted, there still has the risk. With
			the development of harware in accord with the Moore's Law, the
			capability of computing equipment will be increased step by step.
			Sometime, somehow, the brutal force decryption of the stub encryption
			method may be possible. And, there is also posibility that the
			currently safe encryption algorithm may be proved to be
			mathematically solvable. So, all in all, it is only optional to
			tranport the stub on the untrusted network, even if it can be
			protected strongly.
	6. Conclusion		6. Conclusion
	In this draft, a new solution is proposed to do IKE SA		In this draft, a new solution is proposed to do IKE SA
	synchrinization for fast re-establishment of IKE SA. It will remove		synchrinization for quick session resumption of IKE SA. With the
	the most time-consuming IKEv2 exchanges, which makes it much faster		extension of IKE_SA_SYNC payload in IKE_INIT message, it can remove
	to transfer millions of ipsec clients from old gateway to old/new		the most time-consuming IKEv2 exchanges to re-build the IKE SA, which
	gateway. And the proposal in this draft will only slightly modify		makes it much faster to transfer millions of IKE sessions from old
	the base IKEv2 protocol with a new logical IKE SA Stub in the		gateway to target gateway. And the proposal in this draft will just
	network.		slightly modify the base IKEv2 protocol with a new logical IKE SA
			Stub bank in the network.
	7. Normative References		7. Normative References
	[Narayanan06]		[Narayanan06]
	Narayanan, V., "IPsec Gateway Failover and Redundancy		Narayanan, V., "IPsec Gateway Failover and Redundancy
	Problem Statement and Goals",		Problem Statement and Goals",
	draft-vidya-ipsec-failover-ps-00.txt (work in progress),		draft-vidya-ipsec-failover-ps-00.txt (work in progress),
	December 2006.		December 2006.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	skipping to change at page 15, line 26 ¶		skipping to change at page 16, line 26 ¶
	Peng Yang		Peng Yang
	Hitachi (China) R&D Corporation		Hitachi (China) R&D Corporation
	301, North Wing, Tower C Raycom Infotech Park		301, North Wing, Tower C Raycom Infotech Park
	2 kexueyuan Nanlu		2 kexueyuan Nanlu
	Haidian District		Haidian District
	Beijing, 100080		Beijing, 100080
	P.R. China		P.R. China
	Phone: +861082862918(ext.)328		Phone: +861082862918(ext.)328
	Email: pyang@hitachi.cn		Email: peng.yang.chn@gmail.com
	Yuanchen Ma		Yuanchen Ma
	Hitachi (China) R&D Corporation		Hitachi (China) R&D Corporation
	301, North Wing, Tower C Raycom Infotech Park		301, North Wing, Tower C Raycom Infotech Park
	2 kexueyuan Nanlu		2 kexueyuan Nanlu
	Haidian District		Haidian District
	Beijing, 100080		Beijing, 100080
	P.R. China		P.R. China
	Phone: +861082862918(ext.)327		Phone: +861082862918(ext.)327
	Email: ycma@hitachi.cn		Email: ycma@hitachi.cn
	Hui Deng		Hui Deng
	China Mobile		China Mobile
	Xu Ke		53A,Xibianmennei Ave.,
			Xuanwu District,
			Beijing 100053
			China
			Email: denghui@chinamobile.com
			Ke Xu
	Tsinghua University		Tsinghua University
	Department of Computer Science		Department of Computer Science
	Tsinghua University		Tsinghua University
	Haidian District		Haidian District
	Beijing, 100088		Beijing, 100088
	P.R. China		P.R. China
	Email: xuke@mail.tsinghua.edu.cn		Email: xuke@mail.tsinghua.edu.cn
	Full Copyright Statement		Full Copyright Statement
End of changes. 66 change blocks.
	178 lines changed or deleted		290 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/