Subject: Re: Modefg considered harmful

From: Michael Richardson <[email-masked]>
Date: Sat, 01 Feb 2003 15:59:28 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Scott" == Scott G Kelly <[email-masked]> writes:
    Scott> below which you suggest won't work. Perhaps you should ask the folks
    Scott> from Zurich University of Applied Sciences if you can take a look at
    Scott> their frees/wan implementation.

  I know a lot about this.
  It works as well as it does for a number of hysterical raisins:

  1) FreeSWAN essentially still pretends to be a bump in the stack. 
     (The actual truth depends upon which kernel revision you ask about,
     is even stranger than fiction)
     To the point of impersonating the MAC address of the interface that it sits on.
     As such, dhclient is actually rather happy with the situation.

     (I haven't investigating what happens when you run it with a PPP
     interface as the underlying hardware. FreeSWAN pretends to be a PPP
     device in that situation, and I wonder what dhclient will think)

  2) ISC dhclient actually goes around the IP stack to send its packets
     (using PF_PACKET on Linux, BPF+raw sockets on BSD). Because FreeSWAN
     has a very "complete" bump in the stack, this works. 

  Both of these things are VERY hard to do when IPsec is integrated into the
stack. 

    Scott> To my original point, Darren seems to be suggesting that he wants the
    Scott> ability to configure values not supported by DHCP. I was simply asking
    Scott> what these might be.

  I strongly agree with you - I want to use DHCP.
  I just do not want to run it over a very hard to manage IPsec SA. The
coordination between dhclient getting an IP address and IKE, and renewals,
etc. just scares me. 

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Van Aken Dirk <[email-masked]>
Date: Mon, 3 Feb 2003 09:24:32 +0100

Hi Cheryl,

You wrote:

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

I have difficulties in understanding what is against short-lived tunnels.
Isn't this is one of the reasons of existence of IKE i.e. a protocol that
can easily create and destroy tunnels ? 

Best regards - Dirk

---

From: Van Aken Dirk <[email-masked]>
Date: Mon, 3 Feb 2003 12:08:42 +0100

Hi Charlie,

See my comments below.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: zondag 2 februari 2003 2:25
> To: Bernard Aboba
> Cc: [email-masked]; [email-masked]
> Subject: Re: Modefg considered harmful
> 
> 
> 
> 
> 
> 
> While my personal interests are in settling the MODECFG vs DHCP-relay
> debate in any way that sticks, I can't resist throwing in my technical
> opinion.
> 
> The appeal of MODECFG is that it minimizes the number of messages and
> crypto operations in getting an IPsec session set up. The appeal of
> DHCP-relay is that it provides all of the flexibility and 
> power of DHCP
> (including extensions defined in the future) and does so in a way that
> appears to make it independent of the IKE specification. But 
> I believe this
> appearance is illusory.
> 
> For an endnode to acquire an IP address on a remote network 
> for use with
> IPsec, there are several things going on - only one of which 
> involves DHCP.
> Yes, the address must be leased, but in addition the IPsec gateway
> implementation has to begin responding to ARPs to that address and
> forwarding packets addressed to that address over the IPsec 
> tunnel.

The fact that an IPSecGW must respond to ARP's just depend on you addressing
scheme.
e.g. If your central LAN uses 30.0.0.0/24 and you use let's say
30.0.0.100-120 for your VPN RAS users your IPSecGW must do Proxy-ARP for
30.0.0.[100-120]. Because your Central LAN servers cannot know whether these
addresses are local or extruded via a VPN GW. And indeed some IKECfg
implementations have a check box next to the IKCfg-range that one defines.
However I consider this as a configuration optimization.

On the other hand if your VPN configuration and central office is large, you
have a dedicated subnet for your VPN users.
e.g. Your central office users are on the 30.0.0.0/24 network and your VPN
your users on the 40.0.0.0/24 network.
The routeing infrastructure on the central LAN has route entries for this
extruded network, pointing to the IPSec GW.

Could we at least keep these arguments out of the discussion; they might
just confuse the audience. What I would like to hear is, is IKECFG better
compared to RFC3456 ?

Best regards - Dirk 

> The IPsec gateway should only accept packets over the IPsec 
> tunnel with source
> address equal to one that the endnode has legitimately 
> leased. That means
> the gateway can't be a passive relay. It has to parse the 
> messages it is
> passing through, and if there are extensions to DHCP in the 
> future that
> affect leases on IP addresses, the gateways will have to be updated to
> understand them. I believe this is what Cheryl Madson 
> referred to as "a
> special state" in the state machine.
> 
> So I would claim that the IPsec endnode, the IPsec gateway, 
> and the DHCP
> server are running a three party protocol, and it's not 
> obvious whether
> it's better to have the IPsec gateway eavesdrop on the DHCP 
> conversation or
> be a full participant by acting as a DHCP server to the endnode and a
> client to the DHCP server. As a practical matter, MODECFG 
> specifies exactly
> what the two participants have to do, while DHCP-relay is more open to
> interpretation. Unless DHCP-relay were specified more 
> precisely in terms of
> what the IPsec gateway had to do with the information it saw 
> passing by, it
> seems likely that MODECFG would give us better 
> interoperability. And if
> IPsec gateway actions in response of DHCP messages were specified more
> precisely, I believe that proposal would lose must of its 
> extensibility.
> 
> The use of MODECFG does not preclude the use of tunnelled 
> DHCP for uses
> other than acquiring leases on IP addresses. If I were designing the
> protocol, I'd have IKE handle *only* IP address leases 
> (defining the life
> of the lease to match the life of the SA), and use tunnelled 
> DHCP for all
> other functions (like getting DNS server addresses). Adding a few more
> fields to MODECFG enhances performance - probably in a 
> trivial way - but
> it's likely that doing so will result in requests for more in 
> the future
> (which we can either accept or decline). I could be convinced 
> either way.
> 
> In summary, I believe MODECFG as specified will work and will 
> provide few
> interoperability surprises. I believe DHCP-relay could be 
> made to work if
> it were more tightly specified, but would be more likely to provide
> interoperability problems. DHCP-relay does provide some 
> functionality not
> possible with MODECFG - in particular assignment of IP 
> addresses based on
> additional information about the client. If any of that 
> functionality is
> actually needed, it could be added to MODECFG, but I haven't 
> heard a case
> for it yet.
> 
>           --Charlie
> 
> Opinions expressed may not even be mine by the time you read them, and
> certainly don't reflect those of any other entity (legal or 
> otherwise).
>

---

From: Van Aken Dirk <[email-masked]>
Date: Mon, 3 Feb 2003 13:13:10 +0100

> Sent: zondag 2 februari 2003 5:10
> To: Bernard Aboba
> Bernard Aboba <[email-masked]> wrote:
> > RFC 2131 states the responsibilities of DHCP Relays very 
> clearly. The
> > primary responsibility is packet forwarding. I think you 
> may be confusing
> > the operation of a DHCP Relay with a DHCP proxy -- which *is*
> ill-defined.
> 
> OK... bear with me. I just reread RFC 2131 and still don't get it.
> 
> When an IPsec gateway is acting as a DHCP Relay, I can almost 
> see how it
> forwards the DHCP packets in a stateless fashion (it seems 
> like it has to
> hold state between the request and response, but could be 
> stateless the
> rest of the time). But there is a second function of the 
> gateway that is
> intimately bound to address allocation. The IPsec gateway has 
> to respond to
> ARPs to the assigned IP address and forward packets addressed 
> to that IP
> address to the endnode. How does it know when to start and 
> stop doing that?
Charlie,

I don't see the problem with ARP's ...
In case of an extruded range (that is an address range within the same
subnet as your central office LAN's but assigned to VPN RAS users), each
time IKECfg assigns an address to a VPN RAS user, it automatically adds an
ARP entry in its Proxy-ARP table. True it is nice optimization however as
soon as you are working with extruded networks this technique no longer
works.

In case you would use RFC3456 in combination with an extruded range you just
configure Proxy-Arp for that range in the IPec GW.  Packets addressed to
that destination end-up in the VPN GW and are either dropped there (if the
address is not in use) or are forwarded in a tunnel..

> It can't just trust the endnode to tell it... that would allow someone
> connecting in to seize IP addresses belonging to someone 
> else.

Why not via Phase2 ID's ? If an SA has not yet expired and the address is
assigned to another VPN client, clean-up the old SA for that address.

> It seemslike it has to keep track of the interaction between the 
> endnode and the
> DHCP server including keeping track of lease expiration and renewal.
> 
> What am I missing?
> 
>           --Charlie
>

---

From: Van Aken Dirk <[email-masked]>
Date: Tue, 4 Feb 2003 10:55:16 +0100

> From: Michael Richardson [mailto:[email-masked]]
> Sent: maandag 3 februari 2003 21:42
> To: [email-masked]
> >>>>> "Van" == Van Aken Dirk <[email-masked]> writes:
>     Van> Have you thought about following situation ?
> 
>     Van> 
> RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN
> 
>     Van> Following parameters are configured on the SmallIPSecGW:
> 
>   This is out of scope.

Hi Michael,

The configuration I described above was created in our labs with two very
simple (and old) IPSec gateways not supporting any dynamic IP parameter
assignment method. So if I have to choose between configuring remote PC's
connected to these gateways manually or automatically, I sure know what to
choose.

Whether it is out of scope, I leave in the middle because I know too little
of the history of the IPSec working group. The point I wanted to make is
that in complex environments you will find a mix of IPSec GW's:
- old IPSec GW's with very little features;
- new ones with the latest feature set;
- IPSec GW's connecting VPN RAS users and VPN GW's connecting remote
offices.

If a system administrator can at least have a uniform IP parameter
distribution method over his whole network (including his central office LAN
;-) ), he would be very happy !
With IKEModeCfg this is clearly not the case but with DHCP based methods it
can be accomplished and that's my main motivation for the RFC3456 based
method.

