[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKECFG and DHCP (was Getting the Feature Chart going)
Hi Bernard,
Bernard Aboba wrote:
>
<trimmed here and there...>
> >Does this mean the IPSEC security gateway (sgw) also runs a dhcp server?
>
> No, I hope it dos not mean that. You probably want
> a sgw machine to only perform that function.
(preserving above for later reference below)
>
> >Does it mean that we embed a dhcp (bootp) relay spoofer within the isakmp
> code?
>
> I do think that the sgw will end up running as a DHCP relay. If the address
> is assigned by the pure DHCP method, then this will be the only involvement
> that the sgw will have in the DHCP process. If the address is assigned
> within
> IKECFG, the interaction becomes somewhat more complex as described below. If
> IKECFG *only* handles addressing, then I think that the sgw will serve as a
> relay for DHCP INFORM packets, used for configuration.
> Since the IKE negotiation will have completed by the
> time the INFORM is sent, I don't think that the IKE code will need to be
> involved in the INFORM per se. However, as noted below, the sgw role
> with respect to address assignment is somewhat more complicated, as
> described below.
>
> The way address assignment would work is presumably similar to the
> way NAS devices handle address allocation within PPP today. This is
> typically by one of two methods: allocating out of an assigned pool,
> or making a DHCP request on behalf of the user.
>
> In allocating out of an assigned pool, there is typically an assumption that
> the sgw "owns" the address space with an infinite lease and that users
> connected
> to it get to use the address for as long as the session/tunnel remains up.
> So you do not get into the issue of leases and renewal.
>
> However, this model can be complicated by the fact that often there is more
> than one address pool, so that there needs to be a selection of what pool
> the address is assigned from. Since some networks use the pool in order
> to differentiate beween users for things like QoS, it can be important
> to be able to get this right. The pool can be negotiated between the user
> and
> sgw or the sgw can select it based on information it gleans from the IKE
> phase 1 negotiation, such as the identity. One question is whether most
> current implementations offer enough information to make this decision
> or whether additional IKECFG attributes are needed. In DHCP this kind of
> issue is handled via the User-Class option. I think that such an option
> will be needed in IKECFG for reasons that follow.
>
> When making a DHCP request on behalf of the user, it is necessary for IKE
> to be able to receive the same kind of address that the user would have
> gotten for himself. This implies that the sgw must be able to impersonate
> the user if DHCP authentication is in force, or must be able to request
> a DHCP address with the proper User-Class option so that the user is
> assigned
> out of the right pool. Since User-Class cannot necessarily be ascertained
> from the user identity, I think that this will be needed in IKECFG.
>
> Impersonation of the user in DHCP authentication is an interesting issue.
> Right now the IKECFG proposal does not address this, which is a
> shortcoming. Networks concerned enough about security to deploy IPSEC are
> probably among those who will care about DHCP authentication. In order
> to be able to impersonate the user context for DHCP authentication, the
> sgw must be able to verify integrity/auth options returned by the server,
> as well as to sign these options on behalf of the user. This implies that
> the sgw must either proxy between the user and DHCP server in a full fledged
> DHCP conversation, *or* must have access to the appropriate secrets to
> act on the user's behalf.
>
What you describe above becomes increasingly complex as you proceed.
This concerns me, and I think it contradicts the sentiment expressed
above when you said
> No, I hope it dos not mean that. You probably want
> a sgw machine to only perform that function.
In fact, this is what has concerned me most about isakmp-cfg and xauth
all along: they add significant complexity to IKE. I think that added
complexity most likely degrades security, and that we should strive for
the simplest, most secure mechanism. I don't think this necessarily
rules out isakmp-cfg in a definitive way, but I think it should make us
very suspicious of its suitability for the specific task at hand.
I think one of the things we need to nail down at this point regards
scalability limitations. In an earlier email, you expressed concern that
using individual dhcp SAs for remote clients would not scale well. I'm
curious as to how many individual remote clients we're talking about,
and how the work related to dhcp proxying as discussed above compares to
the work related to setting up and tearing down the individual SAs. This
would give us a good relative indicator regarding the scalability
differences of the 2 approaches.
I'm continuing to think about this, but if you (or anyone else) has
already worked through some of this, I'd be interested in seeing the
results.
Scott
Follow-Ups:
References: