Subject: Re: [Int-area] [dhcwg] DHCPv6 router option

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Mar 2009 18:09:04 -0700

The DHCP issue you describe below is not exclusive to DHCPv6 as I am sure
you would agree.

John
=========================================
John Jason Brzozowski
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
=========================================

> From: Frank Sweetser <[email-masked]>
> Date: Mon, 23 Mar 2009 20:54:23 -0400
> To: "Brzozowski, John" <[email-masked]>
> Cc: Hemant Singh <[email-masked]>, <[email-masked]>, dhc WG
> <[email-masked]>, Ted Lemon <[email-masked]>, Ralph Droms
> <[email-masked]>
> Subject: Re: [dhcwg] DHCPv6 router option
> 
> John Jason Brzozowski wrote:
>> Frank,
>> 
>> Are you suggesting we specify a way in DHC to prevent people from improperly
>> configuring their DHCPv6 servers?
> 
> Not at all.  I run a network full of students, so I'm thoroughly aware of the
> futility of assuming that all of your clients are well behaved ones =)
> 
> My point simply was that, in any network full of untrusted hosts, there are
> multiple ways for a rogue DHCP server to cause network problems, regardless of
> the existence or lack of a router DHCPv6 option.  If you're at all concerned
> about rogue DHCPv6 servers, then you absolutely need some form of switch based
> "DHCP guard" - a filter applied to all edge ports which prevents them from
> sending out the rogue DHCP advertisements.
> 
> So in other words, with or without the DHCPv6 router option, you still have to
> spend the time on a DHCP guard or you're going to be vulnerable to rogue DHCP
> servers.
> 
> --
> Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
> WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
>      GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Mar 2009 17:38:36 -0700

Frank,

John

> Date: Mon, 23 Mar 2009 20:27:21 -0400
> To: Hemant Singh <[email-masked]>
> Cc: dhc WG <[email-masked]>, Ted Lemon <[email-masked]>, Ralph Droms
> <[email-masked]>
> Hemant Singh (shemant) wrote:
>>> * "RA guard" to filter and limit the scope of misconfigured RAs
>>> * a DHCP option, to be sent with the initial DHCP message exchange,
>>> signaling the host to ignore all future RAs
>> 
>>> We need to continue the discussion; let's focus on how to allow both
>>> methods of configuration to coexist.
>> 
>> 
>> Ralph,
>> 
>> You see one obvious problem here?  With only ND and RA we have a RA
>> guard solution to deal with for rouge RAs or misconfigured RAs.  With
>> DHCPv6 option now we have to think of two solutions for most such
>> problems in an IPv6 network.  Interesting use of our times....
> 
> Leaving the router option out of DHCPv6 only means that you don't have to
> protect against a rogue/misconfigured router DHCP option.  Unfortunately, it
> doesn't get you off the hook for all of the other ways that DHCpv6 can be
> abused or misconfigured.
> 
> As a real world example, there is at least one family of viruses in the wild
> that uses a local DHCP server.  It maliciously reconfigures other hosts on the
> local subnet with a rogue DNS server, which in turn is used to trick web
> browsers into viewing pages loaded with exploits.
> 
> Crippling DHCPv6 by leaving out a router option may remove one way that DHCP
> can be used to break a network, but it doesn't eliminate the requirement the
> need for a v6 DHCP guard - without it there are still too many ways to play
> silly buggers with the local subnet.
> 
> --
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Frank Sweetser <[email-masked]>
Date: Mon, 23 Mar 2009 20:54:23 -0400

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 30 Mar 2009 13:23:21 -0700

On Sun, Mar 29, 2009 at 01:32:00PM -0400, Danny Mayer wrote:
> Though this is more about using DHCP guard everywhere.

This particular attack vector isn't new, but we are seeing a
recent 'resurgance' (which suggests to me that other more attractive
vectors are getting nailed down).

The problem of casual interconnections - where a client system has no
a priori knowledge about the network it is about to be connected to -
demands some kind of validation of network-offered configuration.  The
trouble then becomes, how do you validate configuration without using
it?

Even if you trust some off-site validation mechanism (e.g. certificate
chains), you need working network access to acheive it, which means
using the offered (bad) configuration.  The agent performing this
operation knows not to trust the configuration, but other applications
on the same system might not.

This suggests to me that a host operating system needs a "middle
ground" between the up-to-now boolean configuration state, so that
configuration state can be used provisionally - only to ratify the
configuration - and not by higher layer applications.

One potential candidate way forward is emerging in today's *nix
desktops, which have a 'NetworkManager' applet or similar.  This
applet could potentially be a place where the "we have config, but
do not use it yet" problem could be solved, provided that more (or
the most important) applications were integrated to listen.

The trouble of course is coming up with a model whereby a DHCP server
administrator can reasonably be proven to be 'in control' of a range
of IP(v*) addresses.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins