Subject: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt ticket location

From: "Hui Deng" <[email-masked]>
Date: Tue, 18 Nov 2008 14:07:09 +0800

Hello, authors,

After reading your draft and rethinking of the main issues, I would like to
raise one issue about ticket location issue:
there have two problems on sending tickets with all the information to the
client

a) If the session resumption solution is deployed in mobile network,
it will consume a lot of air-interface cost to request/present/update
the ticket. As the mobile operators, we prefer not do that.

b) As discussed in the list, the packet to send the ticket may be
fragmented. When session resumption happened, a large number of the
client may try to present the ticket at the same time. In this case, a
bunch of fragmented IP packets will be sent to the gateway. Some
equipments (such as mobile network GW, firewalls, etc) between clients
and gateway may be overloaded to handle the IP fragment. And, some
equipments may treat it as DoS attack and simply drop all the
fragmented packets. the most important issue, the wireless base station
will be chunked and died.

thanks for your consideration. under this consideration, we would like to
recommend the solution which could store the ticket information purely on
the network side.
thanks for your consideration.

-Hui
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Nov 2008 10:52:20 +0200

Hi Hui,

On Nov 18, 2008, at 8:07 AM, Hui Deng wrote:

> Hello, authors,
>
> After reading your draft and rethinking of the main issues, I would  
> like to raise one issue about ticket location issue:
> there have two problems on sending tickets with all the information  
> to the client
>

The draft does not specify the ticket format. This could be very  
compact, down to 16-24 bytes, including notification payload header.

> will be chunked and died.

I understand that resumption may have severe implications for the core  
network - lots of simultaneous IKE traffic, but aren't the clients  
supposed to be spread out among very many base stations?  I didn't  
think there should be congestion at the base stations.
> thanks for your consideration.

The "ticket" could be a 64- or 128-bit index into a database table,  
giving a total payload size of 16 or 24 bytes respectively. I believe  
a payload this small should not overload the "air". Does a solution  
such as this address your concerns?

Hope this helps

Yoav

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 18 Nov 2008 23:13:28 +0800

2008/11/18 Yoav Nir <[email-masked]>

>> After reading your draft and rethinking of the main issues, I would like
>> to raise one issue about ticket location issue:
> The draft does not specify the ticket format. This could be very compact,
> down to 16-24 bytes, including notification payload header.

> network - lots of simultaneous IKE traffic, but aren't the clients supposed
> to be spread out among very many base stations?  I didn't think there should
> be congestion at the base stations.

it depends on how to express it, mostly congestion will happen in security
gateway or firewall, sometime it also lead to the congestion at the base
station. it depends on how many subscribers under this base station, how
could the signaling channel of this base station to handle this. Anyway, I
think this issue exists.

> The "ticket" could be a 64- or 128-bit index into a database table, giving
> a total payload size of 16 or 24 bytes respectively. I believe a payload
> this small should not overload the "air". Does a solution such as this
> address your concerns?

this working group doc already refer to our input, so we are fine with this.

-Hui

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 18 Nov 2008 07:58:05 -0800 (PST)

Hello,

> 2008/11/18 Yoav Nir <[email-masked]>
[snip]
>> supposed

  It should not matter what traffic the subscribers are sending. If the
base station does not have trouble supporting them while they send random
data traffic then it will not have trouble supporting them when they
initiate IKE session resumption. If it is having trouble supporting them
when they initiate IKE session resumption then you have problems at your
base station that have nothing to do with IKE session resumption.

  Dan.

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 19 Nov 2008 00:49:12 +0800

see below inline.

2008/11/18 Dan Harkins <[email-masked]>

> base station that have nothing to do with IKE session resumption.

Current base station are handling fragmentation as a critical issue.
during the session resumption, fragmentition could ead it to die.

-Hui

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 18 Nov 2008 15:00:30 +0200

I am a bit confused about the performance restrictions of cellular systems
that are being described. 
Given that the IKEv2 exchanges are infrequent and that the ticket size is
indeed small I was wondering what type of environment we are talking about
where it comes to overload situations at base stations with a ticket. I
guess in such an environment it would be difficult to download a webpage or
anything else. 

I would like to learn a bit more about the environments we are talking
about. 

Irrespectively of that question I am wondering why this is an issue at all
given that the draft does not mandate a specific format (neither ticket nor
reference). Nothing additional needs to be standardized from that point of
view. 
 
Ciao
Hannes

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hui Deng
	Sent: 18 November, 2008 17:13
	To: Yoav Nir
	Cc: [email-masked]
	Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt
ticketlocation

		Hi Hui, 

			Hello, authors,
			
			After reading your draft and rethinking of the main
issues, I would like to raise one issue about ticket location issue:
			there have two problems on sending tickets with all
the information to the client
			
			a) If the session resumption solution is deployed in
mobile network,
			it will consume a lot of air-interface cost to
request/present/update
			the ticket. As the mobile operators, we prefer not
do that.

		The draft does not specify the ticket format. This could be
very compact, down to 16-24 bytes, including notification payload header. 

		

			b) As discussed in the list, the packet to send the
ticket may be
			fragmented. When session resumption happened, a
large number of the
			client may try to present the ticket at the same
time. In this case, a
			bunch of fragmented IP packets will be sent to the
gateway. Some
			equipments (such as mobile network GW, firewalls,
etc) between clients
			and gateway may be overloaded to handle the IP
fragment. And, some
			equipments may treat it as DoS attack and simply
drop all the
			fragmented packets. the most important issue, the
wireless base station
			will be chunked and died.

		I understand that resumption may have severe implications
for the core network - lots of simultaneous IKE traffic, but aren't the
clients supposed to be spread out among very many base stations?  I didn't
think there should be congestion at the base stations. 

	it depends on how to express it, mostly congestion will happen in
security gateway or firewall, sometime it also lead to the congestion at the
base station. it depends on how many subscribers under this base station,
how could the signaling channel of this base station to handle this. Anyway,
I think this issue exists.

			thanks for your consideration. under this
consideration, we would like to
			recommend the solution which could store the ticket
information purely on
			the network side.
			thanks for your consideration.

		The "ticket" could be a 64- or 128-bit index into a database
table, giving a total payload size of 16 or 24 bytes respectively. I believe
a payload this small should not overload the "air". Does a solution such as
this address your concerns?

	this working group doc already refer to our input, so we are fine
with this.
	 
	-Hui 

		Hope this helps
		
		Yoav

---

From: "Peny Yang" <[email-masked]>
Date: Wed, 19 Nov 2008 06:35:08 +0800

Hi, Hannes:

Please check inline:

On Tue, Nov 18, 2008 at 9:00 PM, Hannes Tschofenig
<[email-masked]> wrote:
> indeed small
[Peny] In the case of ticket-by-reference, it's small. In case of
ticket-by-value, there is the possibility.

> I was wondering what type of environment we are talking about
[Peny] what's in my mind is that all the clients under one base
station will try to present the tickets at the same time during
session resumption. At this time, the reverse link of the BS may be
fully occupied for a while depends on the reserver link capacity and
traffic status.If the ticket is fragmented, more air-resources will be
consumed. And if fragmented, BS need to reassemble the packets to do
some work required by access network. In this case, most of CPU
resources of BS may be consumed, which could even make the BS down.
Another possibility is that BS just simply drops all the fragmented
messages (with ticket inside) to be on the safe side based on the
local policy.

> reference). Nothing additional needs to be standardized from that point of
[Peny] Well, in case of ticket-by-value, there is the possibility that
message of presenting ticket is fragmented.

Peny