Sign In to Follow Application
View All Documents & Correspondence

Logical Virtual Bridged Local Area Networks

Abstract: A method for segregating traffic among a plurality of end stations associated with a single network access point comprising: a first end station from among said end stations receiving frames transmitted from said single network access point, some of said frames belonging to a first subset of said end stations to which said first end station belongs, others of said frames belonging to at least a second subset of said end stations; and for a first received frame received at said first end station: computing a cryptographic authentication code over fields comprising said first received frame using a cryptographic message digest algorithm; determining whether said first received frame belongs to said first subset of said end stations by comparing said computed cryptographic authentication code with a received cryptographic authentication code contained in said code do not match, discarding said first received frame if said computed cryptographic authentication code and said received cryptographic authentication code do not match.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
31 December 2009
Publication Number
17/2010
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
Parent Application

Applicants

MICROSOFT CORPORATION
ONE MICROSOFT WAY, REDMOND, WASHINGTON 98052, UNITED STATES OF AMERICA

Inventors

1. DENNIS MICHAELVOLPANO
17555 SUGARMILL ROAD, SALINAS, CA 93908, USA

Specification

A METHOD FOR SEGREGATING NETWORK TRAFFIC AMONGST
A PLURALITY OF END STATIONS IN COMMUNICATION WITH
A NETWORK DEVICE, AND A NETWORK DEVICE THEREFOR
BACKGROUND OF THE INVENTION
TECHNICAL FIELD
The invention relates to local area networks. More particularly, the invention
relates to a personal virtual bridged local area network.
DESCRIPTION OF THE PRIOR ART
An access point (AP) Is a link-layer bridge between one or more stations
(STAs) and a distribution system (DS). See IEEE 802.11, Wireless LAN
Medium Access Control and Physical Layer Specifications, ISO/IEC 8802-
11:1999(E), ANSI/IEEE Std 802.11, 1999 Edition. An example of a DS is a
LAN segment, or an intranet. An AP enables packets to be transmitted via
radio either from a station (STA) to the DS, or from the DS to a STA. An
access point therefore has at least two physical ports. One is the DS interface
and the other is a radio interface. Multiple STAs, each with their own radio
interface, can send packets to the DS by multiplexing the single shared radio
interface of an AP. The radio interface operates at a particular frequency and
the STAs share the medium through a MAC-PHY protocol that guarantees
mutually exclusive access to the medium. The DS also sends packets to
STAs by using the same protocol.
The STA of an AP has a Basic Service Set ID (BSSID). It serves to partition
802.11 Basic Service Sets logically. Every STA that associates with an AP
shares the AP's BSSID. A frame destined for a group address received by an
AP or a STA is discarded if the BSS to which the AP or STA belong does not
match the BSSID of the frame. In this sense, the BSSID behaves as a Virtual
LAN ID (VID). See IEEE 802.1 Q, IEEE Standards for Local and Metropolitan
Area Networks: Virtual Bridged Local Area Networks, IEEE Std 802.1Q-1998.
Every STA is therefore a member of the same virtual LAN (VLAN) as a
consequence of associating with the same AP.
Every STA in a BSS, however, should not share the same VLAN unless the
STAs trust each other. Yet in public space deployments, all STAs associated
with an AP are required to share the same VLAN when typically there is no
trust among them. This can make a STA vulnerable, for instance, to various
link-layer attacks launched by an untrusted STA, such as Address Resolution
Protocol (ARP) cache re-mapping.
It would be advantageous to provide a mechanism for segregating traffic
amongst STAs that are associated with a bridge such that, for example, an
untrusted STA associated with said bridge can not be used to launch a link
layer (OS! Layer 2) attack on another STA associated with the same bridge.
SUMMARY OF THE INVENTION
The invention provides a mechanism for segregating traffic amongst STAs
that are associated with a bridge such that, for example, an untrusted STA
associated with said bridge can not be used to launch a link layer (OSI Layer
2) attack on another STA associated with the same bridge. The invention is
based upon the use of a VLAN to segregate traffic. The IEEE 802.1 Q-1998
(Virtual Bridged LANs) protocol provides a mechanism that is extended by the
invention to partition a LAN segment logically into multiple VLANs. In the
preferred embodiment, a VLAN bridge forwards unicast and group frames
only to those ports that serve the VLAN to which the frames belong. One
embodiment of the invention extends the standard VLAN bridge model to
provide a mechanism that is suitable for use within an AP.
Suppose an AP is attached to a DS. Every STA that associates with the AP
should have an opportunity to create a new VLAN with itself and the DS as its
members. This way traffic between trusted and untrusted STAs can be
separated even though they associate with the same AP. In general, if the DS
comprises multiple VLANs, then the members of any subset of them can be
members of the new VLAN. So there should be a way to discover existing
VLANs. Furthermore, there should be a protocol for joining an existing VLAN.
Creating a VLAN and joining an existing VLAN are both operations that
require authentication. The IEEE Std 802.1 Q-1998 VLAN model is deficient
for such purposes because it does not provide these capabilities. The
preferred embodiment of the invention comprises a mechanism for providing
such capability, referred to herein as the persona! virtual bridged local area
network (Personal VLAN).
In a preferred embodiment, the Personal VLAN bridge extends the standard
VLAN bridge in at least any of the following ways:
• VLAN discovery: A Personal VLAN provides a protocol for VLAN discovery
(discussed below).
• VLAN extension/creation: A Personal VLAN bridge allows a station to
create a new port that serves a new VLAN, or to join an existing VLAN or
to join an existing VLAN via an authentication protocol.
• Logical ports: A Personal VLAN bridge can maintain more than one
logical port per physical port. It bridges between ports of any kind. A
VLAN's member set is defined in terms of logical and physical ports. Every
logical port has a lifetime controlled by the bridge.
• Cryptographic VLAN separation: In a Personal VLAN, a logical port
serves at most one VLAN. However, because there may be more than
one logical port per physical port, more than one VLAN may exist on a
physical port. Traffic within one VLAN is separated from another VLAN on
the same physical port by cryptography. An authentication code uniquely
identifies the VLAN to which the traffic belongs, while another level of
encryption keeps the traffic private except to members of the VLAN.
• Layer-2 VLAN support across routers: When an STA can roam and re-
attach to a network at a different bridge, e.g. by associating with a new AP,
the STA can inform the bridge of a VLAN to which it already belongs. The
VLAN may have been created by a station, e.g. itself, at another bridge
that links the VLAN with one or more logical or physical ports at that
bridge. The STA can maintain its membership in the VLAN at layer 2 even
though the new bridge may be located on a different subnet. This
capability subsumes Mobile IP capability because Mobile IP aims to retain
subnet membership for a station across routers. A subnet may correspond
to a VLAN, but in general it does not.
• Spanning tree maintenance: A Personal VLAN bridge permits an STA to
create a VLAN where the STA itself is a bridge. A spanning tree algorithm
eliminates cycles among bridges when membership is granted. The
process for joining a personal VLAN enforces restrictions on VLAN
topology that make re-constructing a spanning iree unnecessary alter a
new bridge joins a VLAN.
ACCOMPANYING
BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block schematic diagram that illustrates two bridges in a
Personal VLAN network according to the invention;
Figure 2 is a block schematic diagram which shows an embodiment in which
station A shares SA1 with bridge 1;
Figure 3 is a block schematic diagram which shows an embodiment in which
stations D and E belong to VLAN5, however, unlike the other staiions, they do
not share security associations with bridge 1, but rather with personal VLAN
bridge 2;
Figure 4 is a block schematic diagram that shows Personal VLAN discovery
according to the invention;
Figure 5 is a flow diagram that shows the requesting of service for a new
VLAN according to the invention;
Figure 6 is a flow diagram that shows linking of a VLAN served by a logical
port at a bridge to one or more VLANs served by physical ports at a bridge
according to the invention;
Figure 7 is a flow diagram that shows inter-station authentication that is
triggered when a bridge receives a join-VLAN request whose destination
VLAN set consists of a single VLAN served by a logical port according to the
invention; and
Figure 8 is a flow diagram showing ingress filtering a logical ports according
to the invention.
DETAILED DESCRIPTION OF THE INVENTION
The presently preferred embodiment of the invention provides a mechanism
for segregating traffic amongst STAs that are associated with a bridge such
that, for example, an untrusted STA associated with said bridge can not be
used to launch a link layer (OSI Layer 2) attack on another STA associated
with the same bridge. Those skilled in the art will appreciate that the invention
disclosed herein is applicable to a wide range of systems and networks,
including but not limited to wired and wireless networks.
The Personal VLAN Bridge Modei
The invention is based upon the use of a VLAN to segregate traffic. The
IEEE 802.1Q-1998 (Virtual Bridged LANs) protocol provides a mechanism
that is extended by the invention to partition a LAN segment logically into
multiple VLANs. In the preferred embodiment, a VLAN bridge forwards
unicast and group frames only to those ports that serve the VLAN to which the
frames belong. One embodiment of the invention extends the standard VLAN
bridge model to provide a mechanism that is suitable for use within an AP.
Suppose an AP is attached to a DS. Every STA that associates with the AP
should have an opportunity to create a new VLAN with itself and the DS as its
members. This way traffic between trusted and untrusted STAs can be
separated even though they associate with the same AP. In general, if the DS
comprises multiple VLANs, then the members of any subset of them can be
members of the new VLAN. So there should be a way to discover existing
VLANs. Furthermore, there should be a protocol for joining an existing VLAN.
Creating a VLAN and joining an existing VLAN are both operations that
require authentication. The IEEE Std 802.1Q-1998 VLAN model is deficient
for such purposes because it does not provide these capabilities. The
preferred embodiment of the invention comprises a mechanism for providing
such capability, referred to herein as the personal virtual bridged local area
network (Personal VLAN).
A presently preferred embodiment of the invention is discussed herein in
connection with Figures 1-3. It will be appreciated by those skilled in the art
that the configurations shown in Figure 1-3 are provided for purposes of
example only and are not intended to limit the configurations with which the
invention may be practiced.
Figure 1 is a block schematic diagram that illustrates two bridges 10, 12.
Personal VLAN Bridge 1 (10) has four physical ports 11, 13, 15, 17, two of
which 11, 13 are wired Ethernet. The wired ports serve VLAN1 and VLAN2
respectively. The other two ports 15, 17 are wireless Ethernet ports. One of
these ports 15 conforms to the high-rate (54Mbps) 802.11g standard, and the
other port 17 conforms to the 802.11a standard. There are three logical ports
19, 21, 23 associated with the 802.11g port. Each logical port has its own
security association 25, 27, 29 which is shared by some number of end
stations 20, 22, 24 to constitute a separate VLAN.
Station A 20 shares SA1 25 with bridge 1 10, as illustrated in Figure 2. No
other stations share SA1 and so STA A is in a unique VLAN, i.e. VLAN3,
represented by a spanning tree whose root is bridge 1.
Stations B and C 22, 24, on the other hand, belong to VLAN4 because they
share SA2 27 with bridge 1 (see Figure 2). This VLAN was created by one of
STA A or STA B. Then the other station joined it after being authenticated by
the creator. This illustrates case of joining a personal VLAN (see below).
VLAN4 is also represented by a spanning tree with bridge 1 as root.
Stations D 16 and E 18 belong to VLAN5. However, unlike the other stations,
they do not share security associations with bridge 1 but, rather, with Personal
VLAN bridge 2 12 (see Figure 3). Bridge 2 is the root of a spanning tree for
VLAN5 until the tree was extended, making bridge 1 the new root.
In one embodiment, the Personal VLAN bridge extends the standard VLAN
bridge in at least any of the following ways:
• VLAN discovery: A Personal VLAN provides a protocol for VLAN discovery
(discussed below).
• VLAN extension/creation: A Personal VLAN bridge allows a station to
create a new port that sen/es a new VLAN, or to join an existing VLAN or
to join an existing VLAN via an authentication protocol.
• Logical ports: A Personal VLAN bridge can maintain more than one
logical port per physical port. It bridges between ports of any kind. A
VLAN's member set is defined in terms of logical and physical ports, tvery
logical port has a lifetime controlled by the bridge.
• Cryptographic VLAN separation: In a Personal VLAN, a logical port
serves at most one VLAN. However, because there may be more than
one logical port per physical port, more than one VLAN may exist on a
physical port. Traffic within one VLAN is separated from another VLAN on
the same physical port by cryptography. An authentication code uniquely
identifies the VLAN to which the traffic belongs, while another level of
encryption keeps the traffic private except to members of the VLAN.
• Layer-2 VLAN support across routers: When an STA can roam and re-
attach to a network at a different bridge, e.g. by associating with a new AP,
the STA can inform the bridge of a VLAN to which it already belongs. The
VLAN may have been created by a station, e.g. itself, at another bridge
that links the VLAN with one or more logical or physical ports at that
bridge. The STA can maintain its membership in the VLAN at layer 2 even
though the new bridge may be located on a different subnet. This
capability subsumes Mobile IP capability because Mobile IP aims to retain
subnet membership for a station across routers. A subnet may correspond
to a VLAN, but in general it does not.
• Spanning tree maintenance: A Personal VLAN bridge permits an STA to
create a VLAN where the STA itself is a bridge. A spanning tree algorithm
eliminates cycles among bridges when membership is granted. The
process for joining a personal VLAN enforces restrictions on VLAN
topology that make re-constructing a spanning tree unnecessary after a
new bridge joins a VLAN.
The presently preferred Personal VLAN bridge model parallels the VLAN
model in terms of its rules for tagging frames, determining member/untagged
sets, and in terms of components involved with relaying MAC frames, as
described in IEEE Std S02.1Q-1998, IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged Local Area Networks, pp. 28.
Extensions to these components in a Personal VLAN bridge are described
below.
Personal VLAN control channels
Every physical port has a Personal VLAN control channel 40, 42 for sending
and receiving control frames and authentication protocol frames. The channel
has no security association and is identified by a frame field, e.g. Ethernet
Type encoded. Authentication frames are preferably encapsulated using a
format such as EAPoL (see IEEE 802.1X, IEEE Standards for Local and
Metropolitan Area Networks: Port based Network Access Control, IEEE Std
802.1X-2001) which can handle a variety of authentication protocols.
VLAN discovery
A Personal VLAN bridge runs server and client VLAN discovery agents 26
and 28, 30, respectively. The server agent responds to information requests,
while the client agent issues information requests. An example of such agents
is the client and server agents of the Service Location Protocol v2, IETF, RFC
2608. Therefore, a Personal VLAN can discover other VLANs and/or allow the
VLANs it serves to be discovered. Discovery (see Figure 4) involves
transmission of a VLAN-DISCOVER frame. In response, a VLAN-OFFER
frame is sent to the source MAC address of the discover frame. An offer
frame lists all or some of the VLANs served by a bridge and information that-
can be used to select from among them. There may be more than one offer
frame received by a client in response to a discover frame it sent.
Transmission of a VLAN-OFFER frame is delayed by some randomly chosen
period of time to minimize collisions among responders.
Serving a new VLAN
A Personal VLAN bridge can receive a request to serve a new VLAN. The
request contains the VID of the new VLAN. A request is not granted unless
the requester is authorized, the request is fresh, and it can be authenticated
through a control channel. To serve a new VLAN at a bridge requires making
the bridge the root of a spanning tree for the named VLAN. Requesting
service for a new VLAN consists of the following steps;
• The bridge receives a request frame with a source MAC address through
the control channel of some physical port. The holder of that MAC address
is the requester (100).
• Receipt of the request frame initiates an authentication protocol with the
requester through the control channel (102).
• If the requester cannot be authenticated, or is not authorized to request
VLAN service from the bridge (104), then the request is discarded (106).
• If there is no conflict in using the VID requested (105), a new logical port is
created and associated with the physical port through which the request
frame is received (108). This is the logical port the bridge uses to serve the
VLAN. Otherwise, the bridge negotiates a VID with the requester (110).
The VLAN's filtering rules are determined by a policy for the requester.
• The port state information is updated for ihe logical port to include a
security association (SA), shared with the requester that is in effect for all
traffic through that port (112). Only the holder of the SA can change ihe
logical port state
Upon completion of these steps, a new logical port exists to serve the new
VLAN, but the VLAN is not linked to any other VLAN served by the bridge until
a request is made to join a particular VLAN. Until this time, the new VLAN is
inoperable at the bridge.
Joining a VLAN
A new VLAN served by a bridge must extend one or more existing VLANs
served by physical ports of the bridge to be useful. In other words, it must be
linked to one or more existing VLANs. Linking the VLAN served by a logical
port at a bridge to one or more VLANs served by physical ports at a bridge is
performed through a join-VLAN request sent over a control channel. The
request does not bridge the VLANs served by the physical ports. Rather, they
remain separate yet the new VLAN extends all of them simultaneously.
A join-VLAN request contains the VID V of a VLAN served by a logical port P'
of the bridge, referred to herein as the source VLAN, and a set V of VIDs for
VLANs served by a set of physical ports P, referred to herein as the
destination VLANs. The request aims to link V to every VLAN ID in V, or in
other words, to allow the requester to join every VLAN in V. The requester has
already created V.
The bridge takes the following steps (see Figure 6):
• First the request is authenticated (200). This is done with respect to the SA
associated with V which was established when the bridge was asked to
serve V. A simple challenge-response strategy is used in the preferred
embodiment, although other approaches may be used as appropriate. If
authentication fails, the request is discarded.
• Logical port P' is added to the member set of even/ V1D in V (202), and
every physical port in P is added to the member set of V (204). The
untagged set of V is formed by taking a union of all untagged sets for
VIDs in V (206). If the request frame contains a null VID in its tag header,
or it is untagged, then P' is added to the untagged set of every VID in V
(208).
The requests to serve a new VLAN and to link it to other VLANs can be
combined into one request. Thus, creating a VLAN and joining another can be
performed through one authentication process, specifically, the process
required for serving a new VLAN.
Joining a personal VLAN
Joining a personal VLAN, i.e. one served by a logical port, requires special
treatment. A Personal VLAN bridge is not authorized to link VLANs served by
logical ports because it did not create the ports, unlike its physical ports. In
this case, the creator of the logical port authenticates the requester through a
mutually-agreed upon protocol, for example, challenge-response. This inter-
station authentication (see Figure 7) is triggered when the bridge receives a
join-VLAN request whose destination VLAN set consists of a single VLAN
served by a logical port (298).
There are three cases:
• The source and destination VLANs have the same creator, and the creator
issued the join-VLAN request (300). In this case, the request is discarded
(302). Otherwise, a cycle could result in the bridged VLANs.
• The source and destination VLANs are identical and the creator did not
issue the request (304). In this case, the creator authenticates the
requester for membership into the Personal VLAN (306).
• In all other cases (308), the bridge first authenticates the request to make
sure that the requester is the creator of the source VLAN (same as step 1
for joining VLANs served by physical ports only—see above) (310). If
authentication succeeds (312), then the creator authenticates the
requester for membership into the destination VLAN (314).
When joining a personal VLAN, the destination VLAN set is preferably limited
to exactly one VLAN, i.e. the source VLAN. It is constrained in this way
because the request would otherwise reflect an attempt by a siation to bridge
a VLAN it does not own to other VLANs, something it is not authorized to do.
The owner of a VLAN can join a new VLAN and, as a result, all its member
stations also become members of the new VLAN.
Authentication of a requester by a creator is facilitated by a control channel of
the bridge and respective Auth/Supplicant modules 50, 52, 54. The bridge
uses the channel to relay authentication protocol messages between the
creator and requester. Management of the control channel and relaying
messages can be implemented using, for example, IEEE 802.1 X, IEEE
Standards for Local and Metropolitan Area Networks: Port based Network
Access Control IEEE Std 802.1 X-2001. In the 802.1 X model, the requester is
the Supplicant and the creator is the Authenticator. If the creator can
authenticate the requester, then it shares the SA it holds with the bridge with
the requester as well. It is not the bridge's responsibility to decide whether it
should share with the requester the SA it holds with the creator. This is the
creator's responsibility. There are many ways to achieve sharing. One way is
to use the requester's public key to encrypt a Transport-Layer Security (TLS
v1.0) pre-master secret from which the SA could be derived at the requester's
station.
Ingress filtering at logical ports
A security association contains at least two keys, one for encryption and the
other for computing an authentication code, referred to herein as the Message
Integrity Code (MIC). Uniquely, the SA is associated with a VLAN. The
authentication code is used to limit traffic at the logical port to members of an
entire VLAN, while encryption keeps the traffic private except to members.
Only stations having the SA belong to the VLAN. There is a single broadcast
domain for each SA. All stations having the SA belong to the same broadcast
domain. Therefore, no separate encryption key is needed for broadcasts.
A physical port may serve more than one VLAN by virtue of having multiple
logical ports associated with it (see Figure 1). Therefore, unless the frame
received at such a port carries a VID, its VLAN classification must use rules
beyond port-based classification. See IEEE 802.1Q, IEEE Standards for
Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks
IEEE Std 802.1 Q-1998, D.2.2. Otherwise, there is no way to know at this
stage which VID should be assigned from among the VLANs served by the
port. It is necessary to identify the iogicai port through which the frame is
received.
See Figure 8 in connection with the following discussion. If the received frame
carries a null VfD or is untagged (400), then its source MAC address is used
to determine a preliminany VLAN classification (402). This is the PVID of a
logical port. )f the frame carries a VID, then the VID Is used as the preliminary
classification instead (404). The preliminary classification is used to index into
a table of security associations giving a MIC key (406). The received frame
carries a MIC computed over the frame payload using a message digest
algorithm, e.g. HMAC-MD5, agreed upon by both the bridge and requester at
authentication time and recorded in the SA. The Personal VLAN bridge re-
computes the MIC (408), using its MIC key, over the payload of the received
frame, and then compares it with the received MIC (410). If they match (412),
then the preliminary VLAN classification becomes the final VLAN classification
(414). The final classification is used as the value of the VLAN classification
parameter of any corresponding data request primitives (416). The frame is
then decrypted, using the SA, and then submitted to the IEEE802.1Q
Forwarding and Learning Processes (418). Otherwise, the frame is discarded.
Egress filtering at logical ports
In the VLAN bridge model, if the transmission port for a frame that belongs to
some VLAN is not in the member set of the VLAN, then the frame is
discarded. The same rule applies to all logical transmission ports.
Although the invention is described herein with reference to the preferred
embodiment, one skilled in the art will readily appreciate that other
applications may be substituted for those set forth herein without departing
from the spirit and scope of the present invention. Accordingly, the invention
should only be limited by the Claims included below.
We claim:
1. A method for segregating traffic among a plurality of end stations
associated with a single network access point comprising:
a first end station from among said end stations receiving frames
transmitted from said single network access point, some of said frames
belonging to a first subset of said end stations to which said first end
station belongs, others of said frames belonging to at least a second subset
of said end stations; and
for a first received frame received at said first end station:
computing a cryptographic authentication code over fields
comprising said first received frame using a cryptographic message digest
algorithm;
determining whether said first received frame belongs to said first
subset of said end stations by comparing said computed cryptographic
authentication code with a received cryptographic authentication code
contained in said code do not match.
discarding said first received frame if said computed cryptographic
authentication code and said received cryptographic authentication code
do not match.
2. The method as claimed in claim 1, wherein said steps of computing,
determining, and discarding are performed by said first end station.
3. The method as claimed in claim 1, wherein for each of said end stations,
communication with said single network access point occurs over either a wired communication
link or a wireless communication link.
4. The method as claimed in claim 1, wherein communication between said
single network access point and said end stations occurs over a point-to-multipoint wireless
network.
5. The method as claimed in claim 1, wherein said single network access
point communicates with said plurality of end stations over the same wireless channel.
6. The method as claimed in claim 1, wherein said single network access
point communicates with said plurality of end stations over a point-to-multipoint shared-media
LAN.
7. The method as claimed in claim 1, wherein traffic within one VLAN is
separated from another VLAN on a same physical port by cryptography.
8. The method for segregation traffic among a plurality of end stations
associated with a single network access point comprising:
enabling a first end station from among said end stations to
perform a step of receiving frames transmitted from said single network
access point, some of said frames belonging to a first subset of said end
stations to which said first end station belongs, other of said frames
belonging to a least a second subset of said end stations; and
wherein for a first frame received at said first end station, said first
end station is enabled to perform steps of:
computing a cryptographic authentication code over fields comprising said
first received frame using a cryptographic authentication messages digest
algorithm;
determining whether said first received frame belongs to said first
subset of said end stations by comparing said computed cryptographic
authentication code with a received cryptographic authentication code
contained in said first received frame; and
discarding said first received frame if said computed cryptographic
authentication code and said received cryptographic authentication code
do not match.
9. A method for segregating traffic among a plurality of end stations
associated with an access point that has a processor and a memory, comprising:
receiving a frame at the access point wherein the frame includes a
cryptographic authentication code;
if the received frame carries a null virtual LAN ID (VID) or is untagged,
then using the received frame's source MAC address to determine a preliminary
VLAN classification of the received frame;
if the received frame carries a VID, then using the VID as the preliminary
VLAN classification instead;
using the preliminary VLAN classification to index into a table of security
associations, the table giving a cryptographic authentication code key;
re-computing the cryptographic authentication code, using the
cryptographic authentication code key from the table, over a payload of the
received frame;
comparing the recomputed cryptographic authentication code with the
received cryptographic authentication code included in the received frame;
wherein if the recomputed cryptographic authentication code and the
received cryptographic authentication code match, then using the preliminary
VLAN classification as a final VLAN classification and decrypting the received
frame; and
wherein if the recomputed cryptographic authentication code and the
received cryptographic authentication code do not match, discarding the received
frame.
10. The method as claimed in claim 9, further comprising:
performing an initial authentication operation by the access point, wherein
the authentication code key is generated during the initial authentication
operation.
11. The method as claimed in claim 9, wherein the cryptographic
authentication code is recomputed over the payload using a cryptographic message digest
algorithm determined during an initial authentication operation.
12. The method as claimed in claim 9, wherein the final VLAN classification
is used as a value of a VLAN classification parameter of any corresponding data request
primitives.
13. The method as claimed in claim 9, wherein the cryptographic
authentication code uniquely identifies the VLAN.

A method for segregating traffic among a plurality of end stations associated with a single
network access point comprising: a first end station from among said end stations receiving
frames transmitted from said single network access point, some of said frames belonging to a
first subset of said end stations to which said first end station belongs, others of said frames
belonging to at least a second subset of said end stations; and for a first received frame
received at said first end station: computing a cryptographic authentication code over fields
comprising said first received frame using a cryptographic message digest algorithm;
determining whether said first received frame belongs to said first subset of said end stations by
comparing said computed cryptographic authentication code with a received cryptographic
authentication code contained in said code do not match, discarding said first received frame if
said computed cryptographic authentication code and said received cryptographic authentication
code do not match.

Documents

Orders

Section Controller Decision Date

Application Documents

# Name Date
1 4574-KOLNP-2009-HearingNoticeLetter01-10-2019.pdf 2019-10-01
1 abstract-4574-kolnp-2009.jpg 2011-10-08
2 4574-KOLNP-2009-Correspondence to notify the Controller (Mandatory) [30-08-2019(online)].pdf 2019-08-30
2 4574-kolnp-2009-specification.pdf 2011-10-08
3 4574-KOLNP-2009_EXAMREPORT.pdf 2016-06-30
3 4574-kolnp-2009-pa.pdf 2011-10-08
4 Abstract [19-01-2016(online)].pdf 2016-01-19
4 4574-KOLNP-2009-OTHERS.pdf 2011-10-08
5 Claims [19-01-2016(online)].pdf 2016-01-19
5 4574-kolnp-2009-international publication.pdf 2011-10-08
6 Correspondence [19-01-2016(online)].pdf 2016-01-19
6 4574-kolnp-2009-form 5.pdf 2011-10-08
7 Description(Complete) [19-01-2016(online)].pdf 2016-01-19
7 4574-kolnp-2009-form 3.pdf 2011-10-08
8 Examination Report Reply Recieved [19-01-2016(online)].pdf 2016-01-19
8 4574-kolnp-2009-form 2.pdf 2011-10-08
9 4574-KOLNP-2009-FORM 18.pdf 2011-10-08
9 OTHERS [19-01-2016(online)].pdf 2016-01-19
10 4574-KOLNP-2009-FORM 13.pdf 2011-10-08
10 Details under section 8.pdf 2015-06-24
11 4574-kolnp-2009-form 1.pdf 2011-10-08
11 new covering letter.pdf 2015-06-24
12 4574-kolnp-2009-drawings.pdf 2011-10-08
12 new covering letter.pdf_4417.pdf 2015-06-24
13 4574-kolnp-2009-description (complete).pdf 2011-10-08
13 FORM-6-1901-2000(MLK).82.pdf 2015-03-13
14 4574-kolnp-2009-correspondence.pdf 2011-10-08
14 MS to MTL Assignment.pdf 2015-03-13
15 4574-KOLNP-2009-CORRESPONDENCE-1.2.pdf 2011-10-08
15 MTL-GPOA - MLK1.pdf 2015-03-13
16 4574-KOLNP-2009-CORRESPONDENCE-1.1.pdf 2011-10-08
16 FORM-6-1901-2000(MLK).82.pdf ONLINE 2015-03-09
17 MS to MTL Assignment.pdf ONLINE 2015-03-09
17 4574-kolnp-2009-claims.pdf 2011-10-08
18 4574-kolnp-2009-abstract.pdf 2011-10-08
18 MTL-GPOA - MLK1.pdf ONLINE 2015-03-09
19 4574-KOLNP-2009-(03-03-2015)-FORM-6.pdf 2015-03-03
20 4574-kolnp-2009-abstract.pdf 2011-10-08
20 MTL-GPOA - MLK1.pdf ONLINE 2015-03-09
21 4574-kolnp-2009-claims.pdf 2011-10-08
21 MS to MTL Assignment.pdf ONLINE 2015-03-09
22 4574-KOLNP-2009-CORRESPONDENCE-1.1.pdf 2011-10-08
22 FORM-6-1901-2000(MLK).82.pdf ONLINE 2015-03-09
23 4574-KOLNP-2009-CORRESPONDENCE-1.2.pdf 2011-10-08
23 MTL-GPOA - MLK1.pdf 2015-03-13
24 MS to MTL Assignment.pdf 2015-03-13
24 4574-kolnp-2009-correspondence.pdf 2011-10-08
25 FORM-6-1901-2000(MLK).82.pdf 2015-03-13
25 4574-kolnp-2009-description (complete).pdf 2011-10-08
26 4574-kolnp-2009-drawings.pdf 2011-10-08
26 new covering letter.pdf_4417.pdf 2015-06-24
27 4574-kolnp-2009-form 1.pdf 2011-10-08
27 new covering letter.pdf 2015-06-24
28 4574-KOLNP-2009-FORM 13.pdf 2011-10-08
28 Details under section 8.pdf 2015-06-24
29 4574-KOLNP-2009-FORM 18.pdf 2011-10-08
29 OTHERS [19-01-2016(online)].pdf 2016-01-19
30 4574-kolnp-2009-form 2.pdf 2011-10-08
30 Examination Report Reply Recieved [19-01-2016(online)].pdf 2016-01-19
31 Description(Complete) [19-01-2016(online)].pdf 2016-01-19
31 4574-kolnp-2009-form 3.pdf 2011-10-08
32 Correspondence [19-01-2016(online)].pdf 2016-01-19
32 4574-kolnp-2009-form 5.pdf 2011-10-08
33 Claims [19-01-2016(online)].pdf 2016-01-19
33 4574-kolnp-2009-international publication.pdf 2011-10-08
34 Abstract [19-01-2016(online)].pdf 2016-01-19
34 4574-KOLNP-2009-OTHERS.pdf 2011-10-08
35 4574-KOLNP-2009_EXAMREPORT.pdf 2016-06-30
35 4574-kolnp-2009-pa.pdf 2011-10-08
36 4574-kolnp-2009-specification.pdf 2011-10-08
36 4574-KOLNP-2009-Correspondence to notify the Controller (Mandatory) [30-08-2019(online)].pdf 2019-08-30
37 4574-KOLNP-2009-HearingNoticeLetter01-10-2019.pdf 2019-10-01
37 abstract-4574-kolnp-2009.jpg 2011-10-08