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

Re: Modefg considered harmful

At 05:00 PM 1/30/2003, Michael Richardson wrote:

>>>>> "Bernard" == Bernard Aboba <aboba@xxxxxxxxxxxxx> 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

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

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


Cheryl Madson
Core IP Engineering; Security and Services
Cisco Systems, Inc.