Re: [802.21] HLSI
Stefano,
On Tue, Sep 06, 2005 at 07:42:37PM -0500, Stefano M. Faccin wrote:
> Yoshi,
> one issue with having such security information part only of extended set is that such information may then not be available @ L2 before an authenticated connection is available. Given that one wants such information to find out how and whether to authenticate, it becomes a chcken-egg issue.
Both basic set and extended set should be accessible via both L2 and
higher-layer. For example, an extended schema for an extended set can
be automatically generated from media-specific MIBs such as dot11 MIB,
a bunch of 802.11 specific security parameters can be obtained via
schema-based query (i.e., SPARQL). Then all we need to define is an
L2 and higher-layer transport for the schema-based query. One issue
here would be potential overhead of XML in wireless environment. This
overhead issue is currently under study in W3C XML binary
characterization WG, and depending on the their analysis, we might
just use vanilla XML 1.x format or we might use a binary XML format
defined or recommended by W3C.
Alternatively, one could define a tons of media-specific TLVs in basic
set or extended set. However, we should keep in mind that this is a
kind of reinventing the wheel for each media (we should avoid
duplicate work as much as possible).
Regards,
Yoshihiro Ohba
> Stefano
>
> ________________________________
>
> From: ext Yoshihiro Ohba [mailto:yohba@TARI.TOSHIBA.COM]
> Sent: Tue 9/6/2005 11:42 AM
> To: STDS-802-21@LISTSERV.IEEE.ORG
> Subject: Re: [802.21] HLSI
>
>
>
> The currently defined Cipher Suites and Authentication Method are too
> 802.11 specific, and not useful information for other media. I think
> what we actually need in basic set is more generic security and qos
> suites like Jesse Walker prensented a couple of meetings before (is
> there updated information about Jesse's work?). We can have
> placeholder Security and QoS IEs at this moment, and continue the work
> of defining their contents for a few months.
>
> Besides that we should also discuss whether media-specific securty
> parameters should be defined in basic set or extended set. I think
> they should be defined in extended set in order to avoid definition of
> tons of media-specific TLVs in the 802.21 specification.
>
> Yoshihiro Ohba
>
> On Tue, Sep 06, 2005 at 04:08:15PM -0400, Subir Das wrote:
> >
> >
> > Gupta, Vivek G wrote:
> >
> > >
> > >
> > >
> > >
> > >------------------------------------------------------------------------
> > >
> > >From: stds-802-21@LISTSERV.IEEE.ORG
> > >[mailto:stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of Subir Das
> > >Sent: Tuesday, September 06, 2005 10:57 AM
> > >To: stefano.faccin@NOKIA.COM
> > >Cc: STDS-802-21@LISTSERV.IEEE.ORG
> > >Subject: Re: [802.21] HLSI
> > >
> > >
> > >
> > >The media dependent IEs currently include:
> > >
> > >
> > >
> > >{ Cipher_Suites, Authentication_Methods, Cost (free/not free),
> > >
> > >IP_Version, Data_Rates, QoS, Neighbor_Maps }
> > >
> > >
> > >
> > >
> > >
> > >In my analysis, Cipher_Suites, Authentication_Methods, Data_Rates, QoS
> > >
> > >are questionable. I agree on representing Cost as a binary value
> > >
> > >(free or not free).
> > >
> > >
> > >
> > >[Stefano] Authentication_Methods is needed. How does the UE know which
> > >methods are supported and allowed? The UE will have to try and fail to
> > >find out. Even if an AP implements WPA and WPA2, it does not mean the
> > >network enables/supports all authentication mechanisms.
> > >
> > >
> > >
> > >
> > >
> > >[Subir] Can we capture all these in a more generic "Security" type
> > >IE? In that case, we may avoid mutiple IEs that are related to
> > >security (e.g., Cipher-Suites, Authentication_Methods for lower layers
> > >and NAT, VPN for higher layers). This may be true for QoS as well.
> > >
> > >[Vivek G Gupta] Cipher Suites and Authentication Methods seem to be
> > >quite adequate for capturing security related information for 802
> > >access networks.
> > >
> > [Subir] Do we need Cipher_Suites in base set? Authentication_Methods
> > should be sufficient.
> >
> > >We may need to be more specific when specifying NAT/VPN requirements.
> > >
> > [Subir] Agree. But can we capture them in a high level IE (e.g.,
> > Security_Support)?
> >
> > >
> > >
> > >For QoS, the actual QoS specific parameters are likely to be dynamic
> > >and need to be queried directly from PoA, by possibly using access
> > >network specific methods.
> > >
> > [Subir] Agree. An indication on whether QoS is supported or not may
> > be enough here too.
> >
> > >From 802.21 IS perspective, we could indicate at high level if QoS is
> > >supported or not and any other more static type information.
> > >
> > >Other suggestions welcome.
> > >
> > [Subir] Agree
> >
> > >
> > >