Re: Proposed Configuration payload for IKEv2

["Scott G. Kelly" <scott@xxxxxxxxxxxxxxxxxx>]

I know of several fielded implementations of the ipsec-dhcp draft, and
my understanding is that the group which met in Atlanta consisted mostly
(if not entirely) of mode-cfg/xauth supporters, so the outcome doesn't
seem surprising (or valid as a point of citation). 

The ipsec-dhcp doc does a nice job of explaining the drawbacks of
cfgmode vs tunneled dhcp, and it provides a modular way to implement
dynamic host configuration over ipsec tunnels which requires no
modifications to ipsec. I have personal experience with implementation,
and it is certainly no more difficult than modecfg, and it is far more
powerful.

Darren Dukes wrote:
> 
> I've never implemented draft-ietf-ipsec-dhcp-13.txt but if it works well it
> could be used for address assignment.  However there has been opposition to
> the short-lived DHCP-specific tunnel and the group that met after the
> November IETF meeting wanted something that was well understood by
> implementers, and was deployed.  CP (Configuration Payload, AKA modecfg) was
> a good fit for that.
> 
> I don't agree that "only a single mechanism is required for host
> configuration" is true for ipsec-dhcp.  First modecfg/CP may, and often
> does, use DHCP as a back end for address assignment then adds ipsec VPN user
> specific attributes to the CP.  Second, from what I understand of
> ipsec-dhcp, it would need to do the same thing but tack VPN user specific
> options on to a DHCPOFFER.  So an administrator would configure their DHCP
> server then the IRAS for VPN user specific stuff for either protocol.
> 
> Darren
> 
> > -----Original Message-----
> > From: owner-ipsec@xxxxxxxxxxxxxxxxx
> > [mailto:owner-ipsec@xxxxxxxxxxxxxxxxx]On Behalf Of Van Aken Dirk
> > Sent: Monday, December 23, 2002 10:10 AM
> > To: 'ipsec@xxxxxxxxxxxxxxxxx'
> > Subject: Re: Proposed Configuration payload for IKEv2
> >
> >
> > Hello Gents,
> >
> >
> > Is <draft-ietf-ipsec-dhcp-13.txt> not intended for IP configuration of
> > remote hosts ?
> > IMHO, <draft-ietf-ipsec-dhcp-13.txt> decouples IPSec and IRAC
> > config in the
> > sense that only a short lived tunnel is required for DHCP
> > messages hence all
> > other complexity is in DHCP.
> >
> > What is gained from decoupling IKE from host configuration is that only a
> > single mechanism is required for host configuration. In that way a system
> > administrator must not learn new mechanisms/methods to configure hosts. To
> > her/him it is the same whether configuring a central office or a remote
> > IPSec protected host.
> >
> > Best regards - Dirk
> >
> >
> > -----Original Message-----
> > From: Darren Dukes [mailto:ddukes@xxxxxxxxx]
> > Sent: donderdag 19 december 2002 20:39
> > To: Hugo Krawczyk
> > Cc: ipsec@xxxxxxxxxxxxxxxxx; ietf-mode-cfg@xxxxxxxx
> > Subject: RE: Proposed Configuration payload for IKEv2
> >
> >
> > > From: Hugo Krawczyk [mailto:hugo@xxxxxxxxxxxxxxxxx]
> > > Sent: Thursday, December 19, 2002 12:30 PM
> > >
> > > On Wed, 18 Dec 2002, Darren Dukes wrote:
> > >
> > > > Attached is a draft which is intended to be merged with the
> > IKEv2 draft.
> > > > There is no intent for this draft to continue on its own.  It
> > contains a
> > > > payload and description of how an IPsec Remote Access Client
> > > (IRAC) may use
> > > > that payload to get configuration information (internal IP,
> > > subnets, etc.)
> > > > from an IPsec Remote Access Server (IRAS).
> > > >
> > > > The payload in this draft is very similar to the IKEv1 modecfg
> > > draft, this
> > > > draft states the differences between the two.
> > > >
> > > > Why do this?  (copied from vpnc.org) "At the IETF meeting in
> > Atlanta in
> > > > November, 2002, the IPsec WG decided to add remote access capabilities
> > > > (legacy authentication and remote client configuration) to
> > IKEv2. At an
> > >
> > > If I understand it correctly, your draft only addresses the
> > remote client
> > > configuration issue, not the legacy authentication. How do you envision
> > > adding the legacy authentication support and still making use of the
> > > configuration mechanism described in the draft?
> >
> > After taking a quick look at Paul's draft he just sent out, I
> > think CP will
> > go in the LAS exchange message 3 and message N the same way it's specified
> > for message 3 and 4 now.
> >
> > > Note that you add the
> > > configuration mechanism to messages 3 and 4 of ikev2 and assume
> > that it is
> > > protected under the IKE-SA, however if you need to perform legacy
> > > authentication then you will not have an established IKE-SA in
> > messages 3
> > > and 4.
> > >
> > > Also, it is worth noting that even if client and server use regular IKE
> > > authentication (signatures or preshared key) then in message 3
> > the server
> > > (responder) is not yet authenticated by the client so the information
> > > transmitted from IRAC to IRAS in this message is NOT protected. This
> > > should be documented and explicitly said that this message should not
> > > contain any confidential information.
> >
> > You are right about message 3, and the IRAS not being
> > authenticated to IRAC.
> > I think text about the lack of authentication should suffice with strong
> > suggestions of what configuration attributes should go into the
> > CFG_REQUEST.
> >
> > >
> > > These problems are solved if the configuration information exchange
> > > happens in phase 2 (at the expense, of course, of more round trips).
> >
> > I had originally thought of this as just a post 'phase-1'
> > exchange but since
> > the first Child-SA is always created in message 3 and 4 we will need the
> > configuration data before or during its creation.  Without it the IRAS has
> > no way of knowing how to narrow TSi in message 4.
> >
> > Darren
> > >
> > > Hugo
> > >
> > > > informal design team meeting after the WG meeting, the VPN
> > > vendors attending
> > > > decided that the best options to propose to the WG were to add
> > > capabilities
> > > > similar to XAUTH and MODE-CFG."
> > > >
> > > > Please send all comments regarding this draft to
> > ipsec@xxxxxxxxxxxxxxxxx
> > > >
> > > > Thanks,
> > > >   Darren
> > > >
> > >