Re: road warrior and id field.

>Kaustubh Kumbhalkar writes:
>> In RFC 2409 "The Internet Key Exchange (IKE)",
>>  in 5.1 "IKE Phase 1 Authenticated With Signatures", describing Main
>>  Mode:
>>
>>          Initiator                          Responder
>>         -----------                        -----------
>>          HDR, SA                     -->
>>                                      <--    HDR, SA
>>          HDR, KE, Ni                 -->
>>                                      <--    HDR, KE, Nr
>>          HDR*, IDii, [ CERT, ] SIG_I -->
>>                                      <--    HDR*, IDir, [ CERT, ] SIG_R
>>
>> my question,
>> we can send and IDii of a thrid machine in I3.

>The value of IDii is used by the responder to determine whether it
>wants to setup a connection with the initiator.  To a certain extent
>it doesn't matter what is in there as long as the responder will
>accept it as identifying the initiator.  Assuming that the responder
>has been told to identify the initiator by the IP address I3 (as
>opposed to whatever the IP address of the initiator actually is) then
>it does *not* imply that return packets will go to I3.  The return
>packets will still go the initiators address.

by I3 i meant the message MI3 - third message from initiator. ( i should
have been more clearer).

anyways , then the point is that the responder should respond to the
initiators 'source address' and not the address as specified by IDii.

in freeswan when we initiate a connection from the road warrior , the
responder updates its connection information with the 'source addresss' of
the road warrior.
while the security association is required to be made w.r.t the address
specified by IDii.
if this is possible then ,this wil allow a road warrior to negotiate SA's
for its home address (using IDii) while having foreign address as the
source address for its IKE packets.
anything wrong in  this?


>> this way it is not possible to negotiate for an SA having address other
>> than the addresses of the negotiating machines?
>> is this conceptually wrong?

>ISAKMP SAs are between an initiator and responder and only protect
>ISAKMP/IKE traffic between those machines.  Once you have an ISAKMP SA
>then Quick Mode can be used to negotiate :-

>* a transport or tunnel mode IPsec SA between the initiator and
>responder to secure all other traffic between the machines.

>* a tunnel mode IPsec SA between addresses that are protected by the
>initiator and responder e.g. subnet<->subnet security.  In this
>case the IDci and IDcr in the *Quick Mode* SA negotiation will be
>different from the initiator and responder addresses.