[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Non-IP type Client IDs
You have mentioned the two alternatives that need to be handled.
The first alternative is that the initiating system sends the USER_FQDN as
IDci in quick mode. This allows the gateway to lookup policy based on
client IDs, however the gateway must then assume that the selectors to use
in IPSec are the initiators IP Address (rather than IDci) and IDcr.
The second alternative is that the initiator send it's dynamically assigned
IP address in IDci. In this case, the assumption is that IDii used in
phase 1 will be something like USER_FQDN or KEYID and IDii together with
IDcr can be used to lookup phase 2 policy. In this case, the selector
values used by IPSec will be IDci and IDcr directly.
We have decided that we need to be able to handle either of these
situations, however we have seen that some implementation will not support
the first. What I am trying to understand is whether or not both are
allowed. From reading the RFCs, I believe they are.
Mike
"Mason, David" wrote:
> [snip]
>
> >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.
>
> The certificate used in phase 1 differentiates between remote users.
> If you're relying on a USER_FQDN in phase 2 to determine policy such
> that user1@xxx.com is allowed access to all machines behind the gateway
> and user2@yyy.com is only allowed access to a subset of machines,
> user2@yyy.com will just stick user1@xxx.com in its phase 2 ID. I'd
> prefer to restrict phase 2 IDs to IP addresses. The certificate is
> the identity of the remote peer, duplicating this identity in various
> parts of the exchange(s) is redundant and unnecessary.
>
> -dave
Follow-Ups:
References: