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
Attachment:
pgp9PODFzBe28.pgp
Description: PGP signature