Subject: RE: Modefg considered harmful

From: Van Aken Dirk <[email-masked]>
Date: Mon, 3 Feb 2003 11:07:17 +0100

Hi Darren,

See my comments below.

> -----Original Message-----
> From: Darren Dukes [mailto:[email-masked]]
> Sent: vrijdag 31 januari 2003 21:59
> To: Bernard Aboba; [email-masked]
> Subject: RE: Modefg considered harmful
> 
> 
> Bernard you made me read a lot of specs today, something I 
> should have done
> weeks ago.  I am no DHCP expert, in fact I haven't looked at 
> RFC2131 for
> years (until today).

I wonder if you were familiar with DHCP years ago that we would still have
this discussion on ModeCfg ;-) ...

  Hopefully I've retained enough from 
> them to make sense
> to you, I know someone (probably many) will tell me if I don't.
> 
> I agree with some of what you write but ipsec-DHCP suffers 
> from some of the
> same problems as you suggest IKECFG suffers from, plus others.
> 
> "Basic Configuration"
>    A definite problem for IKECFG but I do think it can be 
> overcome with
> DHCPINFORM, 5.6.4 of RFC3118 allows the DHCP server to accept 
> authenticated
> or unauthenticated DHCPINFORM and may reply with authenticated or
> unauthenticated DHCPINFORM.  Besides if the ipsec client has 
> a shared key
> for local DHCP use he can reuse that key for the DHCPINFORM since K =
> MAC(MK, opaque unique-id).
> 
>   ipsec-DHCP suffers from the opposite problem.  It does not 
> contain the
> rich configuration options that vendors have added to IKECFG. 
>  While many
> _are_ vendor-specific the ability to move them to DHCP servers and the
> OS-specific-DHCP implementation in ipsec clients is no 
> trivial matter and
> will likely result in a non-standardized way of distributing non-DHCP,
> per-user VPN configuration.

You might have a look at the Vendor Option class in RFC2131.

BTW, IKECfg supports 6 options that are specific to IPv4; 6 options are
duplicated for IPv6 and there 3 general options.
So for IPv4 I have in total 9 options which is clearly infuficient compared
to DHCP. All other options are vendor specific implying that each vendor
implements these in its own format/syntax. If I don't create devices at both
ends on the tunnel, how am I going to solve this and how do I avoid
interoperabilty problems ?

Best regards - Dirk

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Feb 2003 04:10:57 -0800 (PST)

> overcome with DHCPINFORM.

Sure. So why include configuration in MODECFG in the first place?

> contain the rich configuration options that vendors have added to
> IKECFG.
>

Sounds like an obvious solution.