[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heartbeats Straw Poll
In message <399195F6.C21F3863@redcreek.com>, "Scott G. Kelly" writes:
>"Steven M. Bellovin" wrote:
>>
>
>> Precisely. In ipsra, it was pointed out that we need some sort of
>> identifier to pass to DHCP in lieu of a MAC address. If we use, say,
>> the cert-id, someone who dials in anew and negotiates a new SA will get
>> the same DHCP address, which is exactly what you want to preserve
>> ongoing application connections. Furthermore, by DHCP semantics you
>> can't reuse an address until its lease is up, which again means that
>> you don't need a heartbeat to tell you that you've lost touch.
>>
>
>Maybe I'm misunderstanding you. If you require dhcp to associate a
>specific cert-id with a specific address, you lose scaling capability,
>meaning you may as well statically assign the address. What seems more
>reasonable is to associate a pattern (which the cert-id or whatever you
>use matches) with an address *pool*, but in this case you have no
>guarantee that the same address is reassigned in subsequent attempts,
>and in fact, this is somewhat unlikely. This in turn implies that there
>may be a window during which addresses become unavailable, but the
>window size may be reduced by shortening the dhcp lease duration.
>
It's the behavior of DHCP server I'm referring to; see section 4.3.1
of RFC 2131. Briefly, DHCP servers have a pool of addresses that they
hand out. If a client with a valid lease requests an address, the old
one SHOULD be handed back. If the client had had an address, but it
has expired, it SHOULD be given back to that same client if still
available. Or, if the client remembers its old address, it can request
it specifically; again, it SHOULD be given that address if possible.
But no, there is no one-to-one, static mapping of clients to addresses.
And clients can do explicit DHCP Release operations to surrender an
address if they're done with it.
--Steve Bellovin
Follow-Ups: