RE: Modefg considered harmful

[Van Aken Dirk <VanAkenD@thmulti.com>]

Hi Allison,

See my comments below.

Dirk.

> -----Original Message-----
> From: Tylor Allison [mailto:allison@securecomputing.com]
> Sent: woensdag 5 februari 2003 20:56
> To: Van Aken Dirk
> Cc: 'ddukes@cisco.com'; Michael Richardson; ipsec@lists.tislabs.com;
> Scott G. Kelly
> Subject: RE: Modefg considered harmful 
> 
> 
> I've been following this discussion for a bit now, but must 
> admit that I'm
> still coming up to speed on how rfc.3456 is intended to work, 
> so please
> bear with me.  For background, I have implemented Mode-Config, but not
> rfc.3456.
> 
> On Wed, 5 Feb 2003, Van Aken Dirk wrote:
> 
> > Hi Darren,
> >
> > See my comments below.
> >
> > > Regarding your comments about modecfg, there is no need for
> > > an address pool
> > > on the LargeIPsecGW since it could act as a DHCP-client when
> > > it receives
> > > modecfg requests from an IRAC instead of having its ipsec
> > > engine sniffing
> > > for inbound DHCP packets and forwarding them to the internal
> > > DHCP relay.
> > >
> > > Darren.
> >
> > The IPSec engine must not sniff on DHCP packets. As said before,
> > implementing RFC3456 can IMHO happen almost completely 
> outside the IKE and
> > IPSec code! More specific, a DHCP discover arriving via an 
> IPSec tunnel has
> > a source address (0,0) and destination address (-1,-1). 
> After passing
> > through the SPD, this packet must be delivered locally, 
> that is, to the
> > internal IP host of the IPSec GW (see RFC1812-section 
> 5.2.3). The local host
> > is configured with a DHCP relay that is listening on UDP 
> port 67 (DHCP
> > server port). This DHCP relay can either forward the 
> request to an internal
> > DHCP server or relay it to an external DHCP server. The 
> only IPSec specific
> > item that the relay must take care of is that replies from 
> the server must
> > end-up in the correct "DHCP-tunnel". This can be 
> accomplished via the DHCP
> > Relay Information Option/sub-options. i.e. The DHCP relay 
> must "tag" the
> > DHCP requests (e.g. with the Tunnel IP address, Tunnel port 
> number) in the
> > direction towards the DHCP server and must "untag" the DHCP 
> replies and use
> > this tag to look-up the correct tunnel in the direction 
> towards the DHCP
> > client (see section 4.2 of RFC3456).
> 
> Regarding the DHCP relay to IPSEC tunnel selection, rfc.3456 
> gives several
> options on how this may be done... one of which is the Relay 
> Info Option.
> The question I have is whether or not you can count on DHCP servers
> supporting this option (can you count on all servers supporting this)?

The DHCP Relay Agent Information Option (RFC3046) is a basic building block
and must be used in combination with sub-options.
such as the ones defined in the same RFC:

- Agent Circuit ID Sub-option
- Agent Remote ID Sub-option

In following draft RFC's new suboptions are defined:
(<http://www.ietf.org/ids.by.wg/dhc.html>)

- <draft-ietf-dhc-agent-subnet-selection-04.txt> Link Selection sub-option
for the Relay Agent Information Option for DHCPv4           
- <draft-ietf-dhc-agent-vpn-id-02.txt> VPN Identifier sub-option for the
Relay Agent Information Option 
- <draft-ietf-dhc-subscriber-id-00.txt> DHCP Subscriber ID Suboption for the
DHCP Relay Agent Option

As you will notice RFC3046 is a rather recent option i.e. looking at the
date of RFC3046 (jan 2001). So it might be that you currently find limited
support for this RFC. However given the fact that there are already 3 new
sub-options, my feeling is that it is a matter of time whether industry
strength servers will have full support for RFC3046 and its extensions.

At least following servers support RFC3046:

<http://www.isc.org/products/DHCP/dhcp-v3.html>
<http://www.doradosoftware.com/> (I can't find detailed info regarding the
supported options but it has been told to me RFC3046 is included)
<http://www.weird-solutions.com/product/dhcpt.html>
<http://www.thresholdnetworks.com/products/razzo/faq.html> (this one is an
incarnation of the ICS server).

BTW: the ICS server is often used as a reference implementation.


> If this option is not supported, this means another method 
> for determining
> the tunnel selection must be used, and the only viable option 
> that I can
> think of is for the SGW to keep the state table mentioned 
> which tracks the
> DHCP transaction to the IPSEC tunnel.

Correct.

> 
> You state that the IKE/IPSEC engine must not sniff the DHCP 
> packets... but
> that's in opposition to what's suggested in rfc.3456...
> 
>     "To learn the internal IP address of the client in order to route
>     packets to it, the security gateway will typically snoop 
> the yiaddr
>     field within the DHCPACK and plumb a corresponding route 
> as part of
>     the DHCP Relay processing."

Better wording would be: the DHCP relay in the security gateway will
typically snoop the yiaddr
field within the DHCPACK and plumb a corresponding route as part of the DHCP
Relay processing.

> 
> My biggest concern here is where the enforcement of client to 
> virtual IP
> mapping happening?  Or is this not a desired goal/capability 
> for remote
> access?  For example, if I have Joe User who should always receive IP
> 10.1.1.111, and I setup a security policy which allows the 
> 10.1.1.111 to
> have special access privileges, how can I guarantee that 
> someone besides
> Joe can't obtain the 10.1.1.111 address?  The security 
> concerns section for
> rfc.3456 states that the assigned address MUST NOT be 
> depended upon for
> security.

DHCP has a few mechanism for assigning a particular IP addresses to a
specific client (so called static leases).

> 
> This sort of access control can be done easily w/ 
> Mode-Config, as IKE knows
> the address which should be assigned to the client and can setup the
> allowed Quick Mode selectors appropriately.

In case the relation host-VPNclient is 1:1 agree with you that on the part
of access control Mode-Config can accomplish this easily just because it
possesses the identity and has direct access to the SPD.
But I thought IPSec was not about access control but I can be wrong on this.

However I wonder how Mode-Config is going to cope with a situation where
there are multiple hosts behind the VPN client (host-VPNclient relation
X:1).

> 
> > So to conclude:
> > - I don't have to touch the IKE code
> 
> While this may be true, I don't believe it carries the same 
> weight as it
> used to, since we're working on defining what the IKEv2 code should
> actually be.
> 
> > - I don't have to touch IPSec code
> 
> This isn't totally true, is it?  You have to add the glue which
> inserts/extracts the DHCP traffic into the IPSEC tunnel.

IMHO not, as said in my previous email, as soon as the DHCP packets passes
the SPD it is standard IP forwarding/host delivery behaviour. It depends of
course how your IP stack is implemented.
 
> You also have to
> deal with the management of the DHCP-specific IPSEC SA

For me this is policy that is configured in the SPD just like any other
policy.

 and 
> setting up of
> the dynamic SPD entries associated with the assigned address.

Well the DHCP relay is a host process in the sense that it can be modified
such that it has access to PF_Key (RFC2367).
As you might know PF_Key is an API that allow applications to communicate
with the Security Association Database (SADB).
To have access the SPD we had to use the private extension of PF_Key. And
indeed for the private extension we had to make minor changes to IPSec code.
However if there was an PF_Policy
<http://www.ietf.org/proceedings/02nov/minutes/ipsp.htm> this could have
been avoided. To summarize, the DHCP relay talks to the IPSec code via well
defined interfaces.
I hope this clarified my point of view ?

> 
> > - I might have to change DHCP relay code but this technology is well
> > understood
> > - my IP parameter distribution method is in-line with the 
> rest of the
> > network infrastucture and inherits an existing and rich feature set.
> >
> > Best regards - Dirk
> 
> I'm struggling here because I'm not sure I totally like 
> either solution
> that's being offered.  My biggest complaints with RFC.3456 are the
> specialized IPSEC SA required for DHCP traffic and the lack 
> of control on
> address assignment.

This is an argument that seems to come back and I have he feeling that I
miss something here.
In previous emails the DHCP SA's were termed "weird". But to me it are just
SA's that have specific selectors (any/any/UDP/68/67) and indeed they are
short lived. But apart from that I don't consider them special; of course my
background is more in networking than in IPSec so maybe you can elaborate a
little bit more on this topic.
e.g. It might be that IPSec "centric"-people don't feel comfortable with
"any" for both source and destination address in an SPD entry.

I can understand your argument on the lack of control of address assignment
but this is an IKE centric view on security.

> 
> Mode-Config for IKEv1 had a similar problem to rfc.3456 for 
> SA management,
> as MC was a "phase 1.5" exchange, causing headaches in the IKE state
> tables.  This seems to be solved in IKEv2 by the fact that 
> the MC payloads
> are now inline in the base phase 1 exchange.  I would agree, 
> however that
> MC does duplicate the purpose of DHCP.
> 
> The solution?  The ideal solution in my mind would be to 
> still use DHCP,
> but have the initial DHCP traffic pass through IKE instead of IPSEC.
> Either attempt to introduce the DHCP payloads directly into 
> the phase 1
> exchange (similar to what's proposed for MC), or to instantiate a new
> exchange for the DHCP traffic.  IKE would be required to 
> parse a minimum
> number of DHCP attributes in order to determine some base 
> info, like the
> assigned IP address.
> 
> If such a solution is not possible, then I'd prefer to keep 
> the current
> Mode-Config proposal as described in the IKEv2 draft.  We can keep the
> scope of MC to be very simple... address assignment for the 
> remote peer.
> Once a VPN is established, any other network configuration 
> parameters can
> be determined via the DHCPINFORM method.

To be honest I'm very afraid of these "mixed" solutions just because of my
bad experiences in PPP-IPCP combined with DHCP.
Just looking at the stricking resemblance of the IKEv2 ModeCfg attributes
and the PPP-IPCP options I guess we will be stuck with an identical problem.

> 
> My $.02 worth.

It was worth more than $.02 as your arguments were about pro and con of both
solutions.
And maybe I should analyse the IKEv1 ModeCfg implementations more in detail
to show the limitations in various scenario's. However to fuel this
discussion up till now, it took quite some investment from my side. i.e. I'm
not just discussing; I did experiments in our labs with commercially
available equipment and I don't have the time to continue like this.

Anyway as a few people already expressed that both ModeCFG and DHCP might
have pro's and con's I wonder whether both solutions (or at least a pointer
to RFC3456) can be specified in the IKEv2 RFC. It is up to the implementers
then to choose the appropriate solution (and its inherent shortcomings).

> 
> =====================================================================
> = Tylor Allison         Secure Computing Corporation        =========
> =====================================================================
> 
>