Subject: Re: [IPsec] Resuming the session resumption discussion

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Oct 2008 23:46:40 +0200

On Oct 14, 2008, at 6:35 PM, 胡泊 wrote:

> Hi, Yoav and all:
>
> This discussion is becoming more and more interesting. Please check my
> reply below:
>
>>> The ticket shares the packet with traffic selectors, configuration
>>> payload, authentication, certificates and other payloads. That
>>> packet can be quite large, which leads to fragmentation and  
>>> potentially
>>> packet loss.
>
> In this sense, the message to deliver ticket could suffer from the IP
> fragmentation. Well, when we see the RFC4306 (IKEv2£©£¬the  
> following
> lines can be found:
>
> =====================
>  Although IKEv2 messages are intended to be short, they contain
>  structures with no hard upper bound on size (in particular, X.509
>  certificates), and IKEv2 itself does not have a mechanism for
>  fragmenting large messages.  IP defines a mechanism for fragmentation
>  of oversize UDP messages, but implementations vary in the maximum
>  message size supported.  Furthermore, use of IP fragmentation opens
>  an implementation to denial of service attacks [KPS03].  Finally,
>  some NAT and/or firewall implementations may block IP fragments.
>
> =====================
> Obviously, base IKEv2 protocol recommends short messages. In the
> ticket solution, except for the ticket presentation, the GW surely
> need to push the tickets to clients by IKEv2 messages beforehand. Will
> the fragmented packet for ticket delivery compromise the principle of
> IKEv2 base protocol?
>
> Does anybody in this list can clarify How much negative effect of
> message fragmentation is on IKEv2 operation?
>
> Thanks
>
> -Po

IKEv2 recommends short messages, but then goes on to include in the  
last IKE_AUTH packet the traffic selectors (which may include the  
entire protected networks), the configuration payload (which may also  
include the entire protected networks, but in a different format,  
certificates (which have no upper bound on size) and potentially even  
CRLs.  So that packet is already in danger of being too large, and  
adding a chunky payload like the ticket increases the likelihood of  
fragmentation.

As for the negative effects, there is obviously the problem of packet  
loss. In a high packet loss environment (wireless devices come to  
mind) if, say, 30% of packets get lost, 50% of 2-fragment packets will  
be lost, and 65% of 3-fragment packets. Also, as the IKEv2 document  
says, some operating systems will have a limit on assembly, as will  
some firewalls that reassemble fragments to inspect the packet in full.

In the early 2000's a lot of wireless access points, home routers, DSL  
modems and such were broken - they dropped all fragments, so any  
packet larger than the MTU was doomed to be dropped. Things were so  
bad, that my company had to invent a proprietary IKE-over-TCP just to  
get client connections working. This has vastly improved. Today most  
such equipment is working well, and fragments are passed through  
correctly. Operating systems in use today are also in better shape,  
and I can't think of any current version that won't handle UDP packets  
as large as the standards allow. Packet loss is still an issue, but  
for regular wired and wireless access, even most cellular, packet loss  
is reasonably low.

I admit that my experience may not be representative of all the world,  
but IMO some fragmentation is not as big a problem as it used to be.

Yoav

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

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 20 Oct 2008 19:35:13 +0200

[Spoken as a coauthor of draft-tschofenig:]

Draft-tschofenig does have a facility to mitigate this issue, by ensuring that the ticket is the only thing that goes into the IKE message. Quoting from the draft:

o  [The gateway] returns an N(TICKET_ACK), if it cannot grant a ticket
      immediately, e.g., due to packet size limitations.  In this case
      the client MAY request a ticket later using an Informational
      exchange, at any time during the lifetime of the IKE SA.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Tuesday, October 14, 2008 23:47
To: 胡泊
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] Resuming the session resumption discussion

Yoav