Authentication and network access control method for FTTR

Abstract

The invention relates to the technical field of network and security, in particular to an authentication and network access control method for FTTR. The method comprises the following steps: acquiring initial communication data of equipment to be accessed; generating an equipment security level initial mapping table based on the initial communication data; performing environment context collection based on the equipment security level initial mapping table to obtain network environment context data; generating an authentication strategy according to the equipment security level initial mapping table and the network environment context data to obtain a differential authentication strategy set; performing virtual slice demand analysis according to the equipment security level initial mapping table to obtain virtual slice configuration parameters; and performing micro-isolation virtual network slice creation based on the virtual slice configuration parameters to obtain a virtual network slice topology. According to the invention, the differentiated requirements of different types of equipment on network security and access authority can be met, and the flexibility and adaptability of network authentication and access control are improved.

Description

Technical Field

[0001] This invention relates to the field of network and security technology, and in particular to an authentication and network access control method for FTTR. Background Technology

[0002] Fiber optic communication technology, with its advantages of high speed, stability, and strong anti-interference capabilities, has been widely used in home network construction. FTTR network systems, by laying fiber optic cables directly into rooms, provide a high-speed, stable network access environment for various smart terminal devices in the home, greatly improving home network performance and user experience.

[0003] In FTTR network systems, with the increasing number of smart home devices, various smart terminals such as smart cameras, smart door locks, and smart appliances are connecting to the FTTR network. The access of these devices not only enriches the application scenarios of home networks but also brings great convenience to people's lives. However, this process has also brought some problems that urgently need to be addressed. Existing network authentication and access control methods mostly adopt a uniform authentication strategy, failing to provide flexible and differentiated processing based on device type and security requirements. For example, different types of smart devices have different requirements for network security and access permissions, but current authentication and access control methods cannot meet these differentiated needs. In a home environment, when a user adds a smart device, they often need to manually configure network parameters and security policies. This not only increases the complexity of user operations but may also lead to security vulnerabilities because users may not understand the security levels required for different devices. Summary of the Invention

[0004] Therefore, the present invention needs to provide an authentication and network access control method for FTTR to solve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, an authentication and network access control method for FTTR includes the following steps:

[0006] Step S1: Obtain the initial communication data of the device to be connected; generate an initial mapping table of device security levels based on the initial communication data;

[0007] Step S2: Collect the network environment context based on the initial mapping table of device security level to obtain network environment context data; generate authentication policies based on the initial mapping table of device security level and network environment context data to obtain a differentiated authentication policy set;

[0008] Step S3: Perform virtual slice requirement analysis based on the initial mapping table of device security levels to obtain virtual slice configuration parameters; create micro-segmented virtual network slices based on the virtual slice configuration parameters to obtain the virtual network slice topology;

[0009] Step S4: Obtain network behavior data during device operation; perform behavior baseline modeling on the network behavior data to obtain the device behavior baseline model; dynamically adjust the differentiated authentication policy set based on the device behavior baseline model to obtain an updated device security level table;

[0010] Step S5: Perform policy visualization conversion based on the virtual network slice topology and the updated device security level table to obtain policy explanation text; perform user confirmation interaction based on the policy explanation text to obtain the final network access control policy.

[0011] The beneficial effects of this invention are as follows:

[0012] On the one hand, by acquiring the initial communication data of the devices to be accessed and generating an initial mapping table of device security levels, the system achieves accurate security level classification for different devices, providing a foundation for subsequent differentiated authentication and access control, and effectively solving the problem that existing technologies cannot flexibly handle device types and security requirements.

[0013] On the other hand, by collecting environmental context based on the initial mapping table of device security levels and generating a differentiated authentication policy set, this invention can dynamically generate flexible authentication policies according to the actual operating environment of the network and the security level of the devices, meeting the differentiated needs of different types of devices for network security and access permissions, and improving the flexibility and adaptability of network authentication and access control.

[0014] On the other hand, by performing virtual slice demand analysis and creating micro-isolated virtual network slices, this invention achieves on-demand allocation and isolation of network resources, improves network stability and security, avoids mutual interference between devices, and ensures efficient network operation. Attached Figure Description

[0015] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description taken in conjunction with the accompanying drawings:

[0016] Figure 1 A flowchart illustrating the steps of an embodiment of an authentication and network access control method for FTTR is shown.

[0017] Figure 2 A schematic diagram of a home all-optical networking architecture according to an embodiment is shown. Detailed Implementation

[0018] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0019] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0020] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0021] To achieve the above objectives, please refer to Figures 1 to 2 This invention provides an authentication and network access control method for FTTR, comprising the following steps:

[0022] Step S1: Obtain the initial communication data of the device to be connected; generate an initial mapping table of device security levels based on the initial communication data;

[0023] Step S2: Collect the network environment context based on the initial mapping table of device security level to obtain network environment context data; generate authentication policies based on the initial mapping table of device security level and network environment context data to obtain a differentiated authentication policy set;

[0024] Step S3: Perform virtual slice requirement analysis based on the initial mapping table of device security levels to obtain virtual slice configuration parameters; create micro-segmented virtual network slices based on the virtual slice configuration parameters to obtain the virtual network slice topology;

[0025] Step S4: Obtain network behavior data during device operation; perform behavior baseline modeling on the network behavior data to obtain the device behavior baseline model; dynamically adjust the differentiated authentication policy set based on the device behavior baseline model to obtain an updated device security level table;

[0026] Step S5: Perform policy visualization conversion based on the virtual network slice topology and the updated device security level table to obtain policy explanation text; perform user confirmation interaction based on the policy explanation text to obtain the final network access control policy.

[0027] Preferably, step S1 includes the following steps:

[0028] Step S11: Obtain the initial communication data of the device to be connected, wherein the initial communication data includes the device MAC address, the device OUI vendor code and the device protocol handshake data;

[0029] In this embodiment of the invention, in a home FTTR network environment, when a new smart camera attempts to access the network, the network access control system captures the initial communication data of the device through the network interface. Specifically, using the Wireshark network packet capture tool, the communication process between the camera and the network access point is monitored in real time, and the initial communication data of the camera is successfully obtained. This data includes the device's MAC address "00:1A:2B:3C:4D:5E", the device's OUI vendor code "00:1A:2B", indicating that the device is manufactured by a well-known camera manufacturer, and the device protocol handshake data, which includes the three-way handshake process data in the TCP / IP protocol stack used by the camera, such as the interaction information of SYN, SYN-ACK, ACK and other flag bits, as well as related port number information, such as the default ports used by the camera being 80 (HTTP) and 443 (HTTPS) for device management and data transmission.

[0030] Step S12: Evaluate the manufacturer's trustworthiness based on the device's MAC address and OUI vendor code to obtain the device manufacturer's trustworthiness evaluation result;

[0031] In this embodiment of the invention, after obtaining the device's MAC address and OUI vendor code, a pre-established vendor credibility assessment database is invoked. This database collects credibility information from numerous network equipment manufacturers, which is based on a comprehensive evaluation of factors such as the manufacturer's market reputation, product quality, and security vulnerability history. For the aforementioned smart camera's OUI vendor code "00:1A:2B", the database shows a credibility score of 85 out of 100.

[0032] Step S13: Extract protocol interaction features from the device protocol handshake data to obtain the device protocol type and device port usage mode;

[0033] In this embodiment of the invention, protocol interaction features are extracted from the acquired device handshake data. The handshake data packets are parsed layer by layer using the network protocol analysis tool Scapy. During the parsing process, the protocol type used by the data packets is identified. By analyzing the IP header information in the TCP / IP protocol stack and the TCP / UDP header information in the transport layer, it is determined that the smart camera primarily uses the TCP protocol when communicating with the network access point. Furthermore, by focusing on the port number information of the data packets, it is found that the device uses ports 80 and 443 during the handshake process. This indicates that the device performs some basic communication operations via the HTTP protocol during normal operation, such as device status queries, and also uses the HTTPS protocol for encrypted communication to transmit sensitive data, such as video streams captured by the camera, thus determining the device's port usage pattern.

[0034] Step S14: Quantify communication behavior characteristics based on device protocol handshake data to obtain device communication frequency and device data packet size distribution data;

[0035] In this embodiment of the invention, a data acquisition window is set, for example, with 10 minutes as a time unit, to monitor the network communication behavior of the smart camera within this time period. Using a network traffic analysis tool, such as ntopng, the communication frequency of the device is statistically analyzed in real time, that is, the number of times the device sends and receives data packets within 10 minutes. Assuming the statistical results show that the device sends and receives data packets an average of 50 times per minute. Simultaneously, the size distribution of the device's data packets is statistically analyzed, recording the size of each data packet and classifying them according to size range, for example, dividing the data packet size into intervals such as less than 100 bytes, 100-1000 bytes, and 1000-10000 bytes, and statistically analyzing the proportion of data packets within each interval.

[0036] Step S15: Calculate the static security score of the device based on the device manufacturer's trustworthiness assessment results, device protocol type, and device port usage pattern.

[0037] In this embodiment of the invention, a set of preset scoring rules is used to calculate the static security score of the device. These rules comprehensively consider multiple factors, including the device manufacturer's credibility assessment results, the device's protocol type, and the device's port usage patterns. The device manufacturer's credibility assessment results are directly used as the base score; the aforementioned smart camera has a manufacturer credibility score of 85, therefore, the device's base score is 85. For the device's protocol type, points are added or subtracted based on the protocol's security; since this device primarily uses the TCP protocol, 10 points are added. Regarding the device's port usage patterns, the system checks whether the device uses high-risk ports, such as common malware communication ports. Since ports 80 and 443 used by this device are common and legitimate ports, no points are deducted. The final static security score for this device is 95.

[0038] Step S16: Calculate the device dynamic security score based on the device communication frequency and device data packet size distribution data to obtain the device dynamic security score;

[0039] In this embodiment of the invention, when calculating the dynamic security score of a device, the device's communication frequency and data packet size distribution data are utilized. A baseline value is set for the device's communication frequency; for example, for smart devices in a home network, the baseline value for normal communication frequency is set to 30 times per minute. If the device's communication frequency exceeds this baseline value, points are deducted according to the degree of excess; assuming 1 point is deducted for every 10 times exceeding the baseline value. In this example, the smart camera's communication frequency is 50 times per minute, exceeding the baseline value by 20 times, therefore 2 points are deducted. For data packet size distribution data, a reasonable distribution range is set; for example, for home smart devices, under normal circumstances, the proportion of data packets mainly concentrated in the 100-1000 byte range should be between 60% and 80%. If the device's data packet size distribution deviates from this range, points are also deducted; assuming 1 point is deducted for every 10% deviation. In this example, although the device's data packet size distribution is mainly concentrated in the 100-1000 byte range, its proportion is 70%, slightly higher than the upper limit of the normal range, therefore 1 point is deducted. Taking into account both communication frequency and data packet size distribution, the device's dynamic security score is 97 points (assuming a maximum score of 100 points).

[0040] Step S17: Map the equipment's static safety score and dynamic safety score to obtain the initial mapping table of the equipment's safety level.

[0041] In this embodiment of the invention, a security level mapping table is predefined, which divides the overall security score range of a device into different security level intervals. For example, 90-100 points is a high-level security device, 80-89 points is a medium-level security device, 70-79 points is a low-level security device, and so on. In this example, the smart camera has a static security score of 95 points and a dynamic security score of 97 points. These two scores are weighted and averaged, assuming a static score weight of 0.6 and a dynamic score weight of 0.4, resulting in an overall security score of 95.8 points. According to the security level mapping table, the device's overall security score falls within the 90-100 point range, and therefore it is mapped as a high-level security device. The device and its corresponding security level are recorded in the initial device security level mapping table.

[0042] Preferably, step S2 includes the following steps:

[0043] Step S21: Extract access time features based on the initial mapping table of device security levels to obtain device access time period distribution data;

[0044] In this embodiment of the invention, in an FTTR network environment, the log analysis module in the Network Management System (NMS) is used to record and analyze the access time of the smart camera. Specifically, a time window is set, for example, with a 24-hour cycle, to record the number of times the device accesses the network within each time period. By analyzing the log data, it was found that the smart camera accesses the network more frequently during the two time periods of 8:00 AM to 10:00 AM and 6:00 PM to 8:00 PM each day, recorded as 10 times and 15 times respectively. These time periods and their corresponding access counts are recorded to form device access time period distribution data.

[0045] Step S22: Perform a signal strength scan at the device access location to obtain the signal strength at the device location;

[0046] In this embodiment of the invention, a Wi-Fi signal scanning tool, such as NetSpot, is used to obtain the signal strength at the device's access location. In a home environment, signal scanning devices are placed in multiple preset locations (such as the living room, bedroom, and kitchen) to scan the signal strength of the smart camera when it accesses the network. Based on the NetSpot scan results, the signal strength was recorded as -30dBm when the device was connected in the living room, and -50dBm when connected in the bedroom.

[0047] Step S23: Perform neighbor discovery protocol parsing on the current network topology to obtain a list of neighbor devices;

[0048] In this embodiment of the invention, Link Layer Discovery Protocol (LLDP) and Address Resolution Protocol (ARP) scanning tools, such as Angry IP Scanner, are used to quickly scan devices in the network and obtain their IP addresses, MAC addresses, and other information. The IP addresses, MAC addresses, and device types of these devices are recorded to form a list of neighboring devices.

[0049] Step S24: Conduct an environmental risk assessment based on the distribution data of device access time periods and the signal strength of device locations to obtain the network environment risk index;

[0050] In this embodiment of the invention, an environmental risk assessment model is predefined, which comprehensively considers the frequency of device access time and changes in signal strength. Specifically, high-frequency access time periods (e.g., more than 10 times per day) in the device access time distribution data are marked as high-risk time periods, because these time periods may indicate that the device is being used frequently without the user's notice, posing a risk of malicious use. Simultaneously, locations with signal strength below -60dBm are marked as high-risk locations, because excessively low signal strength may indicate that the device is at the edge of signal coverage, making it susceptible to interference or tampering. In this example, the smart camera has a signal strength of -30dBm when accessed in the living room, which is considered a low-risk location; while when accessed in the bedroom, the signal strength is -50dBm, which is considered a medium-risk location. These risk assessment results are combined to calculate a network environment risk index of 70 (out of 100, with higher values ​​indicating higher risk).

[0051] Step S25: Based on the initial mapping table of device security level and network environment risk index, perform authentication strength requirement analysis to obtain device authentication strength requirement data;

[0052] In this embodiment of the invention, a set of authentication strength requirement rules is defined. These rules determine the required authentication strength of a device based on its security level and network environment risk index. Specifically, for high-security devices (such as smart cameras), if the network environment risk index is higher than 60, a strong authentication method, such as multi-factor authentication (MFA), is required; if the network environment risk index is lower than 60, a medium-strength authentication method, such as certificate-based authentication, can be used. In this example, the smart camera has a high security level and a network environment risk index of 70; therefore, the authentication strength requirement for this device is determined to be a strong authentication method.

[0053] Step S26: Match the authentication strategy with the neighbor device list based on the device authentication strength requirement data to obtain preliminary authentication strategy configuration data;

[0054] In this embodiment of the invention, an authentication policy library is maintained, containing various authentication policy templates, each corresponding to different authentication strength requirements and device types. A suitable authentication policy template is selected by matching the authentication strength requirements with the device types in the neighbor device list. In this example, based on the strong authentication requirements of the smart camera, a policy template including multi-factor authentication (MFA) is selected. This template requires the user to perform secondary verification via SMS verification code or an authentication application in addition to entering the device password. This authentication policy configuration data is then applied to the smart camera's access process.

[0055] Step S27: Optimize and adjust the initial authentication strategy configuration data to obtain a differentiated authentication strategy set.

[0056] Preferably, step S27 includes the following steps:

[0057] Step S271: Perform policy conflict detection on the preliminary authentication policy configuration data to obtain policy conflict point identifiers;

[0058] In this embodiment of the invention, in an FTTR network environment, a policy management tool, such as Ansible Tower, is used to manage and detect policy conflicts. Ansible Tower can detect potential conflicts between policies. For example, it detects two conflicting policies in the initial authentication policy configuration data: one policy requires the smart camera to use certificate-based authentication when accessing the living room, while the other policy requires multi-factor authentication (MFA) at the same location. Ansible Tower's conflict detection module marks these conflict points and generates policy conflict point identifiers.

[0059] Step S272: Prioritize the policy conflict point identifiers based on the initial mapping table of device security levels to obtain policy priority ranking data;

[0060] In this embodiment of the invention, preset priority rules are used to determine the priority of policies based on the security level of the device and the risk index of the network environment. For example, for high-security devices (such as smart cameras), strong authentication policies (such as MFA) are given the highest priority. In this example, the smart camera has a high security level, so the priority of the multi-factor authentication (MFA) policy is set to 1, while the priority of the certificate-based authentication policy is set to 2. These priority ranking results are recorded to form policy priority ranking data.

[0061] Step S273: Allocate policy weights to the preliminary authentication policy configuration data according to the policy priority sorting data to obtain policy weight allocation data;

[0062] In this embodiment of the invention, preset weight allocation rules are used, which assign weights based on the priority of the strategy. For example, a strategy with priority 1 is assigned a weight of 0.8, and a strategy with priority 2 is assigned a weight of 0.2. In this example, the multi-factor authentication (MFA) strategy has a priority of 1, so it is assigned a weight of 0.8; the certificate-based authentication strategy has a priority of 2, so it is assigned a weight of 0.2. These weight allocation results are recorded to form strategy weight allocation data.

[0063] Step S274: Use preset strategy optimization rules to fine-tune the strategy weight allocation data to obtain optimized strategy parameters;

[0064] In this embodiment of the invention, optimization algorithms, such as genetic algorithms (GA), are used to adjust strategy parameters. For example, the parameters of a multi-factor authentication (MFA) strategy, such as the validity period and attempt limit of SMS verification codes, are adjusted using a genetic algorithm. The validity period of the SMS verification code is adjusted from 5 minutes to 3 minutes, and the number of attempts is adjusted from 5 to 3. These optimized parameters are recorded to form the optimized strategy parameters.

[0065] Step S275: Reconstruct the policy rules of the preliminary authentication policy configuration data based on the optimized policy parameters to obtain the reconstructed policy rule data;

[0066] In this embodiment of the invention, a policy management tool, such as Ansible Tower, is used to reconstruct policy rules. For example, based on optimized parameters, the rules of the multi-factor authentication (MFA) policy are reconstructed as follows: when a user enters their device password, they must undergo secondary verification via SMS verification code within 3 minutes, with a maximum of 3 attempts. These reconstructed policy rules are recorded to form reconstructed policy rule data.

[0067] Step S276: Verify the validity of the reconstructed policy rule data to obtain the policy verification results;

[0068] In this embodiment of the invention, automated testing tools, such as JMeter, are used to verify the effectiveness of the strategy. For example, JMeter is used to simulate a scenario where a smart camera is connected to the network in the living room to verify the effectiveness of the multi-factor authentication (MFA) strategy. The test results show that the strategy executes correctly; after the user enters the device password, they must perform secondary verification via SMS verification code within 3 minutes, with a maximum of 3 attempts. These verification results are recorded to form the strategy verification results.

[0069] Step S277: Based on the policy verification results, generate the final policy from the reconstructed policy rule data to obtain a differentiated authentication policy set.

[0070] In this embodiment of the invention, a policy management tool, such as Ansible Tower, is used to generate the final authentication policy. For example, based on the verification results, a multi-factor authentication (MFA) policy is adopted as the final policy to ensure that the smart camera must execute this policy when accessing the network in the living room. The final authentication policy is recorded in a differentiated authentication policy set and deployed to the network access control system.

[0071] Preferably, step S3 includes the following steps:

[0072] Step S31: Divide the security domains according to the initial mapping table of equipment security levels to obtain equipment security domain grouping data;

[0073] In this embodiment of the invention, in an FTTR network environment, network management tools, such as Cisco Prime Infrastructure, are used to manage and divide security domains. Devices are divided into different security domains based on their security level. For example, high-security devices (such as smart cameras) are assigned to the "high-security domain," medium-security devices (such as smart locks) are assigned to the "medium-security domain," and low-security devices (such as smart light bulbs) are assigned to the "low-security domain." Through the device management module of Cisco Prime Infrastructure, these devices are grouped according to their security level, generating device security domain grouping data. For example, the system groups all smart cameras (high security level) into one group, all smart locks (medium security level) into another group, and all smart light bulbs (low security level) into a third group.

[0074] Step S32: Based on the device security domain grouping data, perform resource demand prediction to obtain virtual slice resource demand data;

[0075] Step S33: Perform a network resource scan on the current network architecture to obtain available network resource distribution data;

[0076] In this embodiment of the invention, a network scanning tool, such as Solar Winds Network Performance Monitor, is used to scan for available resources in the network. For example, the scan may reveal 100 Mbps of available bandwidth distributed across different network nodes. The IP address, bandwidth capacity, and current utilization rate of each node are recorded. For instance, node A has an IP address of 192.168.1.1, a bandwidth capacity of 50 Mbps, and a current utilization rate of approximately 30%; node B has an IP address of 192.168.1.2, a bandwidth capacity of 50 Mbps, and a current utilization rate of approximately 20%. These scan results are recorded to form available network resource distribution data.

[0077] Step S34: Match the slice parameters with the virtual slice resource demand data and the available network resource distribution data to obtain the basic slice configuration parameters;

[0078] In this embodiment of the invention, a resource allocation tool, such as Open Stack Neutron, is used to match resource requirements with available resources. For example, resource matching is performed based on the virtual slice resource requirement data (60Mbps bandwidth requirement) and available network resource distribution data (100Mbps available bandwidth) of the "high-security domain". Node A and Node B are selected as resource-providing nodes and allocated to the virtual slice of the "high-security domain". These matching results are recorded through the Open Stack Neutron API interface to form the basic slice configuration parameters.

[0079] Step S35: Enhance the security policy of the basic slice configuration parameters based on the differentiated authentication policy set to obtain the enhanced slice configuration parameters;

[0080] In this embodiment of the invention, a security policy management tool, such as Palo Alto Networks Panorama, is used to enhance the security policy of computer slices. For example, based on a differentiated authentication policy set, a multi-factor authentication (MFA) policy and a certificate-based authentication policy are configured for the virtual slices in the "high-security domain". These security policies are applied to the basic slice configuration parameters through Panorama's policy management module to generate enhanced slice configuration parameters. For example, the following security policy is configured for the virtual slices in the "high-security domain": users must undergo dual authentication using a device password and a mobile SMS verification code when accessing the network, and the device must possess a valid security certificate.

[0081] Step S36: Send the enhanced slice configuration parameters to the network device through the virtualization platform interface to obtain the virtual network slice instantiation data;

[0082] In this embodiment of the invention, a virtualization platform, such as VMware vSphere, is used to manage and deploy virtual network slices. Enhanced slice configuration parameters are distributed to network devices (such as routers and switches) via the vSphere API. For example, enhanced slice configuration parameters for a "high-security domain" are distributed to nodes A and B, which then create virtual network slice instances based on the configuration parameters. The creation process of virtual network slice instances is monitored and instantiation data is recorded through the vSphere management interface. For example, the ID, configuration parameters, and status information of each virtual network slice instance are recorded.

[0083] Step S37: Construct topology relationships on the virtual network slice instantiation data to obtain the virtual network slice topology.

[0084] In this embodiment of the invention, a network topology management tool, such as GNS3, is used to construct the topology relationships of virtual network slices. Based on the virtual network slice instantiation data, the various virtual network slice instances are connected to form a complete topology structure. For example, the virtual network slice instance of the "high-security domain" is connected to the core router to form an independent virtual network topology. The topology diagram of the virtual network slices is drawn using the GNS3 topology editor, showing the connection relationships between the nodes. The configuration parameters and connection status of each node in the topology diagram are recorded. Finally, the virtual network slice topology is generated.

[0085] Preferably, step S32 includes the following steps:

[0086] Step S321: Perform device count on the device security domain grouping data to obtain the number of devices in each security domain;

[0087] In this embodiment of the invention, in an FTTR network environment, network management tools, such as Cisco Prime Infrastructure, are used to manage and count the number of devices. Based on an initial device security level mapping table, devices are divided into different security domains. For example, all smart cameras (high security level) are assigned to the "high security domain," all smart locks (medium security level) to the "medium security domain," and all smart light bulbs (low security level) to the "low security domain." The device management module of Cisco Prime Infrastructure is used to count the number of devices in each security domain. The results show that there are 5 smart cameras in the "high security domain," 10 smart locks in the "medium security domain," and 20 smart light bulbs in the "low security domain."

[0088] Step S322: Estimate bandwidth requirements based on the number of devices in each security domain to obtain estimated bandwidth requirements data;

[0089] Step S323: Allocate resources to the number of devices in each security domain using preset resource allocation rules to obtain basic resource quota data;

[0090] In this embodiment of the invention, resource management tools, such as VMware v Realize Operations, are used to allocate basic resource quotas. For example, based on preset resource allocation rules, basic resource quotas are allocated to each security domain. Assume the system allocates a basic bandwidth quota of 50Mbps to the "high security domain," 30Mbps to the "medium security domain," and 20Mbps to the "low security domain." These allocation results are recorded to form basic resource quota data.

[0091] Step S324: Adjust the resource reserve based on the estimated bandwidth demand data and the basic resource quota data to obtain the adjusted resource quota data;

[0092] In this embodiment of the invention, resource management tools, such as VMware v Realize Operations, are used to adjust resource quotas. For example, it is found that the estimated bandwidth requirement of the "high security domain" is 60Mbps, while the basic resource quota is 50Mbps, resulting in a 10Mbps resource shortfall. According to preset resource adjustment rules, resources are adjusted from other security domains (such as the "low security domain"), reducing the basic resource quota of the "low security domain" from 20Mbps to 10Mbps, and allocating the saved 10Mbps to the "high security domain". After the adjustment, the resource quota of the "high security domain" is 60Mbps, the resource quota of the "medium security domain" remains at 30Mbps, and the resource quota of the "low security domain" is 10Mbps. These adjusted resource quota data are recorded to form the adjusted resource quota data.

[0093] Step S325: Integrate the adjusted resource quota data to obtain virtual slice resource demand data.

[0094] In this embodiment of the invention, a resource management tool, such as VMware v Realize Operations, is used to integrate resource quota data. The adjusted resource quota data is then aggregated to form virtual slice resource requirement data. For example, the integrated virtual slice resource requirement data is as follows: "High Security Domain" requires 60Mbps bandwidth, "Medium Security Domain" requires 30Mbps bandwidth, and "Low Security Domain" requires 10Mbps bandwidth. This integrated resource requirement data is recorded to form the virtual slice resource requirement data.

[0095] Preferably, step S322 includes the following steps:

[0096] Step S3221: Classify the number of devices in each security domain by device type to obtain the distribution data of device types in the security domain;

[0097] In this embodiment of the invention, in an FTTR network environment, network management tools, such as PRTG NetworkMonitor, are used to manage and classify device types. For example, counting the number of devices in the "high-security domain" reveals a total of 5 devices. Using the device classification function of PRTG Network Monitor, these devices are categorized by type. The classification results show that 3 of these 5 devices are smart cameras, and 2 are smart security sensors. These classification results are recorded to form security domain device type distribution data.

[0098] Step S3222: Use the preset bandwidth baseline value table to query and match the distribution data of security domain device types to obtain the baseline bandwidth requirement data of the devices;

[0099] In this embodiment of the invention, a resource management tool, such as Solar Winds Network Performance Monitor, is used to query the baseline bandwidth requirements of matching devices. For example, based on a preset bandwidth baseline value table, the baseline bandwidth requirement for smart cameras is found to be 10 Mbps, and the baseline bandwidth requirement for smart security sensors is 5 Mbps. The query function of Solar Winds Network Performance Monitor is used to match these baseline bandwidth requirement data with the distribution data of device types in the security domain. The matching results show that the baseline bandwidth requirement for the three smart cameras in the "high security domain" is 10 Mbps, and the baseline bandwidth requirement for the two smart security sensors is 5 Mbps. These matching results are recorded to form the device baseline bandwidth requirement data.

[0100] Step S3223: Multiply the number of security domain devices by the baseline bandwidth requirement data of the devices to obtain the initial bandwidth requirement estimate data;

[0101] In this embodiment of the invention, an Excel spreadsheet tool is used to perform multiplication operations. For example, multiplication is performed based on the number of devices and baseline bandwidth requirements in the "high-security domain". Specifically, the calculations are as follows: the total bandwidth requirement for 3 smart cameras is 3 × 10 Mbps = 30 Mbps, and the total bandwidth requirement for 2 smart security sensors is 2 × 5 Mbps = 10 Mbps. Adding these calculations together, the initial bandwidth requirement for the "high-security domain" is 40 Mbps.

[0102] Step S3224: Adjust the initial bandwidth demand estimation data based on the preset redundancy coefficient to obtain the adjusted bandwidth demand data;

[0103] In this embodiment of the invention, an Excel spreadsheet tool is used for adjustment calculations. For example, a product operation is performed based on the number of devices in the "high-security domain" and the baseline bandwidth requirement data. Specifically, the calculation is as follows: the total bandwidth requirement of 3 smart cameras is 3 × 10 Mbps = 30 Mbps, and the total bandwidth requirement of 2 smart security sensors is 2 × 5 Mbps = 10 Mbps. Adding these calculation results together, the initial bandwidth requirement of the "high-security domain" is 40 Mbps.

[0104] Step S3225: Accumulate the adjusted bandwidth demand data for each security domain to obtain the estimated bandwidth demand data.

