Subject: draft-ietf-ipsec-dhcp-09.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 24 Apr 2001 14:31:02 -0400

While reviewing this document for the IESG, I came up with some
questions that I'd like the DHC WG to comment on. i.e., this document
seems to call for changes to existing DHCP practice, and the need for
such changes does not seem properly motivated (at least to me). I
would appreciate it if folks from the DHC WG would provide their
perspective.

I have a basic question/concern with one aspect of this document,
namely its use of the chaddr field, the client identifier option, and
relay agents.

Background (to be sure I have this right). In DHCPv4, the chaddr field
always has the link-layer address of the client in it. The relay agent
needs this information (together with the giaddr field) to determine
how to forward a DHCP response from the DHCP server back to the client
(i.e., the giaddr field identifies the interface, the chaddr field is
the link-layer address to use). (Actually, broadcast can also be used,
but in the case of IPsec tunnels, that seems a non-starter.)

In most cases the chaddr value also serves as the way to identify a
client to the DHCP server from the perspective of which parameters to
assign. However, the client identifier option allows the client to
specify an alternate way of identifying itself to the DHCP server, one
that doesn't use the chaddr value. In such cases, the chaddr field may
still needed by the relay agent to forward DHCP messages from the
server to the client.

This document seems to be rather unclear about how it uses these
values. In particular, it seems to provide a set of options rather
than one clear way. I think this needlessly complicates the relay
agent.  Specifically, the chaddr field (together with the giaddr
field) is no longer sufficient information to forward packets from the
DHCP server to the client, and the document suggests that relay agents
will need to maintain state in order to properly forward packets to
clients. I believe this is a change to existing DHCP practice.

> differentiate VPN from non-VPN requests.  The chaddr field of the
> DHCPDISCOVER SHOULD  include a unique identifier.  The client MUST use
> the same chaddr field in all subsequent messages within the same DHCPv4
> exchange. This permits the use of DHCP Relay load balancing as described
> in [19]. In addition, the chaddr SHOULD be persistent between reboots so
> that the DHCP server will be able to re-assign the same address if

The above doesn't seem quite what is needed. First, shouldn't it be a
MUST rather than a SHOULD? What you might point out is that one can't
guarantee that it is unique. Making it a SHOULD (per 2026) implies
that there may be good reasons to not choose a unique identifier and
an implementation might choose not to send one. If that is the case,
an explanation would help. I.e., the DHCP server won't be happy if
identifiers aren't unique enough. This is a basic DHCP assumption.

Also, the load balancing stuff that used to be in the DHCP failover
document has been removed and is now standalone (see RFC 3074). It is
transparent to the client, so I don't see why anything in this
document needs to be done to support it (as the above wording
suggests)

> 6.2.  DHCPOFFER message processing
> 
> Typically, the security gateway will also store the xid and the chaddr
> gleaned from the DHCPDISCOVER in a table so as to be able to route the
> corresponding DHCPOFFER message(s) back to the remote host.

This would appear to be a fundamental change in relay agent model
compared to standard DHCP. That is, traditional relay agents are
stateless. All the info that a relay agent needs in order to relay
DHCP packets is contained in those packets. No per-client state is
needed.  The above text suggests that the relay agent caches the
chaddr field in order to be able to route back DHCP responses. Why is
this needed? Isn't this info in the packet that needs to be relayed?

The answer appears to be no, as the chaddr field as defined in this
document isn't sufficiently useful for this.

Wouldn't it be better to (say) have the relay agent add a relay agent
option that includes information about the SA over which the packet
was received? When the server responds, that relay agent option could
contain the information needed properly forward the packet. This would
be consistent with existing DHCP specifications and would eliminate
the need for the relay agent to maintain per-client state.

> For use in DHCv4 configuration of IPSEC tunnel mode, the client-
> identifier option SHOULD be included and set to something that is unique
> and persistent across reboots.  Possibilities include:
> 
> a) The htype/chaddr combination, if a LAN interface is present.
> 
> b) The machine FQDN concatenated with an interface number.
> 
> c) The user FQDN as determined from the user's NAI or certificate,
>    concatenated with an interface number.

Another possiblity: why not just make it a MUST that a client
identifier option be used (i.e., this is the approach taken by RFC
2855), and then have the chaddr field be the IPv4 (public) address of
the client?  If this were done, the relay agent would just do its
normal processing. I.e., the IPv4 address would be who it forwards the
packet too.

The remaining comments are more editorial in nature.

> concatenating H'4OO0', the IPv4 address of the interface supplying

Do you mean 0x4000 ??

> the vendor-class-identifier option; the vendor-specific information
> option; the subnet selection option [15] or the host name option [18].

Citing ralph and ted's book here? yikes! We should be citing the
definitive source, i.e., RFCs!!!

The spelling of IPsec isn't consistent. The document uses "Ipsec" and
"IPSEC". I believe the preferred spelling is IPsec

The abstract is a verbatim copy of the introduction. This shouldn't be
the case.

The wording surrounding DHCP failover wording seems a bit weird. Note
that the DHPC failover mechanisms are transparent to DHCP clients.
When failover is present, it is just a private thing between DHCP
servers. Having this document cite DHCP failover as something it
supports or helps, seems a stretch.

The comparison between DHCP and IKECFG seems a bit long-winded.
Somewhat hidden, is the assumption that everyone runs DHCP on the
enterprise, including those folks using IKECFG. From that assumption,
its pretty clear that having an all DHCP solution would avoid many
problems that would be present if IKECFG and DHCP needed to sync up
behind the scenes. Can't you just come out and say that?  (Actually, I
personally don't see much reason to include the
comparison/justificaiton -- the document itself has chosen DHCP).

Thomas

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Apr 2001 15:24:45 -0700 (PDT)

> guarantee that it is unique. 

I agree.

> document needs to be done to support it (as the above wording

The requirement is that the chaddr be consistent throughout the DHCP
conversation. 

> was received? 

Yes, this would be better in my opinion. Then the relay would not need to
keep state. 

> normal processing. I.e., the IPv4 address would be who it forwards the

Remember, the IPv4 address may not be unique for systems behind a NAT, and
you'd want two systems doing VPN from behind the same NAT to obtain
different IP addresses. So I don't think this is a good idea.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 25 Apr 2001 10:50:15 -0400

> The requirement is that the chaddr be consistent throughout the DHCP

Right. It would be good to just state that directly.

> different IP addresses. So I don't think this is a good idea. 

I'm assuming we're talking about the client address here. But if the
IPv4 client address is NATted, how will it be able to set up an IPsec
tunnel between the client and the security gateway?  I.e., the outer
IPsec header for packets going between the client and security gateway
cannot traverse a NAT box. At best this would seem to be a gray area;
does IKE work through a NAT box in practice?

But my thinking here in any case is that the client identifier option
indicates WHO the client is (to the DHCP server) and the chaddr
corresponds to whatever IP address the client is using at that
time. That address needs to be reachable from the security gateway in
any case. Oh, and DHCP will have trouble going through NAT boxes if
they do port mapping, I think, as both the source and destination port
numbers are fixed per the protocol spec.

Thomas

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Apr 2001 10:55:37 -0700 (PDT)

> does IKE work through a NAT box in practice?

Surprisingly, Tunnel mode clients do work through NAT boxes in many
cases. Remember, IPSEC ESP's message integrity check does not include the
IP header so translating IP addresses will not break ESP tunnels. 

Unlike L2TP, w/tunnel mode there is no UDP header and therefore no
(optional) checksum, or floating port problems. Assuming that the client
negotiates "ANY to ANY" filters (most do), the only address dependency
occurs  due to the mismatch between the IKE identifiers and the source
address. Most existing implementations ignore this. 

The end result is that a single tunnel mode client can work through a
NAT, and this has become a big selling point for tunnel mode. Note that
trying to get two clients to run behind a NAT generally won't work though.

> Oh, and DHCP will have trouble going through NAT boxes if
> they do port mapping, 

This isn't a problem because the DHCP packets travel *inside* the
tunnel, not outside it, so they don't get translated.