Subject: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection

From: Thomas Narten <[email-masked]>
Date: Tue, 08 Oct 2002 13:50:01 -0400

Hi Kim.

> I was trying to recover some lost ground and figure out where the
> drafts which I am editing are in the process.  The following mail
> is the last on the subject of the subnet-selection sub-option
> that I can find in my mail archives.

This document is tied up in IESG unhappiness with the WGs dealing with
security issues. Basically, the IESG thinks that the overall security
model of relay agent option is rather inadequate (it assumes that the
entire network from the relay agent to the DHC servers is
trustable/secure). This is not a new issue; it was a concern back when
the original relay agent option document was approved. However, the WG
keeps sending new relay agent options to the IESG without also working
on the security model.

One thing that was pointed out was that other WGs have been told flat
out "no approval until you get a realistic security story". So, the
issue that was raised was why should the DHC WG be held to a lesser
standard.

What the IESG wants to see is a credible story for the WG will get
deployable/useable DHC security. In the case of the relay agent
option, the technical issues seem fairly straightforward. Because
relay-agents need to be configured, and because relay agents only need
to talk (securely) with DHC servers, the key distribution problem can
be handled via static keys/configuration.

Bottom line: the IESG wants an updated charter that has a reasonable
story for getting better security, together with an indication that
there is meat behind the wording (e.g., a draft, and/or a design team
that includes security clueful folk, etc.)

Thomas
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 8 Oct 2002 14:45:05 -0500

Why is IPsec a problem if you have multiple relays? If so, we may have the same
issue with DHCPv6?

In DHCPv4, each relay generates a new message so it can be subject to IPsec.

The server must assume that the relay before it (the one it received the packet
from) has sufficiently trusted the source (such as another relay) to relay the
packet.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Tuesday, October 08, 2002 3:22 PM
To: Thomas Narten
Cc: Ted Lemon; Bernie Volz (EUD); Kim Kinnear; [email-masked]
Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection 

If I squint my eyes and stand back far enough, I don't see that the DHCPv4 
case is different.  While the relay agent is relaying a message on behalf 
of the client, it really is relaying that message in an independent UDP 
message, in which the source address belongs to the relay agent.  I don't 
think there is any reason the relay agent and server can't employ IPsec on 
the relay agent<->server messages.

Of course, IPsec may be problematic if there are multiple relay agents in 
the path - which is the problem Mark Stapp is trying to solve, right?

- Ralph

At 03:11 PM 10/8/2002 -0400, Thomas Narten wrote:
>Ted Lemon <[email-masked]> writes:
>
> > > Perhaps I shouldn't raise this, but it seems like we should be
> > > worrying much
> > > more about security on the first hop (client <-> server/relay) than the
> > > relay <-> server hop. The latter is much easier to secure as IPsec,
> > > tunneling,
> > > and other fairly standard techniques could be used.
> > >
> > > Also, is the DHCPv6 draft strong enough in this area to satisfy the
> > > IESG (at
> > > least around the relay <-> server security)?
>
> > Right, the relay<->server hop is regular IP, so there's no reason not
> > to use IPsec to secure it.
>
>In DHCPv6, using IPsec makes sense. The relay agent is originating a
>new message that it sends to the DHC server.
>
>But DHCPv4 is different, in that it relays the client packet. So IPsec
>can't really be used there. But certainly a DHC-specific
>authentication option could be defined for covering the relay agent
>option and/or portions of the client request.
>
>Thomas

---

From: Ralph Droms <[email-masked]>
Date: Tue, 08 Oct 2002 16:00:57 -0400

Oh, right, if I remember correctly the IPsec trust is pairwise between 
relay agents and then between the last relay agent and the server.  Not 
pretty to configure - but the configuration is reasonably static.

- Ralph

At 02:45 PM 10/8/2002 -0500, Bernie Volz (EUD) wrote:

>From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]]

---

From: "Kostur, Andre" <[email-masked]>
Date: Wed, 9 Oct 2002 13:05:21 -0700

Not necessarily.  The giaddr is required to be the IP address of the
interface upon which the original packet was heard, but I don't recall an
actual restriction on what IP the relayed packet must be sourced from.  If
you have a multiple interface router doing the relaying, the giaddr could be
different than the source IP....

However, the DHCP server is required to send the answer back to the giaddr,
and not the source IP.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 12:40 PM
To: Ralph Droms
Cc: Ted Lemon; Bernie Volz (EUD); Kim Kinnear; [email-masked]
Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection 

> The message from the relay agent to the server uses the relay agent's 
> address as the source address.  The relay agent modifies and sends the
DHCP 
> message as the payload in a UDP message that appears to originate from the

> relay agent.  Section 4 of RFC1542 gives more details.  The difference 
> between DHCPv4 and DHCPv6 is in the way in which the client message is 
> processed by the relay agent (in DHCPv6, the message is encapsulated in a 
> new message generated by the relay agent).

OK. I misunderstood how this worked. Because the relay agent mucks
with the giaddr field, I had never understood that the relay agent is
in fact sourcing a packet with its own source address (which contains
the same info as the giaddr field). I guess back then, getting the
source address of a packet out of the API was deemed to hard or
something?

So yes, I agree IPsec could be used to secure the relay-agent - server
path.

Thomas