Subject: RE: Modefg considered harmful

From: Van Aken Dirk <[email-masked]>
Date: Fri, 31 Jan 2003 12:28:07 +0100

Hello ipsra people,

Thank you for this extensive explanation/motivation !

Personally I'm in favour of RFC3456 solely because of following reasons:

1) RFC3456 allows me to separate IKE from IP configuration.
What is the added value of this approach ?
Well I don't need to dig into IKE code in order to have remote IP-IPSec
configuration working. 
True I must make changes to the surrounding of IKE (create the necessary
policies, cope with short lived tunnels, add some routes modify a DHCP relay
etc ..). But the added value is I can leave IKE intact and preserve its
security properties.

As a remark, my background is not in IPSec but in LAN/WAN networking and I
integrate IPSec more from a "building block" point of view. Of course people
writing IKE code have the opposite approach.

2) IKE-Mode-Cfg is very limited in features
IMHO, the IKE-Mode-Cfg is already limited in its capabilities implying it
shall be extended soon, most likely via proprietary extensions. Currently,
the IKE-Mode-Cfg features might be sufficient as there are still a lot of
implementations around that can only operate with static IP config. For
these the move toward dynamic config is a big step. However shortly after
that new features will be needed, currently not foreseen in IKEv2.
Choosing the DHCP based method on the other hand gives me the assurance that
I won't have to change my IKE code in the future just because a new feature
is requested. All that I have to foresee in that my IPSec implementation is
transparent for DHCP messages. There is an important benefit to this: IKE
code remains unchanged in the advent of new features hence security
properties are not lowered and extensive validation cycles can be avoided.

3) Scalability & integration with networking infrastructure.
A last important factor is how well does an IPSec Gateway embedding
IKE-Mode-Cfg integrates with the surrounding network infrastructure ?
As an IPSec GW is part of larger infrastructure which is for sure based on
DHCP, it will have to integrate with it. This implies tying state machines
together. My experience with this kind of constructs is that this will
always fail in one form or another because of state machines not being
identical, different message formats, different timers and so on.

As a last word, I too would like to see a consensus (whatever it is) as it
is always better to have one instead of implementing two methods and
confusing customers.

Dirk

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: Cheryl Madson <[email-masked]>
Date: Fri, 31 Jan 2003 06:59:29 -0800

>etc ..). But the added value is I can leave IKE intact and preserve its

Well, some of us take the view that this is still really part of IKE, just 
in a
roundabout way (e.g. this whole "special short-lived tunnel" stuff). Sort of
like the implicit "phase 0" of PIC. Also, address assignment may in many
cases end up being associated with the original user credentials (e.g.
what address I give you, if at all, depends on who you are). This means
that I can have a finer degree of control over where you might be able
to go (think of an SP RAS), so I'd argue that there still is a binding with
IKE. Doing it outside of IKE can overly complicate things, IMO.

Apart from the above issue, the desired model (in general terms) isn't
clear to me. I never saw any discussion of the below in the IPSRA
requirements. (Or if it was there, it wasn't represented in a way that
us non-remote access geeks understood).

Is all this information really pass-through from the "address assignment
server" to the client? Is there any case (either now or imagined in the
future) where the RAS may have a need to know some of this information
(is the RAS expected to enforce something)? If so, how do we define
which pieces the RAS has to care about and which pieces the RAS can
ignore (which becomes an issue in terms of extensibility)?

thx - C

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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Jan 2003 06:42:48 -0800 (PST)

> what address I give you, if at all, depends on who you are).

Conditional address assignment is supported by most modern DHCP servers,
and the facilities are quite rich. So it probably makes more sense to use
the existing DHCP facilities (including conditional processing of the
Class and Client-Identifier options), rather than try to add this
functionality to IKE -- especially since the contents of the IKE
identifier payload does not necessarily map well to the identifiers used
for DHCP conditional address assignment. That means that with Modecfg it
is actually quite difficult to create a unified IP addressing plan.

> requirements.

The general requirements are there -- but the details are left for
discussion in RFC 3456.

> (is the RAS expected to enforce something)?

Well, the RAS does need to know what address was assigned to plumb the
correct route. But the address assignment and configuration *is*
end-to-end -- the RAS is a DHCP Relay, not a DHCP proxy.

> If so, how do we define

Because the RAS is a DHCP Relay all the obligations of a DHCP Relay apply,
as it would for any other Relay application.