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