Re: dhcp-over-ike.txt

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

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


>>>>> "Gregory" == Gregory Lebovitz <Gregory@netscreen.com> writes:
    Gregory> Maybe I should post this discussion to the list since the draft
    Gregory> is now published?

  Yes.

    >> -----Original Message----- From: Michael Richardson
    >> [mailto:mcr@sandelman.ottawa.on.ca] Sent: Sunday, February 16, 2003
    >> 7:40 AM To: Gregory Lebovitz; Scott Kelly; Ted.Lemon@nominum.com
    >> Subject: dhcp-over-ike.txt

    Gregory> --SNIP--
 
    Gregory> sect 2
    >> HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, DHCP(disc)} -->
    >> 

    Gregory> Am I correct in ascerting that at this point the Security
    Gregory> Gateway would need to do a policy check on the IDi to ensure
    Gregory> that (a) user is acceptable, (b) users request should/is
    Gregory> permitted to be forwarded to configuration server?

  I would think so, yes.

    Gregory> Your draft is specifically for DHCP. However, there may be other
    Gregory> mechanisms that large enterprises/xSPs want to use to do address
    Gregory> assignment/client config, including RADIUS, PPPoE (which
    Gregory> backends to a RADIUS server), ActiveDirectory, LDAP (though less
    Gregory> common). Is there a way we could make the actual request more
    Gregory> generic to accomodate more responder types, including DCHP?

  None of those other protocols involve the actual client.
  I.e. they do not involve communication with the client. 

  PPPoE, as you point out, is really RADIUS or AAA.

  There are no DHCP servers that I'm aware of that communicate with any
of those protocols for provisioning. 

  I don't see why there shouldn't be. This implies that the gateway needs
to understand the DHCP request, and needs to know how to translate this to
RADIUS, COPS, etc..

    Gregory> This is the idea I voiced earlier of using the ModeCFG formats,
    Gregory> but being able to have the Gateway use any number of back-end
    Gregory> mechanisms, including on-board services, to actually serve the

  That's fine, but you are now forcing the client to speak two protocols:
	 1) modeCfg
	 2) DHCP over something

    Gregory> configuration elements. Those not covered by ModeCFG could then
    Gregory> be acquired by the client via a DHCP request (or [whatever]
    Gregory> request) directly to the CONFIGURATION server once the CHILD-SA
    Gregory> is established. Does this make any sense?

  Yes, it certainly could be a solution. It seems to just involve more code.

    >> 3. Comparisons with mode-cfg
    Gregory> --SNIP--
    >> The major advantage of DHCP-over-IKE vs mode-cfg is that it leverages
    >> all of the DHCP protocol infrastructure for configuration of the end
    >> host.  Further, it naturally interacts with the DHCP infrastructure at
    >> the enterprise end.

    Gregory> And the major disadvantage is that it limits us to DHCP only,
    Gregory> whereas others may want to use other forms of client
    Gregory> configuration.

  I just don't see this.
  *Some* trusted entity will have to query the X/FOO/BAR server and translate
the result to DHCP so that the client can understand it.

    Gregory> --SNIP--
    >> DHCP-over-IPsec requires that a very strange IPsec SA be configured
    >> for: 0.0.0.0/0:udp/67 <->0.0.0.0/0:udp/68.  Note that extreme care
    >> must be taken to make sure that this does not also catch packets
    >> destined to the DHCP server on the physical wire.  This SA MUST be be
    >> torn down before any traffic is mis-directed on it.  Further, it is
    >> very difficult to configure a mobile system that must maintain tunnels
    >> to two enterprises.

    Gregory> So it takes longer than if we did it in IKE, because we have to
    Gregory> set up a CHILD-SA, do the special DHCP, tear it down, and set up
    Gregory> another CHILD-SA before we can begin sending application
    Gregory> traffic.

  Yes. AND, it really is a fundamental change from 2401. Particularly
difficult for the gateway, which can have a lot of these strange 0.0.0.0/0:68
SPDs at the same time. I can't imagine what would happen on a box that runs
IKE on a different processor than the IPsec.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPlwk0YqHRg3pndX9AQFbkwQA475O/JlZky1PJ86wANYEuLJRF5stjwQa
OnqTn7KNb7J4o7/AkYxWhJAycWuDol0BdyZwgAmfOrCtF3kfossTI/OuizaUWIUw
Xlok3Y5UH1oooGzYpAl70V1LtMzR9kvxKilikUxT8GVE0iPpdOjBr8lSsgdLdXVq
3+QwuM6gq1w=
=X5R7
-----END PGP SIGNATURE-----