Subject: [IPsec] IKEv2 Traffic Selector narrowing questions

From: Paul Wouters <[email-masked]>
Date: Sun, 12 Feb 2012 16:54:13 -0500 (EST)

I have a few design questions on IKEv2 Traffic Selector narrowing

Specifically, regarding http://tools.ietf.org/html/rfc5996#section-2.9

1) The responder can propose a narrowed proposal of the initiator's request

a) What should the initiator do with packets that suddenly fall outside
    the new narrowed proposal? drop them? send them in plain text?
    (in other words, I'm trying to define a "local policy")

b) If the initiator agrees to the narrowed proposal, how on earth should it
    inform the user? Should the user know? (I think so, see a)

2) If the initiator triggers the IKE on a packet, then it should send
    that packet's source/destination as the first TSi/TSr, and the complete
    tunnel proposal as the second TSi/TSr. The responder gets to pick which
    traffic selector to use.

a) If the packet is 10.a.b.c to 10.d.e.f, and the policy on the initiator
    is 10.a.b.0/24 to 10/8, then why would it ever want to give the
    responder an option to narrow it down to what will eventually become
    a cascade of /32 <-> /32 Child SA's ?

b) If the packet is triggered on some opportunistic encryption policy,
    eg based on IPSECKEY, then the initiator can reasonably only propose
    a /32 to /32 policy (and maybe not allow gateway != endpoint), in
    effect already (and only) creating the packet src/dst as the only
    valid traffic selector.

3) The first (so implicating important) use case mentioned is:

    "This could happen when the configurations of the two endpoints
     are being updated but only one end has received the new
    information."

This seems like a real odd corner case. It reads me as "if we changed
the lock on the front door, try this key on the back door". My guess is
this is to support clients that were configured for say 10.0.0.0/8, to be
narrowed down more specifically, say 10.0.0.0/24 but since the initiator
is setting up the tunnel, it might have a need to reach 10.1.2.3/32. Now
with that "this packet triggered this IKE request" it could signal this,
and the responder could figure out its narrowing won't work for this client.
But this just seems a bad patch to a bad starting situation.

4) The next use case is:

    "It also allows for intentionally different configurations, as when one
     end is configured to tunnel all addresses and depends on the other end
     to have the up-to-date list."

This really smells like creating 0/0 <-> 0/0 tunnels, or as some vendors
call it, "routing based VPNs". I guess the use case is to setup all
clients with 0/0 <-> 0/0 and then reconfiguring/narrowing down on the
head-end what you really want tunneled. This would then depend on the
head-ends changing address range use. I can see the use case here.
You want split-tunnel and tell the client which parts to send. It is
something you want the client to agree to, though if it is already agreeing
to send you everything, I guess it already decided to put all trust in
the remote peer. But I believe this case is already covered via XAUTH with
ModeCFG type scenarios?

In other words, I find it really hard to come up with valid scenario's
of narrowing down policy as per RFC 5669 Section 2.9. And as a result,
I'm not sure how (and if) I should implement this part of the RFC.

Am I wrong in that allowing narrowing on the initiator or responder is
not something that should be allowed per-default, but only after being
explicitely told to allow it? Or am I missing a (secure!) use case when
not allowing narrowing of traffic selectors per default?

Paul

---

From: Nico Williams <[email-masked]>
Date: Sun, 12 Feb 2012 20:31:05 -0600

>   (in other words, I'm trying to define a "local policy")

Local policy is not changed.  If local policy requires that packets
for some flow be sent with protection and there is no such SA, then
the packets don't go.  The local node should make a new proposal,
possibly narrowed for the particular outgoing packet that's triggering
SA negotiation.

>   inform the user? Should the user know? (I think so, see a)

Why should the user know?  What matters is that policy be enforced.
If there's no way to obtain a suitable SA, then you let the user know.

>   a cascade of /32 <-> /32 Child SA's ?

Because sometimes it's desirable to have per-flow SA pairs.

>[...]

Narrowing proposals means having more SA pairs, basically.  Does that
have a negative impact on security?  More, narrower SA pairs -> easier
traffic analysis, perhaps.  But beyond traffic analysis I see nothing
wrong with lots of narrow SA pairs from a security point of view.
>From a performance p.o.v. there may be an issue (more SA pairs -> more
keys and key schedules -> more cache pressure -> lower performance).
Replay protection may affect the choice to narrow traffic  selectors,
IIUC.

Nico
--

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Sun, 12 Feb 2012 21:17:31 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Wouters
> Sent: Sunday, February 12, 2012 4:54 PM
> To: [email-masked]; [email-masked]
> Cc: Paul Wouters
> Subject: [IPsec] IKEv2 Traffic Selector narrowing questions
> 
> 
> 

If the initiators SPD says that a particular packet should be protected,
it'd be the Wrong Thing to send it in the clear just because it fell
outside of the proposal that the responder replied with.

IMHO, the correct behavior you should do if you have a packet that the
SPD says should be encrypted but you don't have any SAs that you can
send it with, is to attempt to negotiate an SA that can handle the
packet.  This is true regardless of whether you have any existing SAs
for other packets.  And, if the peer refuses to negotiate an SA that
accepts the packet, well, I don't see you have any alternative to
dropping the packets (unless you can find an alternative route to the
destination that doesn't involve the IPsec SPD).

>     inform the user? Should the user know? (I think so, see a)

Why would the user care?  If you create new SAs on an as-needed basis,
so that all the traffic is being encrypted, why would the user care if
everything was handled by one SA, or a couple of SAs were used.

Now, if the peer rejected the negotiation for some traffic the user was
interested in, then yes you should inform him.  However, this wouldn't
appear to differ from the case that the peer rejected the SAs from the
start.

>     tunnel proposal as the second TSi/TSr. The responder gets to pick

Not quite.  The responder responds with a proposal that is a subset of
the union of the proposals that the initiator sent.  This subset could
be just one of the selectors that the initiator sent, but doesn't have
to be.  In the example you give in (a) below, the responder could also
send a proposal 10.a.b.0/24 to 10.d.e.0/24.

>     a cascade of /32 <-> /32 Child SA's ?

Perhaps it's to avoid scenarios like "A can negotiate with B (because
A's policy is a subset of B's), but B can't negotiate with A (because B
proposes a proper superset of what A can accept)".  After all, if A
couldn't ask that the policy be narrowed, it would have to reject B's
entire proposal, even if it could have handled the traffic we were
actually interested in.

In any case, as above, it is not meant to reduce to SAs that handle
traffic source/dest'ed from single IP addresses.

> the lock on the front door, try this key on the back door".

Doesn't sound like that much of a corner case to me.  It's more of "if
the two sides has policy that doesn't quite agree, we'll let them agree
to the parts of the policy they have in common".

Or, are you of the opinion that the two sides should reject negotiations
(and all traffic is dropped) until the policy resyncs?

> My guess is
>     "It also allows for intentionally different configurations, as
when
> one
>      end is configured to tunnel all addresses and depends on the
other
> end
> call it, "routing based VPNs".

That's certainly part of it, but I don't believe that's the only case.

> I guess the use case is to setup all

The above can also be useful when ModeCFG isn't being used.

> not allowing narrowing of traffic selectors per default?

Are you wrong in suggesting that the RFC should be changed?  That, of
course, is a matter of opinion.  If you ask my opinion, well, IKE always
had the provision of the initiator proposing multiple encryption methods
(3DES, AES) and the responder selecting a subset.  How is this
fundamentally different from the initiator proposing selectors, and the
responder selecting a subset?  If the former is useful, why isn't the
latter?

In any case, why do you think that there is a security problem with
allowing the responder to narrow the selectors?  If the responder
narrows the selectors (and if the initiator makes sure that this
narrowing really is a subset), then the SAs that will be set up with be
in according to both SPDs; with selectors that are listed as to be
protected, to peers that the SPD allows.  I don't see a problem with
this.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Feb 2012 08:26:07 -0500 (EST)

> outside of the proposal that the responder replied with.

Right, so that likely means the initiator cannot allow any narrowing
(unless you accept it is okay to start an IKE negotiation for each
src/dst combo, which causes lots of delay for the user over establishing
one broad SA)

> destination that doesn't involve the IPsec SPD).

Agreed. But the initiator already sent a proposal that it thinks will
cover its traffic. The responder's second guessing is what makes this
harder.

> everything was handled by one SA, or a couple of SAs were used.

Because I need to give the user some feedback if they bring a tunnel up
to tell them if it succeeded or not. If part of the range is only
covered, then what does one tell the user? The initiator also cannot
keep requesting more narrow SA's until its covered all the space (esp in
a 10/8 or even 0/0 case). So in the end, part of a tunnel is up and the
user might need to know.

> appear to differ from the case that the peer rejected the SAs from the

"some traffic" is all the traffic the responder narrowed down...

> entire proposal, even if it could have handled the traffic we were

Right. While I agree encrypting some is better then encrypting none, the
confusion goes back to the user. Is the VPN up or not? Well, it's kinda
up. As implementor, I have a hard time working with this.

> to the parts of the policy they have in common".

But again, leaving the user in some odd state of having partial vpn
connectivity.

> (and all traffic is dropped) until the policy resyncs?

At least that is something I can convey back to the user.

> The above can also be useful when ModeCFG isn't being used.

Yes, but that is the "routed vpn" scenario.

> responder selecting a subset?  If the former is useful, why isn't the

Because that case covers all traffic the initiator wanted, while
reducing the address space covers only partialy what the initiator
wanted. The question then becomes, did the initiator meant to say "give
me all or some of this". And if so, then how does the initiator know
which "some" is good and which "some" is bad for the user?

> protected, to peers that the SPD allows.  I don't see a problem with

If I want to setup a tunnel to 10/8 and I only get 10/24, then for 10/24
the tunnel suceeded, but for 10.255.255.0/24 the tunnel failed. The only
information I have as implementor is that the user wanted 10/8. So to me
the tunnel has failed to establish. But taking that approach just means
I always end up rejecting every narrowed down proposal, which I still
think is the sane default. I am just reaching out to understand why and
how I should allow this narrowing to take place to get the advantages of
it without the disavvantages.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Feb 2012 21:28:26 +0200

> src/dst combo, which causes lots of delay for the user over establishing

Not really. Think of an example, where Gw-A has 192.168.3.0/24 behind it, while Gw-B has 192.168.6.0/23 behind it, although on Gw-B it is defined as two /24 subnets. 

Gw-A might initiate with TS: 192.168.3.0/24<-->192.168.6.0/23, but since the triggering packet is 192.168.3.5-->192.168.6.9, the proposal gets narrowed to 192.168.3.0/24<-->192.168.6.0/24.

If later a 192.168.3.5-->192.168.7.10 packet comes around, the SA won't cover it, so it will start a new negotiation that will get narrowed to 192.168.3.0/24<-->192.168.7.0/24.

There is no reason why the initiator cannot allow any narrowing. This is supposed to be an improvement over IKEv1 where any mismatch in configuration between the peers resulted in failure to set up a tunnel. I realize that this invalidates the concept of a defined tunnel being either "up" or "down".

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Feb 2012 15:16:43 -0500

> Gw-A might initiate with TS: 192.168.3.0/24<-->192.168.6.0/23, but since the triggering packet is 192.168.3.5-->192.168.6.9, the proposal gets narrowed to 192.168.3.0/24<-->192.168.6.0/24.
I'm still looking at it from the user's point of view. Let's say that 
Sysadmin A brought up the "A to B" tunnel. They think they got the whole 
/23 covered, but in fact half of what they think is up, is not.
Should GwA keep retrying the for either the entire /23 or for the 
remaining /24 that fell outside the narrowing?

> There is no reason why the initiator cannot allow any narrowing. This is supposed to be an improvement over IKEv1 where any mismatch in configuration between the peers resulted in failure to set up…

Right. This is the exact problem I'm trying to handle, and I don't see a 
good way out. I'm also really afraid people will start demanding I 
configure 0/0 to them so they can be lazy and I end up with massive 
overlapping policies to deal with and I won't be able to have more then 
one vpn up at a time.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Feb 2012 12:40:48 -0800

On Feb 13, 2012, at 12:16 PM, Paul Wouters wrote:

> Right. This is the exact problem I'm trying to handle, and I don't see a good way out. I'm also really afraid people will start demanding I configure 0/0 to them so they can be lazy and I end up with massive overlapping policies to deal with and I won't be able to have more then one vpn up at a time.

If the problem is "the application knows the exact tunnel it needs", then the solution is that if the responder narrows the tunnel, the IPsec stack tells the application "you never got a tunnel".

IKEv2 was designed around the idea of gateways being the ones that control the tunnel properties, thus avoiding the API issues to applications.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Mon, 13 Feb 2012 15:00:15 -0600

Traffic selector narrowing can also have uses in end-to-end IPsec.
For example, on Solaris apps can use the IP_SEC_OPT socket option to
request IPsec protection, and they can even request narrow SAs such
that there's an SA pair for just the connected socket's packet flow,
and this can be requested on both, the client and server side of a TCP
socket.

I don't think narrowing traffic selectors implies that the responder
is unwilling to handle traffic covered by the initiator's proposal but
not by the responder's narrowed selectors.  If the initiator tries
again for a different triggering outbound packet it may find that it
can tunnel that packet too, and it may find itself having many narrow
SAs instead of one big one.  So what?  Or have I misunderstood
narrowing?

A tunnel is "up" when bits move.  IKE connectivity (specifically being
able to establish an IKE_SA) will be a pre-requisite, if you're using
IKE anyways.  Beyond that bits will move IFF a) local policy allows
them to, b) nothing is wrong with the network, the responder, and
ultimate end-point.  "Bits are not moving" in some cases can only be
determined heuristically (by timeouts).  So what does "tunnel is up"
mean?  To me it means local configuration is setup to require
tunneling, not that the bits are guaranteed to move.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Feb 2012 23:13:29 -0500 (EST)

> If the problem is "the application knows the exact tunnel it needs", then the solution is that if the responder narrows the tunnel, the IPsec stack tells the application "you never got a tunnel".

Okay, so in that context, reading section 2.9:

    To enable the responder to choose the appropriate range in this case,
    if the initiator has requested the SA due to a data packet, the
    initiator SHOULD include as the first Traffic Selector in each of TSi
    and TSr a very specific Traffic Selector including the addresses in
    the packet triggering the request.

Am I right that it is valid to not send the first TSi/TSr of the packet
that triggered the IKE initiation?

> IKEv2 was designed around the idea of gateways being the ones that control the tunnel properties, thus avoiding the API issues to applications.

If you give me a $vendorbox at home to handle the VPN for me, and my box
initiates a connection to the mothership, and it narrows it down to half
of it, me on my laptop still have no idea why my connection is failing
if it trying to hit the other half.

I do see the use case where you configure a 0/0 on my $vendorbox and
it sets up narrow SAs to the mothership for those addresses is would
like to receive, as those indeed do change depending on mothership
expansion. So I do think we should support this, but I do think the
default of this should be "off". I'll think about how to relay this
information back to the user. With NetworkManager integration, this
should be possible.

Thanks for everyone's input on this,

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Feb 2012 16:12:56 +0200

Paul Wouters writes:
> >>> There is no reason why the initiator cannot allow any narrowing.
> >>> This is supposed to be an improvement over IKEv1 where any
> >>> mismatch in configuration between the peers resulted in failure
> >>> to set up a tunnel. I realize that this invalidates the concept
> >>> of a defined tunnel being either "up" or "down".

I think your problem is as you think it as concept of "tunnel" being
up or down, it would be better to think it as "VPN connection" as
defined by "IKEv2 SA" being up or down.

I.e. immediatley when you get your first IKEv2 SA (and Child SA)
negotiated with the other end your VPN is up. You can now send traffic
through that VPN connection to the other end. If there is no Child SA
suitable for the traffic defined in the policy, you use IKEv2 SA to
create it and send it forward using that Child SA. If that Child SA is
not allowed by remote policy, then you drop the packet (and that means
you have mismatching policies between the two hosts).

You do not need to have all possible SAs you could negotiate with that
specific policy up, before you should consider your VPN being up. 

> >> Right. This is the exact problem I'm trying to handle, and I
> >> don't see a good way out. I'm also really afraid people will
> >> start demanding I configure 0/0 to them so they can be lazy and I
> >> end up with massive overlapping policies to deal with and I won't
> >> be able to have more then one vpn up at a time.

