IKEv2 proxy mode

[Francis Dupont <Francis.Dupont@xxxxxxxxxxxxxxxx>]

IKEv1 supports a proxy mode which is (with a terrible wording) described
in section 5.5 "Phase 2 - Quick Mode" by:

   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.

I propose for IKEv2 section 4.11 "Address and Port Agility":

   If IKE is acting as a client negotiator on behalf of another party
   (so called the "proxy mode"), the transport mode MUST be specified
   (by an USE-TRANSPORT-MODE notification) and the TSi gives the address
   of the party which will override the source peer address in IPsec SAs.
   Proper local authorization policy will dictate whether the proposals
   are acceptable for the traffic selectors specified.
Note: we should specify the error for failed TS negociation (and not
only for this case).
If we need a rationale, the proxy mode can be used to when the initiator
has several addresses and wants to negociate IPsec SAs for different
addresses from the same IKE SA (we can find many reasons to do that).
I don't believe the tunnel mode case should be supported (too complex
for a very low benefit, a peer address updating mechanism is better).

Regards

Francis.Dupont@xxxxxxxxxxxxxxxx