[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: parallel vpns
>Hi Sankar,
>
>Comments follow quoted text...
>
>Sankar Ramamoorthi wrote:
>>
>> Hi,
>>
>> An IPSec Architecture question.
>> In the following network
>>
>> S1----- -----D1
>> | |
>> SG1 SG2
>> | |
>> S2_---- -----D2
>>
>> I have a setup where a pair of gateways SG1, SG2 are protecting
>> hosts S1,S2 and D1,D2 respectively. I want to define 2 vpns
>> VPN1, VPN1 where
>>
>> S1,D1 belong to VPN1
>>
>> S2,D2 belong to VPN2
>>
>> Does IPsec architecture allows for such policy defnitions?
>> ie: multiple VPNs managed by a pair of gateways.
>>
>> If so
>> Can the main mode characterstics for VPN1 and VPN2 be different?
>> Are there any constraints on how they can be different?
>>
>> For example:
>>
>> VPN1 (main mode characterstics)
>> DES, MD5, preshared authentication with secret1
>>
>> VPN2 (main mode characterstics)
>> DES, MD5, preshared authentication wih secret2
>>
>> VPN1 and VPN2 are different only in the preshared secret used
>> for authentication purposes.
>>
>> SG1 initiates an IKE request to SG2. How can SG2
>> determine to which VPN the request belongs looking the SA
>> request?
>>
>> If SG2 were to pick the wrong VPN, then authentication will
>> fail down the line and SG1 will not be able to complete
>> the IKE exchange.
>>
>> I thought about using non-ip identifiers and having different phase 1
>> identifiers
>> for VPN1 and VPN2, but that leads to different set of problems.
>>
>> What am I missing?
>>
>> Thanks for any input.
>>
>> -- sankar --
>
>
>Use agressive mode, with ID_KEY_ID payload to identify the preshared
>key.
>
>Scott
Thanks for the suggestion.
One problem in this approach is that both parties need to know
how to map the preshared key into a opaque stream of bytes.
Also I presume you are suggesting ID_KEY_ID as a way of getting
identity protection while still having the advantages of using
aggressive mode. If so how secure/vulnerable is the identity
protection provided by ID_KEY_ID mechanism?
-- sankar --
Follow-Ups: