【每日文稿】2024-11-21
今日共有20篇文稿更新，涉及7个area里的17个WG
ART
jmap
- Title: JMAP File Storage extension
- Authors: Bron Gondwana(brong@fastmailteam.com)
- Summary: 本文是关于在JMAP协议中添加对文件节点的支持。文件节点是一个特殊的数据类型，用于存储和管理各种类型的文件。它包含一个名为id的唯一标识符、一个可能为空的parentId属性，以及可以作为Blob的数据。文件节点还可以支持多种操作，如set（设置）、get（获取）等。此外，还定义了一些相关的安全性考虑和修改建议。 总的来说，本文为JMAP协议提供了对文件节点的支持，并提出了安全性和性能优化的建议。
mimi
- Title: An Architecture for More Instant Messaging Interoperability (MIMI)
- Authors: Richard Barnes(rlb@ipv.sx)
- Summary: 本文介绍了更即时消息互操作性(MIMI)工作组定义的一套协议，用于使不同消息提供商能够互相兼容。这些协议允许用户在多个提供商之间进行即时消息交互。 主要介绍如下： 1. 概述：讨论了MIMI的工作原理和目标。 2. 过渡到具体架构：概述了各协议之间的关系和它们如何协同工作以提供一个综合的即时消息应用体验。 3. 协议功能介绍：详细描述了各个层次的功能，如端对端安全、事件处理、房间状态同步以及消息传递等。 4. 实体识别与认证：说明了参与者（客户端、服务器）的身份标识及认证机制。 5. 安全考虑：探讨了端到端加密、传输层安全性等方面的安全性要求。 6. 注册密钥：描述了发送者签名所使用的公私密钥对，并强调了该过程中的身份验证问题。 7. 安全策略：解释了授权规则及其动态变更。 总之，MIMI旨在解决当前消息服务领域存在的多提供商、跨设备连接等问题，通过统一的消息格式和一致的安全框架，为用户提供一致的即时消息体验。
- Diff: 以上新的英文标准文档（MIMI）定义了一套协议，允许不同消息提供者互相兼容，为用户提供即时消息服务。这个架构分为四个部分：总体框架、房间状态、协议交互以及参与者和标识符认证。 总体框架包括了用户、客户端、服务器等角色，以及它们之间的通信方式；房间状态包含用户参与情况、客户端参与情况以及授权策略等内容；协议交互涉及了各个参与者的操作，如添加或移除成员、改变权限等；参与者和标识符认证则保证了参与者能够合法地执行相关操作。 相比旧版的英文标准文稿，新的文档增加了更多的具体细节，并且更加详细地描述了整个系统的交互流程和功能。此外，它还提供了具体的示例代码，使得开发者可以更好地理解和实现这些协议。总的来说，新的文档更为详尽，更易于理解与使用。
wimse
- Title: The Contextualized REST Architecture
- Authors: Atul Tulshibagwale(atultulshi@gmail.com)
- Summary: 是IETF发布的一份关于HTTP架构和缓存的文档。本文主要讨论了如何在HTTP服务器上实现一个缓存，以减少每个请求携带大量数据的情况，从而提高网络性能。文稿详细介绍了这个概念，并提供了一些示例来说明它的应用。 该文档强调了Context Cache（CC）的概念，它是一个独立存储的数据结构，用于存储与HTTP请求相关的上下文信息。通过使用CC，HTTP客户端可以在每次请求时只携带需要的信息，而不需要每次都传递整个上下文。同时，CC还支持创建或删除CC项的功能，使得HTTP服务器可以根据实际需求共享不同的Cache。 此外，文稿还提到了一些设计注释，包括CC的编码方式、CC项之间的依赖关系等。这些都为实现更高效、更灵活的HTTP架构提供了可能。 总的来说，《Contextualized REST》提出了一个新的解决方案，旨在解决HTTP架构中的问题，使网络服务更加稳定可靠。虽然其具体实施细节还需进一步研究和完善，但其理念和方法已经引起了广泛的关注和兴趣。
INT
dtn
- Title: DTN Bundle Protocol Security (BPSec) COSE Context
- Authors: Brian Sipos(brian.sipos+ietf@gmail.com)
- Summary: 本文主要定义了一个用于使用基于可序列化的加密对象 (COSE) 算法在包协议安全 (BPSec) 原始块中的安全上下文中实现完整性验证和保密性的安全上下文。该上下文可以包含公钥相关信息，以及特定于包类型的附加块数据，这些都可以通过标准方式编码到 BPSec 安全块中。 另外，还定义了针对 COSE 的证书认证环境，并描述了如何使用 COSE 进行多证书使用以支持公共密钥基础设施 (PKI) 的部署。此外，还提供了实施建议、安全性考虑和参考文献等。
- Diff: 这个文档详细定义了使用COSE算法在Bundle Protocol Security (BPSec)安全块中的应用方法，以及如何使用这些算法创建和处理包含公共密钥信息的安全上下文。它还提供了一个统一的COSE安全性上下文标识符，并定义了一些参数，以支持包完整性、保密性和一致性消息之间的转换。 相较于旧版文档，新版本的主要区别在于： 1. 定义了一个单一的安全上下文用于BPSec的完整性与机密性块。这样可以简化编码工作并节省代码点。 2. 增加了对PKIX证书的支持，允许使用来自证书授权机构（CA）的证书为BP节点签发证书。 3. 提供了COSE认证模式（AAD）的一个新的定义，即包括了所有块作为AAD的一部分，而不是仅限于主块或目标块。 4. 规定了加密层和解密层的范围，限制了某些类型的操作，例如不信任的端实体证书或未识别的关键材料。 5. 针对特定协议进行了补充说明，如BPSec块重建威胁等。 6. 引入了一种基于COSE的AAD表示形式，使其更加通用且便于处理。 总的来说，新版本通过优化数据结构、简化代码实现，为实现BPSec安全特性提供了更强大的工具。
intarea
- Title: ICMP Extension Header Length Field
- Authors: Ron Bonica(rbonica@juniper.net), hexiaoming(hexm4@chinatelecom.cn), Xiao Min(xiao.min2@zte.com.cn), Tal Mizrahi(tal.mizrahi.phd@gmail.com)
- Summary: 本文主要讨论了ICMP扩展头部长度字段的问题。由于ICMP扩展结构没有长度字段，除非其他数据可以在ICMP消息中推断出其长度外，否则必须将其视为最后一条项。 本文还定义了一个长度字段来表示ICMP扩展结构的长度，当提供长度信息时，接收者可以使用它解析ICMP消息。具体来说，接收者可以根据ICMP扩展结构后的长度信息确定之后条目开始的位置。此外，本文还提到了对ICMP扩展结构长度字段进行标准化的必要性，并介绍了IANA对相关工作的影响。 总的来说，本文旨在解决ICMP扩展结构长度问题，并为相关标准制定提供参考。
- Diff: 以上新版本的英文标准文稿定义了ICMP扩展结构中的长度字段，当提供长度信息时，接收者可以使用该信息来解析ICMP消息。这个新的长度字段用于表示ICMP扩展结构的总长度，包括所有选项和可选填充，但不包括ICMP扩展头部。此长度字段要求在没有额外数据的情况下设置为零，以避免传递无关信息。另外，ICMP扩展结构必须是IP包的最后一项。 与旧版标准文稿不同的是，ICMP扩展结构不再具有长度字段。因此，在没有其他数据支持的情况下，如果ICMP扩展结构的长度不能从其他数据中推断出来，那么它必须是最后一个项目。此外，旧版文档仅适用于BGP路径属性协议，并且不包含对IPv6的支持。相比之下，新版本文档引入了对IPv6的支持，并包含了对BGP路由属性协议的支持。此外，它还提出了关于IPv6地址和子网掩码的新建议，以及对多部分ICMP消息的支持。
OPS
opsawg
- Title: Link-Layer Types for PCAP and PCAPNG Capture File Formats
- Authors: Guy Harris(gharris@sonic.net), Michael Richardson(mcr+ietf@sandelman.ca)
- Summary: 该文档主要介绍了PCAP和PCAPNG文件格式中用于保存网络捕获的LINKTYPE值的IANA注册规则。通过创建新的IANA组，如“PCAP库”组和“PCAPNG链接类型列表”，建立了新的LINKTYPE值注册机制。这些值被分配给不同的范围，以支持各种操作系统的网络捕捉需求。文中还讨论了安全注意事项，并指出了在处理PCAP或PCAPNG格式捕获时可能遇到的安全风险。总的来说，该文档为不同操作系统环境下的网络数据记录提供了统一的数据描述方式。 总结：本文是关于PCAP和PCAPNG文件格式中的LINKTYPE值的注册规则与指导，旨在解决因使用这些格式进行网络数据捕获而可能导致的安全问题。通过建立一个新的IANA组并制定规范来管理LINKTYPE值，可以确保数据的标准化和安全性。
- Diff: 该新版本的英文标准文稿为（链接层类型对PCAP和PCAPNG捕获文件格式），是关于网络数据包中使用的“LINKTYPE”值的IANA登记。其主要内容包括： 1. 创建了新的IANA组来管理PCAP和PCAPNG的LINKTYPE值。 2. 制定了LINKTYPE的政策分配，如初始值、优先级等。 3. 提供了一个初步的LINKTYPE表，每个表项都指明了LINKTYPE的名称、数值以及描述。 与旧版本相比，主要区别在于： 1. 增加了更多的LINKTYPE值，并且将一些历史上的LINKTYPE值进行了更严格的定义或弃用。 2. 提供了更多关于LINKTYPE的指导信息和建议。 3. 强调了私有用途LINKTYPE值不应泄露给使用它们的目的地，并推荐使用官方值。 总体而言，这个新版本加强了对LINKTYPE值管理和指导方面的规范性，以防止无意中的私有用途泄露问题。同时，也提供了更多详细的文档参考信息和示例说明，使得后续使用者可以更好地理解这些LINKTYPE值的意义和作用。
RTG
cats
- Title: CATS Metrics Definition
- Authors: Kehan Yao(yaokehan@chinamobile.com), Hang Shi(shihang9@huawei.com), Cheng Li(c.l@huawei.com), Luis M. Contreras(luismiguel.contrerasmurillo@telefonica.com), Jordi Ros-Giralt(jros@qti.qualcomm.com)
- Summary: 本文定义了用于计算感知流量导向（CATS）的几个计算指标，这些指标包括：Level 0（L0）为原始测量值；Level 1（L1）通过分类汇总L0来实现标准化；Level 2（L2）是最终标准化值。为了保证数据的有效性，提出了三种层别，并且详细说明了它们在编码和分布中的处理方式。 总结文稿主要分为以下几个部分： 1. 引言部分概述了CATS框架和其基本原理。 2. 概述了不同级别的度量标准以及每种级别所包含的具体信息。 3. 描述了每种级别的计算指标如何进行统一抽象和归一化，以简化复杂性和提高准确性的平衡。 4. 分析了各层级之间度量级的比较，建议使用Level 2作为首选，因为它具有更高的可扩展性和稳定性。 5. 讨论了安全、IANA考虑等其他方面的问题，但未给出具体解决方案。 总的来说，本文提出了一种将原始流量数据转换为更高层次数据的分层模型，旨在优化网络资源分配并支持服务实例的选择。该模型有助于确保各个层面数据的有效性和可用性，从而支持高效的计算感知流量导向决策过程。
- Diff: 新版本的英文标准文稿定义了三种层次的计算指标来支持网络服务提供商在不同服务实例之间进行流量导向。相比旧版本的英文标准文稿，主要有以下区别： 1. 对于原始（L0）级别的指标，不再提供具体物理单位和格式信息，而是直接以“数字”形式表示。 2. 对于分类（L1）级别的指标，通过将原始指标进行归类汇总为多个维度来实现抽象化处理，例如网络、计算和存储等，并将这些指标归一化到一个分数范围内。 3. 对于完全标准化（L2）级别的指标，使用单一值对所有原始指标进行归一化处理。这样可以简化指标传输和管理复杂性，避免每个服务实例都收集大量指标。
idr
- Title: Advertisement of Segment Routing Policies using BGP Link-State
- Authors: Stefano Previdi(stefano.previdi@gmail.com), Ketan Talaulikar(ketant.ietf@gmail.com), Jie Dong(jie.dong@huawei.com), Hannes Gredler(hannes@rtbrick.com), Jeff Tantsura(jefftant.ietf@gmail.com)
- Summary: 该文档主要讨论了在BGP协议上发布段路由政策（SR Policy）信息的方法。通过扩展BGP协议中的链路状态属性，可以携带SR Policy信息，包括每个SR Policy的候选路径信息和其支持的SID列表。这种机制使得外部组件能够收集到网络上的SR Policy状态信息，从而实现对网络资源的有效利用以及服务的高效配置。 该文档还详细介绍了如何将这些信息封装为BGP-LS（链路状态更新）属性，并使用其中的信息进行路由计算、重新优化等操作。此外，它还定义了一些子TLV来表示SR Policy的状态和约束，以帮助管理组态SR Policy。 总之，该文档提出了一种新的方法，用于从头端节点到控制器的BGP-LS消息中发布SR Policy状态信息，这有助于改善网络管理和提供更有效的服务规划。
- Diff: 以上新版本的英文标准文稿，主要内容如下： 1. 引言：介绍SR Policy架构以及其在多区域或多AS网络中的应用。 2. 在BGP中携带SR Policy信息：定义了新的“Link-State NLRI”类型和与之关联的TLV，用于携带SR Policy状态信息。 3. SR Policy候选路径NLRI类型：描述了该类型的格式、标识符、颜色等属性。 4. SR Policy候选路径描述符（Descriptor）：定义了SR Policy候选路径描述符结构及其相关参数。 5. SR Policy状态TLV：定义了各个状态TLV及子TLV，用于报告SR Policy状态信息。 6. 程序规范：详细介绍了如何使用这些TLV进行SR Policy信息的发布。 7. 管理性考虑：讨论了对外部组件收集SR Policy状态信息的重要性。 8. IANA考虑：描述了用于不同目的的特定TLV编码方案。 9. 安全考虑：提出了可能的安全威胁并给出了相应的安全措施。 10. 贡献者：列出参与编写此文档的主要作者。 11. 参考文献：列出了参考文献列表。 总的来说，相比于旧版，新版本更加关注于SR Policy的信息传播方式，并引入了新的技术来支持SR Policy的动态管理，如SR Policy候选路径的识别等。同时，增加了对安全性方面的考虑，并提供了一套统一的TLV编码方案，方便后续的研究和发展。
pce
- Title: Carrying SR-Algorithm Information in PCE-based Networks.
- Authors: Samuel Sidor(ssidor@cisco.com), Alex Tokar(atokar@cisco.com), Shaofu Peng(peng.shaofu@zte.com.cn), Shuping Peng(pengshuping@huawei.com), Andrew Stone(andrew.stone@nokia.com)
- Summary: 本文是关于在点路由（segment routing）中的路径计算元素协议（PCEP）中携带端到端路径计算算法信息的一个草案。这是为了支持灵活的路径计算算法，以适应不同场景和约束条件。例如，可以使用不同的路径计算算法来提供低延迟路径。 此外，头端路由器也可以发送特定的路径计算算法作为约束消息给主节点路由器，以便收集或故障排查目的需要。还提出了一个新TLV用于指示端到端路径计算算法的约束。这个机制同样适用于IPv6段路由（IP-Routing）。 总之，该草案提供了端到端路径计算算法的信息传递机制，允许端节点和主节点之间的路径计算算法配置，以及对路径计算算法进行约束的功能。这将有助于提高网络的灵活性和可扩展性，并增强端节点与主节点之间的通信效率。
- Diff: 该文档提出了一种方法来通知内嵌路由器关于每段SID所使用的SR算法信息，以及通过在PCE对象中编码特定的SR算法约束给PCE。同时引入了新的TLV类型用于承载这些信息，例如SR-ERO和SRv6-ERO。 相较于旧版本，新版本的主要区别在于： 1. 在PCEP协议中新增了支持SR算法的功能。 2. 提供了包含SR算法信息的新TLV格式。 3. 规定了如何向头部端路由器传递这些信息，并设置了特定的标志位以确保路径计算过程符合指定的SR算法约束。 总的来说，这一改动使内部网关协议能够更准确地管理其使用SR算法的信息，并有助于实现更加精确、有效的网络配置。
savnet
- Title: Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements
- Authors: Dan Li(tolidan@tsinghua.edu.cn), Jianping Wu(jianping@cernet.edu.cn), Lancheng Qin(qinlc@mail.zgclab.edu.cn), Mingqing(Michael) Huang(huangmq@mail.zgclab.edu.cn), Nan Geng(gengnan@huawei.com)
- Summary: 这篇英文标准文档主要讲述了关于源地址验证(intra-domain SAV)在多域网络中的问题、现有机制以及未来改进的需求。文中指出现有的源地址验证机制存在准确性低和操作复杂度高的问题，尤其是针对主机侧或客户侧路由器的问题。这些问题导致了误判，例如不能准确阻止合法来源的数据包或者允许伪造源地址的数据包。因此，提出了对新源地址验证机制的一些要求：自动适应动态网络的变化；提高数据包验证的准确性；支持增量部署，并且能够在收敛过程中尽量减少错误判断。 总的来说，该文稿是为了解决现有源地址验证机制中存在的问题而提出的建议，旨在推动新的源地址验证技术的发展。
- Diff: 新的文档提供了现有内网源地址验证机制的差距分析，描述了基本问题，并定义了未来技术改进的要求。 主要内容如下： 1. 基于源地址验证（SAV）和多层防御架构的概念被提出以实现内网源地址验证。当SAV未在所有源宿主机部署时，这种多层防御架构有助于通过防止或缓解网络内部源地址欺骗来增强整个互联网的SA效果。 2. 介绍现有的内网源地址验证机制。例如，BGP38/BGP84规则用于在访问网络边界路由器、客户侧路由器和外部AS边界路由器处进行进制过滤。此外，严格uRPF也适用于针对某些业务场景的内网源地址验证。 3. 分析指出现有内网源地址验证机制存在不准确验证或高操作开销的问题。因此，它们将错误地阻止合法源地址（即不精确验证）或错误地允许伪造源地址（即不精确验证）。具体来说： - 对于使用不同网络运营商管理的多个访问网络，在部署SAV之前需要强制要求所有访问网络同步部署SAV。 - 进口网络中的SAV规则通常由作为AS的一部分的内部AS自身生成。如果内部AS之间没有协作，则可以自行创建这些规则。 - 这些机制要么需要高度的操作性开销，要么在某些情况下限制了准确性。 4. 该文档总结了存在的关键问题，并定义了未来的技术改进需求。例如，自动更新、准确验证、增量/部分部署以及快速收敛等。 总的来说，相较于旧版，新版本更加专注于差距分析，提出了当前内网源地址验证机制的关键问题，并强调了未来的需求。它还详细讨论了如何解决这些问题，以提高效率并提供必要的安全保证。
spring
- Title: YANG Data Model for SRv6 Base and Static
- Authors: Syed Kamran Raza(skraza@cisco.com), Sonal Agarwal(sagarwal12@gmail.com), Xufeng Liu(xufeng.liu.ietf@gmail.com), Zhibo Hu, Iftekhar Hussain(ihussain@infinera.com), Himanshu C. Shah(hshah@ciena.com), Daniel Voyer(daniel.voyer@bell.ca), Hani Elmalky(helmalky@google.com), Satoru Matsushima(satoru.matsushima@gmail.com), Katsuhiro Horiba(katsuhiro.horiba@g.softbank.co.jp), Jaganbabu Rajamanickam(jrajaman@cisco.com), Ahmed Abdelsalam(ahabdels@cisco.com)
- Summary: 本文主要描述了YANG数据模型中的SRv6基础和静态模块。包括定义了一些关键概念，如SRv6类型、基础SRv6模型、静态应用模型等。这些模型是用于管理SRv6网络的基础框架，可以与其他相关的SRv6技术模型一起使用。本文还提供了相关的通知事件，并指出了当前的YANG规范版本。总的来说，该文档为构建一个基于SRv6的子系统提供了一个基本框架。
- Diff: 该文档描述了一个YANG数据模型，用于Segment Routing IPv6（SRv6）的基础和静态配置管理。这是为了增强其他SRv6技术模型（如ISIS、OSPFv3、BGP、EVPN、Service Chaining等）而设计的。主要内容包括： 1. 定义了SRv6基础和静态应用所需的共同类型，如Locator名称、LOCATOR长度、LOCATOR块长度、LOCATOR节点长度、SID功能值、SID功能值保留类型、端点类型、头端行为类型等。 2. 描述了SRv6基础架构，包含了配置项、操作状态和通知事件。这些信息将结合在一起形成SRv6网络的完整层次结构。 3. 定义了静态配置，允许用户为特定定位器上的本地SID分配静态配置，并指定具体的结束行为类型以及相关的配置细节。 4. 提供了SRv6-静态配置模型，可以用来为SRv6网络中的某个定位器设置静态配置，并定义了一些关于路由表查找、路径转发等方面的信息。 5. 模型还包括一些关键的协议状态提取规则，以提供必要的状态信息，覆盖所有的“配置”和“不配置”属性节点。 总的来说，这个新版本的主要区别在于增加了SRv6基础和静态应用的具体实现细节，丰富了模型的适用范围，使模型能够更好地支持不同类型的SRv6部署需求。
SEC
ipsecme
- Title: Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP)
- Authors: Daniel Migault(mglt.ietf@gmail.com), Tobias Guggemos(guggemos@nm.ifi.lmu.de), David Schinazi(dschinazi.ietf@gmail.com), J. William Atwood(william.atwood@concordia.ca), Daiying Liu(harold.liu@ericsson.com), Stere Preda(stere.preda@ericsson.com), Maryam Hatami(maryam.hatami@mail.concordia.ca), Sandra Cespedes(sandra.cespedes@concordia.ca)
- Summary: 本文主要讨论了Internet Key Exchange（IKE）v2协议中的Header Compression（头压缩）特性，以及如何通过IKEv2协议来实现。首先，本文定义了两个不同的消息类型：HCP_SUPPORTED和HCP_UNSUPPORTED，并详细介绍了这两种消息包含的信息。然后，本文指出了在IKEv2协议中可以使用的Header Compression属性及其可能的选择范围。此外，还讨论了如何注册和管理这些属性的各个方面。 总的来说，本文为如何使用Header Compression特性提供了详细的指导，使得IKEv2协议更加灵活和高效地处理网络通信。
- Diff: 本文是关于IPsec协议中的Header Compression Extension（HCE）的一个新版本，提供了新的属性和注册流程来管理这种压缩功能。以下是主要内容的简要概述： 1. 新版本增加了对HCE的支持，定义了更多的属性类型，并允许用户指定范围内的值。 2. 注册流程也有所变化，现在有更详细的描述和额外的细节，以确保正确的属性被正确地注册到系统中。 3. 对于IKEv2通知消息类型的分配也有了一些更新。 4. 安全性考虑方面，文档强调了在处理大量资源请求时需要谨慎对待的情况，以及如何避免这种情况的发生。 总的来说，新版本引入了更多的灵活性、详细性和安全性，使得IKEv2中的Header Compression更加易于管理和配置。
- Title: Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security
- Authors: Valery Smyslov(valery@smyslov.net)
- Summary: 是关于IPSec安全协议的一种扩展，其中引入了新的Preshared Key（预先共享密钥）机制来提高安全性。在传统的IKEv2协议中，Preshared Key只在建立初始IKE安全联盟时使用，并且其安全性依赖于静态的PPK（预共享密钥）。然而，在最近发布的[RFC8784]中，提出了一种新方法，允许将Preshared Key用于保护整个IKEv2安全联盟。 这个改进主要通过在IKEv2的中间交换中使用Preshared Key来实现。这个交换可以同时支持多个密钥交换，并且可以用来创建额外的IPSec安全联盟和重新配置现有安全联盟。这种做法避免了传统上需要两轮循环（一次是IKEv2的安全联盟，另一次是原始密钥对），从而简化了密钥管理流程。 总结来说，该文档讨论了如何利用预先共享密钥增强IKEv2的安全性，特别是当密钥交换需要在不同时间点进行时。它提供了一个通用的方法，可以在不同的时间和场景下应用Preshared Key机制，以提高网络通信的安全性和可靠性。
- Diff: 本文是关于混合预共享密钥（Preshared Key, PPK）在IPSec v2协议版本中的应用，特别是用于保护IPsec通信免受量子计算机攻击。与之前的RFC8784版本相比，主要有以下不同： 1. 新增加了使用PPK（Post-Quantum Preshared Key）的概念，允许在IPSec SA建立阶段预先使用PPK来实现对初始IKE SA的安全保护。 2. 在创建新的IPSec SA时，可以考虑使用PPK，而不需要先删除现有的IKE SA和重新创建。 3. 在使用PPK的情况下，必须确保PPK的选择和分配是可配置的，并且应有相应的策略支持。 4. 对于未使用的PPK，必须避免在IKE SA初始化过程中将其重新分配给其他目的。 5. 安全方面，结合了IPSec v2协议和IKEv2协议的现有安全机制，如QR保护，以提高安全性。 总的来说，该标准文档扩展了使用PPK的方法，使得在IKEv2协议版本中提供了更好的防护措施，尤其是针对量子计算机攻击的情况。它为后续的发展预留了空间，包括使用PPK进行进一步的加密或重新密钥交换等。
rats
- Title: An EAT-based Key Attestation Token
- Authors: Mathias Brossard(mathias.brossard@arm.com), Thomas Fossati(thomas.fossati@linaro.org), Hannes Tschofenig(Hannes.Tschofenig@gmx.net), Henk Birkholz(henk.birkholz@ietf.contact)
- Summary: 本文定义了一个基于Entity Attestation Token（EAT）的证据格式，用于实现对密钥的验证。该文档首先介绍了相关术语，包括Root of Trust（RoT）、Attestation Key（AK）、Platform Attestation Key（PAK）、Key Attestation（KA）、Identity Key（IK），以及它们之间的关系和作用。 然后详细描述了Key Attestation Token（KAT）的结构，它包含了证明私钥持有状态的属性。同时，还讨论了平台认证令牌（PAT）的作用和如何将其与KAT组合在一起形成复合文件的概念。 接着，本文列举了几种可能的例子来说明这种数据格式的实际应用场景，例如在使用TLS协议时进行安全链路验证。 最后，文稿总结了这个数据格式的安全性和可扩展性，并指出了需要考虑的一些方面，如安全性、架构设计等。 总的来说，本文提供了一种新的证据格式，旨在提高密钥验证的安全性和有效性。
- Diff: 本文档定义了一个基于实体认证令牌（EAT）的证据格式用于关键验证。与旧版相比，新版本的主要区别在于： 1. 提供了基于EAT的证明持有凭据的格式。 2. 分离了平台认证和关键认证的角色，使得前者更具有权限，后者则不直接涉及到密钥认证代码。 3. 使用Nonce机制来确保平台认证和关键认证的完整性。 4. 简化了平台认证凭证（PAT）生成流程中的关联过程，包括使用CBOR数据格式进行编码。 5. 保留了之前的KAT/平台凭证（PAT）结合方式，并添加了新的绑定机制，即通过哈希算法将KAK上的公钥映射到PAT上的nonce字段。 6. 在安全考虑部分引入了一些最新的概念和建议，如基于CBOR的CDDL数据格式等。 总的来说，新版本简化了架构设计，加强了安全性，并且在保持现有功能的基础上增加了更多灵活性。
WIT
core
- Title: Update to the IANA CoAP Content-Formats Registration Procedures
- Authors: Thomas Fossati(thomas.fossati@linaro.org), Esko Dijk(esko.dijk@iotconsultancy.nl)
- Summary: 本文是关于CoAP内容格式注册程序更新的一个文档。主要目的是修改CoAP内容格式注册程序中的FCFS部分，减少恶意篡改相关注册的可能性。新的注册流程将从FCFS转换为专家审查（专家检查：FCFS+），以增加注册过程的安全性。此外，还提到了一些具体的注册要求和安全考虑，如使用CoP认证、媒体类型、参数名称等。总体来说，本文旨在加强CoAP内容格式注册的安全性，并且通过更严格的审核来防止潜在的恶意行为。
- Diff: 该文档更新了CoAP Content-Format注册程序，以减少由于恶意操纵导致的错误的可能性。其主要内容包括： 1. 更新了CoAP Content-Format注册程序，将原来的“First Come First Served（FCFS）”部分调整为“专家审查（Expert Check：FCFS+）”，使得检查变得更加复杂和专业。 2. 在FCFS范围内的0-255代码点被更改为“专家审查（Full）”，区别于10000-64999范围中的“专家审查（Expert Check：FCFS+）”。 3. 修改了在0-255范围内的专家审查政策，加入了对1-byte代码点空间有限性的评估。 总的来说，该文档通过增加额外的审查步骤来提高CoAP Content-Format注册的安全性，并且减少了因恶意操作而造成的潜在风险。
nfsv4
- Title: Reporting of Errors via LAYOUTRETURN in NFSv4.2
- Authors: Thomas Haynes(loghyr@gmail.com), Trond Myklebust(trond.myklebust@hammerspace.com)
- Summary: 本文提出了一种新的机制来解决网络文件系统版本4(NFSv4)中当存储服务器重启时，客户端无法通知其错误的情况。在传统的处理方式下，如果客户端在重启后遇到错误，它将不再恢复被写入的数据文件，并且必须重新读取整个数据文件以进行修复。然而，本文提出了一个新的解决方案，即通过使用一个特殊的匿名状态ID（anonymous state ID），该状态ID表示所有零位，来代替LAYOUTRETURN结构中的layout stateID。这样，即使客户端报告了错误，服务器也不会重新读取整个数据文件，而是根据错误类型进行相应处理。此外，服务器还应确保在取消请求之前释放write intent，并在文件恢复完成之后开始执行数据文件的重建过程。这样，即使服务器没有及时回收其他写入意图，也能够正确地处理数据文件。最后，本文还讨论了一些安全和IANA方面的考虑。
- Diff: 本文档提出了在NFV4.2协议中扩展的一个功能，即允许客户端更新文件元数据信息以避免数据文件的重新映射过程。当服务器重启时，客户端可以仍然修改数据部分。在恢复阶段启动期间，服务器和数据服务器一起恢复状态（哪些文件打开、最后修改时间等）。如果客户端没有在数据文件上遇到错误，则可以恢复这些状态，避免重新映射数据文件。然而，在任何错误情况下，客户端都无法向服务器报告错误。因此，服务器必须假设文件需要重新映射。这一变更使得客户端不必报告其对数据文件的更改。 此外，文档还讨论了在metadata server重启后，如何处理与新的LAYOUTRETURN相关的任何问题，以及如何防止因重新映射而丢失的状态。这些变化旨在解决客户端无法正确报告其数据文件错误的问题，并且通过将LAYOUTRETURN中的layout stateid设置为零来实现这一点。这种做法有助于服务器准确地修复受影响的文件。同时，文档也强调了在配置上的一些细节，如如何响应不匹配当前镜像实例的情况，以及如何在resilver过程中阻止或强制所有I/O操作。 总的来说，这个扩展的功能使NFSv4.2协议更加灵活和健壮，解决了某些客户可能在使用某些功能时遇到的问题。它通过提供一个方法让客户端直接通知服务器发生错误，从而避免重新映射数据文件，使得整个系统更加高效和稳定。
scone
- Title: Throughput Advice Object for SCONE
- Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Dan Wing(danwing@gmail.com), Tirumaleswar Reddy.K(kondtir@gmail.com), Sridharan Rajagopalan(sridharan.girish@gmail.com), Luis M. Contreras(luismiguel.contrerasmurillo@telefonica.com)
- Summary: 本文主要讨论了如何通过网络速率限制政策来管理网络流量。首先，介绍了通过网络速率限制政策（Throughput Advice）发现网络速率限制策略的方法，以及这些信息被应用到应用程序的行为调整上。 文稿还详细分析了不同类型的速率限制政策对象，如单色码（Single Rate, Three-Color Marker）、双色码（Two Rates, Three-Color Marker），并解释了它们在实际部署中的应用场景和使用方法。 此外，还探讨了速率限制政策的参数定义、作用机理等，并给出了具体的例子和示例。最后，对速率限制政策对象进行了注册和描述，并提到了一些参考文献。
IRTF
cfrg
- Title: The OPAQUE Augmented PAKE Protocol
- Authors: Daniel Bourdrez(d@bytema.re), Hugo Krawczyk(hugo@ee.technion.ac.il), Kevin Lewi(lewi.kevin.k@gmail.com), Christopher A. Wood(caw@heapingbits.net)
- Summary: (Draft-irtf-cfrg-opaque-18) 是由国际互联网工程工作组(IETF)的一个研究小组(CFRG)起草的一份文档。该文档定义了 OPAQUE 协议，这是一个基于 OPRF 的增强密码验证协议，用于提供客户端服务器之间的安全密码认证和互操作性。OPAQU 提供了对预计算攻击的抗性，并且可以隐藏客户端密码。此外，它还支持后向保密性和隐秘存储功能。 OPAQU 有三个核心组件：一个公开伪随机函数（OPRF），一个密钥恢复机制，以及一个认证交换（AKE）协议。这个文档详细描述了 OPAQUE 实例的实现细节，包括客户端凭据的生成、编码和存储，以及在线认证阶段的信息交互。 总的来说，OPAQU 是一个能够提高密码协议安全性、支持客户端服务器间的安全通信并允许应用程序安全地将凭据存储在服务器上的增强密码验证协议。它的设计使得它可以与多种 AKE 协议无缝集成，并且可以在未来加入更多技术来进一步提升其安全性。
- Diff: 摘要 本文档描述了OPAQUE协议，这是一种增强后的密码认证授权密钥交换（aPAKE），在不依赖PKI的情况下支持客户端/服务器设置中的身份验证，并提供前向保密性以及隐藏密码给服务器的能力。该协议允许应用程序增加离线字典攻击难度，通过迭代哈希或其他键伸缩方案来提高安全性。此外，OPAQUE协议是可扩展的，允许客户端安全地将任意应用数据存储在服务器上仅使用其密码。 相比于旧版本的英文标准文稿，主要内容有： 1. 新增了一个额外的OPEAK实例基于[TripleDH]。 2. 增加了关于配置和实施考虑方面的讨论。 3. 提出了更详细的实现安全措施建议。 4. 对于输入验证、OPRF密钥扩展等进行了进一步说明。 5. 在要求注释中增加了更多关于OOPRF和AKE协议细节的注释。
Unknown
Unknown
- Title: The "doi" URI Scheme
- Authors: Pierre-Anthony Lemieux(pal@sandflow.com)
- Summary: 本文主要介绍了doi uri scheme这一标准的详细信息，以及它如何被替换为doi-uri-scheme。此外，还提供了对相关参考文献和作者地址的介绍。文稿总结了doi uri scheme作为最初的URI规范，但在后来被取代为doi-uri-scheme。文稿提醒读者，虽然此文档可以用于参考，但不应该将其作为正式引用材料或在其他地方使用。同时，也呼吁读者就任何反馈提供建议。
- Diff: 以上新版本的英文标准文稿主要在文档标题、版本日期等方面进行了更新，并删除了部分冗余信息。总体而言，该标准文档是对现有“doi”URIScheme规范的一个补充和扩展，新增了关于DOI名解析过程的规定，以及对安全性和IANA注册的相关考虑。 相较于旧版，新版的主要区别在于： 1. 增加了对DOI名解析过程的详细说明。 2. 对DOI名的安全性进行了更详细的讨论。 3. 提供了DOI名解析的永久性注册请求，以便于后续维护。 4. 没有提及DOI名的规范化问题。 5. 删除了一些不再适用的信息，如关于DOI名称表示为代码点的不一致性描述。 总的来说，新版标准化文件对于当前使用的“doi”URIScheme提供了更多的细节和指导，更加全面地考虑到了其安全性和应用范围。
- Title: Conceptual Model for Digitized Emblems
- Authors: Bill Woodcock(woody@pch.net), Brian Haberman(brian@innovationslab.net), Casey Deccio(casey@deccio.net)
- Summary: 本文主要讨论了数字化标识符（digital emblem）的概念模型，包括其概念、角色和关系，以及其数据模型、功能要求等。主要提出了以下几点： 1. 数字化标识符是一种电子版的保护标记，用于描述资产并提供法律或类似规范框架下的附加信息。 2. 发布机制使实体能够通过分布式网络发布数字标识符，而验证机制允许实体对它们进行验证。 3. 数字标识符的数据模型由一系列相关记录组成，并与特定的分发机制相绑定。这些记录定义了标识符的属性及其与其他资产的关系。 4. 数字标识符的功能需求包括绑定实体到资产、认证实体的身份、验证实体对标识符的认证等。 5. 标识符的安全性考虑也提到了一些安全措施，例如加密传输、身份认证等。此外，还有对使用过程中的伦理和责任的强调。 总的来说，该文档为创建一个通用的基于现代技术的数字化标识符提供了基础概念模型，它不仅有助于促进不同组织之间的信息共享，还可能为未来的国际法和区块链技术的发展铺平道路。
- Diff: 该文档描述了基于数字标记符的概念模型，这些标记符用于表示保护资产以满足国际法律要求。主要内容包括： 1. 讨论了使用概念模型的协议架构、角色和关系。 2. 描述了如何通过数字标识符来绑定资产到实体或实体类，并提供了详细的描述，以便验证和展示。 3. 提出了数据模型，包括描述实体特性的记录集及其联系信息，以及如何通过一系列渠道（如认证、显示等）将信息传递给验证者。 4. 对IANA考虑事项进行了概述，指出了可能存在的分配机制和安全措施。 5. 阐述了安全性考虑，指出在使用任何协议时都需要谨慎对待，并强调了使用现代加密技术的重要性。 6. 分析了贡献者名单，包括起草人和参与者。 7. 确定了规范性引用文献，表明它们的有效性和可用性。 8. 详细列出了作者地址，说明了他们的联系方式。 9. 告诉读者应该参考哪些文档，并简要概述了修订历史。 总的来说，本文档旨在简化数字化标示符的设计，使其更加通用且易于理解。它为设计和实施此类协议奠定了基础。与旧版相比，它专注于提供一种更简洁的方法来表示和传输法律保护，从而减少了人为干预的可能性。