[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-IP type Client IDs

At 08:41 20.8.1999 -0400, Mike Williams wrote:
>See my comments below.
>
>Mike Williams
>IBM Corporation
>
>
>Joern Sierwald wrote:
>
>> The use of Phase 2 IDs is indeed a bit unclear and implementations
>> use them differently.
>>
>> In my opinion, phase 2 IDs should be limited to the IP address types:
>>   IPSEC_ID_IPV4_ADDR                    = 1,
>>   IPSEC_ID_IPV4_ADDR_SUBNET             = 4,
>>   IPSEC_ID_IPV6_ADDR                    = 5,
>>   IPSEC_ID_IPV6_ADDR_SUBNET             = 6,
>>   IPSEC_ID_IPV4_ADDR_RANGE              = 7,
>>   IPSEC_ID_IPV6_ADDR_RANGE              = 8,
>>
>> If you are a mobile user, you send your current IP address as IDci.
>> The gateway has to remember the source address of the ISAKMP packets
>> and compares that with IDci. If they match, the SA is allowed.
>>
>
>I don't believe that this is a valid check.  The responder in this case
>has no way of knowing that the initiator is a client.  
Why not? Phase 1 is finished. You have the phase 1 ID, which is USER@FQDN
or ASN1_DN. 

>Making this check
>would prevent the initiator from ever being a gateway.  
Yes. That's the point. You don't want mobile users to be gateways.

>It is valid for
>IDci to be different than the IP address of the initiating IKE system
>when the initiator is a gateway.
Well, sure. Your GW policy says "remote ID (phase 1) 100.100.100.100 
is a gateway, the LAN behind it is 100.100.101.0/24" 
and "remote ID me@somewhere is a client".
I perform the abovementioned "ISAKMP IP address == IDci" test only
for the client, right?
100.100.100.100 will send a subset of 100.100.101.0/24 as IDci.

>
>>
>> Problem remains, what to do with NAT between two IPsec hosts.
>> Now the IDci and the source IP address of ISAKMP packets never
>> match. Using USER_FQDN would indeed solve this, but I'd rather
>> assign a fixed private IP address for the client, so the IDci
>> is always 192.168.7.9, no matter from where he dials in.
>> Or use cfg-mode.
>>
>
>Without using something like USER_FQDN or KEYID, how can you have
>different phase 2 policies for different remote users.  
For mobile users, I use USER@FQDN or ASN1_DN in phase 1 with aggressive mode.

>I also believe
>that there are many cases when you will not be able to assign a fixed
>private IP address to the client.  Config Mode does help, but I don't
>know why we should preclude other options.

Well, I don't recommend cfg-mode, you can usually live without it.

Jörn
References: