[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Configuration portion of OPEN ISSUES...



I am afraid my previous post was unsuccessful. (I apologize if you've seen it twice) I would also like to argue we go with 1) or Derek's interpretation of 3) on the basis that *)Configuration Payload satisfies the basic needs(IP address, DNS, WINS) *)Most install base I am aware of uses ldap or RADIUS not DHCP as address server Regards! /Jing Jing Xiang, jxiang@nortelnetworks.com Nortel Networks Contivity Engineering -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Wednesday, February 26, 2003 2:13 PM To: Tylor Allison Cc: Van Aken Dirk; 'Gregory Lebovitz'; 'Theodore Ts'o'; ipsec@lists.tislabs.com; byfraser@cisco.com Subject: Re: Configuration portion of OPEN ISSUES... Tylor Allison writes: > > To clarify this open issue can we modify the list as follows (in order to > > not have any confusion on what we are discussing about): > > > > 1) Keep configuration payload > > 2) Remove configuration payload and pursue RFC 3456-style configuration > > 3) Keep configuration payload and allow optional RFC 3456-style > > configuration > > 4) Remove configuration payload and pursue an DHCP-over-IKE style > > configuration > > > > I'm in favour of 2) and can live with 3). > > > > Dirk > > I agree with this distinction in the options... > > I'd prefer to see option 1 or 4... don't really care which one. I strongly > disagree with option 3... leaving this optional really means implementing > both if you want to be interoperable with all vendors. I think option 3 needs to be clarified some before it's written off completely. My reading of option 3 is that you use the config payload for the IP Address, netmask, and a few, limited other options, and then optionally the client can use DHCP to obtain _other_ configuration informtation. Perhaps we need a "3a" and "3b" to define the different interpretations of what you have in option 3? If my interpretation of #3 is "correct", then I have no problem with it, because it does not affect the IPsec/IKE implementation at all. It's just a hook on the client to run the DHCP client once you're up on the net. The (standalone) DHCP client can perform further configuration (beyond IP Address leases, which you get from the config payload). Personally I don't have a strong opinion between 1, my interpretation of 3, and 4. I would lean towards 1 or my interpretation of 3, only because DHCP is larger and less bounded, so it would be nice to know we can complete the configuration process in 2 messages (via config) rather than 4-6 additional messages (via encapsulated DHCP). Size and latency do matter, to some extent. I think that all of it is dwarfed by RSA/DH operations, but the number of round trips does matter. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com