[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dhcp/modecfg summary



Hi Michael,

Michael Richardson wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> >>>>> "Scott" == Scott G Kelly <scott@bstormnetworks.com> writes:
>     Scott> - some folks seem to imply that remote access entails only a pc
>     Scott> connected to the target network over the internet; in fact, many
>     Scott> telecommuter applications involve a personal sgw at the remote
>     Scott> end, with a small network behind it - this should not be ignored
>     Scott> in evaluating prospective mechanisms.
> 
>   This is small office VPN to me, not a road warrior.
>   Unless you claim that it moves around, it is really a different situation
> than RW. If you claim that it is in scope, then so are all "VPN"s.

I agree that the line is sometimes a little fuzzy, but what
differentiates these scenarios is that the IP address of the remote
user's personal sgw is not fixed, and so it cannot be preconfigured on
the headend. In some cases, the small network behind gw consists of a
single system:

+-------+   +------------++              
| user  |---|personal sgw||=[internet]==
+-------+   +------------++

The fact that the ipsec implementation is BITW instead of a BITS does
not invalidate this as a remote access scenario. It can be implemented
in such a manner as to be indistinguishable from a software
implementation from the other end of the connection. I've personally
worked on an implementation where the remote sgw does a ULA exchange
with the user (similar to xauth) through the tunnel. This *is* a remote
access scenario.

Scott



> 
>     Scott> - one stated aim of this wg in redesigning IKE has been to
>     Scott> minimize impact on ike, to not add anything which is not
> 
>   I want to emphasis that while we want to minimize impact on ike, we are
> changing that piece. We want *ZERO* impact on RFC2401 if possible. We may add
> (i.e. AES being a MUST) to 2401bis, but I think that IKEv2 should assume that
> IPsec is implemented in some piece of silicon and can't be changed.
> 
>     Scott> required. If we stick to this position, this seems to imply that
>     Scott> dhcp support will be required regardless (via dhcp inform and
>     Scott> relay), unless we actually intend to expand modecfg2 to encompass
> 
>   I agree.
> 
>   To me, the only question is: DHCP over IPsec vs DHCP over IKE.
>   DHCP over IKE basically looks just like modecfg.
> 
>   Thank you very much for the summary.
> 
> ]       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
> 
> iQCVAwUBPkRb1IqHRg3pndX9AQE4ngP9HiXgkhtrT930DSuLWYVAXpUVTLsgEv3A
> Ec5jlFtONC7xbFToVqVPMtLSuaxDJ91KE/ntA7q9X3T48c+lUCNxSoAzeSKnGW9h
> MrSVNARAhGVqXtziTqAKNO6Ni0NQbHg595Xp5CyjZVzFYJFCclMjt9in7GVt4/Hz
> Sc7cWsTdVl8=
> =Q82N
> -----END PGP SIGNATURE-----

-- 
-------------------------------------
BlackStorm Networks is now airespace
-------------------------------------