(racoon2 34) Re: remote peers_id as iniator

 In your previous mail you wrote:

   > The draft -17 says:
   > 
   >    The optional payload
   >    IDr enables the initiator to specify which of the responder's
   >    identities it wants to talk to. This is useful when the machine on
   >    which the responder is running is hosting multiple identities at the
   >    same IP address.
   > 
   > So IMHO it should be sent only in some very special cases... I propose
   > to comment out (#ifdef 0) this piece of code.
   
   You can leave the field out if it is initiator only, to suppress it.

=> yes, I explicitely wrote "initiator".

   Although, you need to specify peers_id as a responder.

=> the peers_id has two functions in the protocol:
 - put it into messages: there is the exceptional case I've talked about.
 - check it from received messages: this is the standard (and should be
   IMHO the only) usage.
In the code there is a third function: the key to find the peer public key.

   Is there any specific reason you want not to send IDr?
   
=> yes, it is an exceptional case which was spuriously translated
into the standard case.

To be clear:
 - peers_id in ike_conf.c ikev2_public_key() is fine even the cert payload
   should be handled too
 - peers_id in ikev2.c initiator_state1_send() is bad, i.e.,

        if (ike_sa->rmconf->ikev2->peers_id) {
                id_r = ikev2_identifier(ike_sa->rmconf->ikev2->peers_id);
                if (!id_r)
                        goto fail;
        }

   should be #ifdef out
 - peers_id in ikev2.c responder_ike_sa_auth_recv() is fine because either
   it gives the right remote entry when it can't be found by the address
   or it checks the ID payload against the remote entry

Note that IMHO the last code (call to ike_compare_id() into
responder_ike_sa_auth_recv()) is perhaps buggy because:
 - it doesn't handle the case there is no peers_id
 - it doesn't handle multiple peers_ids
I believe a for() like in ikev2_public_key() should be far better as
it fixes both concerns.

Regards

[email protected]

PS: for optional IDr sent by the initiator the best is to add a new
directive as soon as someone finds a good name for it (i.e., even
if its usage seems to be very limited, it is so easy to support for
the initiator side...). Note we should look at the responder side too,
i.e., understand what to do when the responder receives a 3rd message
with an IDr.