RE: Proposed Configuration payload for IKEv2

["Darren Dukes" <ddukes@xxxxxxxxx>]

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
> > >
> >