Subject: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Sep 2010 13:07:03 +0300

The section 2 describing RFC4306 crash recovery is not complete. It
does not include the normal processing happining on the peer that is
not rebooting.

I suggest adding following text:
----------------------------------------------------------------------
When the one peer loses state or reboots it might not be able to
recover immediately (especially in case of reboot). This means that at
first the peer just goes silent, i.e. does not send or respond to any
messages. Conforming IKEv2 implementation will detect this situation
and follow the rules given in the section 2.4:

              "If there has only been outgoing traffic on all of
   the SAs associated with an IKE SA, it is essential to confirm
   liveness of the other endpoint to avoid black holes.  If no
   cryptographically protected messages have been received on an IKE SA
   or any of its Child SAs recently, the system needs to perform a
   liveness check in order to prevent sending messages to a dead peer."

I.e. the peer usually will start liveness checks even before the other
end is sending INVALID_SPI notification, as it detected that the other
end is not sending any packets anymore while it is still rebooting or
recovering from the situation.

This means that the several minutes recovery period is overlaping the
actual recover time of the other peer, i.e. if the security gateway
requires several minutes to boot up from the crash then the other
peers have already finished their liveness checks before the crashing
peer even has change to send INVALID_SPI notifications.

There are cases where the peer looses state and is able to recover
immediately, in those cases it might take several minutes to recover.

Note, that IKEv2 specification specifically leaves number of
retries and lengths of timeouts out from the specification, as they do
not affect interoperability. This means that implementations are
allowed to use the hints provided by the INVALID_SPI messages as hints
that will shorten those timeouts (i.e. different environment and
situation requiring different rules).

Good existing IKEv2 implementations already do that (i.e. both shorten
timeouts or limit number of retries) based on that kind of hints and
also start liveness checks quickly after the other end goes silent.
----------------------------------------------------------------------

The final paragraph saying:

   Those "at least several minutes" are a time during which both peers
   are active, but IPsec cannot be used.

is incorrect, as it is only true when the crashed peer recoverd
instantenously. In normal case most of that time is actually
overlaping the recovery time of the peer.

--

The protocol currently says that:

   Supporting implementations will send a notification, called a "QCD
   token", as described in Section 4.1 in the last IKE_AUTH exchange
   messages.  These are the final IKE_AUTH request and final IKE_AUTH
   response that contain the AUTH payloads.

This is very differnet compared to all other processing, usually this
kind of payloads are put to the same packet that contains traffic
selectors etc. Is there some reason why this is done this way?

--

Also do we really need the QCD token for the initiator too? The
initiator has already proven to be able to create the IKE SA on its
own, and it will have enough information to recreate the IKE SA after
the boot. Responder usually does not have enough information to be
able to recrete the IKE SA on its own after reboot, as it might not
for example know anymore what was the peer address where the IKE SA
was connected to when it just has IP packet it needs to forward to
that peer. The initiator must already have that information as he was
able to trigger IPsec SA creation in the first place based on the ip
packet.

I think it would simplify the implementations and the protocol by just
limiting that only responders can be token makers without loosing any
of the functionality. 

--

Section 7.4 is mostly wrong.

The default retransmission policy needed for mobike cases is much,
much longer than what is needed in normal case. When mobike switches
from one interface to the another there might be very long delays
because of this (for example the device first needs to notice that
old interface does not work anymore, and then perhaps it needs to run
dhcp and other link related protocols on the new interface before it
can even try it and all those take a long time).

For example in our implementation the mobike uses MUCH longer timeouts
just to make sure we do not time out the IKE exchanges while we are
trying to go through all possible interfaces etc. Because of those
even longer timeouts there is very good reason to shorten those
timeouts in case we get any feedback back from the other end (i.e.
INVALID_SPI notifications).

The timeouts used in different situations even in the same
implementation needs to be different. In our case when you enable
mobike the number of retries used is more than 2 times what it is if
you do not turn mobike on.

Also the last paragraph again assumes that the peer staying up didn't
start liveness check almost immediately when the crashing peer
crashed. This is something that is already part of the standard IKEv2
specification, so implementions need to do that. This means the
timeout starts from the time of the crash, not from the time when the
gateway is up again.

Anyways as all this is standard IKEv2 already it does not belong here
in the alternative solutions section, but belongs as part of the
section 2.

--

Section 8 again ignores the IKEv2 text saying:

              "If there has only been outgoing traffic on all of
   the SAs associated with an IKE SA, it is essential to confirm
   liveness of the other endpoint to avoid black holes.  If no
   cryptographically protected messages have been received on an IKE SA
   or any of its Child SAs recently, the system needs to perform a
   liveness check in order to prevent sending messages to a dead peer."

Especially the text:

                                  A failed gateway may go undetected
   for as long as the lifetime of a child SA, because IPsec does not
   have packet acknowledgement, and applications cannot signal the IPsec
   layer that the tunnel "does not work".  

If the gateway has failed then if there is ANY traffic on any of the
IPsec SAs then that means that from the other peers point of view
there is only outgoing traffic, thus it needs to do liveness check to
verify that the other end is alive. Thus the failed gateway cannot
really go undetected for as long as the lifetime of child SA, unless
the lifetimes is in order of few minutes :-)

I know there are implementations who do not implement that part of the
IKEv2 specification, but that does not mean that the part is not
there. We should not write or specifications to cover broken
implementations, but try to assume that implementations are following
the IKEv2 specification.

Note that the IKEv2 text does not have any conditionals there, it says
that "...the system needs to perform a liveness check...". It does not
say it may, or even should do it, it says it needs to be done.

Also I think the picture itself is bit incorrect, the exchange after
the reboot should probably be:

                ---- Reboot -----

       HDR, SK {}          -->

                        <--  HDR, N(INVALID_IKE_SPI), N(QCD_TOKEN)

I.e I assume the first packet is normal liveness check, and the reply
that is normal INVALID_IKE_SPI with QCD_TOKEN. 

--

In section 9.1. it says that inter-domain VPN gateways should do both,
but I think that inter-domain VPN gateways does not really need this
specification as all, as they by configuration do know the other ends
IP-addresses etc, thus when the inter-domain VPN gateway gets up, it
can immediately create the IKE SAs needed based on the configuration.
This is in the case where either end of the inter-domain VPN gateway
can act as a initiator, i.e. no EAP is used, and neither is behind the
NAT.

If one of the inter-domain VPN gateway is behind restricted NAT, then
it is more or less similar to the remote-access client case (i.e. only
that end can initiate connections), and as the other peer cannot
initiate connections to the gw behind NAT, there is no point of
supporting token taker on that end.
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 8 Sep 2010 08:13:17 -0400

> limiting that only responders can be token makers without loosing any

I don't think we should limit this.  First, rekeys can easily reverse the
sense of who is initiator.  Second, it is a stretch to assume that the
underlying traffic pattern is always such that at all times the initiator's
side is the one doing sending/retransmitting and can thus resurrect the SA.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:	Tero Kivinen <[email-masked]>
To:	[email-masked]
Date:	09/08/2010 06:07 AM
Subject:	[IPsec] Comments to draft-ietf-ipsecme-failure-detection-00
Sent by:	[email-masked]

--

--

--

--

Especially the text:

                ---- Reboot -----

       HDR, SK {}          -->

--

If one of the inter-domain VPN gateway is behind restricted NAT, then
it is more or less similar to the remote-access client case (i.e. only
that end can initiate connections), and as the other peer cannot
initiate connections to the gw behind NAT, there is no point of
supporting token taker on that end.
--
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Sep 2010 15:19:11 +0300

Scott C Moonen writes:
> sense of who is initiator.

I was thinking about the original initiator, not the exchange
initiator. 

> Second, it is a stretch to assume that the underlying traffic
> pattern is always such that at all times the initiator's side is the
> one doing sending/retransmitting and can thus resurrect the SA.

I am not talkin gabout traffic patters, I am talking about the ability
to recreate the SA. The reason the SGW in normal case cannot simply
recreate the IKE SA after the reboot is because it does not know who
the other end was, i.e. it does not know their IP-addresses,
identities, the traffic selectors etc used for that.

The initiator has all this information in its configuration as it
already created the SAs in the first place earlier, so for it, it is
enough to just start new IKE SA with INITIAL_CONTACT notification when
it boots up. 
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 8 Sep 2010 08:44:11 -0400

Tero,

> I was thinking about the original initiator, not the exchange

Ok, but this then imposes an awkward new requirement to remember the
"original original initiator," as it were.  Today the initiator of the
rekey becomes the original initiator of the rekeyed IKE SA.

> I am not talking about traffic patterns, I am talking about the ability

But the responder side does have this information -- if the initiator
reboots, the responder still has the original SAs.  Once it receives the N
(INVALID_IKE_SPI)+N(QCD_TOKEN) it can treat it essentially as a case where
it needs to reauthenticate the IKE SA rather than starting from some
hypothetical clean slate.  In the normal case the responder should be able
to negotiate new SAs.  (I realize this may be problematic for some EAP and
some NAT traversal cases.)

I am not suggesting we require the responder to re-create the SAs.  But I
don't think we should disallow it,

From:	Tero Kivinen <[email-masked]>
To:	Scott C Moonen/Raleigh/IBM@IBMUS
Cc:	[email-masked]
Date:	09/08/2010 08:19 AM
Subject:	Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 9 Sep 2010 11:01:25 +0300

> rekey becomes the original initiator of the rekeyed IKE SA.

True, we need some other term for it. Something like the original
IKE_SA_INIT initiator or the party initiating the initial connection
(i.e. triggering). Or simply say that the QCD_TOKENs in INFORMATIONAL
exchanges and rekeys can only be sent by the peer who originally sent
them in the IKE_AUTH, and in IKE_AUTH limit the QCD_TOKEN to the
responder. 

> hypothetical clean slate.

Yes. But on the other hand the initiator also has this information in
this case, as it originally initiated the connection by triggering the
IKE SA to be created. So when next packet which will cause similar
trigger comes, then the party who originally initiated the connection
will trigger again, and recreate the IKE SA, and in that case it will
also send INITIAL_CONTACT notification which will clean up the state
from the SGW.

In road warrior cases if the party who originally initated the
connection (i.e. road warrior client) is rebooted, it already lost all
other state too which means that the state that SGW has (TCP
connections, IP number allocations etc) are not useful, and will be
cleaned out anyways.

The other way is not possible in common case. I.e. if the party who
was responder to the initial connection is rebooted, it does not have
enough information to recreate the IKE/Child SAs. It must somehow
indicate this to the party who originally initiated the connection, so
it can restart the IKE SA creation from the beginning. For this
QCD_TOKENs are useful. 

> In the normal case the responder should be able

In road warrior case it not normally possible for the responder (road
warrior server, sgw) to negotiate new SAs as it does not have
configuration needed to create them. For example its policy is usually
that from any IP, anybody who can identify itself with id that is in
my database can connect and allocate IP-address from me and use that
for tunneling all traffic from that IP-address to the internal
network.

Now if SGW is rebooted it does not know who was connected to it before
the crash, thus it cannot recreate the state. Even if it gets some IP
packets from the internal network directed to some road warrior
client, it does not have information to tell how to recreate the
connection.

> don't think we should disallow it,

If it has enough information, sure it can recreate the state, but in
that case it does not even need QCD at all. I.e. if both parties have
all the information they need to recreate the state (for example site
to site VPN) then there is no need for QCD.

Quite often the setup is so that the tunnels are brough up immediately
when the peer is up again, thus immediately when the peer recovers
from the crash it will recreate the IKE / Child SAs and by sending
INITIAL_CONTACT notification it cleans up the state from the other
end.

Even if the peers are configured to create SAs only based on the
packets, most likely if there was any traffic going through the tunnel
then that traffic is two way, which means that the crashed party will
get triggering packet very soon.

Even if that is not true when the crashed peer gets unknown ESP
packets from the source it knows based on its configuration (i.e. it
is configured remote peer of IPsec tunnel), it can use that to trigger
IKE SA exchange and use that IKE SA to send delete for that Child SA
(our implementation already does this kind of operations).

In general I do not think there is that much use for QCD in site to
site VPNs, or the trying to detect crashed road warrior clients. I do
think there is use case for them in detecting and recovering from the
crashing road warrior servers.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Sep 2010 07:58:18 -0700

<no hat>

>them in the IKE_AUTH, and in IKE_AUTH limit the QCD_TOKEN to the

Is this added complexity really needed? It sounds like a dangerous addition. Please be sure the value is actually worth the risk.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 10 Sep 2010 17:29:35 +0300

Paul Hoffman writes:
> Is this added complexity really needed? It sounds like a dangerous
> addition. Please be sure the value is actually worth the risk. 

I am suggesting simplyfying the protocol, not adding complexity. It
might add some text to the specification, but reduce code from the
implementation, as then implementation is always either token maker or
taker, never both.
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Fri, 10 Sep 2010 11:02:20 -0400

>implementation, as then implementation is always either token maker or

I disagree with this "simplification."  Tero's logic is that this does make
sense in some cases (e.g. his case), so let's disallow it.  As Scott Moonen
pointed out, there are cases where it is perfectly valid to expect either
endpoint to send the next packet and cases where it makes sense that either
endpoint can initiate the creation of an IKE SA.  I see no reason to
restrict who can be a token maker and a token taker.  IMHO, Adding this
restriction just reduces the potential effectiveness of the solution.

Dave Wierbowski

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Sep 2010 08:07:38 -0700

>implementation, as then implementation is always either token maker or

Ah! I hadn't seen it that way. That works. :-)

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 12 Sep 2010 10:57:13 +0200

I agree with Scott's position. In the case of site-to-site VPN, where 
SAs are NOT set up by configuration, but rather triggered by traffic, 
you can have a tunnel triggered by traffic from A to B, but later mostly 
used in the opposite direction. This would benefit from allowing the 
original responder to be a token taker.

And to answer Tero's original concern, if we require the token maker's 
SPI to be unpredictable, then we don't need to worry about token 
stealing and we can send the token in the first IKE_AUTH message. Which 
would make things a little more regular.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 13 Sep 2010 13:46:26 +0300

David Wierbowski writes:
> endpoint can initiate the creation of an IKE SA.

As I explained that if both ends can initiate the creation of the IKE
SA, then QCD is not needed as both end can simply recreate the IKE SA
immediately (with INITIAL_CONTACT notify) when they are up and running
(or when they receive first unknown ESP packet from the configured
peer). This is simple and already specified by the IKEv2, so no new
code is needed.

> I see no reason to restrict who can be a token maker and a token
> taker. IMHO, Adding this restriction just reduces the potential
> effectiveness of the solution.

I do not agree on that, as I cannot really see any cases where it
might be more efficient than simply recreating the IKE SA (or do IKE
SA resume) immediately when peer is up again. QCD will simply add one
extra round trip (or half a round trip in case of other end sending
unknown ESP first) to recovery process compared to starting directly
with IKE SA creation or recovery.

I.e. if both ends are able to recreate the IKE SA this is not needed,
it is just wasting resources and slowing down the recovery.

QCD is useful in situation where the peer cannot initiate, but must
tell the other end to remove old IKE SA and start creating new one (or
start doing IKE SA recovery). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 13 Sep 2010 13:51:30 +0300

> original responder to be a token taker.

As I explained that even in that case the QCD still slows recovery
down by half a round trip.

I.e. when the traffic is only coming from B to A, and A crashes, then
when A gets up and its getting the unknown ESP, and would be sending
QCD token, instead of sending QCD token, it can simply start creating
the IKE SA again, and save half a round trip in the recovery time.
As the peer B is already known by the configuration as host A was able
to initiate IKE SA to it originally, there is no real DoS attack
option here, as only thing that attacker can do is to force A to
create all the preconfigured connections it is normally doing anyways. 

> would make things a little more regular.

I would prefer that, and I think we can require token maker's SPI to
be unpredictable if it is using this feature. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 13 Sep 2010 14:23:57 +0200

Hi Tero,

you are assuming you can always map an IP address (of the incoming ESP) 
into the peer's identity. This is often possible, but not always. For 
example, if you're using round-robin DNS to look up the B peer, or if 
IKE Redirect was used.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 13 Sep 2010 16:43:29 +0300

> example, if you're using round-robin DNS to look up the B peer, or if 

Yes, that is the case if you have information in the configuration.
Round-robin DNS is not a problem, as all the IP-addresses are there in
the DNS, thus you do know all of them. IKE Redirect could be problem,
but I do not think that is commonly used with site to site VPNs, it is
mostly used in the road warrior cases where you have lots of clients
connecting to the same server, and as in this case the configuration
was so that either end could initiate connection all of the possible
redirected addresses are most likely already in the configuration to
make sure we know which policy to use when other end connects (in IKE
you must be able to select the initial IKE SA responder policy based
on the IP-address alone, thus in most site-to-site VPNs where the
policy is enforced, configuration already is such that every possible
IP-address of the other end is configured in to the system).
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 13 Sep 2010 22:39:26 +0200

Hi Tero,

It seems to me we are adding architectural assumptions, just to gain a 
relatively minor simplification of the protocol. Not a very good trade-off.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Sep 2010 11:19:29 +0300

Yaron Sheffer writes:
> It seems to me we are adding architectural assumptions,

Not really adding architectural assumption, but just explaining that
in those cases we do not need QCD, as we have more efficient already
standardized ways to handle the situation. 

> just to gain a relatively minor simplification of the protocol. Not
> a very good trade-off.

I do not really consider the simplification a minor. When you have
protocol which allows lots of options it gets much more complicated to
write the implementation and especially test all possible
combinations.

What I was proposing that if only the initiator can act as token taker
and responder can act as token maker, then that removes lots of
different combinations:

Otherwise the initiator can act as token maker or token taker or both,
and it might also receive token or might not receive token. Same thing
for responder, and you need to combine all possible combinations:

1) I token maker, R token maker
2) I token maker, R token taker
3) I token maker, R token taker and maker
4) I token taker, R token maker
5) I token taker, R token taker
6) I token taker, R token taker and maker
7) I token taker and maker, R token maker
8) I token taker and maker, R token taker
9) I token taker and maker, R token taker and maker

(yes, some of those combinations are no-ops, like 1 and 5).

And then you also have similar setup for rekeying, and similar setup
for recovery.

What I was proposing you have:

1) I token taker, R token maker

I do not consider very open protocols which allow all kind of things
"just for fun" and "in case we someday get scenario which can use it"
as good thing. Even if those are allowed in the protocol, nobody is
going to implement those combinations, thus when someone then thinks
a scenario where they might be useful, the implementations need to be
modified anyways to support that, and most likely what happens is that
we need to specify something new because we cannot break old
implementations by using features they have not implemented.
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Tue, 14 Sep 2010 11:57:40 -0400

Tero writes:
>as good thing.

I do not think we are allowing the initiator and responder to
be both a taker and a maker just for fun.  There are cases where
either side can initiate and it makes sense in those cases.

>peer). This is simple and already specified by the IKEv2, so no new

I certainly would not advise creating an IKE_SA based on the receipt of
an unknown ESP packet from a configured peer.  If the ESP packet is
unknown then it is not authenticated and could have come from anywhere.

Prior to QCD, if the initiator of the initial IKE_SA reboots and then
receives a packet with an invalid ESP SPI from the responder the
initiator would send an INVALID_SPI notify to the responder.  The
responder would then start dead peer detection.  It's Tero's belief that
this should use a shorten retransmission timer.  Section 7.4 of the QCD
draft explains why using a shortened retransmission timer is not wise,
but let's assume one does use a shorten timer.  That shortened timer
introduces a delay that QCD eliminates.

Tero desires QCD to limit the role of taker to the initiator.  He seems
to expect that the initiator would not only retain a mapping of received
tokens to IKE_SAs, but also a mapping of ESP SAs to IKE_SAs.  When the
initiator gets a packet with an invalid SPI after a reboot he wants
the initiator create a new IKE_SA.  Actually, I think he wants to do
this without saving any state (i.e. without QCD).

Section 9.2 of QCD indicates that a implementation MAY maintain such
a mapping.  As such QCD does not require such a mapping.  QCD states
that in the case where such a mapping is maintained that the initiator
should respond with both an INVALID_SPI notification and a QCD_TOKEN
notification.  The reason for this action is that the initiator should
not start an IKE_SA negotiation based on an unauthenticated packet.

As such, it makes sense to allow the initiator and responder to be both
a taker and a maker in environments where either side is capable of
initiating the IKE_SA negotiation.

Dave Wierbowski

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 15 Sep 2010 11:17:24 +0300

> either side can initiate and it makes sense in those cases.

Can you give example of such setup, preferrable something that I have
not already covered in my previous emails and explained why QCD is not
needed there. 

> unknown then it is not authenticated and could have come from anywhere.

Yes it is not authenticated, but you do have limited number of
configured IP-addresses in your configuration file, which means that
attacker can only set up IKE SA for exactly those hosts, not any
other, and as you only create the IKE SA if you do not have any, then
only thing attacker can cause is you to create the IKE SA even when
you do not yet have traffic to go that way. 

> initiator would send an INVALID_SPI notify to the responder.

As I said, in our case we do check our configuration and if the
invalid ESP packet has IP-address which matches a known peer in the
configuration file, our implementation do set up the IKE SA for the
peer and do send Child SA delete for the ESP SPI to clean up the
state.

If we already have IKE SA up and running then we do send the same
delete notification inside that IKE SA. 

> The responder would then start dead peer detection.

Responder has most likely already started the dead peer detection
few seconds after the other end crashed, i.e. when the traffic changed
to be one way. So the DPD is already in progress when the peer gets
up. 

> It's Tero's belief that this should use a shorten retransmission
> timer.

Yes. There is no point of trying for 5 minutes (default timeout in our
implementation if mobike is in use) when we are already getting
some kind of feedback from other end. Waiting for 30 seconds and
retransmitting 3-5 times should make it so that if the machine is up
and network is working one of those packets should generate proper
response if the IKE SA is still up.

If attacker can block all traffic for the peer so it cannot respond in
30 seconds, then attacker can usually also block traffic for 5
minutes...

If there is network connection problem, which might take few minutes
to clear out, then we are not getting the error notifications either. 

> Section 7.4 of the QCD draft explains why using a shortened
> retransmission timer is not wise, but let's assume one does use a
> shorten timer.

I do not agree on the text on section 7.4. There are multiple things
which retransmission counts and retranmission timers try to cover:

1) Save network bandwidth.
   == send as few packets as possible.
2) Allow enough time for packets to reach other end.
   == Use long enough time between packets that the packets actually
      can reach other end, and that they can be processed there 
3) Allow packets to be dropped by the network.
   == Do not assume packets always gets there, so send multiple
      packets

The retransmission policy also tries to recover for different things:

1) Other end crashed, and will not ever get up
   == do not care how quickly we will detect this, as other end is
      never coming back
2) Network broke down for few seconds - few minutes
   == Try to retransmit long enough that short (few minutes) breaks in
      the network do not break connectivity
3) Lots of congestion on the network
   == Do not send too many packets to make congestion worse, but
      retransmit enough times to get packet through
4) Other end cleared state, or rebooted
   == No point of retransmitting too many times, as other end does not
      have state anymore

Retransmission policies are not really there to cover attacks. They
are there for normal operations.

If attacker can block connectivity (i.e. break the network), nothing
we can do with retranmissions can fix this.

If attacker can cause congestion, we might get something through
better if we send more retranmissions, but by doing that we cause even
more congestion and make situation worse.

If attacker can crash or reboot peers, then retranmission does not
really help.

There is nothing that says our retranmission policy needs to be same
for all situations. I think that any good implementation will tweak
its retranmission policies based on the situation. The TCP for example
already has built-in mechanisms for that by measuring the RTT etc.

In IKEv2 we cannot really measure RTT, because our visible RTT
includes variable length of processing time (i.e. whether we do
Diffie-Hellman or not) and that messes up the measurements.

If we do get feedback from the other end (or the routers along the
route) that it is not anymore having the state it used to have, AND we
are not getting any feedback which would tell otherwise (i.e. we do
not get any protected packet from the other end) then we can shorten
the retranmission timers, as that usually means that network is
working and there is no congestion (i.e. retransmission is not for
cases 2 or 3, but for case 1 or 4). In those cases there is no need
for excessive retransmits as retransmits does not help at all in those
situations. 

> That shortened timer introduces a delay that QCD
> eliminates.
> 
> tokens to IKE_SAs, but also a mapping of ESP SAs to IKE_SAs.

IKEv2 already mandates keeping mapping from ESP SAs to IKE SAs. Or do
you mean over reboots? I do not expect initiator to keep any state
over reboots, only to keep the same configuration they had before
reboot.

> When the initiator gets a packet with an invalid SPI after a reboot
> he wants the initiator create a new IKE_SA. Actually, I think he
> wants to do this without saving any state (i.e. without QCD).

Yes, but only for those IP-address found from the configuration. 

> not start an IKE_SA negotiation based on an unauthenticated packet.

You do not need QCD for any of that, you can simply do it by looking
the configuration. If you get ESP packet with source IP that matches
the known peer of your configuration and which you do not have IKE SA
already up, then you create one, and then send Child SA delete to the
other end to clean up the state. If you already have IKE SA up with
the peer, you use that IKE SA and send delete notification over that.

This saves half a round trip compared to the QCD. 

> initiating the IKE_SA negotiation.

I disagree on that.

Already existing standard conforming methods are more efficient than
QCD in those environments. 
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Thu, 16 Sep 2010 11:14:52 -0400

>not already covered in my previous emails and explained why QCD is not

Consider a business partner relationship where data exchanged between
the partners are protected by IPsec.  In these environments it is often
common for either end to initiate a negotiation and for either end to
initiate sending data.  For example perhaps they share a process
management system or order fulfillment system.  One end might initiate
a connection to submit an request/order.  Days later the other end might
initiate a connection to indicate the fulfillment of the request/order.
There truly envirnoments that do and can initiate from either end.

The ability to initiate an IKE_SA is not the only case where allowing
both endpoint be takers and makers is applicable.  Consider the
following:

Host (responder) <======> GW (initiator) <-------> Client

The Client is connecting to the Host.  The GW chooses to initiate a
single SA per client behind the GW.  The Client's connection has data
streaming in from the host -- perhaps the Client is downloading a
significant database replication update.  The GW oes down.  The Client
connection is still viable.  If the GW goes down and I am the host I do
not want to depend on the GW being smart enough to receive my ESP packet
and negotiate a new tunnel, especially when QCD might let me (the host)
initiate a new tunnel.  It really does not matter if the Host could have
done this initial negotiation.  It just to be able to reconstitute the SA.

When the GW goes down the host still has the IKE and Child SAs, and in
many cases it should be able to renegotiate them just as though it were
reauthenticating.

It seems unlikely to me that every GW behaves as Tero suggests here.  In
case that do not behave as Tero suggest QCD will allow me to drive a faster

recovery.

I think allowing both the initiator and responder to be token makers
actually keeps the protocol simpler.  From an implementation perspective
I'd prefer to take advantage of QCD as a rather than rely on the fact that
every gateway behaves as Tero suggests.  Using QCD seems like a simpler
and safer approach.

>you do not yet have traffic to go that way.

I'm not so sure that having a limited number of configured IP addresses in
the configuration file equates to having a small number of address.  It is
also likely that one could easily determine the range of valid addresses.

>peer and do send Child SA delete for the ESP SPI to clean up the

But how do you authenticate that address?  Are you saying that if I
find an addresses in your config file that I can sit there all day
sending you bogus ESP packets and watch you initiate IKE_SAs?  I must
be missing something here.

Dave Wierbowski