Subject: Re: Modefg considered harmful

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 30 Jan 2003 19:51:27 -0500

"what bernard said".  

I see modecfg as reinventing a square wheel.

DHCP is sufficient to solve this problem.  

					- Bill

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Jan 2003 15:09:13 -0800 (PST)

OK, I'll speak up.

One of the major requirements for IPSRA in choosing DHCP-based
configuration was so that we could move towards a single configuration
model for both real and virtual interfaces -- and one which supported the
security features that have been under development over the last few years
-- such as RFC 3118 and was compatible with both IPv4 and IPv6.

Among other things, Modecfg does not satisfy those requirements,
as outlined in RFC 3456. In particular, were Modecfg to be extended to
IPv6, it would constitute an alternative to RS/RA, complicating the IPv6
architecture.

In addition, Modecfg is incompatible with DHCP security as
described in RFC 3118, so that contrary to your statements below, it is
*not* easy to integrate it correctly with DHCP.

There are lots of other reasons why Modecfg is a bad idea -- and why the
IPSRA WG chose not to select it. In fact, there are so many that an entire
appendix in RFC 3456 had to be devoted to listing them all (and I left out
quite a few). Here is the text:

======================================================================
Appendix - IKECFG evaluation

   Alternatives to DHCPv4, such as ISAKMP CFG, described in [13], do not
   meet the basic requirements described in [21], nor do they provide
   the additional capabilities of DHCPv4.

   Basic configuration
         While ISAKMP CFG can provide for IP address assignment as well
         as configuration of a few additional parameters such as the DNS
         server and WINS server addresses, the rich configuration
         facilities of DHCPv4 are not supported.  Past experience with
         similar configuration mechanisms within PPP IPCP [11] has
         taught us that it is not viable merely to support minimal
         configuration.  Eventually, either much of the functionality
         embodied in the DHCPv4 options [4] is duplicated or support for
         DHCPINFORM [3] will be required.

   Address management integration
         Since IKECFG is not integrated with existing IP address
         management facilities, it is difficult to integrate it with
         policy management services that may be dependent on the user to
         IP address binding.

   Address pool management
         IKECFG does not provide a mechanism for the remote host to
         indicate a preference for a particular address pool.  This
         makes it difficult to support address pool management.

   Reconfiguration
         IKECFG does not support the concept of configuration leases or
         reconfiguration.

   Fail-over support
         Since IKECFG creates a separate pool of address state, it
         complicates the provisioning of network utility-class
         reliability, both in the IP address management system and in
         the security gateways themselves.

   Security and simplicity
         As past history with PPP IPCP demonstrates, once it is decided
         to provide non-integrated address management and configuration
         facilities within IKE, it will be difficult to limit the
         duplication of effort to address assignment.  Instead, it will
         be tempting to also duplicate the configuration, authentication
         and fail-over facilities of DHCPv4.  This duplication will
         greatly increase the scope of work, eventually compromising the
         security of IKE.

   Authentication
         While IKECFG can support mutual authentication of the IPsec
         tunnel endpoints, it is difficult to integrate IKECFG with
         DHCPv4 authentication [5].  This is because the security
         gateway will not typically have access to the client
         credentials necessary to issue an DHCPv4 authentication option
         on the client's behalf.

   As a result, security gateways implementing IKECFG typically request
   allocation of an IP address on their own behalf, and then assign this
   to the client via IKECFG.  Since IKECFG does not support the concept
   of an address lease, the security gateway will need to do the renewal
   itself.  This complicates the renewal process.

   Since RFC 2131 [3] assumes that a DHCPREQUEST will not contain a
   filled in giaddr field when generated during RENEWING state, the
   DHCPACK will be sent directly to the client, which will not be
   expecting it.  As a result, it is either necessary for the security
   gateway to add special code to avoid forwarding such packets, or to
   wait until REBINDING state.  Since [3] does not specify that the
   giaddr field cannot be filled in when in the REBINDING state, the
   security gateway may put its own address in the giaddr field when in
   REBINDING state, thereby ensuring that it can receive the renewal
   response without treating it as a special case.
======================================================================
B) DHCP-based vs. MODECFG style remote access configuration
-----------------------------------------------------------

Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a
Configuration payload with defined attributes.  An alternate mechanism
involves using tunneled DHCP requests.  The latter approach is about to be
published as an RFC by the IPSRA working group.  Proponents of this method
argue that it is more powerful than modecfg (because of the extensibility
and large number of options already specified for DHCP; for example, being
able to specify DNS, time, print, or WINS servers, and so on.)  It is also
argued that it requires less code on the server/firewall, since an
existing DHCP server can be used.

Proponents of the modecfg approach argue that many implementation already
have support for modecfg, and that setting up sort-lived specialized
tunnels to allow the DHCP packets to flow through the gateway is kludgy,
and requires multiple special case entries into packet forwarding tables.
Modecfg proponents also argue that it is also possible to transform
modecfg requests into DHCP requests, so there are implementation choices
that do not require reimplementation of the DHCP's address assignment
function.  They also point out that it certainly is possible --- and in
some ways easier --- to obtain the time, print, WINS server information by
using DHCP (via the DHCPINFORM
request) after the IPSEC tunnel is setup and the client address is
assigned.

Either approach seems to be workable.  It is certainly true that most of
the people in Atlanta were implementors who were already familiar with
modecfg, representing a large implementation community.  That being said,
there is also some number of working group members that are in favor of an
approach similar to draft-ietf-ipsec-dhcp-13, including Van
Aken Dirk, Michael Richardson, and Scott G. Kelley.   One way or
another, however we need to make a choice and move forward.

Given that we have a fully specified solution in the ikev2-04 draft, and
it would seem that while there is a sizeable minority in favor of the
ipsec-dhcp-13 approach, the majority are comfortable with the modecfg
based approach.  So at this point, we, as working group chairs, judge that
the consensus is with the current approach.

If there are those who feel otherwise, or who see fatal problems with the
current approach, please speak now.

					Ted and Barabara
					IPSEC wg chairs

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2003 20:00:41 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:
    Bernard> OK, I'll speak up.

    Bernard> One of the major requirements for IPSRA in choosing DHCP-based
    Bernard> configuration was so that we could move towards a single
    Bernard> configuration model for both real and virtual interfaces -- and

  Bernard, I support your reasoning for using DHCP.
  (I'd rather that we used DHCPv6 rather than RS/RA. Since DHCP is a lot
easier to secure and extend than RS/RA. But that is a different argument)

  I still do not understand why creating a ephemeral IPsec SA to carry the
DHCP traffic makes sense. I don't see that it is any easier for
bump-in-the-stack implementations, nor do I see it easier for in-stack
implementations. 

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Cheryl Madson <[email-masked]>
Date: Thu, 30 Jan 2003 17:31:31 -0800

>bump-in-the-stack implementations, nor do I see it easier for in-stack

I've always contended that for IKEv1 that *both* modecfg and DHCP
had the same underlying issue -- an introduction of a "special" state
into the protocol processing (either somewhat explicitly via "phase 1.5"
or implicitly via the "special phase 2 which if it happens has to happen
before any other phase 2").

In other words, I have always hated both proposals, basically as it
assumed that via some <unspecified> miracle both sides would
correctly figure out that this special phase had to happen and not
jump ahead in the state machine.

IMO we can do better with IKEv2. I don't have much opinion one way
or the other about encoding, but we need to explicitly spell it out in
any state machine. I don't care in terms of encoding one way or the
other, but this lack of determinism has to be addressed.

thx - C

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.7 (GNU/Linux)
>Comment: Finger me for keys
>
>iQCVAwUBPjnKuIqHRg3pndX9AQEGywP/dRrtuNSBHGPVgiBFLYhSA1asUiFQYjZW
>xGu+b/+48x/t0HwhxthBInXiqT1qWwHXf9TxuxK1RPEdpF4+A/bayl7W+bB+UH8q
>4q12R+yQkVLvxprJU8VWRxc+Wduzphw9XukDj1gZrIg7MujAIe/YMArJP4LzH8b5
>Sk1+sVLVoNE=
>=rha4
>-----END PGP SIGNATURE-----

====================================
Cheryl Madson
Core IP Engineering; Security and Services
Cisco Systems, Inc.
[email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 30 Jan 2003 21:21:50 -0500

>   (The "wraps this up in some way" really means putting a layer 2,3 and 4
> on the payload. The key thing is that it needs to look like it came via a
> DHCP relay. 

Well, the remote access gateway in this case *would* be a DHCP relay.

> The MAC address that is provided to the DHCP server for the client
> should likely be derived in some way from the public key or legacy
> auth identity)

MAC address?  or client identifier?

							- Bill

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2003 20:55:55 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Cheryl" == Cheryl Madson <[email-masked]> writes:

    >> Bernard, I support your reasoning for using DHCP.  (I'd rather that we
    >> used DHCPv6 rather than RS/RA. Since DHCP is a lot easier to secure
    >> and extend than RS/RA. But that is a different argument)
    >> 
    >> I still do not understand why creating a ephemeral IPsec SA to carry
    >> the DHCP traffic makes sense. I don't see that it is any easier for

    Cheryl> I've always contended that for IKEv1 that *both* modecfg and DHCP
    Cheryl> had the same underlying issue -- an introduction of a "special"
    Cheryl> state into the protocol processing (either somewhat explicitly
    Cheryl> via "phase 1.5" or implicitly via the "special phase 2 which if
    Cheryl> it happens has to happen before any other phase 2").

  Yes, it does seem funny.
  It seems that we need to be explicit about this. I.e. that the client
should really propose something to the gateway, following phase 1 completion
(and any legacy auth...) which essentially says "I don't know what to do,
tell me".

  I think that the proposal should have a payload of DHCPDISCOVER
payload. The gateway, wraps this up in a some way, sends it to the DHCP
server, and sends the reply back.

  (The "wraps this up in some way" really means putting a layer 2,3 and 4
on the payload. The key thing is that it needs to look like it came via a
DHCP relay. The MAC address that is provided to the DHCP server for the
client should likely be derived in some way from the public key or legacy
auth identity)

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2003 21:49:53 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:
    >> (The "wraps this up in some way" really means putting a layer 2,3 and
    >> 4 on the payload. The key thing is that it needs to look like it came
    >> via a DHCP relay.

    Bill> Well, the remote access gateway in this case *would* be a DHCP
    Bill> relay.

  yes, true!

    >> should likely be derived in some way from the public key or legacy

    Bill> MAC address?  or client identifier?

  Yeah... exactly the question.
  I don't know what the current document says.

  But, doing address allocation by MAC address is something people are
familliar with. Doing it by client identifier option is increasingly easy. I
suggest that both should be filled in. I'm not clear that the client should
be permitted to set those values directly.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 31 Jan 2003 00:52:24 -0500

> other, but this lack of determinism has to be addressed.

Cheryl,

I agree with your last point.  Indeed, the current Configuration
Payload specification in ikev2-04 is pretty explicitly spelled out.
There isn't a magic phase1.5; instead, the Configuration payload is
included in message 3 (or in any request to create a CHILD-SA), and
the response is message 4.  To quote from ikev2-04.txt:

       Initiator                           Responder
      -----------------------------       ---------------------------
       HDR, SAi1, KEi, Ni, Nr,
        SK {IDi, [CERT,] [CERTREQ,]
        [IDr,] AUTH, CP(CFG_REQUEST),
        SAi2, TSi, TSr}              -->

                                     <--   HDR, SK {IDr, [CERT,] AUTH,
                                            CP(CFG_REPLY), SAr2,
                                            TSi, TSr}

   ....

   For example, message from Initiator to Responder:
      CP(CFG_REQUEST)=
        INTERNAL_ADDRESS(0.0.0.0)
        INTERNAL_NETMASK(0.0.0.0)
        INTERNAL_DNS(0.0.0.0)
      TSi = (0, 0-65536,0.0.0.0-255.255.255.255)
      TSr = (0, 0-65536,0.0.0.0-255.255.255.255)

   NOTE: Traffic Selectors are a (protocol, port range, address range)

   Message from Responder to Initiator:

      CP(CFG_REPLY)=
        INTERNAL_ADDRESS(192.168.219.202)
        INTERNAL_NETMASK(255.255.255.0)
        INTERNAL_SUBNET(192.168.219.0/255.255.255.0)
      TSi = (0, 0-65536,192.168.219.202-192.168.219.202)
      TSr = (0, 0-65536,192.168.219.0-192.168.219.255)

Although it is very clear that this is much less powerful and less
flexible than what RFC 3456 describes (it doesn't support
reconfiguration, it doesn't support renewals periods except via SA
expiration, etc.) it does have the virtue that I can explain how it
works to somone else in about 30 seconds.  After reading through the
13 page RFC 3456 (the text devoted to the configuration payload in
ikev2-04 is perhaps 1-2 pages long), I very much doubt I could explain
the DHCP-based method as easily or as quickly.

						- Ted

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 31 Jan 2003 01:25:00 -0500

Bernard, 

Could I volunteer you (or some other RFC-3456 author/supporter) to
supply text that could potentially replace the Configuration Payload
text in ikev2-04.txt?  If it turns out that we have clear working
group consensus to replace the Configuration payload with a DHCP-style
solution, we need to have specific text that we can send to Charlie to
put into the IKEv2 specification.  Also, I think it would be easier
for the working group to come to consensus --- one way or another ---
if they can look at specific text and compare it with what is
currently in ikev2-04.

Unfortunately, we can't just point at RFC 3456, since enough things
have changed in IKEv2.  And while experts would probably understand,
"RFC 3456, except ignore the part were it talks about Phase 1 and
Phase 2, main, agressive, and quick mode, and instead do the obvious
Right Thing", it's probably better to lift the specific text from RFC
3456, and then update it for IKE V2.

BTW, looking at RFC 3456, it would probably be a good idea to specify
exactly what *should* happen in the case of "reconfiguration".
Presumably, the client will need to establish a new SA with updated
traffic selectors --- which means that on the client side, the DHCP
client code will always be inextricably bound with the IPSEC
implementation, for better or forworse --- however, RFC 3456 never
says so explicitly.

						- Ted

P.S.  For my own curiosity/edification, how often do administrators
really use DHCP reconfiguration anyway?  Given that it can seriously
screw over the user, by immediately destroying all existing TCP
connections after the IP address of the client is suddenly,
precipitously, and without warning changed, it doesn't seem like the
sort of thing which would or should be used often.  So I'm curious why
the IPSRA wg decided that reconfiguration was a requirement that MUST
be supported.  

I can see this being useful for web kiosks, perhaps, but under what
circumstances would an administrator want to play such a rude trick on
a VPN client?  (And I mean besides a BOFH being bored.  :-)

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Jan 2003 21:33:35 -0800 (PST)

> if they can look at specific text and compare it with what is

I'd be happy to help any way I can.

> 3456, and then update it for IKE V2.

I see only three places in RFC 3456 where "quick mode", "phase 2",
"main mode" or "aggressive mode" are used: pp.6 (once), pp. 9 (twice).
Rather than incorporating the text of a 17 page document into IKEv2, I'd
suggest that only the changes be incorporated into IKEv2, or if that
doesn't suffice, we can do an RFC 3456bis and reference that.

> implementation, for better or forworse --- however, RFC 3456 never

A new SA would only be needed if an address change occurred -- e.g. a Nak
was received in response to a DHCP Request. If only new options are
received then no new SA is needed.

Binding IP address assignment to the IPsec implementation is nothing new,
by the way. If you think this is wierd, you ought to read the MIPv6 and
MIPv6/IPsec documents :)

> the IPSRA wg decided that reconfiguration was a requirement that MUST

Reconfiguration can occur whenever DHCP leases expire, so support for
leases and reconfiguration was considered a basic configuration
facility in an IPv4 network where addresses may be in short supply. On the
other hand, *forced* reconfiguration is not used very often, and
typically requires DHCP authentication (RFC 3118).

> a VPN client?  (And I mean besides a BOFH being bored.  :-)

When there is a shortage of IPv4 addresses, and the administrator wants to
be able to assign an unused address to another VPN client. That's not a
rude trick -- it's a necessity in many modern networks, but one which
Modecfg does not support.

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 31 Jan 2003 07:32:16 -0500

> be permitted to set those values directly.

dhcp insists that the client fill these in.  if you want the relay to
add information, there's now a "relay agent information option"
(RFC3046) which allows the relay to append additional information to
the messages.  might do the trick here..

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Jan 2003 11:26:40 -0500

-----BEGIN PGP SIGNED MESSAGE-----

    >> be permitted to set those values directly.

    Bill> dhcp insists that the client fill these in.  if you want the relay to
    Bill> add information, there's now a "relay agent information option"
    Bill> (RFC3046) which allows the relay to append additional information to
    Bill> the messages.  might do the trick here..

  The degenerate case is a client connecting to a security-gateway/firewall
of a small organization. It should get the same inner-address as when it is
plugged into the organization LAN. 

  Worse case is that PCMCIA card is not inserted in the notebook when it not
at the office. So, even though you'd like to use the same MAC address, as
that would make life most easy for the DHCP server configuration. Do you want
to type this into the client configuration? I don't think so, as you might as
well type the IP address in!
  You may not mind putting something on the gateway however.

  Anything we can do to make the DHCP server configuration simpler, is a win
in my opinion.

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 31 Jan 2003 11:49:16 -0500

> plugged into the organization LAN. 

okay, good goal.

but the way to do this is not for the relay agent to overwrite the
client's dhcp request, but rather to annotate it using the relay agent
information option.

>   You may not mind putting something on the gateway however.

right, and there's a mechanism in the DHCP protocol for this sort of
thing, and we should use it.

						- Bill

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 31 Jan 2003 09:09:11 -0800

Hi Michael,

Michael Richardson wrote:
<trimmed...> 
> bump-in-the-stack implementations, nor do I see it easier for in-stack

This is probably a point of confusion for some, and is what originally
resulted in a change that some folks have referred to as "kludgy", that
being the on-the-fly modification of the selectors you can do to after
dhcp to avoid the second sa negotiation.

We should back up a bit, as there is something really fundamental that
should be called out. Not all ipsec users have the same security
requirements, so ideally, the mechanisms we design should be adaptable
to varying levels of security, depending upon one's needs.

In the case at hand, it is not always *necessary* that the precise
selectors be known in advance of phase 2. In some cases, we may be
willing to trust both tunnel endpoints to behave, and in such cases a
phase 2 can be negotiated with zero'd traffic selectors prior to DHCP,
and this SA can be used for all traffic. In such cases, it is not
necessary to have a separate SA for DHCP, and it is not necessary to do
anything "kludgy" if you want to avoid this. It is only in the cases
where security requirements are such that the SGW is not able/willing to
trust the IRAC, and therefore requires more stringent address controls,
in which the ephemeral DH SA (or some hack to get around it) is
required.

Scott

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Jan 2003 12:40:18 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Scott" == Scott G Kelly <[email-masked]> writes:
    Scott> This is probably a point of confusion for some, and is what originally
    Scott> resulted in a change that some folks have referred to as "kludgy", that
    Scott> being the on-the-fly modification of the selectors you can do to after
    Scott> dhcp to avoid the second sa negotiation.

    Scott> We should back up a bit, as there is something really fundamental that
    Scott> should be called out. Not all ipsec users have the same security
    Scott> requirements, so ideally, the mechanisms we design should be adaptable
    Scott> to varying levels of security, depending upon one's needs.

  No, I want to back up further.
  
  The only reason to carry the DHCP over the IPsec SA is because you've
figured out a way to *reuse* an existing DHCP client implementation.  I want
to hear from multiple people who implemented this that they were actually
able to preserve the DHCP client code.

  I can see that this may work for bump-in-the-stack people... but if you
have a bump, you have complete control on where the packet goes.

  I do not see how carrying this info over an IPsec SA is at all workable for
implementations that have IPsec in the stack. In the case of the KAME
implementation, for instance, there isn't even a virtual interface on which
you could run the dhclient on.

  The kludge, to me, is using an IPsec SA at all for this.
  I think that the DHCP payload should be encapsulated in IKE.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Jan 2003 12:24:28 -0500

-----BEGIN PGP SIGNED MESSAGE-----

    >> plugged into the organization LAN. 

    Bill> okay, good goal.

    Bill> but the way to do this is not for the relay agent to overwrite the
    Bill> client's dhcp request, but rather to annotate it using the relay agent
    Bill> information option.

  okay. I'm just not convinced that there is actually any deployed software
that lets me make this decision in the DHCP server. 
  {I've noticed that certain DHCP servers in certain commodity OSs are very
hard to even configure to provide static MAC->IP mapping... Apparently it is
possible... }

  The advantage of using DHCP is that we do not have to create new
infrastructure. The downside is that in order to maximize the simplicity, we
have to live with what is out there.

    >> You may not mind putting something on the gateway however.

    Bill> right, and there's a mechanism in the DHCP protocol for this sort of
    Bill> thing, and we should use it.

  okay. You've sold me... care to tell me what we should put in, and how I'd
deal with this on the DHCP server?

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 31 Jan 2003 10:10:50 -0800

Hi Michael,

> plugged into the organization LAN.

In my experience, this leads to routing issues that are most easily
resolved by ensuring that remote access client addresses are *never*
assigned internally.

Scott

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 31 Jan 2003 10:07:27 -0800

Hi Michael,

> able to preserve the DHCP client code.

Or (perhaps more importantly), you've figured out a way to reuse the
existing DHCP *infrastructure*. Modifications of some sort must be made
at the client end either way, whether you transport things over IKE or
over IP/IPsec. You either have to have some concept of virtual interface
which is bound to the tunnel via routing mechanics, or you have to come
up with some other sort of mechanism. Arguably, running dhcp over ike
requires more hacking than running it over IPsec.

And running DHCP over IPsec allows us to minimize the interaction with
IPsec and IKE.

> you could run the dhclient on.

I don't see the relevance - seems like if this is the case, it is the
consequence of a kame implementation decision.

>   I think that the DHCP payload should be encapsulated in IKE.

I guess we disagree on this point.

Scott

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Jan 2003 13:24:15 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Scott" == Scott G Kelly <[email-masked]> writes:
    Scott> Hi Michael,

    Scott> Michael Richardson wrote:
    Scott> <trimmed...> 
    >> able to preserve the DHCP client code.

    Scott> Or (perhaps more importantly), you've figured out a way to reuse the
    Scott> existing DHCP *infrastructure*. Modifications of some sort must be made
    Scott> at the client end either way, whether you transport things over IKE or
    Scott> over IP/IPsec. You either have to have some concept of virtual interface

  Well, if we agree on this, then we should avoid having to change both IKE
and IPsec.

    Scott> which is bound to the tunnel via routing mechanics, or you have to come
    Scott> up with some other sort of mechanism. Arguably, running dhcp over ike
    Scott> requires more hacking than running it over IPsec.

  No, it requires that you change both IPsec (to introduce these changeable
selectors, or to make it have a virtual interface, or to permit a 0/0<->0/0
tunnel) and IKE. Remember that you have to do this at the gateway as well.

  I can see implementing DHCP-over-IKE, or modecfg without any changes to IPsec.

    Scott> And running DHCP over IPsec allows us to minimize the interaction with
    Scott> IPsec and IKE.

  I don't see how this follows. It only is true if you have an existing
virtual interface, which already pretends to be an ethernet, and already runs
a dhcp client. I.e. you are a bump-in-the-stack-of-windows.

    >> you could run the dhclient on.

    Scott> I don't see the relevance - seems like if this is the case, it is the
    Scott> consequence of a kame implementation decision.

  RFC2401 does not require virtual interfaces. DHCP-over-IPsec-SA requires them.

---

From: Andreas Steffen <[email-masked]>
Date: Fri, 31 Jan 2003 20:02:38 +0100

Hi Scott,

we at the Zurich University of Applied Sciences have implemented
DHCP-over-IPsec (RFC 3456) as an add-on for Linux FreeS/WAN last
summer and this convenient feature is now being widely used by many
people. From our own VPN production system at the university we have
gained practical experience in everyday use.

If you don't allow split-tunneling for remote VPN clients then I
must agree with you that a special DHCP SA for getting a Virtual IP
address won't be needed since the subnet mask will be 0.0.0.0/0 anyway.

But in all other cases where the remote client is allowed to access
the Internet locally (e.g. via NAT) and just maintains one or several
IPsec tunnels to specific subnets, you must setup a short-lived DHCP
SA restricted to 0.0.0.0:udp/68 because the DHCPDISCOVER broadcast message
carries a destination IP of 255.255.255.255 but you wouldn't want to
tunnel all IP traffic over this SA.

Regards

Andreas

======================================================================
Andreas Steffen                     e-mail: [email-masked]
Zuercher Hochschule Winterthur      home:   http://www.zhwin.ch/~sna/
CH-8401 Winterthur (Switzerland)    phone:  +41 52 267 76 77
===============================================================[ZHW]==

---

From: Geoff Keating <[email-masked]>
Date: 31 Jan 2003 11:55:13 -0800

> before any other phase 2").

I agree with this.  One of the most annoying parts of implementing
modecfg and XAUTH when I did it was that it adds a large number of
states to IKE negotiation, and the behaviour in each state is not
always obvious.  The modecfg draft I saw, for instance, wasn't clear
on whether the initiator should expect the responder to give it an
address without asking; or whether it had to ask; or whether it could
just tell the responder that it was taking a known-good address.

-- 
- Geoffrey Keating <[email-masked]>

---

From: "Darren Dukes" <[email-masked]>
Date: Fri, 31 Jan 2003 15:58:56 -0500

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

"Address Management Integration"
   Remote access is where IKECFG and ipsec-DHCP is used, and implementations
do retrieve ipsec client user configuration from RADIUS servers.  This
brings up a shortfall of ipsec-DHCP; the SGW, as a DHCP-relay agent, can not
insert options into the OFFER or ACK without breaking RFC3118 so it can not
relay any user-specific configuration from a RADIUS server (or even locally
configured) to the ipsec client.  All user configuration must then reside on
the DHCP server, or be transported via some other method.

"Address Pool Management"
   I'm not sure what you mean here, the identity of the peer is known in
IKECFG so a pool may be selected based on that.

"Reconfiguration"
   You're wrong here.  IKECFG can support reconfiguration of an IP address.
It can either be SET by the SGW to the ipsec client if the client still has
an IKE SA when approaching the time of expiry, or the expiry attribute can
be used and the ipsec client can request the address when it is about to
expire.  The address may also be tied to the IKE SA and be released when
there is no longer an IKE-SA with the client.  The address could be changed
by the SGW on a whim, and cause all sorts of havok to tcp sessions and the
ipsec tunnels, but the same would be true for ipsec-DHCP.

"Failover Support"
  This is simpler for ipsec-DHCP since the SGW _may_ know nothing of the
contents of the ACK.  However if the SGW is sniffing the ACK to glean
configuration it will need to maintain and checkpoint that extra state as
well.  The gain in my opinion is minimal.

"Authentication"
  The SGW has no need to issue an authentication option with the clients ID.
It can use its own.  From a quick glean of RFC3118 the client identifier is
opaque to the server and only serves to uniquely identify a client and
generate or lookup a key for authentication of the DHCP* packet.  Such a
client identifier could (must?) be created by the SGW for any ipsec client
requesting an IP address via modecfg and offer the same shared key
authentication available to ipsec-DHCP clients.

Regarding this...
>    response without treating it as a special case.

It's really implementation specific but the IKECFG SGW could implement the
special code you mention (I'm sure some do now).  It could also fill in the
giaddr and act as its own relay agent for the renew request.  Ensuring it
will receive the ACK or NACK and processing and dropping it when it does.
Any other relay agents that may be between it and the DHCP server are
required to forward the packet unmodified.

Darren

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Bernard Aboba
> Sent: Thursday, January 30, 2003 6:09 PM
> To: [email-masked]
> Subject: Modefg considered harmful
>
>
> OK, I'll speak up.
>

[ddukes] This is really implementation specific but the IKECFG SGW could
implement the special code you mention.  It could also fill in the giaddr
and act as its own relay agent for the renew request.  Ensuring it will
receive the ACK or NACK and dropping it when it does.  Any other relay
agents that may be between it and the DHCP server are required to forward
the packet unmodified.

---

From: "Darren Dukes" <[email-masked]>
Date: Fri, 31 Jan 2003 16:19:00 -0500

I think any mature implementations that will be trying to use DHCP for
complete configuration of the ipsec client (beyond network addresses, as is
possible with modecfg today) will need to implement their own DHCP client
and server in order to include their user-specific ipsec-VPN configuration.
So what we'll end up with is as follows.

OS-DHCP-client(optional) <-> ipsec-DHCP-client <TUNNEL> SGW-DHCP-server

Reusing the OS DHCP client (if possible at all) will not give enough
flexibility.

Darren

> [mailto:[email-masked]]On Behalf Of Michael Richardson
> Sent: Friday, January 31, 2003 12:40 PM
> Cc: Scott G. Kelly
> Subject: Re: Modefg considered harmful
>
>
> iQCVAwUBPjq1AIqHRg3pndX9AQEd1gP/ZwbzDqY5G6ueKr71ei29o6bIP+ACO6LA
> LxgAG8+mXObjhy/njQDXNPxcbeK2gEXVCzguyv0TUZ1cG80+5e4f/vkVAD4twpjz
> LFOyzDDzJNJIqY+vQkduuu/fS5lPKsQB2q/4pjaeYw554f/voun3ZkV/E/IgC5oH
> whe/X3bjbo0=
> =5KUI

---

From: "Darren Dukes" <[email-masked]>
Date: Fri, 31 Jan 2003 16:27:13 -0500

> [mailto:[email-masked]]On Behalf Of Cheryl Madson
> Sent: Thursday, January 30, 2003 8:32 PM
> To: Michael Richardson
> Cc: [email-masked]

In IKEv2 there is no phase 1.5, either the CP is there and an address is
being requested or not.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 31 Jan 2003 14:20:35 -0800

Hi Darren,

> Reusing the OS DHCP client (if possible at all) will not give enough

What ipsec-vpn configuration are you referring to? DHCP permits
configuration of (at least) the following:

      o IP address(es)
      o Subnet mask(s)
      o Broadcast address(es)
      o Host name
      o Domain name
      o Time offset
      o Servers (e.g., SMTP, POP, WWW, DNS/NIS, LPR,
        syslog, WINS, NTP, etc. )
      o Router(s)
      o Router discovery options
      o Static routes
      o MTU
      o Default TTL
      o Source routing options
      o IP Forwarding enable/disable
      o PMTU options
      o ARP cache timeout
      o X Windows options
      o NIS options
      o NetBIOS options
      o Vendor-specific options

DHCP is obvlivious to the presence of the VPN, and as far as I can tell,
it has never been the intent of either the ipsec or ipsra wg's to
provide vpn policy config, so I can't figure out what you might be
talking about.

Scott

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Jan 2003 18:18:40 -0500

-----BEGIN PGP SIGNED MESSAGE-----

    >> Reusing the OS DHCP client (if possible at all) will not give enough

    Scott> What ipsec-vpn configuration are you referring to? DHCP permits
    Scott> configuration of (at least) the following:

  No, you are missing the point.
  The problem is that you have to filter certain things out, include other things.

    Scott>       o Subnet mask(s)
    Scott>       o Broadcast address(es)

  Might screw things up.

    Scott>       o Time offset

  probably wrong, take the one from the real IP, which likely is
geographically correct.

    Scott>       o Router(s)

  Probably wrong.

  You may also have to make sure that you take the DNS server from the
tunnel, so you get internal addresses. This needs to *override* the one from
both PPP and the DHCP on the real wire.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 31 Jan 2003 16:49:33 -0800

I don't mean this in a trite or flip way, but I simply don't have time
to explain how to set up a virtual private network configuration in dhcp
right now.  I know of a number of large and small organizations that
have been using such configurations for several years now, and your
comments below are simply wrong. 

DHCP has long provided the ability to segment configurations (address
pools/scopes, etc), and it is straightforward to configure the values
below which you suggest won't work. Perhaps you should ask the folks
from Zurich University of Applied Sciences if you can take a look at
their frees/wan implementation.

To my original point, Darren seems to be suggesting that he wants the
ability to configure values not supported by DHCP. I was simply asking
what these might be.

Scott

Michael Richardson wrote:
> iQCVAwUBPjsET4qHRg3pndX9AQFVdQP/fUOob1TNGRkKZ6HM692pLeLEG25Q9I7I
> Kcfcn9v0sknaznhmJCtP4Tw2oNCoegMexrBIx8XqNnJSZ8z3SU32/81N7Sa/sUBW
> 93GEZmDs1/P08ENBmBZ4kAkpvrzoaBd+9s5vICaSMsGsQNXbS1SrgsG/HRrxl8PJ
> u2SO5g7kQMk=
> =iTXs