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