Subject: [IPsec] Fragmentation causing IKE to fail

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Jun 2012 18:20:56 +0300

Hi

I work for a vendor selling and IKE/IPsec solution.

In the last few months, we've heard a troubling complaint from some of our customers. They say that some ISPs have begun to drop IP fragments. While specific ISPs were not named, most of the issues seem to be in south-east Asia. One customer has speculated that this has something to do with preparing to deploy CGNs.

According to draft-ietf-behave-lsn-requirements, CGNs MUST comply with the NAT requirements for UDP as in RFC 4787, and that RFC says in section 11 that NAT devices MUST support fragments. So these routers are not compliant, but that doesn't help our customers much.

Most traffic on the Internet is either TCP or small-packet UDP. The IKE protocol (both versions) has the rather rare distinction of having large UDP packets. These are packets #5 and #6 in IKEv1 Main Mode, or the IKE_AUTH packets in IKEv2, especially when using certificate authentication.

For now, the customers managed to "fix" the ISP with an angry phone call. That got them into an exception list where fragments are not dropped. One had to change ISPs for that. While this can work for a while, it won't work when the carrier doing the dropping is not the one that the customer has a business relationship with, but another one downstream.

Trying to think up ways to deal with this, I can think of some:

* Get all ISPs to stop dropping fragments. This would be great, but as the saying goes, you are so not in charge.

* Find ways of making the packets smaller: move to PSK, fiddle with trust anchors so that only one cert is needed, avoid sending CRLs, hash-and-URL, etc. These are not always successful, and often require more configuration than we would like.

* Build a fragmentation layer within IKE, so IKE messages are broken into several packets that get reassembled at the destination. This is the path taken by one of our competitors [1]. This means that IKE has segmentation in addition to other TCP-like features such as retransmission.

* Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to "ISAKMP". We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel.

Have others on this list run into this issue?  

Yoav

[1] http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_fragment_ike_pack.html
[2] http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jun 2012 09:15:38 -0700

> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to "ISAKMP". We have had IKE running over TCP for several years for remote access clients. This was done bec…

* Use IKE over TCP only after IKE over UDP fails during transmission of a packet >512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of course), it costs little, and is trivial to implement.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Jun 2012 12:43:57 -0400 (EDT)

> * Use IKE over TCP only after IKE over UDP fails during transmission of a packet >512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of…

Is that compatible with some vendor's tcp port 10000 implementation?

Also, if we are doing this, I'd prefer to be able to signal which tcp
port to use, to make it more flexible to bypass port 500 blocks (which
is part of the tcp 10000 implementation I believe)

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jun 2012 09:54:36 -0700

> Is that compatible with some vendor's tcp port 10000 implementation?

Why should I care about that completely non-standard use? Seriously.

> is part of the tcp 10000 implementation I believe)

That seems fine to me. However, assuming that a firewall that blocks TCP/500 will not block TCP/somerandomnewnumber is not wise.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Jun 2012 12:26:16 -0500

> That seems fine to me. However, assuming that a firewall that blocks TCP/500 will not block TCP/somerandomnewnumber is not wise.

Use port 80.

(I'm being half facetious, half sarcastic, and half serious with this.)

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jun 2012 10:40:18 -0700

> (I'm being half facetious, half sarcastic, and half serious with this.)

Being non-all-of-the-above: that won't work. Many firewalls that are blocking UDP fragments do deep packet inspection on port 80 and will throw away traffic that doesn't look like HTTP. (Don't get me started on "look like"...)

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Jun 2012 12:55:41 -0500

> Being non-all-of-the-above: that won't work. Many firewalls that are blocking UDP fragments do deep packet inspection on port 80 and will throw away traffic that doesn't look like HTTP. (Don't get…

To be closer to 100% serious I'd have to advocate an HTTP mapping of
IKE and/or use of port 443.  I'm not sure that I want to go there, but
really, if you want to get past deep inspection nowadays then your
best bet seems to be port 443.  Which, of course, would not be enough.
 You'd find that ESP (encapsulated in UDP or not) also gets filtered,
so you'd have to start sending ESP over HTTPS.  And that's all kinds
of not fun.

At some point though one has to give up and declare the ISP useless.
If you're a dissident in Iran, well, you're not using IPsec anyways,
and Tor and all things port 443 are really your only friends, and if
in the end the great firewalls get good enough, well, what can we do
as far as *standards*?  Not much.  But I don't think Yoav was talking
about this case, just a lousy ISP case, and for that I suspect deep
packet inspection is not really the problem.  For Yoav I suspect that
IKE over TCP + UDP encapsulation of ESP is the way to go; worst case
scenario: ESP over TCP.

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Jun 2012 15:18:49 -0400

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> Trying to think up ways to deal with this, I can think of some:

    Yoav> * Get all ISPs to stop dropping fragments. This would be
    Yoav> great, but as the saying goes, you are so not in charge. 

1) better diagnostics would help the end users point the finger
   properly.  I wish the POSIX/BSD APIs would give the application
   an error when a fragment assembly times out..

    Yoav> * Build a fragmentation layer within IKE, so IKE messages are
    Yoav> broken into several packets that get reassembled at the
    Yoav> destination. This is the path taken by one of our competitors
    Yoav> [1]. This means that IKE has segmentation in addition to other
    Yoav> TCP-like features such as retransmission. 

I proposed this for IKEv2 awhile ago.  I twould be worthwhile for people
who like certificates.

    Yoav> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP
    Yoav> port 500 is already allocated to "ISAKMP". We have had IKE
    Yoav> running over TCP for several years for remote access
    Yoav> clients. This was done because remote access clients connect
    Yoav> from behind some very dodgy NAT devices, and some of those do
    Yoav> drop fragments. Getting this behavior at the ISP is novel. 

And ESP over TCP on port 4500?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Jun 2012 00:53:19 +0300

> * Use IKE over TCP only after IKE over UDP fails during transmission of a packet >512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of…

This is possible, but since UDP is not reliable, you'd have to retransmit several times before giving up on UDP. Even if we shorten the "at least a dozen times over a period of at least several minutes", it's still long enough for users to feel - get the "connection with Exchange lost" message in Outlook, for example. 

You could begin both UDP (first IKE message) and TCP's 3-way handshake at the same time. If the 3-way handshake completed in time, the larger packets would go over that connection. If not, they would go over TCP.

But all this is implementation-specific details. I'm more interested in hearing whether others are seeing this (I would guess yes, otherwise Cisco would not have developed the IKE fragments), and on whether there is interest in the group in an IKE-over-TCP draft.

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jun 2012 15:01:41 -0700

> This is possible, but since UDP is not reliable, you'd have to retransmit several times before giving up on UDP. Even if we shorten the "at least a dozen times over a period of at least several min…

Good point.

> You could begin both UDP (first IKE message) and TCP's 3-way handshake at the same time. If the 3-way handshake completed in time, the larger packets would go over that connection. If not, they wou…

Yuck. But possibly the right answer.

> But all this is implementation-specific details. I'm more interested in hearing whether others are seeing this (I would guess yes, otherwise Cisco would not have developed the IKE fragments), and o…

Please consider "IKE-with-TCP-and-UDP" before "IKE-over-TCP".

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Jun 2012 01:05:47 +0300

>> That seems fine to me. However, assuming that a firewall that blocks TCP/500 will not block TCP/somerandomnewnumber is not wise.

Well, we came up with IKE-over-TCP for clients in 2002. That worked OK with broken routers and NAT devices, but not with firewalls. So in 2003 we came up with sending both IKE and IPsec over port 443 (because at the time few firewalls other than ours validated that what goes on port 443 looks like SSL). Finally in 2005 we came out with a client that actually uses SSL for traffic, so that firewalls have to either be SSL proxies or do traffic flow analysis to recognize non-HTTPS.

But this arms race between tunneling clients and firewalls is not the issue here. Without getting into the whole net neutrality controversy, ISPs are not supposed to, nor are they trying to block the creation of tunnels. What they are doing is saving themselves the need to keep state on received fragments, which allows better scale and better performance with the same hardware.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Jun 2012 18:09:55 -0400 (EDT)

> But all this is implementation-specific details. I'm more interested in hearing whether others are seeing this (I would guess yes, otherwise Cisco would not have developed the IKE fragments), and o…

Yes we have seen this in the past with openswan, though people affected
would usually use 2048 bit RSA keys instead of 1024 bit RSA keys.
And usually in combination with a CAcert without intermediary CAs.

We would advise them to use 1024 and the IKE fragemntation problem would
go away.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Jun 2012 01:13:43 +0300

> Please consider "IKE-with-TCP-and-UDP" before "IKE-over-TCP".

I think we can accommodate different implementations by requiring:
 - that initiator MAY switch back and forth between TCP and UDP
 - that responder MUST respond in the same transport where the request arrived
 - that responder must not depend on all requests for a particular flow coming through the same transport. For example, it's perfectly acceptable for the first request of Main Mode to come over UDP, while the next two come over TCP.

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 8 Jun 2012 09:05:03 +0500

Hi,

we've being running into this issue constantly. I think it is serious problem
for road warriers, who have to deal with all kinds of buggy or crippled SOHO
routers installed in hotels etc. Many our customers complain that they are
unable to connect to main office while being on business trip and most
offen the reason is inability (or unwilling) of some intermediate router(s) to pass
UDP fragments.

> * Get all ISPs to stop dropping fragments. This would be great, but as the saying goes,
you are so not in charge.

No an option.

> * Find ways of making the packets smaller: move to PSK, fiddle with trust anchors so
that only one cert is needed, avoid sending CRLs, hash-and-URL, etc. These are not always
successful, and often require more configuration than we would like.

Not an option either. Corporate PKI has plenty of requirements to deal with and
the requirement to make certificates smaller is the least. Hash-and-URL is a nice
feature, but it requires an additional infrastructure that not every customer is
willing to deploy.

> * Build a fragmentation layer within IKE, so IKE messages are broken into several
packets that get reassembled at the destination. This is the path taken by one of our
competitors [1]. This means that IKE has segmentation in addition to other TCP-like
features such as retransmission.

I like this approach, but as far as I know this is done for IKEv1 only.

> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated
to "ISAKMP". We have had IKE running over TCP for several years for remote access clients.
This was done because remote access clients connect from behind some very dodgy NAT
devices, and some of those do drop fragments. Getting this behavior at the ISP is novel.

IKE over TCP has its drawbacks. It eliminates the ability of IKE to be stateless (with
COOKIE),
thus considerably increasing its vulnerability to DoS attack. Switching between UDP and
TCP
(especially in the middle of exchange) considerably complicates protocol that is already
complex in that part (remember switching to port 4500 on the fly).

> Have others on this list run into this issue?

I'm in favor of developing standard way of fragmenting big packets in IKEv2.
I beleive there might be relatively simple solutions not breaking core protocol
implementation.

Regards,
Smyslov Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 9 Jun 2012 10:40:06 +0500

Hi, 

> Hash-and-URL do require customer to deploy www-server. I admit that
> for some enterprices that might be burden to deploy, but quite a lot
> of other enterprices do already have working deployed www-server they
> can use...
> 
> The url can be static, the certificate stored on that url can be
> static, new certificates needs to be pushed to www-server only and
> only when the new certiticate is enrolled. The url can be something
> like http://certs.example.com/<ca-short-name>/<hash-of-cert>.
> 
> Hash-and-URL should make the packets small enough that fragmentation
> is not needed (especially if network supports 1280 byte packets). 

> > > * Build a fragmentation layer within IKE, so IKE messages are
> > > broken into several packets that get reassembled at the
> > > destination. This is the path taken by one of our competitors [1].
> > > This means that IKE has segmentation in addition to other TCP-like
> This also requires finding pmtu and so on which means this whole
> protocol gets quite complicated. 

Not necessary. For the sake of simplicity you may always fragment to 
the smallest packets guaranteed to pass through (576 bytes for IP4). 
IKE is not bulk transfer protocol, so performance is not an issue here.

> If mechanisms already defined in the IKEv2 (Hash-and-URL etc) are not
> enough, then I think IKE over TCP is the way to go. Most likely it
> would be better to do it similarly we do NAT-T, i.e. instead of
> switching to UDP port 4500 we would switch to TCP port 4500 for the
> IKE_AUTH packets. Nothing prevents starting the creation of the TCP
> connection while sending the first IKE_SA_INIT packet over UDP.
> 
> As with NAT-T we can either start over TCP port 4500 immediately from
> the beginning, if we like (i.e. we know from previous experience or
> from configuration that we should do that). As with NAT-T we can use
> either UDP or TCP port 4500 at will, regardless whether NAT was
> detected or not.
> 
> Also either end can send requests either over UDP or TCP and reply
> would come back over same channel. In some cases we might want to
> send packet first with UDP, and if we do not get any replies back for
> our requests, we might want to fall back to TCP. In the other hand
> there is no point of sending retransmissions to TCP connection, i.e.
> we always only send one copy there (unless the TCP connection is
> reset, and we recreate it). Anyways it is possible for both initiator
> and responder to see same packet coming both over TCP and UDP, so
> normal windowing and duplicate packet detection needs to be done (and
> resending of replies if needed etc)
> 
> Using TCP port 4500 instead of TCP port 500 has the benefit that it
> might bypass those filters someone was complaining about.
> 
> If we want to support ESP over that TCP channel too, then we need to
> add some kind of framing which will tell the simulated UDP packet
> length, i.e. similar what DNS does (prefix the packet with two byte
> length field). On other hand we might want to add also non-IKE marker
> somewhere too. 

Don't you think it looks too complicated? Two different transport
each with two ports, special framing etc...

> Adding one notification to the IKE_SA_INIT to indicate the support of
> this feature would be need.
> 
> Note, that if we run IKE_SA_INIT over UDP, then we can still support
> stateless cookies, 

Successful COOKIE exchange make you sure that peer is real entity, 
but in case of TCP this information can't help TCP/IP stack to
distinguith between bad and good boys. Or you have to constantly update
firewall rules enabling and disabling incoming TCP connections
from different addresses depending on success/failure of
COOKIE exchange.

> and for packets requiring fragmentation there is no
> stateless processing anyways (whether the state is in the system
> reassembly system, new IKEv2 reassembly system, or in the TCP does not
> really matter). 

Any IKE exchange after COOKIE request is already statefull, 
so I don't see any problem here.

> One open issue is how this fits with MOBIKE. I.e. if we get address
> updates over UDP, do we immediately also create matching TCP
> connection, and what do we do if that TCP connection creation fails,
> even when the UDP worked etc.

Yes, It will become more and more complex.

> The ESP over TCP do cause some problems, as some implementations do
> capture those packets already in the kernel without ever giving them
> to the userland, and doing that from the TCP stream is bit harder and
> requires bit more code. 

Oh... ESP over TCP is very problematic... And if the transports are different
for IKE and ESP, we will catch all kinds of problems when IKE goes
smoothly, but following ESP doesn't work at all.

Regards,
Smyslov Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 09 Jun 2012 19:34:53 +0300

Hi Valery,

There's something I'm missing here. Let's say we go for a solution where 
we fragment IKE packets into pieces of 576 bytes, at the application level.

Now, how do we determine the length of the ESP-over-UDP packets? Are you 
suggesting we fix them at 576 too, or do we need to have a (proprietary) 
path MTU discovery for this to *really* work?

Thanks,
	Yaron

On 06/09/2012 08:40 AM, Valery Smyslov wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Sun, 10 Jun 2012 20:38:42 -0400

>>>>> "Yaron" == Yaron Sheffer <[email-masked]> writes:
    Yaron> There's something I'm missing here. Let's say we go for a
    Yaron> solution where we 
    Yaron> fragment IKE packets into pieces of 576 bytes, at the
    Yaron> application level. 

We need to know what problem we are in fact facing.

It seems to me that the "routers" causing the problems are in fact CGN,
and therefore NAT is likely involved, and so ESP-over-UDP.  

If we have a network where 576 byte ESP packets are required, then
regardless of IKE fragmentation (or not), we have a problem to deal with
at the IPsec level.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 11 Jun 2012 09:37:12 +0400

Hi Yaron,

I think this is a different problem from dropping UDP fragments, and, from my point of view, 
less important. For most of UDP traffic this is not an issue, because packets are small.
For TCP traffic IPsec gateway usually copies Don't Fragment Bit
to outer IP header, and usually this bit is set. If some intermediate router has 
smaller MTU, it should drop packet and send ICMP Destination Unreachable. 
Having received it IPsec gateway may store needed MTU value in SA and then report
this value to any host in protected network that tries to send bigger TCP packet.
This behavior is irrespective to whether ESP-in-UDP employed or just plain ESP,
and is documented in RFC4301 section 8.

Regards,
Valery Smyslov.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 11 Jun 2012 09:53:49 +0300

Hi Valery,

This is not a different problem, because whatever solution we choose, we 
must ensure the whole system is functional: both IKE and IPsec. Routers 
that drop IKE fragments will not hesitate to drop ESP/UDP fragments, too.

Thanks for pointing out Sec. 8 to me. I suppose you are right about the 
behavior of implementations in the case of ESP-in-UDP, but from a 
formalistic point of view, note that:

- RFC 4301, Sec. 8 says nothing about NAT traversal (ESP-in-UDP).
- RFC 3948 (IPsec-in-UDP) says nothing about fragmentation...

So we have a hole here.

By the way, I'm not sure that UDP packets are still typically small. 
There's more and more video on the Internet, and I'm sure some of it is 
NOT on Skype.

Thanks,
	Yaron

On 06/11/2012 08:37 AM, Valery Smyslov wrote:
> Hi Yaron,
>
> I think this is a different problem from dropping UDP fragments, and,
> from my point of view, less important. For most of UDP traffic this is
> not an issue, because packets are small.
> to outer IP header, and usually this bit is set. If some intermediate
> router has smaller MTU, it should drop packet and send ICMP Destination
> Unreachable. Having received it IPsec gateway may store needed MTU value
> in SA and then report
>> There's something I'm missing here. Let's say we go for a solution
>> where we fragment IKE packets into pieces of 576 bytes, at the
>> application level.
>>
>> Now, how do we determine the length of the ESP-over-UDP packets? Are
>> you suggesting we fix them at 576 too, or do we need to have a
>> (proprietary) path MTU discovery for this to *really* work?
>>
>> Thanks,
>> Yaron
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Jun 2012 12:05:22 +0300

Hi Yaron

IPsec usually reduces the effective PMTU by 50-100 bytes. There are ways to overcome this:
 - the encrypting gateway can send ICMP fragmentation needed packets to the origin of the packet
 - the encrypting gateway can fiddle with the MSS on TCP SYN and SYN-ACK to reduce the size of TCP packets
 - the encrypting gateway can fragment before encrypting, thus making the ESP (with or without UDP) small enough and apparently not fragmented.

Yoav 

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: 11 June 2012 09:54
To: Valery Smyslov
Cc: Tero Kivinen; [email-masked]; Yoav Nir
Subject: Re: [IPsec] Fragmentation causing IKE to fail

Hi Valery,

This is not a different problem, because whatever solution we choose, we must ensure the whole system is functional: both IKE and IPsec. Routers that drop IKE fragments will not hesitate to drop ESP/UDP fragments, too.

Thanks for pointing out Sec. 8 to me. I suppose you are right about the behavior of implementations in the case of ESP-in-UDP, but from a formalistic point of view, note that:

So we have a hole here.

By the way, I'm not sure that UDP packets are still typically small. 
There's more and more video on the Internet, and I'm sure some of it is NOT on Skype.

Thanks,
	Yaron

On 06/11/2012 08:37 AM, Valery Smyslov wrote:
> For TCP traffic IPsec gateway usually copies Don't Fragment Bit to 
> outer IP header, and usually this bit is set. If some intermediate 
> router has smaller MTU, it should drop packet and send ICMP 
> Destination Unreachable. Having received it IPsec gateway may store 
> needed MTU value in SA and then report this value to any host in 
> protected network that tries to send bigger TCP packet.
> This behavior is irrespective to whether ESP-in-UDP employed or just 
> plain ESP, and is documented in RFC4301 section 8.
>
> Regards,
> Valery Smyslov.
>
>> Hi Valery,
>>

Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 15 Jun 2012 15:12:40 +0300 (EEST)

Valery Smyslov writes:
> > * Find ways of making the packets smaller: move to PSK, fiddle
> > with trust anchors so that only one cert is needed, avoid sending
> > CRLs, hash-and-URL, etc. These are not always successful, and
> > often require more configuration than we would like.
>
> Not an option either. Corporate PKI has plenty of requirements to
> deal with and the requirement to make certificates smaller is the
> least. Hash-and-URL is a nice feature, but it requires an additional
> infrastructure that not every customer is willing to deploy.

> > * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port
> > 500 is already allocated to "ISAKMP". We have had IKE running over
> > TCP for several years for remote access clients. This was done
> > because remote access clients connect from behind some very dodgy
> > NAT devices, and some of those do drop fragments. Getting this
> > behavior at the ISP is novel.
> 
> IKE over TCP has its drawbacks. It eliminates the ability of IKE to
> be stateless (with COOKIE), thus considerably increasing its
> vulnerability to DoS attack. Switching between UDP and TCP
> (especially in the middle of exchange) considerably complicates
> protocol that is already complex in that part (remember switching to
> port 4500 on the fly).

Note, that if we run IKE_SA_INIT over UDP, then we can still support
stateless cookies, and for packets requiring fragmentation there is no
stateless processing anyways (whether the state is in the system
reassembly system, new IKEv2 reassembly system, or in the TCP does not
really matter). 

> I'm in favor of developing standard way of fragmenting big packets
> in IKEv2. I beleive there might be relatively simple solutions not
> breaking core protocol implementation.

I think TCP is better approach. It has already solved most of the hard
problems, and we can use very small wrapper layer to support it in the
IKEv2.

[email-masked]