[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Non-IP type Client IDs
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. Making this check
would prevent the initiator from ever being a gateway. It is valid for
IDci to be different than the IP address of the initiating IKE system
when the initiator is a gateway.
>
> 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. 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.
>
> Jörn
Follow-Ups:
References: