[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKECFG and DHCP (was Getting the Feature Chart going)
>What you describe above becomes increasingly complex as you proceed.
>This concerns me...
Handling address pool assignment and providing authenticated DHCP
definitely does add some new wrinkles. After I sent the message I
realized that there were probably a few other things that would
be needed that hadn't been listed. For example, if you are managing
address pools on the sgw, then you probably need a MIB or other address
allocation management mechanism so that you can keep track of how
many addresses have been allocated out of the pool and be notified
when the address pool is running out. It is also worth noting that
the DHCP WG is working on a failover protocol so that if you wanted
to achieve equivalent resilience in this case you'd also need to
think about how to provide failover functionality for address
allocation on the sgw.
There are also may be some new wrinkles that arise in
dealing with mobile IP. A mobile node connecting via tunnel mode
has already presumably obtained a care-of-address and wants to
use its home address inside the tunnel. Therefore it does *not*
want the sgw to assign an IP address. It also needs IKE to be able
to handle packets on that SPI coming from another care-of-address
if it moves, all without having to renegotiate the SA. So the client
would need either not to request an IP address at all and just use
the Home Address, or be able to decline an offer of an address in
a way that clearly indicates mobility preference.
>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 is definitely worth exploring. It's worth noting that the DHCP SA
setup and teardown would presumably occur in phase 2 and be able to
leverage the phase 1 negotiation. So it's not entirely clear to me that
these operations are very heavy weight since there should be no
D-H exchange involved. I'm curious as to what others think about this.
It's also worth noting that the DHCP operations described above,
while potentially complex, probably don't consume many cycles since
other than the authenticated DHCP option signing (based on HMAC-MD5)
there really are no cryptographic operations involved.
References: