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).
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
