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 <Ted.Lemon@nominum.com> 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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg