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

From: Tero Kivinen <[email-masked]>
Date: Wed, 6 Oct 2010 16:40:31 +0300

David Wierbowski writes:
> Tero writes:
> >David Wierbowski writes:
> >> Tero writes:
> >> >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.
> >>
> >> 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.
> >
> >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.
> 
> 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.

Yes, and as both ends might initiate connection there is no need for
QCD, as if one end wants to submit request/order and sends packet to
the other end it notices there is no IKE SA and creates one. If
connection breaks down in the middle of the exchange then the end
which did not crash will notice that traffic is unidirectional and
take corrective actions (i.e. start DPD, and then tear down IKE SA and
start to try to create new IKE SA even before the other end has
recovered from the crash).

> 
> 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.

As the host is sending traffic it will immediately notice when it is
not getting ACKs back from the GW, i.e. when the traffic gets
unidirectional, and again it can start fixing situation at that
point.

Note, also that in most cases the Client will also send something when
it does not get any more traffic, and when it sends a single packet
the GW will immediately recreate the IKE SA and Child SAs. 

> 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.

That behavior is described in the RFC4306 and now in RFC5996:

	      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.  

Also as I said if the client sends any packets (TCP acks or similar)
then GW will immediately recreate the IKE SA with Host again. 

> I think allowing both the initiator and responder to be token makers
> actually keeps the protocol simpler.

Clearly we are in disagreement about that. I think it makes protocol
more complex, and adds lots of test cases that needs to be separately
tested. 

> 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.

You do not need to rely it. If the GW or Host implementations are bad
(or broken), then there might be longer delays in recovering.
Everything still works.

If you are making implementation then it is better to make good
implementation that follows the RFC 5996 and which can start liveness
checks when necessarely (and not do stupid things like doing them
every 30 seconds), and use the hints from the network to shorten those
timers.

That good implementation will work well also with implementations
which do not support QCD at all (i.e. all existing implementations). 

> >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.
> 
> 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.

Matching against range or mathing against single IP-address is
trivial. On the other hand usually you need per IP-address shared key,
or other policy information anyways, thus your VPN style
point-to-point configuration usually has fixed entries for each GW.

Note, that VPN GW configuration for VPN client (road warriors) is
different (it usually uses wildcards), but this question is not about
those configurations, as in those setups the VPN GW cannot create
connection to the VPN client, as it does not know in which IP-address
the VPN client is at given time. We were talking here about the
situation where both ends can initiate connections any time. 

> >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.
> 
> 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.

Yes. You can send our GW bogus ESP packet (or you actually might need
few depending on other things), which will couse us to initiate IKE_SA
to the configured host in our configuration. Then the IKE SA is up and
running, and we do not recreate it even if you send more ESP packets.

Usually site to site vpn sessions are set up to be autostarted
anyways, so those IKE SAs are created on the boot time, thus sending
bogus ESP packets do not do anything (or more accurately they can
generate delete message to be send using existing IKE SA to the other
end, which the other end will audit when it gets delete message for
unknown ESP, but those messages are rate limited).
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 6 Oct 2010 09:53:51 -0400

> unidirectional, and again it can start fixing situation at that

But Tero, that process can take several minutes.  First the host initiates
a liveness exchange, then after a minute or two of retransmissions it times
out, then starts to negotiate a new IKE SA.  By that time the TCP
connection has timed out.  This is *exactly* the problem that QCD is
designed to fix, and if I am the host here I definitely want to take
advantage of QCD in this situation rather than lose my TCP connection.

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

From:	Tero Kivinen <[email-masked]>
To:	David Wierbowski/Endicott/IBM@IBMUS
Cc:	[email-masked]
Date:	10/06/2010 09:40 AM
Subject:	Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00
Sent by:	[email-masked]

Usually site to site vpn sessions are set up to be autostarted
anyways, so those IKE SAs are created on the boot time, thus sending
bogus ESP packets do not do anything (or more accurately they can
generate delete message to be send using existing IKE SA to the other
end, which the other end will audit when it gets delete message for
unknown ESP, but those messages are rate limited).
--
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Oct 2010 13:30:21 +0300

Scott C Moonen writes:
> out, then starts to negotiate a new IKE SA.

On bad implementation it can even take forever, if they do not
implement any kind of crash recovery code. On good implementation it
will recover in few seconds after the GW is up again (i.e when GW
receives first unknown ESP packet and finds Host from its
configuration and recreates IKE SA and sends delete for ESP, or when
client sends next IP packet which will cause GW to recreate IKE SA and
Child SA as they do not exists). 

> By that time the TCP connection has timed out.

TCP Timeouts are several minutes too, so TCP connections should not
time out that soon.

> This is *exactly* the problem that QCD is

Host will notice that traffic changed unidirectional and should start
liveness check way before the GW has even recovered, and especially if
it receives hints from the other end that GW has crashed (ICMP host
unreachables, protocol unreachables, IKE invalid SPI notifications
etc), then it can shorten timeouts needed to really delete IKE SA and
start over. Bad implementation can take that much time that TCP
connections times out, but not all implementations needs to be bad,
you can also make good implementations and if you are writing that
host implementation better make that implementation good so it will
work regardless whether QCD is there or not.

It seems that in most discussions about QCD people assume that the
IPsec implementations are the very bad and the QCD is magic wand that
will make those implementations good. I do not expect that to happen.
If the vendors have not bothered to care about crash recover before
QCD, I do not expect them to be bothering about it later either,
meaning they most likely will not implement QCD.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Oct 2010 13:19:22 +0200

Hi all. Tero Kivinen sent the message included below to the mailing list on September 8th.

I am fine with this text.

Please read it thoroughly, and if there are no objections, I will incorporate it into the next version of the draft (which I intend to publish at the last possible moment on Monday)

Yoav

Begin forwarded message:

> Date: September 8, 2010 1:07:03 PM GMT+03:00
> To: "[email-masked]" <[email-masked]>
> Subject: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00
> 
> 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
>   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
>   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]
> Scanned by Check Point Total Security Gateway.