The focal point of the IPSec working group is to create good standards for
IPSec but sometimes I have the impression that the fact that IPSec devices
must be integrated in a larger infrastructure is sometimes overlooked. I
hope that I do not offend anybody with this statement, I just express my
personal feeling on this point.

> 
>   SmallIPsecGW should run a DHCP relay, and tunnel the 
> packets through the
> VPN to the CentralOfficeLAN's DHCP server.
> 
>   The only "difficulty" is that the IP addresses provided to the
> RemoteOfficeLAN will need to either fit into the existing tunnel that
> SmallIPsecGW has

This is only logical: the remote office network, the prefix pointing to this
network and the IPSec policy are identical.

, or that SmallIPsecGW should have a somewhat 
> "wide" policy
> for all communication from RemoteOfficeLAN<->CentralOfficeLAN, and use
> per-host keying to create new LANs.
> 
> ] [email-masked] 
> http://www.sandelman.ottawa.on.ca/ |device driver[
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQCVAwUBPj7UAoqHRg3pndX9AQH8lgP/ReFXm9Www9hi+RJaB94lnecr+r+PIi68
> wvHHFepa2dpt/a8buGQelNV0+FDhr4D4+ogkpUwwpAmLFSByuvPe0CURp43p9zWP
> Vh7CqwZfGkzSp5Ab03hzFmG8UkC446Pg0FNx+qsxzqkt8TelM3tMSLG+iZMG5oza
> 2/FvdBI+tck=
> =TXIU
> -----END PGP SIGNATURE-----
>

---

From: Van Aken Dirk <[email-masked]>
Date: Tue, 4 Feb 2003 16:59:08 +0100

> From: Darren Dukes [mailto:[email-masked]]
> Sent: dinsdag 4 februari 2003 16:42
> To: Van Aken Dirk; Michael Richardson; [email-masked]
> Cc: Scott G. Kelly
> Subject: RE: Modefg considered harmful 
> 
> 
> Actually with this scenario a DHCP relay within the 
> RemoteOfficeLAN instead
> of on the SmallIPsecGW would likely be the implementation of choice.
> RFC3456 does not say anything about the relay being on the inside LAN
> interface, only the interface terminating IKE-SAs so I don't 
> think it could
> be applied to this scenario.

Hi Darren,

The point I wanted to make was that probably NetAdmins are already using
DHCP in one form or another.

> 
> 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.
> 
> PS - I know you don't like the idea of dhcp to modecfg 
> conversion by the
> LargeIPsecGW.

At least we agree on this point ;-)

---

From: Michael Choung Shieh <[email-masked]>
Date: Wed, 5 Feb 2003 19:03:22 -0800

> From: Bill Sommerfeld [mailto:[email-masked]]
> Sent: Wednesday, February 05, 2003 12:44 PM
> To: Marcus Leech
> Cc: [email-masked]
> > Me too, but there was this issue of the large installed base of
> >   MODECFG-like things in existing implementations.  Since I'm not
> >   an implementor, I'm in the situation where I have to believe that
> >   moving away from a MODECFG-like thing is a hardship.
> 
> Except that you probably *already* have a DHCP implementation already!
> 
> I believe the correct comparison is the complexity of MODECFG vs the
> "DHCP to IPsec glue" code; the latter is likely to be significantly
> smaller than the former.
> 

The comparison probably is not fair.  Since most have MODE-CFG in their
implementation, Most vendors probably have both MODECFG & DHCP codes.

So the comparison is the complexity of adapt MODECFG to IKEv2 vs "DHCP to
IPsec glue" code.  The latter is much more complex and harder to get
interoperable.

> > *If* it's acceptablet to discount such claimed hardship, 
> then I have to
> >   agree with Bernards assertion that the IPSRA-style DHCP 
> approach is
> >   cleaner, more flexible, and in the long-term, less work.
> 
> indeed.
> 
> 					- Bill
> 
> 

=======================
Michael Shieh

---

From: Van Aken Dirk <[email-masked]>
Date: Thu, 6 Feb 2003 11:44:12 +0100

Hi Allison,

See my comments below.

Dirk.

> From: Tylor Allison [mailto:[email-masked]]
> Sent: woensdag 5 februari 2003 20:56
> To: Van Aken Dirk
> Cc: [email-masked]'; Michael Richardson; [email-masked];
> Scott G. Kelly
> 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.
> >
> > 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        =========
> =====================================================================
> 
>

---

From: Van Aken Dirk <[email-masked]>
Date: Fri, 7 Feb 2003 14:00:03 +0100

> Dirk, since you appear to have the best implementation 
> understanding of
> RFC3456 of the posters to this list, could you post all the 
> RFCs, drafts,
> etc. that a person would need to know to fully implement the 
> DHCP-relay?
> This may help others come up to speed quicker if they don't have to go
> digging for them.
> 
> Thanks,
>   Darren

Hi Darren,

Here are the RFC's and some condensed info.

Cheers - Dirk

I guess reading following RFC's is sufficient to implement RC3456:

- RFC1542 Clarifications and Extensions for the Bootstrap Protocol
--> This RFC gives the most details on a basic DHCP Relay.

- RFC3046 DHCP Relay Agent Information Option
--> This RFC defines the DHCP Relay Information Option which is a container
option. In addition it also defines two sub options that can be used in
combination with the container option. To implement RFC3456, RFC3046
sufficient.

However implementers wanting to come up with sophisticated/advanced
scenario's might consider reading a few drafts posted on the DHCP working
group or define their own sub-options ...

- RFC3546 Dynamic Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode.
--> and of course this was the RFC which was subject of this debate.

For convenience let me add a little summary on the use of DHCP relays.

BOOTP/DHCP relays were conceived to make BOOTP/DHCP based address assignment
scalable. Without relays a DHCP server must be located on every link layer
network as limited broadcasts are not allowed to cross routers. So the main
function of DHCP relays is to converts limited broadcasts into IP unicasts
by relaying requests to DHCP servers. The server talks-back to the relay via
the "giaddr" field in relayed DHCP packets.

Prior to RFC3046, the giaddr field was overloaded with 3 functions:
- it allows the server to select a client IP address within the same subnet
as the port on which the request was detected
- it allows the server to talk-back to the DHCP relay
- it allows the DHCP relay to figure out on which link-layer-network it must
relay the DHCP reply

The added value of RFC3046 is that 
- it allows to tear these 3 functions apart 
- it provides a generic and extensible mechanism to add/subtract relay
related options to DHCP packets
- it operates in a stateless manner just because the server is required to
loop RFC3046 fields

A little drawback of RFC3046 is that it is written in the context of Cable
Modem networks and some people might have difficulties in understanding the
terminology.
Apart from terminology, RFC3046 is generic and implementers have
successfully applied RFC3046 to complete different situations such as MPLS
based VPN's and in the context of RFC3456, to IPSec based VPN's.

---

From: Van Aken Dirk <[email-masked]>
Date: Wed, 12 Feb 2003 10:59:37 +0100

Hi Derek,

An afterthaugth ..
> 
> This is why you need to tie the identifiers together.  In MGCP you
> need to tie the MGCP identifier into IKE/IPsec.  In the IPsec VPN you
> need to tie the Tunneled IP Addresses to the IKE ID.  This means that
> the IKE policy (on the gateway) needs to know what address(es) are
> assigned to the road-warrior client.

I share your concern regarding tying the Tunneled IP address to the remote
peer identity.
But isn't this accomplished by ESP ? i.e I copied folllowing paragraph from
the second version of ESP:
(<http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt>)

   Data origin authentication and connectionless integrity are joint
   services, hereafter referred to jointly as "integrity." (This term is
   employed because, on a per-packet basis, the computation being
   performed provides connectionless integrity directly; data origin
   authentication is provided indirectly as a result of binding the key
   used to verify the integrity to the identity of the IPsec peer. 

For me a secure solution is not only about IKE but it encompasses IKE, SPD,
SAD ESP and cryptography.

----------------------------------------------------------- 
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: [email-masked] 

Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON. 
More about Thomson: http://www.thomson.net/videochain