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

Re: IKEV2: Issue #3: DHCP vs. Configuration Payload



On 13 Feb 2003, Tero Kivinen wrote:

> tytso@mit.edu ("Theodore Ts'o") writes:
> > Hence, we suggest that as a path forward, that the Configuration payload
> > be left in ikev2-04.txt, and that people who believe that a richer
> > feature set is necessary should be encouraged to update RFC 3456 for use
> > with IKEv2 as an alternative mechanism.  Since an implementation is
>
> I do not really think it is good idea to force everybody to implement
> both RFC 3456 and configuration payload. The client will need to
> implement both, because if the server replies with empty CFG_REPLY
> then it needs to retry with RFC 3456 or similar.

I absolutely agree with this statement... if we don't move forward with a
single selection, we'll end up having to support both... and most likely
not just in the client.  I can see SGW's needing to implement both to work
with the popular clients.

> > allowed to respond with an empty CFG_REPLY packet, this should not prove
> > to be an onerous implementation burden for those who are determined to
> > only support DHCP 3456-style configuration.  While this could
> > potentially cause interoperability problems, the fact that most deployed
> > implementations already support modecfg suggests that for the simple
> > (common?) case where only a single IP address needs to be returned by
> > the IPSEC gateway, it is extremely likely that most VPN-style
> > implementations will support the Configuration payload.
>
> Allowing two things to do the same thing is bad.
>
> How about the mcr's proposal of having dhcp over IKE, i.e take dhcp
> payload and put it inside the some IKE payload (we can name it to be
> configuration payload, so the configuration payload people will be
> happy too, just change the format to follow the dhcp packet).

This is about the third or fourth proposal to use IKE as the DHCP
transport, but I haven't seen much discussion as to whether or not this is
a viable option.  Personally, I believe this has merit, any other opinions?

> --
> kivinen@ssh.fi
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/


=====================================================================
= Tylor Allison         Secure Computing Corporation        =========
=====================================================================