Unfortunately people are lazy, and quite many system adminstrators
want to do exactly that. I myself think 0/0 and ::/0 polices are bad
and should not be used, especially as it requires special handling so
that your "local network" packets still get sent locally and not sent
to the VPN tunnel (for example the http-login page, your dhcp packets,
etc).

But that seems to be something that system adminstrators want so you
might need to implement it anyways.

> > If the problem is "the application knows the exact tunnel it
> > needs", then the solution is that if the responder narrows the
> > tunnel, the IPsec stack tells the application "you never got a
> > tunnel".

The tunnel is there, it is not just yet actually formed. When you send
first packet trying the head to that tunnel it will get automatically
created (provided it is allowed by policy). 

> Am I right that it is valid to not send the first TSi/TSr of the
> packet that triggered the IKE initiation?

It is ok not to send the information about the packet if you do not
have it. If you have it the RFC says you SHOULD send it.

If you do not send it, then other end is STILL allowed to narrow the
SA down to whather it thinks it wants the SA to be, but as it does not
have any information for which of the possible subsets of the
initiators proposal it should narrow to, it might take something that
is not useful for the initiator.

In that case the responder can also send ADDITIONAL_TS_POSSIBLE
notification telling that there would be another possible SA that
would more SAs which could be created using the same TS set.

> If you give me a $vendorbox at home to handle the VPN for me, and my
> box initiates a connection to the mothership, and it narrows it down
> to half of it, me on my laptop still have no idea why my connection
> is failing if it trying to hit the other half.

Your connection is not failing, as when you hit the other half, the
IPsec will automatically trigger the IKEv2 CREATE_CHILD_SA exchange
and create another SA for that second half.

The connection would only fail if you would try to create SA that is
NOT allowed by the responder's policy. 

> information back to the user. With NetworkManager integration, this

Note, that responder is ALWAYS allowed to narrow the TS proposed by
the initiator. There is no way to disable that. This is mandatory
feature of the IKEv2. The responder does not need to support narrowing
itself, but the initiator MUST be able to handle the case where
responder decided to narrow the TS.

Also you SHOULD always send the data from the packet as first TS if
you have packet which triggered the negotiation, as this allows
responder to do intelligent and useful narrowing.

Lets take an example. The HQ has 10.0.0.0/8 network configured, but
because of the adminstrative reasons it is always split up to
10.x.y.0/24 networks. For example each user is given access permission
per /24 network, and thats why the gateway is always configured not to
allow any subnet larger than /24 in one Child SA.

The VPN client wants to connect to the HQ, and in the startup creates
the IKEv2 connection to the HQ server. It sends remote TS as:

TSi = 192.168.2.11
TSr = 10.0.0.0-10.255.255.255

without the data from packet as it does this on the startup and there
is no packet.

The server will narrow that down to some 10.x.y.0/24 network, lets say
it just takes the first network, i.e. sends narrowed TS back:

TSi = 192.168.2.11
TSr = 10.0.0.0-10.0.0.255
N(ADDITIONAL_TS_POSSIBLE)

it adds ADDITIONAL_TS_POSSIBLE notification as there would be more SAs
that would be possible for the TS initiator proposed.

The VPN client now has the VPN connection up to the HQ.

Next VPN client tries to start reading email from the
mail.hq.example.com. It first connects to the dns server 10.0.0.1 to
find out the IP-address of mail.dep1.example.com. This packet goes
through the Child SA created in the first step, and it gets reply back
saying that dep1 mail server is at the 10.0.22.4. (the 10.0.22.0/24
happen to be the dep1 service network).

Now the VPN client tries to send packet to 10.0.22.4 port 25, and
notices there is no Child SA for it, but it is allowed by the local
policy, so it will trigger new CREATE_CHILD_SA negotiation and sends
TS:

TSi: TCP,3233,192.168.2.11
     192.168.2.11
TSr: TCP,25,10.0.22.4
     10.0.0.0-10.255.255.255

sending 2 TS payloads, one for the exact data from the packet, another
for the generic policy.

The gateway will see this, and will narrow the proposed list into the
subset allowed by its policy and making sure the first traffic
selector is included in its response. So it will reply with traffic
selectors saying:

TSi: 192.168.2.11
TSr: 10.0.22.0-10.0.22.255

Note, that it did remove the first initiators traffic selectors, as
they are already included in the traffic selectors it responded. Also
it did include full 10.0.22.0/24 network as this is what policy says.
It does not need to include the ADDITIONAL_TS_POSSIBLE as it was able
to fullfill the requirement that the first TS fits in to the returned
SA and after fullfilling that requirement there was only one subset
which was allowed, i.e. if the client would resend that same TS set
again, it would create exactly same (and only that) response back.
There would not be any other possible answer from the server.

Next if VPN client tries to connect to the some other network which it
is not allowed to i.e. tries to connect to the 10.0.23.4 it tries with
another CREATE_CHILD_SA exchange with traffic selectors:

TSi: TCP,2323,192.168.2.11
     192.168.2.11
TSr: TCP,80,10.0.23.4
     10.0.0.0-10.255.255.255

Now the HQ SGW says that this user is NOT allowed to connect to the
10.0.23.0/24 network, and sgw starts processing the operations as
defined in the RFC5996:

----------------------------------------------------------------------
   The responder performs the narrowing as follows:

   o  If the responder's policy does not allow it to accept any part of
      the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE
      Notify message.

   o  If the responder's policy allows the entire set of traffic covered
      by TSi and TSr, no narrowing is necessary, and the responder can
      return the same TSi and TSr values.

   o  If the responder's policy allows it to accept the first selector
      of TSi and TSr, then the responder MUST narrow the Traffic
      Selectors to a subset that includes the initiator's first choices.
      In this example above, the responder might respond with TSi being
      (198.51.100.43 - 198.51.100.43) with all ports and IP protocols.

   o  If the responder's policy does not allow it to accept the first
      selector of TSi and TSr, the responder narrows to an acceptable
      subset of TSi and TSr.
----------------------------------------------------------------------

It notices, that yes, it would be able to allow some parts of the TS,
so it will not reply with TS_UNACCEPTABLE.

Then it checks whether it can allow the whole set, and finds out that
it cannot, so it needs to do narrowing.

The next check fails also, as it notices that it cannot allow this
users to access the 10.0.23.4 machine, so it cannot do intelligent
narrowing.

Now it is left ot the last option. I.e. it needs to narrow this down
to something that will not be useful for the user. Which of the
possible subsets it takes is completely implementation dependant. It
might take the same way out it took when you created the first SA,
i.e. return 10.0.0.0-10.0.0.255. Or it might intelligently notice that
you already have Child SA for that range, so lets not create
overlapping range, lets take next one from the policy which is not
already covered by the SAs we have. The next one might be
10.0.22.0-10.0.22.255, which it also have. The next one after that
might be 10.0.44.0-10.0.44.255, so it might return

TSi: 192.168.2.11
TSr: 10.0.44.0-10.0.44.255
N(ADDITIONAL_TS_POSSIBLE)

and add the ADDITIONAL_TS_POSSIBLE as there is still more possible
subsets it has not yet used.

Anyways the responder will see that the trigger for the packet did
create Child SA, but when it tries to send packet again, it will not
find usable Child SA for it, so it might trigger again. Normally you
would not want it to go to loop to creating multiple exachanges, so
you would have some kind of negative cache marking that this kind of
packet triggered already lately, so do not trigger again for similar
packets for next n seconds.

This last part of the processing is not really very clean, it would be
better if there would be clean error code returned by the responder,
but as the data from the packet was added bit late to the IKEv2
specification, we didn't want to change the TS format to add for
example a bit for it, but instead hacked it in as being first TS in
the list. Also as some people considered it important to allow NOT
sending the data from packet, we cannot mandate it always being there,
so there is no real way for responder knowing whether it is there or
not, and special processing depending whether it is there or not is
not done.

As this last case is anyways failure case, where the there either is
policy mismatch or the user is trying to do something he is not
allowed (i.e. attack), this is not very common case and thats why
there might not be need to "optimize" that corner case. 
-- 
[email-masked]