Subject: RE: Modefg considered harmful

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

-----Original Message-----
From: Theodore Ts'o [mailto:[email-masked]]
Sent: vrijdag 31 januari 2003 6:52
To: Cheryl Madson
Cc: Michael Richardson; [email-masked]
Subject: Re: Modefg considered harmful

On Thu, Jan 30, 2003 at 05:31:31PM -0800, Cheryl Madson wrote:
> 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.

Cheryl,

I agree with your last point.  Indeed, the current Configuration
Payload specification in ikev2-04 is pretty explicitly spelled out.
There isn't a magic phase1.5; instead, the Configuration payload is
included in message 3 (or in any request to create a CHILD-SA), and
the response is message 4.  To quote from ikev2-04.txt:

       Initiator                           Responder
      -----------------------------       ---------------------------
       HDR, SAi1, KEi, Ni, Nr,
        SK {IDi, [CERT,] [CERTREQ,]
        [IDr,] AUTH, CP(CFG_REQUEST),
        SAi2, TSi, TSr}              -->

                                     <--   HDR, SK {IDr, [CERT,] AUTH,
                                            CP(CFG_REPLY), SAr2,
                                            TSi, TSr}

   ....

   For example, message from Initiator to Responder:
      CP(CFG_REQUEST)=
        INTERNAL_ADDRESS(0.0.0.0)
        INTERNAL_NETMASK(0.0.0.0)
        INTERNAL_DNS(0.0.0.0)
      TSi = (0, 0-65536,0.0.0.0-255.255.255.255)
      TSr = (0, 0-65536,0.0.0.0-255.255.255.255)

   NOTE: Traffic Selectors are a (protocol, port range, address range)

   Message from Responder to Initiator:

      CP(CFG_REPLY)=
        INTERNAL_ADDRESS(192.168.219.202)
        INTERNAL_NETMASK(255.255.255.0)
        INTERNAL_SUBNET(192.168.219.0/255.255.255.0)
      TSi = (0, 0-65536,192.168.219.202-192.168.219.202)
      TSr = (0, 0-65536,192.168.219.0-192.168.219.255)

Although it is very clear that this is much less powerful and less
flexible than what RFC 3456 describes (it doesn't support
reconfiguration, it doesn't support renewals periods except via SA
expiration, etc.) it does have the virtue that I can explain how it
works to somone else in about 30 seconds.  After reading through the
13 page RFC 3456 (the text devoted to the configuration payload in
ikev2-04 is perhaps 1-2 pages long), I very much doubt I could explain
the DHCP-based method as easily or as quickly.

						- Ted
I agree with you if one approaches the subject from an IPSec background,
then it is indeed easier to explain the ModeCFG stuff; it are just a few IKE
messages and you are done.
However in contrast to most people in this working group, my background is
IP networking (LAN/WAN) and as DHCP client/relay/server constructs have been
around for 20 years in this area, reading the DHCP-based method appears only
natural to me.

Anyway we should not select a configuration method based on how easy it is
to explain. So a first point I want to raise is how well does IKE mode
config integrate with the rest of the networking infrastructure ?

In this respect, where does the IKE deamon gets its IP address pool from ?
Is it configured with a fixed pool or must the IKE deamon talk to a DHCP
server hence acts as some kind of DHCP proxy ?

If you start asking these kind of questions you immediatly end-up with a
construct ModeCfgClient-ModeCfgServer-DHCPClient-DHCPServer (I can think of
an even more complex construct i.e.,
ModeCfgClient-ModeCfgServer-DHCPClient-DHCPRelay-DHCPServer).
Looking at the construct DHCPClient(in tunnel)-DHCPRelay(at the VPN
GW)-DHCPServer(stand-alone server) it is far more easier to implement and
clearly separate IKE from IP configuration.

A second point is the scalability of a solution. If you can explain a
protocol to me in 30 seconds I sure know it is not scalable at all. As an
example, studying the ISAKMP framework a few years ago I immeadiatly
realized that protocols derived from ISAKMP will be scalable due to the
richness in exchanges, messages, payloads and attributes. And true you
cannot explain this framework in 30 seconds and this same reasoning applies
to DHCP.

Most likely ModeCfg provides a short term solution to a problem but I'm sure
it need to be extended to cope with future requirements.  IMHO, in order for
the ModeCfgClient to be scalable one ends-up with DHCP anyway. As an example
suppose two groups of VPN users must get IP addresses from different pools,
how is this going to be solved via ModeCfg ? These kind of things are solved
already for years in DHCP.

Dirk.

---

From: Van Aken Dirk <[email-masked]>
Date: Fri, 31 Jan 2003 16:18:34 +0100

Hi Bill,

I'm a little in the dark regarding this discussion on MAC address and Client
identifier. Can you elaborate a little such that I understand what the
problem exactly is ?

Here is may current ;-) understanding of Client-Relay-Server behaviour:

A DHCP client (whether a PC or a VPN client is irrelvant) issues a DHCP
request and fills out the chaddr field (client HW address) and the client
identifier in the client identifier option. Of course the client id can be
equal to the HW address.
A DHCP server uses clientID and/or the chaddr field to bind a lease to a
client hence must be unique within a subnet.

In larger configurations, where there are gateways between server and
client, the giaddr IP address is also taken into account as an implicit
means for subnet selection (pool selection).

Note, giaddr (gateway IP address) is automatically added by a DHCP relay.

For explicit pool selection, the DHCP Relay Information Option can be used:
it is an extensable mechanism to add information to DHCP packets
(client-to-server direction). This information can be used 1) in the server
for explicit pool selection and 2) by the relay to forward replies back to
the appropriate client (in the VPN case into the right tunnel).

-----Original Message-----
From: Bill Sommerfeld [mailto:[email-masked]]
Sent: vrijdag 31 januari 2003 13:32
To: Michael Richardson
Cc: [email-masked]
Subject: Re: Modefg considered harmful 

>     Bill> Well, the remote access gateway in this case *would* be a DHCP
>     Bill> relay.
> 
>   yes, true!
> 
>     >> The MAC address that is provided to the DHCP server for the client
>     >> should likely be derived in some way from the public key or legacy
>     >> auth identity)
> 
>     Bill> MAC address?  or client identifier?
> 
>   Yeah... exactly the question.
>   I don't know what the current document says.
> 
>   But, doing address allocation by MAC address is something people are
> familliar with. Doing it by client identifier option is increasingly easy.
I
> suggest that both should be filled in. I'm not clear that the client
should
> be permitted to set those values directly.

dhcp insists that the client fill these in.  if you want the relay to
add information, there's now a "relay agent information option"
(RFC3046) which allows the relay to append additional information to
the messages.  might do the trick here..