今日共有8篇文稿更新,涉及5个area里的7个WG

INT

6man

1. draft-ietf-6man-addr-assign-02

  • Title: Clarification of IPv6 Address Assignment Policy
  • Authors: Brian E. Carpenter(brian.e.carpenter@gmail.com), Suresh Krishnan(suresh.krishnan@gmail.com), David Farmer(farmer@umn.edu)
  • Summary: 本文主要讨论了关于IPv6地址分配政策的规定。首先,文稿指出了IPv6地址空间大部分被国际互联网工程任务组(IETF)所保留,并且对于未来可能需要更多的全球唯一单播地址空间,应当通过“IETF审查”来确定。此外,为了更好地管理IPv6地址空间,应采用“IETF审查”过程取代之前的“IEG批准”的审批级别。同时,作者也对RFC 1881进行了更新,将流信息从“历史”改为“IETF”。最后,文中强调了安全方面的考虑,因为任何形式的基于地址的安全措施都需要仔细审查。 总结:本文提出了更严格地评估IPv6地址分配的新流程,并明确了新的审批级别。同时也澄清了RFC 1881的相关问题,使其更加符合当前的需求和规范。
  • Diff: 该文档明确了IPv6地址空间管理政策,增加了对IPv6地址空间分配审批级别的更新和澄清,以及对RFC 1881的相关信息进行了调整。主要区别在于: 1. 更新了IPv6地址分配审批级别,从“IE S G批准”升级为“IETF审查”,以适应更严格的分配流程。 2. 增加了对RFC 1881的说明,指出它仍然是当前有效的,并且与之前的“遗留”标签不一致。 3. 对RFC 7249中的第二段进行了修改,强调了未来需要从保留的125位可选地址空间中进一步分配全球唯一标识符地址空间。 4. 强调了严格的安全考虑因素,要求在实施任何形式的地址基安全时仔细审核分配机制。 5. 确认了IANA的注册程序,将“登记制度”部分改为“IETF审查”。 6. 指出了两个IPv6地址空间命名上的差异,建议通过使用更加统一的名称来消除这些混淆。 总的来说,该文档对IPv6地址分配过程进行了改进,强化了对非例行地址分配的认可,同时对一些基本信息进行了澄清和调整。

OPS

opsawg

1. draft-ietf-opsawg-secure-tacacs-yang-01

  • Title: A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)
  • Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Bo Wu(lana.wubo@huawei.com), Guangying Zheng(zhengguangying@huawei.com), Zitao Wang(wangzitao@huawei.com)
  • Summary: 本文主要介绍了TACACS+协议的一个增强版,即TACACS+overTLS版本,它支持使用TLS协议进行网络管理。该模块定义了用于配置TACACS+客户端的相关数据模型,包括TACACS+服务器列表、证书和PSK等,并提供了认证、授权和计费等功能。此外,还讨论了安全性考虑,如限制读写操作以保护敏感数据。最后,提出了与已有的YANG模块和标准的兼容性问题。 总的来说,本文是关于如何在基于TLS的网络环境中实现对TACACS+协议的管理和配置的一份详细指南。它不仅定义了新的数据节点和特性,还提供了详细的指导原则和最佳实践。对于需要在TLS环境下部署TACACS+客户端的开发者来说,这份文档提供了丰富的参考资源。
  • Diff: 该文档定义了一个用于终端访问控制器访问控制系统加性(TACACS+)客户端的YANG模块,它对原来的RFC 9105进行了扩展和改进。主要区别包括: 1. 新增了TACACS+ over TLS 1.3的数据模型支持,允许设备使用TACACS+服务器进行集中身份验证、授权和计费。 2. 提供了新的数据节点,如客户端证书、客户端私钥等,以增强TACACS+客户端的安全性和可配置性。 3. 定义了新的加密算法和支持外部预共享密钥(PSK),以便实现多台设备之间的通信。 4. 增加了网络管理安全性考虑,比如在传输层协议TLS 1.3上的安全要求,并允许用户配置不同的Cipher Suite组合。 5. 对于已知的认证方法,提供了更多的配置选项,从而更好地满足不同场景的需求。 总的来说,该文档的主要目的是为TACACS+提供一个更加全面且可定制化的管理平台,以支持集中式的身份验证、授权和计费需求。

RTG

lsvr

1. draft-ietf-lsvr-applicability-15

  • Title: Usage and Applicability of Link State Vector Routing in Data Centers
  • Authors: Keyur Patel(keyur@arrcus.com), Acee Lindem(acee.ietf@gmail.com), Shawn Zandi(szandi@linkedin.com), Gaurav Dawra(gdawra.ietf@gmail.com), Jie Dong(jie.dong@huawei.com)
  • Summary: 本文讨论了在数据中心网络中使用BGP Link-State Shortest Path First (BGP-SPF)扩展的技术应用。文稿主要从以下几个方面进行了介绍: 1. 引言:介绍了BGP-SPF技术的应用场景,特别是其在Clos或Fat-Tree等非阻塞拓扑中的应用。 2. 推荐阅读:推荐了相关参考文献和文稿,以加深读者对BGP-SPF技术的理解。 3. 常见部署场景:描述了一个简单的数据中心网络部署情景,并解释了为什么需要BGP-SPF技术。 4. BGP-SPF技术适用性:分析了BGP-SPF技术的优点,如简化L3路由和操作、加速下层网络收敛等。 5. BGP-SPF技术到Clos网络的适用性:详细说明了如何利用BGP-SPF技术解决Clos网络中的问题,例如避免多路径故障、加快收敛速度等。 6. 非CLOS/FAT Tree拓扑的适用性:讨论了当采用其他拓扑时,BGP-SPF技术仍然可以发挥作用的情况。 7. 非转发表节点能力:强调了BGP-SPF技术能够适用于不直接参与转发表的数据中心控制器。 8. BGP策略的适用性:探讨了如何将BGP-SPF技术应用于现有的BGP策略中,包括聚合和前缀过滤等高级功能。 9. IANA考虑:未提出新的安全考虑,但指出了BGP-SPF技术的现有安全性考虑。 10. 安全性考虑:概述了BGP-SPF技术的安全性,没有引入任何新的安全特性。 11. 结论:总结了BGP-SPF技术的优势及其在数据中心网络中的广泛应用前景。
  • Diff: 本文档讨论了在基于Clos或Fat-Tree数据中心网络中的BGP(边界网关协议)使用Link State Vector(LSV)路由扩展技术时的适用性和可行性。 主要内容如下: 1. 引言:概述了对BGP-SPF技术的利用以及Clos和Fat-Tree等常见数据中心网络拓扑结构的描述。 2. 推荐阅读:列出了有关数据中心网络和数据中心网络拓扑结构的信息源,包括数据中心路由器、BGP、BGP-SPF等。 3. 典型部署场景:介绍了在数据中心内服务器之间使用Clos网络进行互联的情况。 4. BGP-SPF技术应用的合理性:分析了BGP作为路由协议创建的数据中心网络下层和上层网络的优点,并指出其缺点,如无法创建布线图、限制边缘反射器/控制器的使用、BGP最佳路径算法不支持动态改变、等。 5. BGP-SPF技术在Clos网络中的应用:详细说明了如何将BGP-LS SPF SAFI应用于Clos网络中,并指出了与传统BGP和IPv4/IPv6地址族的关联性。 6. 非CLOS/FAT树拓扑的应用:描述了BGP-SPF技术在非CLOS/FAT树等其他拓扑结构中的应用情况。 7. 非转接节点能力:讨论了BGP-LS SPF SAFI可用于参与BGP SPF拓扑但不用于转发流量的能力。 8. BGP策略应用:现有BGP策略可以结合BGP-LS SPF SAFI一起使用,以实现一致性的路由计算。 9. IANA考虑:没有提出新的IANA注册请求。 10. 安全考虑:没有引入新的安全考虑因素。 总体而言,该文档提供了BGP-SPF技术在数据中心网络中的具体应用示例和理论依据,为数据中心管理员提供了一种简化的方法来管理复杂的数据中心网络。

SEC

lamps

1. draft-ietf-lamps-cms-kyber-06

  • Title: Use of ML-KEM in the Cryptographic Message Syntax (CMS)
  • Authors: PRAT Julien(julien.prat@cryptonext-security.com), Mike Ounsworth(mike.ounsworth@entrust.com), Daniel Van Geest(daniel.vangeest@cryptonext-security.com)
  • Summary: 这一文档详细介绍了用于加密密钥的模块学习误差(ML-KEM)标准。文中详细解释了如何在密码消息语法(CMS)中安全地传输密钥和数据,以及使用ML-KEM算法进行认证数据和认证封装数据的传递。 主要特点包括: - 定义了使用ML-KEM算法的CMS实体,如接收者、发送者等。 - 基于哈希函数(SHA-256)的安全实现。 - 提供了三种不同的安全性级别,分别是ML-KEM-512、ML-KEM-768和ML-KEM-1024。 同时,也给出了具体的实施指南,并强调了对ML-KEM私钥、密钥、密文等关键元素的安全保护措施。最后,提出了针对不同参数设置下的ML-KEM的安全考虑和建议,以确保其安全性。 总的来说,《使用模块学习误差(KL)作为底层密钥封装机制》提供了关于如何安全传输密钥的信息,有助于理解其工作原理并指导实际应用。
  • Diff: 由于原文档已经被删除,我无法提供一个200字左右的中文总结。

pquip

1. draft-ietf-pquip-pqt-hybrid-terminology-05

  • Title: Terminology for Post-Quantum Traditional Hybrid Schemes
  • Authors: Florence D(florence.d@ncsc.gov.uk), Michael P(michael.p1@ncsc.gov.uk), Britta Hale(britta.hale@nps.edu)
  • Summary: 本文是关于互联网上的传统和量子计算安全解决方案的文档。它定义了用于传统和量子计算结合的协议的概念,并提出了术语来描述这些解决方案,以便其他文档可以使用一致的语言。主要讨论了以下内容: 1. 定义了传统的非量子算法(如RSA、ECDH)和量子计算安全算法(如Shor算法),以及它们之间的关系。 2. 提出了混合方案的概念,即在两种算法之间选择一种或多种算法组合在一起。例如,可以使用一个传统的密钥交换方案与一个量子密钥交换方案进行组合。 3. 描述了使用这两种类型的算法的安全性和兼容性问题,特别是在面临可能影响量子计算机性能的风险时。 4. 强调了使用这种组合的好处,例如通过增加对量子攻击的保护以减少风险。同时指出需要继续研究如何实现这种安全性的最佳实践。 总结来说,该文稿提出了一种新的框架来解决传统和量子计算相结合的问题,旨在为不同应用提供灵活的选择,从而提高安全性。然而,由于目前缺乏成熟的量子计算设备,这仍然是一个未完成的任务。
  • Diff: 是关于介绍和定义使用传统和量子算法进行混合组合的协议的一种技术术语。该文档提供了一种语言来描述将传统和量子算法结合在一起的协议。 与旧版本相比,主要区别在于: 1. 新版本更全面地讨论了如何在不同的协议、标准和组织之间保持一致性和清晰度,以确保对这些术语的理解一致性。 2. 在术语定义方面,增加了更多关于加密元素(如公钥、私钥、密文、共享秘密和签名值)及其在混合协议中的作用的信息。 3. 引入了复合协议的概念,这是一种可以实现多个不同类型的算法之间的安全性的协议。例如,它可以包括一个基于量子算法的单个公钥交换方案和一个基于传统的公钥交换方案。 4. 对于那些寻求定义特定类型混合法的解决方案,提供了更通用的指导方针,允许使用仅传统或仅量子算法。 总的来说,新版本的标准化文档为未来协议设计者提供了更加一致且清晰的语言来表达和讨论此类混合协议的概念和特性。

WIT

httpapi

1. draft-ietf-httpapi-api-catalog-07

  • Title: api-catalog: a well-known URI and link relation to help discovery of APIs
  • Authors: Kevin Smith(kevin.smith@vodafone.com)
  • Summary: 这篇英文标准文档主要定义了"api-catalog"这个新的"well-known URI"和"api-catalog"的关联关系,用于帮助发现并使用发布API。它还提出了API Catalog文档的格式、如何利用这个URI以及如何与现有API管理框架集成等技术建议。 总结起来, 这个规范性文档主要提供了实现API自动发现和使用的新机制, 提供了一个统一的API元数据存储位置, 并为开发人员提供了一种方便的方法来查找和使用API。它还指出了在使用API时需要注意的一些安全性和隐私方面的考虑。
  • Diff: 摘要 本文定义了名为“api-catalog”的常熟URI和链接关系,以促进外部第三方访问给定组织或个人公开的API端点及其目的、用途以及每个API的使用政策。API端点应列出在"/.well-known/api-catalog"位置。 文稿引入了一个新的链接关系,即“api-catalog”。该关系指定了一个目标资源,该资源代表从API发布者处获取的一系列可用API列表。API目录文档应包含到API端点的超链接,并推荐包含API元数据,如API版本信息、OpenAPI规范定义等。 API目录文档格式包括但不限于:JSON对象表示法(RFC9264)、APIs.json文件、API书签、REST描述语义描述(RESTdesc)等。API目录文档还应包含到API端点的超链接,以便支持机器(和人类)对API的使用。 操作方面,为了自动发现并使用API,API目录文档需要提供关于API提供商API端点的信息和与API的链接。API目录文档格式可能具有多种形式,由API提供商选择。 安全性方面,TLS应用于所有请求,确保API目录文档不被篡改。API目录文档应该定期更新以处理任何错误或遗漏。 API管理框架可以利用api-catalog作为其输出之一,以促进API元数据的发现和展示,但不应将其视为替代现有API发现机制的工具。

tcpm

1. draft-boucadair-tcpm-rst-diagnostic-payload-10

  • Title: TCP RST Diagnostic Payload
  • Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Tirumaleswar Reddy.K(kondtir@gmail.com), Jason Xing(kerneljasonxing@gmail.com)
  • Summary: 本文主要讨论了TCP重传段(RST)中的诊断信息格式。通过定义一种包含故障码、原因描述和企业标识符等参数的诊断段,使得接收端能够获取到重传事件的原因信息,从而实现网络故障快速定位的目的。此外,还提到了ICANN可能会创建一个新的记录表来存储这个新的诊断段的编码。总的来说,这是一个为提高网络故障诊断效率而设计的规范性文件。
  • Diff: 该文档是关于在TCP重传段(Reset Segment)中添加诊断信息的一个建议。主要区别在于: 1. 标题:从原来的"TCP Reset Diagnostic Payload"改为现在的"TCP RST Diagnostic Payload"。 2. 主要内容变化: - 改变了文档名称和标题,使其更加简洁明了。 - 删除了一些冗余内容,如"AC Glue for VPN Models"等信息。 - 将一些非必需的规范性注释删除。 - 删除了对旧版本部分术语和定义的引用。 3. 保留了关键信息: - 指出了新的格式和编码方式,包括使用CBOR序列化。 - 提供了几个例子来说明如何使用这个新格式。 - 定义了新注册的"RST Diagnostic Payload CBOR Key Values"和"TCP Failure Causes"的新注册项。 4. 取消了某些功能细节,如"Reason Code"和"Description"参数可能被省略的情况,并减少了强制性的参数数量。 总的来说,新版本更注重精简和简化,同时保持了其核心目的——为TCP重传段提供一个明确的诊断信息格式,以帮助终端用户更好地理解网络连接中断的原因。

Unknown

Unknown

1. draft-dejong-remotestorage-24

  • Title: remoteStorage
  • Authors: Michiel B. de Jong(michiel@michielbdejong.com), F. Kooman(fkooman@tuxed.net), Sebastian Kippe(sebastian@kip.pe)
  • Summary: 本文为互联网标准草案,描述了远程存储服务协议,允许客户端应用通过web浏览器内部连接到不同域名的数据存储服务器。它支持存储、检索和删除文档,以及列出文件夹,并基于Bearer令牌提供访问控制。 该协议基于HTTPS、CORS和Bearer令牌,采用树状结构表示数据存储中的文件和子文件夹,允许在特定权限下进行读写操作。文中详细介绍了请求、响应码、版本化、跨域资源共享(CORS)等问题,同时定义了相关的网络接口和属性等。此外,还提到了安全性考虑,如避免中间人攻击,保护用户的隐私等。 总的来说,本文为构建安全可靠、易于使用的分布式数据存储提供了技术规范。
  • Diff: 以上文档是关于远程存储协议的最新版本,主要描述了一个基于HTTPS、CORS和Bearer Token的接口,允许客户端应用与托管在不同域名的数据存储服务器通信,从而避免数据存储提供商必须同时扮演数据存储服务提供者的角色。以下是该标准的主要区别: 1. 支持HTTP/1.1和HTTP/2传输层编码方式。 2. 通过Bearer Token提供了访问控制,将权限细分为模块级别和水平(rw)模式。 3. 允许使用预发请求(OPTIONS)来预览PUT、DELETE操作。 4. 提供了对Range头部的支持,允许客户端获取部分资源。 5. 客户端不需要发送Authorization头即可使用Bearer Token。 总体来说,此标准进一步简化了远程存储的交互流程,并引入了一些新的特性以提高安全性和服务效率。