[0105] In this embodiment of the invention, a Python script is used for cumulative calculation. For example, assume that the adjusted bandwidth requirement for the "medium security domain" is 24 Mbps and the adjusted bandwidth requirement for the "low security domain" is 12 Mbps. Using a Python script, the adjusted bandwidth requirements for the "high security domain," "medium security domain," and "low security domain" are added together to obtain a total estimated bandwidth requirement of 48 Mbps + 24 Mbps + 12 Mbps = 84 Mbps. These estimated bandwidth requirement data are recorded to form the final virtual slice resource requirement data.

[0106] Preferably, step S4 includes the following steps:

[0107] Step S41: Collect network traffic during device operation using a traffic probe to obtain network behavior data;

[0108] In this embodiment of the invention, a traffic acquisition tool, such as ntopng, is used in an FTTR network environment to monitor and record network traffic in real time. For example, ntopng is deployed in a home network to collect network traffic from smart cameras. ntopng can record detailed information such as the device's IP address, port number, packet size, and transmission frequency. A 10-minute data acquisition window is set to record all network traffic from the smart camera during this period. The acquisition results show that the smart camera sent and received 500 data packets within 10 minutes, with an average packet size of 500 bytes. This collected network traffic data is recorded to form network behavior data.

[0109] Step S42: Extract traffic features from network behavior data to obtain a device traffic feature dataset;

[0110] In this embodiment of the invention, data analysis tools, such as Wireshark, are used to analyze and extract traffic characteristics. For example, collected network behavior data is imported into Wireshark, and the device's traffic characteristics are extracted using Wireshark's analysis functions. Specific extracted characteristics include packet size distribution, transmission frequency, and protocol type. Packet sizes are divided into three ranges: less than 100 bytes, 100-1000 bytes, and greater than 1000 bytes. Analysis results show that the smart camera's data packets are mainly concentrated in the 100-1000 byte range, accounting for 70%, with a transmission frequency of 50 times per minute, primarily using the TCP protocol. These extracted traffic characteristics are recorded to form a device traffic characteristic dataset.

[0111] Step S43: Compare and analyze the device traffic feature dataset based on the preset normal behavior template to obtain behavior deviation evaluation data;

[0112] In this embodiment of the invention, behavioral analysis tools, such as Elasticsearch and Kibana, are used to manage and analyze device traffic characteristic datasets. For example, a predefined normal behavior template is used, defining the traffic characteristics of a smart camera during normal operation, such as packet size primarily concentrated in the 100-1000 byte range, transmission frequency of 30-50 times per minute, and primary use of the TCP protocol. The collected device traffic characteristic dataset is compared and analyzed with the predefined normal behavior template. The comparison results show that the smart camera's packet size distribution is consistent with the normal behavior template, but the transmission frequency is slightly higher than the normal range (50 times per minute, while the normal range is 30-50 times). Based on these comparison results, a behavioral deviation assessment is calculated, for example, a deviation of 10%.

[0113] Step S44: Based on the behavioral deviation assessment data, reassess the security level of the differentiated authentication strategy set to obtain security level adjustment recommendation data;

[0114] In this embodiment of the invention, a security policy management tool, such as Palo Alto Networks Panorama, is used to manage and adjust the security policy. For example, the security level of the smart camera is reassessed based on behavioral deviation assessment data (deviation of 10%). A preset security level adjustment rule is established: when the deviation exceeds 5%, the security level is downgraded by one level. In this example, the initial security level of the smart camera is high (95 points). Based on the deviation assessment data, its security level is downgraded by one level to medium (85 points). This adjustment suggestion is recorded to form security level adjustment suggestion data.

[0115] Step S45: Update the security level adjustment suggestion data according to the policy to obtain the updated device security level table.

[0116] Preferably, step S45 includes the following steps:

[0117] Step S451: Verify the validity of the security level adjustment recommendation data to obtain the validity assessment data of the adjustment recommendations;

[0118] In this embodiment of the invention, in an FTTR network environment, a security policy management tool, such as Palo Alto Networks Panorama, is used to verify the validity of adjustment suggestions. For example, a security level adjustment suggestion is received, recommending that the security level of a smart camera be downgraded from high (95 points) to medium (85 points). The Panorama verification module checks whether the adjustment suggestion conforms to preset security policy rules. Specifically, it verifies whether the adjustment suggestion is based on reasonable deviation assessment data (e.g., deviation exceeding 5%) and whether it is consistent with the device's operating status and network environment. The verification result shows that the adjustment suggestion is based on valid deviation assessment data (deviation of 10%) and is consistent with the device's operating status and network environment. Therefore, the adjustment suggestion is marked as valid, and adjustment suggestion validity assessment data is generated.

[0119] Step S452: Prioritize the adjustment suggestion effectiveness assessment data based on the initial mapping table of equipment security levels to obtain adjustment priority ranking data;

[0120] In this embodiment of the invention, a priority sorting tool, such as a Python script, is used to process this data. For example, the initial security level of each device is determined according to the initial security level mapping table. For the smart camera, the initial security level is high (95 points). Based on a preset priority rule, valid adjustment suggestions are sorted according to the device's initial security level. Specifically, the rule is: adjustment suggestions for high-security-level devices have the highest priority, followed by medium-security-level devices, and low-security-level devices have the lowest priority. In this example, the adjustment suggestions for the smart camera are given the highest priority. These priority sorting results are recorded to form adjustment priority sorting data.

[0121] Step S453: Extract policy change parameters from the security level adjustment suggestion data based on the adjustment priority sorting data to obtain the policy change parameter set;

[0122] In this embodiment of the invention, a data extraction tool, such as an Excel spreadsheet, is used to extract policy change parameters. For example, based on the adjustment priority sorting data, key parameters in the security level adjustment suggestions for smart cameras are extracted. These parameters include the device's MAC address, device type, initial security level, adjusted security level, deviation assessment data, etc. In this example, the extracted parameters are as follows: device MAC address is "00:1A:2B:3C:4D:5E", device type is "smart camera", initial security level is "high (95 points)", adjusted security level is "medium (85 points)", and deviation assessment data is "10%". These extracted parameters are recorded to form a policy change parameter set.

