Jari Arkko | 6 May 2005 15:17

Re: Layer-2 issues

Hi Marcus

>Right.  With adequate L3+higher secure channels, the fact that L2+below
>  is like partially-set jello is just a minor annoyance, rather than
>  a security showstopper.
>  
>
Depends on your point of view. The network access industry
may not agree that its a minor annoyance if the technology
that their revenues are based on turns to jello.

>But if you're going to invest as much *work* as groups like 802.16, 802.11, and
>  802.1ae/af have in secure communications design for L2, you might as well
>  get it right, rather than ignore some very fundamental aspects of the
>  threat model.
>  
>
Yes. And there are many things that remain to be done. While things
are improving, there are significant tasks left with regards to, for
instance,

- better security, particularly dos issues, privacy, trusting the whole 
network
  as one entity when you have roaming and many of the devices are
  nowadays hanging from coffee shop walls
- efficiency of the network access stack wrt movements
- functionality, e.g., distribution of information about the available
  networks
- interoperability, e.g., many authentication methods are proprietary
- new link layers

Bernard already advertised 802.16's call for review. But its also
important for everyone to realize that this not just some problem that
IEEE and 3GPP deal with. The IETF is responsible for a large fraction
of the infrastructure components and protocols employed by the
network access industry. For instance:

- RADIUS (RADEXT WG)
- Diameter (AAA WG)
- Extensible Authentication Protocol (EAP WG)
- PANA (PANA WG )
- IKEv2 (used by several network access related initiatives
  such as 3G-WLAN interworking and Unlicensed Mobile
  Access)
- DNA (DHC and DNA WGs)

Lets get to work and do our part! For instance, in the EAP WG
we are working on a document that describes how keys generated
as a part of network access authentication can be used for L2
protection, both current usage and enhanced functionality such
as fast handovers. This work could use additional contributors
with security clue -- let me or Bernard know if you are interested
in contributing.

--Jari


Gmane