[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heartbeats Straw Poll
- To: Skip Booth <ebooth@cisco.com>
- Subject: Re: Heartbeats Straw Poll
- From: "Theodore Y. Ts'o" <tytso@mit.edu>
- Date: Wed, 9 Aug 2000 08:16:26 -0400
- CC: "Theodore Ts'o" <tytso@mit.edu>, smb@research.att.com, sommerfeld@East.Sun.COM, sfanning@cisco.com, warlord@mit.edu, skelly@redcreek.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com
- In-reply-to: Skip Booth's message of Wed, 9 Aug 2000 00:22:10 -0400 (EDT),<Pine.GSO.4.10.10008082355030.17976-100000@uzura.cisco.com>
- Phone: (781) 391-3464
- Sender: owner-ipsec@lists.tislabs.com
Date: Wed, 9 Aug 2000 00:22:10 -0400 (EDT)
From: Skip Booth <ebooth@cisco.com>
> Neither of these (accounting and returning IP addresses to a DHCP pool)
> are IPSEC issues. This is stuff you have to deal with even if you're
> not using IPSEC. Hence, solving it with an IPSEC-specific solution
> seems like we're barking up the wrong tree.
I think if the IPSRA WG states that IP address assignment will only
be done with DHCP, using the method described in
draft-ietf-ipsec-dhcp-06.txt, I would agree with you. However, if
you try to use local IP address pools and something like IKECFG to
hand out IP address to the clients, then I would argue that you need
keepalives.
How IP address assignment is done is a matter of the IPSRA working group
to decide; however, the use of "hacks to IKE", such as those proposed by
IKECFG were explicitly ruled out of scope according to the IPSRA
charter, which was approved by the IESG (who insisted on that
restriction).
The idea here is that we need to simplify and fix IKE, and we can't do
that if people want to keep wanting to add hacks to it.
- Ted
Follow-Ups:
References: