Opened 12 years ago

Closed 11 years ago

#198 closed defect (wontfix)

QCD Token - only for responder?

Reported by: yoav.nir@… Owned by: fd@…
Priority: normal Milestone:
Component: failure-detection Severity: -
Keywords: Cc:


Tero Kivinen says:

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.

Change History (2)

comment:1 Changed 12 years ago by fd@…

  • Owner changed from ynir@… to fd@…
  • Status changed from new to assigned

There is an impact in removing the functionality. Some implementations create SA's only if traffic hits the security policy. In practical peer-to-peer (as opposed to Remote Access) traffic can be triggered by either side and that side may not be known in advance.

comment:2 Changed 11 years ago by yoav.nir@…

  • Resolution set to wontfix
  • Status changed from assigned to closed

While many agree that the responder generating a token is more useful than the initiator, many on the list see use cases for both. We've decided not to change this.

Note: See TracTickets for help on using tickets.