RE: Proposed Configuration payload for IKEv2

[Van Aken Dirk <VanAkenD@xxxxxxxxxxx>]

Hi Darren,

Thank you for you reply. See my comments below.

-----Original Message-----
From: Darren Dukes [mailto:ddukes@xxxxxxxxx]
Sent: vrijdag 10 januari 2003 16:24
To: Van Aken Dirk; ipsec@xxxxxxxxxxxxxxxxx
Subject: RE: Proposed Configuration payload for IKEv2


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.

>>>
I don't know where I picked up this statement but it is in line with what is
happening with PPP-IPCP.
The same problem is encountered here. If a PPP link comes up, PPP-IPCP
negotiates an IP address and a Primary and Secondary DNS server. However if
one looks at DHCP there are lots of other parameters that can be
automatically configured but you won't find these in IPCP.

Nevertheless IPCP is not further extended because there seems to be
objections from working groups. I guess the IETF wants only a single
protocol to configure the IP layer being DHCP (I don't know whether this is
really the truth but this is what I heard ..)

As an example CISCO has a proprietary extension to hand out a subnet via
IPCP (see <www.alternic.org/drafts/drafts-h-i/
draft-helenius-ppp-subnet-05.html>). I guess for the aforementioned reason,
this draft never became an RFC even not an informational one.

I have the same problem with IKE-mode config; the draft is no longer
available via the IETF and I guess IKE mode config will suffer from option
limitation too. e.g. Have a look at the options that are currently available
via DHCP and note that these are constantly expanded(
<http://www.iana.org/assignments/bootp-dhcp-parameters> ).
>>>

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.

>>>
Yes but is ipsec-dhcp not more "natural" in the sense that DHCP requests
arrive in the IRAS which are then forwarded via a DHCP relay to a DHCP
server. The latter talks back to the DHCP relay in the IRAS.

Note that DHCP relays adding options to DHCP packets is quite a standardized
technique.

In addition, in other types of VPN such as BGP-MPLS there is quite some
activity in trying to come up with a scalable DHCP based IP parameter
distribution method (see RFC's and drafts below). Maybe IPSec can apply
similar techniques ? 

3046 DHCP Relay Agent Information Option
2685 Virtual Private Networks Identifier
DHCP VPN Information option <draft-ietf-dhc-vpn-option-02.txt>
VPN Identifier sub-option for the Relay Agent Information Option
<draft-ietf-dhc-agent-vpn-id-02.txt>
Link Selection sub-option for the Relay Agent Information Option for DHCPv4

BTW, I analysed a commercially available IPSec remote access solution (VPN
Client and VPN Gateway) and came to following conclusion:

- towards the external world a VPN client loaded on a Windows machine is
performing IKE-mode config 
- internally though the client drives the Microsoft DHCP client to
dynamically configure the IP interface and the routing table with IP
parameters

- on the IRAS side these IKE-mode config messages are translated back into
DHCP messages, passing over a DHCP relay and forwarded towards a stand-alone
DHCP server

- and of course in the other direction the same process is executed as well.

Wouldn't it be simpler to use DHCP all the way i.e. the construct
DHCPClient-Relay-Server ?
 
Best regards - Dirk
>>>  

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?