quick mode "proxy" case

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

RFC 2409 specifies:

  The identities of the SAs negotiated in Quick Mode are implicitly
   assumed to be the IP addresses of the ISAKMP peers, without any
   implied constraints on the protocol or port numbers allowed, unless
   client identifiers are specified in Quick Mode.  If ISAKMP is acting
   as a client negotiator on behalf of another party, the identities of
   the parties MUST be passed as IDci and then IDcr.  Local policy will
   dictate whether the proposals are acceptable for the identities
   specified.  If the client identities are not acceptable to the Quick
   Mode responder (due to policy or other reasons), a Notify payload
   with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.

In order to make the discussion clearer I propose this terminology:
 - for these phase 2 identities: "traffic selectors"
 - for the case where the initiator acts on behalf of another party:
   the "proxy" case
 - for the "local policy" requirement: "authorization".

The question is: [how] do you implement the "proxy" case for
transport mode? (please provide the interesting details!)

Regards

Francis.Dupont@enst-bretagne.fr

PS: a better wording for the SOI should be wellcome (as I am afraid
this is rarely implemented because not understood or not understable
by users).