[0123] Step S454: Update the policy change parameter set by mapping it to a pre-defined security level update rule to obtain the updated device security level table.

[0124] In this embodiment of the invention, a security policy management tool, such as Palo Alto Networks Panorama, is used to update the security level of the device. For example, according to a preset security level update rule, the security level of the smart camera is updated from high (95 points) to medium (85 points). The updated security level is applied to the initial security level mapping table of the device through Panorama's policy management module. Specifically, the record for the smart camera is found in the initial security level mapping table, and the security level field is updated from "high (95 points)" to "medium (85 points)". These updated data are recorded to form an updated device security level table.

[0125] Preferably, step S5 includes the following steps:

[0126] Step S51: Perform topology relationship parsing on the virtual network slice topology to obtain network slice relationship description data;

[0127] In this embodiment of the invention, in an FTTR network environment, a network topology management tool, such as GNS3, is used to resolve the topology relationships of virtual network slices. For example, a virtual network slice topology containing "high security domain," "medium security domain," and "low security domain" is created. Using GNS3's topology editor, the device connection relationships and network paths of each security domain are analyzed in detail. The analysis results show that devices in the "high security domain" are connected to the network center through the core router, devices in the "medium security domain" are connected to the core router through the aggregation switch, and devices in the "low security domain" are connected to the aggregation switch through the access switch. This topology relationship description data is recorded to form network slice relationship description data.

[0128] Step S52: Perform security level mapping conversion based on the updated device security level table to obtain device security level description data;

[0129] In this embodiment of the invention, a security policy management tool, such as Palo Alto Networks Panorama, is used to perform security level mapping and conversion. For example, the security level of a smart camera has been adjusted from high (95 points) to medium (85 points) from the updated device security level table. According to preset security level mapping rules, the security level score is converted into specific descriptive text. The specific rules are: high (95 points) is mapped to "high security level", medium (85 points) is mapped to "medium security level", and low (below 75 points) is mapped to "low security level". In this example, the security level of the smart camera is mapped to "medium security level". These mapped security level descriptions are recorded to form device security level description data.

[0130] Step S53: Integrate policy rules based on network slice relationship description data and device security level description data to obtain integrated policy rule description data;

[0131] In this embodiment of the invention, a policy management tool, such as Ansible Tower, is used to integrate this data. For example, network slice relationship description data for a "high-security domain" is integrated with security level description data of devices within that domain. The integration result shows that devices in the "high-security domain" (such as smart cameras) have a "medium security level" and are connected to the network center through the core router. Based on this integrated data, integrated policy rule description data is generated. For example, the generated rule description is: "All devices located in the 'high-security domain' have a 'medium security level,' must access the network through the core router, and a multi-factor authentication (MFA) policy must be implemented."

[0132] Step S54: Perform text conversion on the integrated strategy rule description data to obtain the strategy explanation text;

[0133] In this embodiment of the invention, a text processing tool, such as a Python script, is used for text conversion. For example, the integrated policy rule description data is converted into easily understandable policy explanation text. Specifically, the conversion is as follows: "All devices located in the 'high security domain,' with a security level of 'medium security level,' must access the network through the core router and are required to implement a multi-factor authentication (MFA) policy." The converted policy explanation text is: "To ensure network security, all devices located in the 'high security domain' (such as smart cameras) are assigned a 'medium security level.' When these devices access the network, they must connect through the core router and are required to implement a multi-factor authentication (MFA) policy to ensure that only authorized users can access the network."

[0134] Step S55: Collect confirmation feedback on the policy explanation text through the user interface to obtain the final network access control policy.

[0135] In this embodiment of the invention, a user interface tool, such as a web interface, is used to display the policy explanation text and collect user confirmation feedback. For example, the policy explanation text is displayed on the web interface, along with a confirmation button and a feedback button. After logging into the web interface, the user carefully reads the policy explanation text and clicks the confirmation button after confirming that it is correct. If the user has any questions or needs further information, they can click the feedback button to submit specific feedback. The user's confirmation and feedback information are collected to generate the final network access control policy. For example, if the user confirms that it is correct, the policy is deployed as the final network access control policy; if the user provides feedback, the policy is adjusted based on the feedback information and then submitted to the user for confirmation again.

[0136] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0137] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A method for authentication and network access control for FTTR, characterized in that, Includes the following steps: Step S1: Obtain the initial communication data of the device to be connected; An initial mapping table of device security levels is generated based on the initial communication data; Step S2: Collect the network environment context based on the initial mapping table of device security level to obtain network environment context data; generate authentication policies based on the initial mapping table of device security level and network environment context data to obtain a differentiated authentication policy set; Step S3: Perform virtual slice requirement analysis based on the initial mapping table of device security levels to obtain virtual slice configuration parameters; create micro-segmented virtual network slices based on the virtual slice configuration parameters to obtain the virtual network slice topology; Step S4: Obtain network behavior data during device operation; Behavioral baseline modeling is performed on network behavior data to obtain a device behavior baseline model; the differentiated authentication policy set is dynamically adjusted based on the device behavior baseline model to obtain an updated device security level table; Step S5: Perform policy visualization conversion based on the virtual network slice topology and the updated device security level table to obtain policy explanation text; The final network access control policy is obtained through user confirmation interaction based on the policy explanation text.

2. The authentication and network access control method for FTTR according to claim 1, characterized in that, Step S1 includes the following steps: Step S11: Obtain the initial communication data of the device to be connected, wherein the initial communication data includes the device MAC address, the device OUI vendor code and the device protocol handshake data; Step S12: Evaluate the manufacturer's trustworthiness based on the device's MAC address and OUI vendor code to obtain the device manufacturer's trustworthiness evaluation result; Step S13: Extract protocol interaction features from the device protocol handshake data to obtain the device protocol type and device port usage mode; Step S14: Quantify communication behavior characteristics based on device protocol handshake data to obtain device communication frequency and device data packet size distribution data; Step S15: Calculate the static security score of the device based on the device manufacturer's trustworthiness assessment results, device protocol type, and device port usage pattern. Step S16: Calculate the device dynamic security score based on the device communication frequency and device data packet size distribution data to obtain the device dynamic security score; Step S17: Map the equipment's static safety score and dynamic safety score to obtain the initial mapping table of the equipment's safety level.

3. The authentication and network access control method for FTTR according to claim 1, characterized in that, Step S2 includes the following steps: Step S21: Extract access time features based on the initial mapping table of device security levels to obtain device access time period distribution data; Step S22: Perform a signal strength scan at the device access location to obtain the signal strength at the device location; Step S23: Perform neighbor discovery protocol parsing on the current network topology to obtain a list of neighbor devices; Step S24: Conduct an environmental risk assessment based on the distribution data of device access time periods and the signal strength of device locations to obtain the network environment risk index; Step S25: Based on the initial mapping table of device security level and network environment risk index, perform authentication strength requirement analysis to obtain device authentication strength requirement data; Step S26: Match the authentication strategy with the neighbor device list based on the device authentication strength requirement data to obtain preliminary authentication strategy configuration data; Step S27: Optimize and adjust the initial authentication strategy configuration data to obtain a differentiated authentication strategy set.

4. The authentication and network access control method for FTTR according to claim 3, characterized in that, Step S27 includes the following steps: Step S271: Perform policy conflict detection on the preliminary authentication policy configuration data to obtain policy conflict point identifiers; Step S272: Prioritize the policy conflict point identifiers based on the initial mapping table of device security levels to obtain policy priority ranking data; Step S273: Allocate policy weights to the preliminary authentication policy configuration data according to the policy priority sorting data to obtain policy weight allocation data; Step S274: Use preset strategy optimization rules to fine-tune the strategy weight allocation data to obtain optimized strategy parameters; Step S275: Reconstruct the policy rules of the preliminary authentication policy configuration data based on the optimized policy parameters to obtain the reconstructed policy rule data; Step S276: Verify the validity of the reconstructed policy rule data to obtain the policy verification results; Step S277: Based on the policy verification results, generate the final policy from the reconstructed policy rule data to obtain a differentiated authentication policy set.

5. The authentication and network access control method for FTTR according to claim 1, characterized in that, Step S3 includes the following steps: Step S31: Divide the security domains according to the initial mapping table of equipment security levels to obtain equipment security domain grouping data; Step S32: Based on the device security domain grouping data, perform resource demand prediction to obtain virtual slice resource demand data; Step S33: Perform a network resource scan on the current network architecture to obtain available network resource distribution data; Step S34: Match the slice parameters with the virtual slice resource demand data and the available network resource distribution data to obtain the basic slice configuration parameters; Step S35: Enhance the security policy of the basic slice configuration parameters based on the differentiated authentication policy set to obtain the enhanced slice configuration parameters; Step S36: Send the enhanced slice configuration parameters to the network device through the virtualization platform interface to obtain the virtual network slice instantiation data; Step S37: Construct topology relationships on the virtual network slice instantiation data to obtain the virtual network slice topology.

6. The authentication and network access control method for FTTR according to claim 5, characterized in that, Step S32 includes the following steps: Step S321: Perform device count on the device security domain grouping data to obtain the number of devices in each security domain; Step S322: Estimate bandwidth requirements based on the number of devices in each security domain to obtain estimated bandwidth requirements data; Step S323: Allocate resources to the number of devices in each security domain using preset resource allocation rules to obtain basic resource quota data; Step S324: Adjust the resource reserve based on the estimated bandwidth demand data and the basic resource quota data to obtain the adjusted resource quota data; Step S325: Integrate the adjusted resource quota data to obtain virtual slice resource demand data.

7. The authentication and network access control method for FTTR according to claim 6, characterized in that, Step S322 includes the following steps: Step S3221: Classify the number of devices in each security domain by device type to obtain the distribution data of device types in the security domain; Step S3222: Use the preset bandwidth baseline value table to query and match the distribution data of security domain device types to obtain the baseline bandwidth requirement data of the devices; Step S3223: Multiply the number of security domain devices by the baseline bandwidth requirement data of the devices to obtain the initial bandwidth requirement estimate data; Step S3224: Adjust the initial bandwidth demand estimation data based on the preset redundancy coefficient to obtain the adjusted bandwidth demand data; Step S3225: Accumulate the adjusted bandwidth demand data for each security domain to obtain the estimated bandwidth demand data.

8. The authentication and network access control method for FTTR according to claim 1, characterized in that, Step S4 includes the following steps: Step S41: Collect network traffic during device operation using a traffic probe to obtain network behavior data; Step S42: Extract traffic features from network behavior data to obtain a device traffic feature dataset; Step S43: Compare and analyze the device traffic feature dataset based on the preset normal behavior template to obtain behavior deviation evaluation data; Step S44: Based on the behavioral deviation assessment data, reassess the security level of the differentiated authentication strategy set to obtain security level adjustment recommendation data; Step S45: Update the security level adjustment suggestion data according to the policy to obtain the updated device security level table.

9. The authentication and network access control method for FTTR according to claim 8, characterized in that, Step S45 includes the following steps: Step S451: Verify the validity of the security level adjustment recommendation data to obtain the validity assessment data of the adjustment recommendations; Step S452: Prioritize the adjustment suggestion effectiveness assessment data based on the initial mapping table of equipment security levels to obtain adjustment priority ranking data; Step S453: Extract policy change parameters from the security level adjustment suggestion data based on the adjustment priority sorting data to obtain the policy change parameter set; Step S454: Update the policy change parameter set by mapping it to a pre-defined security level update rule to obtain the updated device security level table.

10. The authentication and network access control method for FTTR according to claim 1, characterized in that, Step S5 includes the following steps: Step S51: Perform topology relationship parsing on the virtual network slice topology to obtain network slice relationship description data; Step S52: Perform security level mapping conversion based on the updated device security level table to obtain device security level description data; Step S53: Integrate policy rules based on network slice relationship description data and device security level description data to obtain integrated policy rule description data; Step S54: Perform text conversion on the integrated strategy rule description data to obtain the strategy explanation text; Step S55: Collect confirmation feedback on the policy explanation text through the user interface to obtain the final network access control policy.

Images