Subject: RE: Modefg considered harmful

From: Van Aken Dirk <[email-masked]>
Date: Fri, 31 Jan 2003 17:09:00 +0100

-----Original Message-----
From: Cheryl Madson [mailto:[email-masked]]
Sent: vrijdag 31 januari 2003 15:59
To: Van Aken Dirk
Cc: 'Bernard Aboba'; [email-masked]
Subject: RE: Modefg considered harmful

At 03:28 AM 1/31/2003, Van Aken Dirk wrote:
>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.

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.

On the credentials I can more or less agree with you. However I wonder then
what your solution is when multiple ModeCfg request must be answered by a
VPN GW. This happens in the case where there is a small VPN GW talking to a
large one and proxying for a few PC's (not VPN clients). Always use the same
credentials for several requests ?

On the other hand one might consider the DHCP Relay Agent Information
option. A DHCP relay in the VPN GW can easily add user credentials to DHCP
requests that must be forwarded. This request travels then on the trusted
network to the DHCP server which can further take this information into
account. On its way back the DHCP Relay removes this information of course.

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).
Hi Cheryl,

A reason why there was maybe no discussion in the IPSRA is because DHCP has
proven its capabilities and extensibility.

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

I'm no RAS expert either although I'm active in this arena (DSL routers).

A RAS configuration is rather simple: a user starts a PPP session with the
front-end of an Access Concentrator and provides its credentials (username &
password). Typically a Radius client on the back-end of the AC passes this
information toward a Radius server who performs the necessary checks.

If the user is allowed, an IP address is requested to a DHCP server and
given to the Access Concentrator. The AC adds a route in its forwarding
table and supplies the IP address to its front-end AC-PPP-deamon. The latter
finally delivers it to the original requestor.

Again you have the construct of two state machines that must be tied
together: PPP and DHCP.
The reason of not having DHCP all the way is IMHO historical. PPP grew up in
the WAN arena and BOOTP/DHCP in the LAN.
Due to broadband Access the boundary between WAN and LAN is disappearing and
I guess VPN technology will only accelerate this

I cannot answer for the future and extensibility. What I do know is that
ModeCfg is almost identical to PPP-IPCP (RFC1332, RFC1877) in functionality:
it supports a bare minimum on IP parameters.

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 07:09:57 -0800 (PST)

> it supports a bare minimum on IP parameters.

RFC 1877 has been heavily criticized over the years (see James Carlson's
PPP book), and the island of address state that it created has proven
to be a headache. Also, it became apparent that the set of parameters
defined in RFC 1877 was not enough -- and that attempting to duplicate
all the DHCP options was not fruitful. So PPP peers such as Windows 2000
and XP had to add support for DHCP anyway!

Given what we have learned from history, it makes little sense to
continue on with this approach, particularly with IPv6, where there are
a well defined set of address and configuration mechanisms for all types
of interfaces.