[118568] in North American Network Operators' Group
Re: {SPAM?} Re: IPv6 Deployment for the LAN
daemon@ATHENA.MIT.EDU (David W. Hankins)
Fri Oct 23 17:12:30 2009
Date: Fri, 23 Oct 2009 14:11:37 -0700
From: "David W. Hankins" <David_Hankins@isc.org>
To: nanog@nanog.org
In-Reply-To: <4AE0EFD7.9020907@coders.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--6WlEvdN9Dv0WHSBl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Oct 23, 2009 at 12:50:47PM +1300, Perry Lorier wrote:
> I've implemented myself a system which firewalled all ARP within the AP a=
nd=20
> queried the DHCP server asking for the correct MAC for that lease then se=
nt=20
> the ARP back (as well as firewalling DHCP servers and the like). It's=20
> quite easily doable, and quite reliable. If nodes were to send packets=
=20
> directly when associated to an AP then the 802.11 protocol would fall=20
> apart, I've never met an implementation that broke this requirement of th=
e=20
> standard.
It had not occurred to me to intercept ARP (or ND) as a transition
mechanism, that is pretty clever, but the idea of using DHCPv*
leasequery as a way to make IP->MAC resolution both secure and unicast
is something I've heard many times.
I don't know about my peers, but I would be very interested to see an
RFC that describes and examines your results.
> You can of course pretend you're the AP and send a packet if you're wanti=
ng=20
> to be vicious enough.
Yes, of course, that is much simpler. If the attacker can associate
with the real wireless network, they can always bridge and provide a
rogue AP to insert themselves in the middle.
Sometimes in focusing on packet exchanges, we miss the forest for the
trees.
--=20
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
--6WlEvdN9Dv0WHSBl
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
iD8DBQFK4hwJcXeLeWu2vmoRAjjmAKCFr3hIKNMLel7VkivbzoZRcTL5dQCeJTiX
HbB0hbn3aBf/DEHdjQlUgvk=
=hzsw
-----END PGP SIGNATURE-----
--6WlEvdN9Dv0WHSBl--
