中文叫挑战/应答或质询/应答,是一种身份认证方式,具体流程为:
1. 客户向认证服务器发出请求,要求进行身份认证;
3. 认证服务器内部产生一个随机数,作为”质询值”,发送给客户;
4. 客户把质询值用预先配置的密码进行RC4加密作为应答;
5. 认证服务器将应答串与自己的计算结果比较,若二者相同,则通过一次认证;否则,认证失败;
6. 认证服务器通知客户认证成功或失败。
因为质询值是明文发送的,所以存在安全隐患。
Views: 18
因为使用同一个密码多次加密报文会降低加密数据的安全性,所以每个加密块都会使用唯一的密码加密。通常做法是用一个随机数或序列号或时间戳与密钥进行混合生成子密钥来加密数据。
如初始化向量是按特定规则生成的也可以称为nonce。
实际上复杂一点的情况初始化向量是由随机数和序列号,时间戳等共同组成的,可以是从左到右串起来,也可以是经过一定的运算。初始化向量中的随机数称为salt,比如AES-GCM中通常是4字节的Salt再加8字节的序列号。
根据TLS和IPsec中的定义初始化向量一般是12个字节组成,前4个是固定的salt,后8个是序列号。
在IPsec中Salt是在SA协商时生成的,在一个SA中不会改变,在TLS中Salt是在会话协商时生成的,在一个会话中不会改变。
因为解密的时候也需要IV,所以在不可靠连接(IPSec,DTLS,Wireguard,Wifi的WEP和WPA)加密时,IV都要附在密文前面一起发给对方。因为salt通常是固定的也可以也可以不在报文中发送,虽然序列号是可预测的,但是为了防止丢包(丢包后序列号就对不上了),在不可靠连接报文中发送IV仍然是必须的。
为了避免IV回绕可以执行密钥更新协议定时更新密钥。
以上只是一般做法,不同的算法和应用中IV的长度,生成方法,发送方式都会不同。
Views: 37
在IPSec中定期执行密钥更新是强制性的,比如华为防火墙上是每个小时或者每超过80GB流量就会更新一次SA。
但是TLS中并没有对密钥更新进行硬性规定,可能因为TLS通常用于短连接,对之方面要求低。TLS1.2及以前可以通过重协商(重新握手)来更换密钥,但这可能造成连接中断。TLS1.3中提供了专门的key update所握手消息进行密钥更新,但并没有规定密钥更新周期。
在RFC8446的5.5节提到对于一组密钥,AES-GCM可以对2400万个TLS记录进行安全的加密,一个TLS记录是16KB,也就是384GB的数据大小。看来日常环境中TLS并没有更新密钥的必要性,在nginx,firefox,chrome中我也没有发现有密钥更新的说明或相关配置。
在OpenVPN上可以使用–reneg-bytes和reneg-sec配置更新密钥的数据量和时间周期。不过OpenVPN并没有使用TLS的密钥更新机掉,OpenVPN自己实现了密钥管理,密钥交换,密钥重协商等,需要注意的是,它并不使用SSL握手最终确定的那些密钥,OpenVPN使用SSL握手仅仅是完成了连接者身份认证以及为后续的密钥管理,密钥交换,密钥交换以及控制信道构建一个安全的加密通道,完全类似于IKE的第一阶段协商。
另外在这个IETF提案中提到TLS1.3中自带的key update机制不是PFS(前向保密),所以重新定义了一个用于密钥更新的扩展,用于提供PFS的密钥更新。
在OpenSSL中可以调用SSL_key_update()函数执行TLS1.3的key update握手。
在QuicTLS(RFC9001)中对密钥更新做了更明确也更严格的要求,AES-123-GCM限制为2^23个数据包,1个数据包是1.5KB的话就是12GB的数据量。而且超过数据量后必须更新密钥或中断连接。Quic专门定义了一个key_updated事件,在密钥更新时会触发。QuicTLS并没有使用TLS1.3中的key update报文来更新密钥,而是使用Key Phase bit来进行密钥更新,而且QuicTLS要求两端同时进行密钥更新。在OpenSSL的ssl/quic/quic_record_util.c文件中定义了每种加密套件的AEAD用量限制,共定义了3种加客套件,分别由suite_aes128gcm,suite_aes256gcm,suite_chacha20poly1305这3个结构体表示。
参考:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits/
https://datatracker.ietf.org/doc/html/rfc8446
https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/
http://shanks.link/blog/2022/07/01/openvpn%E5%8D%8F%E8%AE%AE%E8%A7%A3%E6%9E%90%E4%B9%8B%E7%BD%91%E7%BB%9C%E7%BB%93%E6%9E%84%E4%B9%8B%E5%A4%96/
https://docs.openssl.org/master/man3/SSL_key_update/
https://caddyserver.com/docs/json/apps/http/servers/tls_connection_policies/client_authentication/ca/http/tls/renegotiation/
https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-quic-events/
https://autumnquiche.github.io/RFC9001_Chinese_Simplified/#6.6_Limits_on_AEAD_Usage
https://dev.to/shouhua_57/http3zhi-key-update-nod
Views: 9
WPA = IEEE 802.11i draft 3 = IEEE 802.1X/EAP + WEP( 选择性项目 )/TKIP
WPA2 = IEEE 802.11i = IEEE 802.1X/EAP + WEP( 选择性项目 )/TKIP/CCMP-128bit
另外WPA2支持802.11w管理帧保护和80.211r快速漫游而WPA不支持
有些设备支持WPA模式下的CCMP,GCMP,AES-256bit,WPA2模式下的GCMP,AES-265bit这些都是不符合标准的,会存在兼容性问题。
802.11-1997 wep 第一代802.11规范 1997年
802.11i draft3 wpa 2003年
802.11i-2024 wpa2 2004年
wpa3 2018年由Wi-Fi Alliance发布
参考:
https://blog.csdn.net/rheostat/article/details/7844704
Views: 6
叶脊网络架构英文叫Spine-leaf architecture,如下图所示:
Spine+Leaf两层设备的扁平化网络架构来源于CLOS网络,CLOS网络以贝尔实验室的研究人员Charles Clos命名,他在1952年提出了这个模型,作为克服电话网络中使用的机电开关的性能和成本相关挑战的一种方法。Clos用数学理论来证明,如果交换机按层次结构组织,在交换阵列(现在称为结构)中实现非阻塞性能是可行的,主要是通过组网来形成非常大规模的网络结构,本质是希望无阻塞。在此之前,要实现“无阻塞的架构”,只能采用 NxN 的 Cross-bar 方式。
多年以来数据中心一直采用三层网络架构进行网络部署,一个典型的企业分层局域网(hierarchical LAN)包括三层:
随着虚拟化技术的发展,节点虚机vm的数量增多,应用的部署方式越来越分布式,东西向流量( east-west-traffic)越来越大。这些流量需要被高效地处理,并且还要保证低的、可预测的延迟。而虚机互访需要通过层层的上行口,因此三层数据中心架构中的带宽成为了瓶颈。 三层架构的另一个问题是服务器到服务器延迟(server-to-server latency)随着流量路 径的不同而不同。
由于传统三层网络架构存在的问题,在2008年一篇文章A scalable, commodity data center network architecture,提出将Clos架构应用在网络架构中。2014年,在Juniper的白皮书中,也提到了Clos架构。
事实已经证明,基于 Clos 网络的 Spine-and-Leaf 架构(Clos network-based Spine-and-Leaf architecture)架构可以提供高带宽、低延迟、非阻塞的服务器到服务器连接。
叶脊架构主要有两个特点:
为了解决数据中心的另一个问题,即服务器/虚拟机的任意位置迁移,传统的解决方法是大二层网络,汇聚层和接入层交换机都工作在二层模式,但这样广播域太大,MAC地址表也太大,网络容易出现各种问题。新的解决方法是Overlay网络,在overlay模式下所有交换要工作在三层,都有IP地址,这样隔离了广播域。在后在这个spine-leaf架构的三层网络上再建一个大型虚拟二层局域网,就是overlay网络。目前数据中心主要使用VxLAN实现overlay网络。
中国电信提出的实现固移融合的新型城域网就借鉴了数据中心采用的叶脊网络架构和overlay网络,不过城域网中是用SRv6 over EVPN实现的overlay网络,比VxLAN更复杂一些。
数据中心里还有一项技术是网络虚拟化,其实就是NFV(只不过IT领域不常用NFV这个叫法,NFV主要是电信行业在叫)。比如VMware的网络虚拟化平台NSX,OpenStack Neutron。
Views: 11
根据国务院关于印发“十四五”数字经济发展规划的通知中指出,推动我国数字经济健康发展中,要优化升级数字基础设施,加快建设信息网络基础设施,建设高速泛在、天地一体、云网融合、智能敏捷、绿色低碳、安全可控的智能化综合性数字信息基础设施。
近年来互联网业务的迅速发展,网络流量呈井喷式增长,而宽带用户发展空间有限,规模竞争转向品质竞争、智家应用竞争。接应“十四五”数字经济发展规划,根据2B/2C/2H/各种业务的发展趋势,网络应能提供大容量、高带宽、低时延,网络弹性扩展,由封闭型转向开放型,并能适配云网标准化对接。
现有的传统IP三层网络设计的结构发展已经很成熟,随着业务的发展,传统三层网络架构自身存在一些无法突破的限制与弊端无法无限扩展,瓶颈不断涌现。而Spine-Leaf 城域叶脊拓扑网络组成的“胖树”结构,很好地解决了三层网络存在的各种问题。
现有城域网IP 网络一般由传输的三层架构组成,即核心—汇聚—接入。
核心层一般设置两台核心路由器,分别设置在区域DC 机房,上连ChinaNet 和CN2,下联业务接入层,主要为接收全球路由表,承载国际互联网、政企等流量;汇聚层即业务接入层主要由MSE(多服务边缘设备)组成,下联接入层设备OLT,家庭宽带和政企客户由此接入城域网,网络结构如图1 所示。
目前IP 城域网主要承载如下业务。
①上网业务:主要是家庭客户利用宽带网络访问互联网及享受一切相关的网络服务。
② VoIP 业务:利用Internet 或局域网来实现新型电话通信的IP 技术。
图1 传统IP 网络结构示意图
③ITV 业务:基于电信网并以电视为载体显示的双向通信手段。
④ 视频业务:家庭客户提供的视频业务主要是家庭视频监控。
⑤ IP VPN 业务:VPN 常用于大中型企业跨地域组网、同城互联、以及银行、福利彩票营业网点的组网。
采用三层架构的传统城域网对于南北向流量的业务形态非常有效,但随着业务的发展存在越来越多的问题。
(1)现有架构难以满足算力下沉带来的边缘云快速接入
现有IP 城域网难以满足边缘云泛在接入的需求,同时STN 网络由于设备性能不足无法实现公众客户访问边缘云需求;云网对接未标准化,对接方案复杂。
(2)难以满足东西向流量增长
传统城域网(包括IP 光宽城域网与STN)以南北向流量为主,而随着数据中心下沉、私有云等业务带来的东西向流量井喷,树形网络架构难以适应,需占用大量核心资源,无法无限扩展。
(3)带宽及设备利用率低
用户处理与带宽接口紧耦合,导致并发用户数低,带宽利用率不均;无法形成资源池,可靠性得不到提升,设备分散且数量多,更大容量设备引入条件不充分。
(4)多业务并发时带来的承载网设备session 不足
单用户多业务并发时往往由于原有设备性能无法升级,session 数不足导致用户业务掉线。
新型城域网采用积木式网络架构(如图2 所示),主要包含城域POD、云网POP、POD 出口功能区三大组件,可基于业务量进行灵活扩展,满足边缘云的快速接入及东西向流量增长。
(1)城域POD
城域POD 基于城域叶脊网络(Spine-Leaf)组建,每个POD 设置2 台Spine,下挂多对Leaf 设备,实现POD 内灵活扩展,Spine 和Leaf 设备对应STN 网络的ER 和B 设备。
Spine 用于实现高速流量转发与Leaf 设备间流量互访;Leaf 设备包含几种不同类型,包括A-Leaf、S-Leaf 与B-Leaf。A-Leaf 作为公众、政企与移动业务的接入点,实现固、移、云等业务综合接入。A-Leaf 可采用多种厂家的设备,标准化对接,满足异厂家组网需求。S-Leaf 作为核心/边缘DC 及云资源池的网络对接点,实现云资源池的标准化对接。B-Leaf 用于实现与外部网络的对接。Leaf 原则上不直连城域外的网元,访问外部网元通过Spine 转发。
(2)云网POP
云网POP 包括云业务网络出口网元和基础网络接入网元,云业务网络出口网元为互联网、专线、VPN 等网关设备;基础网络接入网元包括Leaf、PE、ASBR 等基础网络专线终结设备。云网POP 中通过部署Leaf,连接云业务网络网元,实现云资源池的标准化对接。
(3)POD 出口功能区
POD 出口功能区由Spine、Super-Spine(CR)、Leaf(ASBR)组成,与骨干网、业务平台/核心网等外部网络对接,实现差异化业务疏导。
Spine 定位实现国内流量疏导,不接受全球路由表。当一个区域设置多个POD 时,可通过Super-Spine(CR)进行汇聚。Super-Spine(CR)实现POD 间流量互访、政企互联网流量和国际流量疏导,接收全球路由表,通过细路由、策略路由等方式实现高质量、差异化和安全服务。Leaf(ASBR)定位实现跨域VPN 业务提供。
POD 出口功能区内,不同局址的2 台Spine 设备交叉上连不同局址的2 台城域CR,Leaf(ASBR)与CR/Spine设备可采用口字型互联,随业务量增大采用交叉上连。
①城域Spine-Leaf 架构,模块化灵活扩展
源于CLOS 网络的Spine-Leaf 架构,借鉴数据中心流量汇聚与横向弹性扩展优点,通过内部冗余实现任意两节点间无阻塞转发。
② 转控分离vBRAS,提升网络处理性能
宽带业务集约化处理,控制面负责用户的控制与管理,转发面实现用户数据报文转发,提升网络可靠性;提升新业务上线效率,能力进一步开放。
③SRv6/EVPN 协议统一,以极简协议构筑业网分离网络,SRv6 被誉为下一代转发技术,基于源路由转发模型,能够实现控制/转发协议统一,实现快速收敛与负载分担。
EVPN 实现二/三层业务承载的融合,从协议实现层面推进转控分离。
基于SRV6/EVPN 技术实现业务融合承载,使能自动化连接能力,实现跨域自动化开通、一跳入云。
④ 网络自动智能管控
城域新一代运营系统,实现城域编排、调度及控制。
以“十四五”数字经济发展规划为指导原则,采用基于Spine-Leaf 架构对传统IP 城域网进行改造,以解决运营商在天地一体、云网融合中建网的实际问题,实现固移、云网业务融合承载和灵活组网。
Spine-Leaf 架构应用在数据中心时,一般可采用新建模式。而对于现有的城域网络,则需考虑进行升级改造,充分利用现有资源。
①POD 区设置原则
设置POD 区时,应根据地理、行政区域、用户数及光缆网现状对POD 区进行规划。单POD 用户数不低于80万为基准。
业务量不大的地区,设置单POD,可考虑Spine 和CR 合设,实现统一网络出口。
在业务量大的地区,可设置多个 POD,CR 作为Super Spine 实现POD 间流量疏导。
② Spine-Leaf 设置原则
Spine-Leaf采用2级架构。1个POD区配置一对Spine设备,Leaf 设备原则上利旧升级STN-B 设备并进行适当补点。
③vBRAS 设置原则
vBRAS-CP 应部署在2 个核心DC,实现异地灾备,满足对全区光宽业务集中管理和控制。
按POD 集中部署转控分离vBRAS-pUP,旁挂Spine设备,实现宽带公众用户集中处理。vBRAS-pUP 设备部署时可采用1:1、1+1、N+1(应该指的是备份模式,1:1是一主一备,1+1是丙个设备负载均衡互为备份,N+1是N个设备负载均衡) 等模式,池内所有vBRAS-U设备工作在负载分担模式下,所有设备均承载业务。
④ 链路设置原则
各网元成对配置时,可采用口字型组网方式,实现链路负荷分担。
为了保证业务测试及部分业务割接,初期可考虑开通少量链路;当达到链路扩容门限时按需扩容。
以XX 市XX 运营商IP 城域网为例,将XX 市城域网升级改造为基于Spine-Leaf 架构的新型城域网。
XX 市XX 运营商承载约200 万带宽用户,根据如上建设原则,可将现有城域网规划为3 个POD 区。
各网元部署建议如下。
4.2.1 Super Spine
设置多个POD 的区域,可利旧原有城域网核心层设备CR 兼作Super Spine,疏导POD 间固网宽带流量,并作为统一出口上联至163;可利旧现网STN 核心层设备,汇聚4G/5G 等流量。后期结合带宽流量,Spine 可按需直连163 和省级ER。
4.2.2 B-leaf
现网的ASBR 可利旧作为B-leaf,口字形对接STN 核心层,并利旧原有与城域网核心层、CN2 网络的链路,承载 L2/L3 VPN 业务,实现POD 间组网和跨域组网接入。
4.2.3 Spine
每个城域POD 均设置一对Spine 设备,上联至Super Spine 与城域ER,用于实现高速流量转发与Leaf 设备间流量互访、汇聚移动网流量;每个POD 区内的STN B 设备上联割接至Spine 设备,各POD 间互通流量通过Super Spine 进行疏导。
同一个POD 的两台Spine 设备安装在不同的DC 机房内,具备异地容灾及负荷分担。
4.2.4 A-leaf
利旧现网STN B 设备(需具备SRV6 功能),实现宽带接入网设备和基站设备等接入,实现固网和移动网合并为一张新型城域网。
4.2.5 vBRAS-CP
在两个核心DC 节点分别部署一套转控分离池化vBRAS,每个POD 区的Spine 设备以10G 链路上联CP面的2 对Sleaf,实现1:1 热备和虚实共管,实现光宽等业务集中管理和控制,具备异地容灾、弹性扩容能力。
4.2.6 vBRAS-pUP
在每个POD 节点部署一套vBRAS-pUP 池,旁挂Spine设备;vBRAS-pUP 设备数量根据POD 内流量或Session 需求制定,需考虑流量转发需求、CGN 板卡、特通板卡等,可利旧现网较空闲的MSE 设备升级为vBRAS-pUP。
每个POD 节点的vBRAS-pUP 池可与Spine 设备同节点部署,减轻网元互联的传输压力。
4.2.7 OLT 上连
城域POD 内,OLT 双归至一对ALeaf;若传输资源不足时也可采用单归至一台ALeaf 进行跨板聚合。
仍以XX 市XX 运营商为例,现有用户结构如表1 所示。
表1 用户结构
链路带宽测算公式如下。
重要链路应配置如表2 所示。
表2 重要链路测算表
根据建设原则及链路测算,网络设备数量应配置如表3 所示。
表3 网络设备配置数量
根据表3 配置,XX 市改造后的新型城域网络结构如图3 所示。
图3 XX 市新型城域网目标网络结构示意图
采用“积木式”架构、模块化组件,可实现多业务融合承载、多厂商异构组网。以现有STN 网为基础,建设新型城域网,构建架构弹性扩展、云网标准化对接,业务快速提供的新型城域网络,统一承载固网宽带、无线宽带、政企专线、入云等云网融合业务,保障用户固定和无线接入体验一致性,降低建网成本,提升运营效率。
个人总结:
– vBRAS-CP一个城域网部署一对在核心DC,两个设备异地灾备部署
– vBRAS-UP按POD集中部署在汇聚机房,也就是与Spine同机房部署,vBRAS-UP可以和A-Leaf由同一台设备充当
– 一个POD一般覆盖1-2个行政区/县
– 汇聚机房可以由附近的DC,边缘云机房充当或者独立的机房
– 以上只是一种可行的组网方案,不同的域域网根据情况会有自己的组网方案
转发:
https://m.fx361.com/news/2022/0917/14354409.html
Views: 184
Views: 28
网络功能虚拟化(Network Functions Virtualization,NFV)是一种关于网络架构的概念。我们平时使用的x86服务器由硬件厂商生产,在安装了不同的操作系统以及软件后实现了各种各样的功能。而传统的网络设备并没有采用这种模式,路由器、交换机、防火墙、负载均衡等设备均有自己独立的硬件和软件系统。NFV借鉴了x86服务器的架构,它将路由器、交换机、防火墙、负载均衡这些不同的网络功能封装成独立的模块化软件,通过在硬件设备上运行不同的模块化软件,在单一硬件设备上实现多样化的网络功能。
NFV可以把链路层以上的功能都用纯软件实现。
NFV套用了企业软件开发的理念
– NFV Infrastructure,NFV基础设施
包括所需的硬件及软件。对应的是物理服务器,KVM,Docker
– VNF
Virtual Network Functions,指虚拟机及部署在虚拟机上的业务网元、网络功能软件等。
对应的是微服务中的一个服务
– MANO
Management and Orchestration,NFV的管理和编排。包括VIM,VNFM及NFVO,提供对VNF和NFVI资源的统一管理和编排功能。
对应OpenStack和K8S。
NFV可以实现部分链路层及以上层次的虚拟化,网络硬件只保留通道和二层交换功能。但是如果用NFV实现转发面的功能必然会带来性能下降和延迟提高,软件实现的东西(又套了一层虚拟化)怎么也比不上ASIC芯片的性能,而且NFV是集中化的,远离实际的业务位置造成延迟增加,只有一些对性能不敏感的功能才适合NFV化。
NFV的定义和SDN有重合之处,SDN分硬件SDN和软件SDN,软件SDN是要求控制面功能软件化的(实际上就是虚拟化),而NFV涵盖了软发面和控制面的虚拟化。只不过NFV强调的是虚拟化和微服务化,而SDN强调的是集中化。在实际中也是NFV和SDN一起使用,起到相辅相成的作用。
Views: 41
参考:
https://datatracker.ietf.org/doc/rfc2409/
https://en.wikipedia.org/wiki/Pseudorandom_function_family
https://thiscute.world/posts/practical-cryptography-basics-4-secure-random-generators/
NIST SP 800-90A R1,2015年更新
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
Views: 1
AD/AEAD算法要慢于纯加密算法。
Views: 8