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.
> In a previous append Tero said:
> >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 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.
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.
> 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.
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.
>
> 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.
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.
> 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.
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.
> 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.
I disagree on that.
Already existing standard conforming methods are more efficient than
QCD in those environments.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
