【每日文稿】2024-12-19
今日共有10篇文稿更新，涉及5个area里的10个WG
INT
6man
- Title: IPv6 Parcels and Advanced Jumbos (AJs)
- Authors: Fred Templin(fltemplin@acm.org)
- Summary: 本文提出了IPv6包裹和高级大包（AJ）的概念，为提高性能、效率和完整性提供了基础。文中提出了一个新的网络层协议，称为IPv6包裹，它允许单个包包含多个传输层协议数据单元。同时，还定义了另一种网络层协议——高级大包，它可以包括大小从非常小到非常大的单一段的所有可能大小。这两种协议为改进性能、效率和完整性提供了必要的核心组件，并鼓励使用更大的最大传输单元（MTU）。此外，本文提出了一个新的延迟容许网络（DTN）链路模型，支持延迟/中断容忍，特别适合移动应用领域。 总的来说，该文档旨在引入新的封装技术来满足当前互联网发展的需求，以及未来可能出现的需求，从而提供更有效的服务。
- Diff: 在最新版本的文档中，IPv6 Parcels and Advanced Jumbos（AJs）是IPv6协议中的一个扩展概念，用于支持多段数据传输。它包含多个运输层协议分段，并允许将它们封装为单独的IPv6包进行传递。此外，还引入了Advanced Jumbo（AJ）服务来提供更完善的端到端服务，包括多大小段传输、延迟容忍等特性。 与旧版标准文稿相比，主要有以下区别： 1. 新版增加了关于Delay Tolerant Networking（DTN）模型的支持，以适应移动性应用。 2. 采用了新的延时容限网络（DTN）链接模型，支持多种大小的单个段传输。 3. 提出了高级大块（AJ）的概念，可以提供比基本jumbogram更大的单段传输能力。 4. 在使用Aerospace Overlay Multilink Network Interfaces（OMNI）的情况下，网络层和下一层之间的协议栈操作可能被替代。 5. 增加了对自动延长路由优化（AERO）和Overlay Multilink Network Interface（OMNI）的考虑，以支持跨多个网络节点的连续增长。
dnssd
- Title: DNS Multiple QTYPEs
- Authors: Ray Bellis(ray@bellis.me.uk)
- Summary: 本文主要探讨了DNS协议中接收多个相关资源记录（RR）在单个DNS响应中的问题。通过引入新的扩展机制，即MQTYPE-Query和MQTYPE-Response选项，允许客户端请求额外的DNS记录类型，并且这些类型的查询可以在不增加传输费用的情况下被分批发送给服务器。同时，本文讨论了处理这些问题时可能遇到的安全性和安全性考虑。最后，提出了对IANA注册新值的需求。 总的来说，本文提出了一种新的方法来解决多QTYPE的问题，为客户端提供了更多灵活性的同时也增加了攻击的可能性。它有助于提高DNS系统的性能，但同时也带来了一些潜在的风险。需要进一步研究如何平衡这种风险与性能提升之间的关系。
- Diff: 以上新版本的英文标准文稿主要描述了DNS客户端请求额外资源记录（RR）类型的机制。相较于旧版文档，主要区别如下： 1. 支持在查询中包含多个QTYPE类型，增加了数据传输量和可能的安全风险。 2. 通过MQTYPE-Query选项将这些额外QTYPE类型作为扩展机制的一部分，增强了安全性并减少了中间件的攻击可能性。 3. 提供了一种安全可靠的方式向DNS服务器请求多个RR类型，同时保留了现有的安全性特性。 4. 指出了对MQTYPE-Response选项的特殊处理方式，确保不出现错误或无效响应，以及如何合并不同类型的回答以生成最终答案。 5. 增强了客户端解析能力，包括如何发现缺失的RR值、正确地组合RR，并遵循现有DNS协议的要求。 总体来说，新版本提供了更加安全且有效的多QTYPE请求机制，旨在减少潜在的安全威胁，并与现有安全措施保持兼容性。
OPS
netmod
- Title: Extensions to the Access Control Lists (ACLs) YANG Model
- Authors: Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com), Samier Barguil(samir.barguil@gmail.com), Mohamed Boucadair(mohamed.boucadair@orange.com), Qin Wu(bill.wu@huawei.com)
- Summary: 本文讨论了对增强型访问控制列表（ACL）模型的一些限制，并提出了一种扩展的ACL结构，以解决这些问题。该架构将ACL定义为一组过滤规则的用户指定集合，而不是原始模型中的规则列表。 本文还提供了用于管理网络操作的模块和例子，包括IPv4、IPv6扩展头部等。此外，还指出了一个保持模块与设备无关性的概念，并提到了改进的标识符注册系统。最后，它定义了一个关于ICMP类型、IPv6扩展头和其他可能需要支持的模块的信息检索点，以便进行进一步的工作。 总之，增强型ACL结构有助于简化ACL配置，改善可管理和维护性，并提供更多的灵活性和功能来满足不同的需求。
- Diff: 该文档是关于增强访问控制列表（ACL）模型的改进，包括扩展了ACL结构、定义了新的IA 名称来管理网络设备和网络元素之间的关系，并讨论了增强ACL模块的功能性需求。 与旧版相比，主要区别在于： 1. 增强了ACL结构以更好地支持网络配置和管理。 2. 定义了新的IA命名空间用于定义网络设备和网络元素之间的关系。 3. 引入了新的安全考虑和安全性措施。 4. 提供了新的资源注册点和模板以简化IA维护过程。 总的来说，文档旨在解决现有ACL模型的一些局限性，并提供更灵活、可管理且易于维护的ACL结构。通过引入新的IA和附加功能，可以进一步提高网络的安全性和灵活性。
opsawg
- 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+）客户端的数据模型。该数据模型支持集中化的身份验证、授权和计费服务，允许用户通过多种机制登录到设备，如命令行界面或Web用户界面。该模型由两部分组成：一个用于管理TACACS+服务器的模块，以及一个用于配置TACACS+客户端的模块。 具体来说，这个数据模型提供了以下功能： 1. 支持TLS 1.3协议传输。 2. 增强了System Management数据模型，以便设备能够使用TACACS+服务器进行集中认证、授权和计费。 3. 提供了新的数据节点来处理共享密钥等敏感信息的安全性问题。 4. 引入了新的安全选择，包括可配置的Cipher Suite和Pre-Shared Key等。 5. 定义了新的数据节点来表示服务器的IP地址、端口号和域名等属性。 总之，该数据模型旨在提供一种更加安全和高效的TACACS+客户端管理和认证方案，以满足现代网络环境的需求。
- Diff: 本文档定义了一个终端访问控制器访问控制系统（TACACS+）客户端YANG模块，它增强了系统管理数据模型，以允许设备使用TACACS+服务器进行集中身份验证、授权和计费（AAA）。具体来说，这个文档定义了用于TACACS+客户端的YANG模块，包括支持TLS 1.3的TACACS+客户端。 主要内容包括： 1. 针对[RFC9105]做了以下更改： - 添加支持TLS [I-D.ietf-opsawg-tacacs-tls13] - 校正一个必须声明，并指出缺失前缀 - 纠正旧示例中的错误 - 添加新的示例来说明TACACS+TLS数据节点的应用 2. 在设计TACACS+数据模型时进行了以下改进： - 客户端和服务器认证配置：定义一组可用于全局配置并随后引用特定服务器的凭证。 - 域名称：提供服务器的域名，每个字段需在[RFC8907]中包含。 - 单个连接模式激活：如果域名已指定，则仅当域名为“true”时才启用Server Name Indication扩展。 3. 支持与旧版不同的是，新版本引入了以下新数据节点： - 客户凭证和服务器凭证：可以在特定服务器实例下全局配置并引用。 - 域名：为每个服务器实例提供服务器域名。 - 单个连接模式激活：仅当域名为"true"时启用。 - 禁止默认端口声明，因为TACACS+TLS使用独立的默认端口号。 综上所述，相比于旧版本，新版本增加了对TLS的支持，添加了新的服务标识类型、证书和公共密钥等信息，并提供了更多的定制选项。这些更新使该模块能够更好地满足现代网络环境的需求。
RTG
bier
- Title: BGP Extensions for BIER
- Authors: Xiaohu Xu(xuxiaohu@huawei.com), Mach Chen(mach.chen@outlook.com), Keyur Patel(keyur@arrcus.com), IJsbrand Wijnands(ice@braindump.be), Tony Przygienda(tonysietf@gmail.com), Zhaohui (Jeffrey) Zhang(zzhang@juniper.net)
- Summary: 本文是关于BGP和BIER协议的一个扩展，主要讨论了如何在BGP协议中添加新的属性来支持BIT INDEX EXPLICIT REPLICATION（BIER）多播转发架构。BIER是一种不需要树建协议和中间路由器维护每条树上的多播状态的多播转发架构。 该文档定义了一个新的可选通配分发路径属性，称为BIER属性，用于标识特定的BFR（BIER Forwarding Router），这些BFR支持多个子域，并携带BIER属性中的额外信息，如BFR ID、比特串长度等。同时，也描述了如何使用这些属性进行BIER状态的计算和传递，以及一些操作注意事项。 总结而言，本文档旨在通过BGP协议的修改，为BIER多播转发提供更灵活的支持，以满足各种应用场景的需求。
- Diff: 上述新版本的英文标准文稿在原有基础上进行了扩展和优化。与旧版相比，新增了以下几个主要区别： 1. 增加了新的BGP路径属性：BIER（Bit Indexed Explicit Replication）路径属性。 2. 定义了一个新的BGP属性类型——BIER，用于携带BIER相关信息。 3. 规定了BIER路径属性的格式、长度、结构等。 4. 描述了BGF协议如何处理和使用BIER信息。 5. 提出了防止BIER属性泄露到非指定域的方法。 6. 针对BFPERS更新BGP路由时，如何根据BFER配置进行更新。 7. 对于支持多种BFS子域名的BFR，提出了一套规范，确保不会将不同BFS共享相同的BFR-ID值导致错误结果。 这些修改使得文档更符合实际需求，增加了实用性，并且更加完整详尽地描述了BGP在BIER上的应用方式。
mpls
- Title: Post-Stack MPLS Network Action (MNA) Solution
- Authors: Jaganbabu Rajamanickam(jrajaman@cisco.com), Rakesh Gandhi(rgandhi.ietf@gmail.com), Royi Zigler(royi.zigler@broadcom.com), Tony Li(tony.li@tony.li), Jie Dong(jie.dong@huawei.com)
- Summary: 本文主要探讨了MPLS网络行动(MNA)的解决方案，包括编码方式、标识方法以及处理流程等。文中定义了MNA的Post-Stack部分，即在MPLS标签堆栈后的附加数据。文稿还讨论了节点间的责任分担和安全考虑，并对相关的注册表进行了描述。此外，还提到了相关引用的规范文档。总的来说，本文提供了一个完整的框架来实现MNA的应用场景及其支持机制。
- Diff: 该文档定义了基于In-Stack MNA方案的Post-Stack MPLS网络动作（MNA）解决方案。与旧版本不同的是： 1. 在Conventions Used in This Document部分，引入了新的需求语言规范。 2. 在Overview部分，增加了Post-Stack Network Action和Post-Stack Data的概念，并对它们进行了详细描述。 3. 新增了一个Post-Stack Header类型注册表（Post-Stack Header Types），用于管理各种类型的Post-Stack Header。 4. 对In-Stack特殊操作码分配也有所调整，如增加了一种新的opcode。 总的来说，新版本在需求语言、概念框架、类型注册等方面都有所更新和完善，为MNA方案提供了更全面的支持。
SEC
oauth
- Title: OAuth Resource Helper
- Authors: Pieter van der Meulen(pieter.vandermeulen@surf.nl), Michiel B. de Jong(michiel@michielbdejong.com)
- Summary: 本文主要提出了OAuth 2.0中的资源辅助器的概念。它是一个模块化的组件，帮助授权服务器管理更细粒度的授权过程。资源辅助器与特定的资源服务器相关联，处理范围选择和资源特定细节，为用户界面提供访问令牌权限的选择或修改。通过将范围相关的用户交互移交给资源辅助器，授权服务器保持通用性和稳定性，而资源辅助器则随着资源服务器需求的发展同步发展。这个规范定义了协议、接口和流程，以及授权服务器与资源辅助器之间的关系。引入资源辅助器不会影响OAuth客户端或客户端与资源服务器之间的交互。 本文总结：该文档介绍了一个名为“资源辅助器”的概念，它是OAuth 2.0中的一个模块化组件，用于帮助授权服务器管理更细粒度的授权过程。它与特定的资源服务器相关联，并负责范围选择和资源特定信息的提供给用户提供选择或修改权限的权利。这个概念有助于保持授权服务器的通用性，同时让资源辅助器能够随资源服务器的需求一起更新和发展。
tls
- Title: TLS 1.2 is in Feature Freeze
- Authors: Rich Salz(rsalz@akamai.com), Nimrod Aviram(nimrod.aviram@gmail.com)
- Summary: 本文主要讨论了在使用TLS 1.3的情况下，由于其安全性更高，对于TLS 1.2来说存在一些缺陷需要解决。因此，建议在没有紧急安全问题、新加密算法或新的应用层协议ID的情况下，不进行任何变更。此外，该文档还指出了与量子计算相关的考虑和计划，以及这些考虑对未来的通信协议的影响。最后，它强调了在部署量子计算机时可能遇到的问题，并呼吁所有希望在将来使用量子技术的用户考虑采用更先进的协议。
- Diff: 新的版本在保留了原版主要内容的基础上，新增了一些对后量子时代影响的讨论，以及对IANA注册规则的一些更新。 新版本的主要区别在于： 1. 新增了对后量子时代影响的讨论，强调了使用后量子加密技术（如模块平方和基于公钥密码系统）对于TLS的重要性，并指出了这些技术在TLS 1.2上的不支持。 2. 更新了IANA注册规则，不再接受任何与TLS相关的注册信息，只保留了TLS 1.3或更晚版本的标签和协议ID。 总的来说，新版本更加关注于未来后量子时代的安全需求，强调了采用安全、可靠的加密算法以应对潜在的安全威胁。
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 Content-Format注册过程中的第一顺序优先级（FCFS）部分，以减少恶意篡改相关注册表的风险。修改后的流程分为两种情况：对于媒体类型名称未在“CoAP Content-Formats”注册表中出现，并且没有使用过该媒体类型的场景，执行专家审查；对于包含参数设置为默认值的情况，由于是相同的逻辑实体，可能会导致两个不同的内容格式ID。此外，还添加了一个新的列，用于记录预期检查的信息。最后，对相关的参考文献和作者信息进行了总结。 总的来说，本文更新了CoAP Content-Format注册流程，旨在降低恶意篡改风险。同时，增加了相关信息来帮助注册者了解如何正确进行内容格式注册。
- Diff: 在本文档中，作者更新了CoAP Content-Format注册程序，使其更严格地检查组合媒体类型和参数的有效性。对于范围0-255的注册，现在被命名为"Full Review"，与之前不同。同时，新增了一个“Note”列，用于记录预期的审查步骤。此外，还修改了“Lightweight Review”部分的检查，以区分专家审核流程。总的来说，新的注册程序将更加严格地检查媒体类型和参数的有效性，从而降低潜在的安全风险。 相较于旧版本，本文档的主要区别在于引入了额外的审查机制，并对原有的审查流程进行了优化，使得注册过程更加严谨有效。这些改进有助于减少恶意操作的风险，提升注册流程的安全性和可靠性。
tsvwg
- Title: Configuring UDP Sockets for ECN for Common Platforms
- Authors: Martin Duke(martin.h.duke@gmail.com)
- Summary: 本文是关于UDP协议上使用ECN（Explicit Congestion Notification）的一个记录，旨在鼓励其他QUIC实现者为他们的服务提供ECN支持。它讨论了如何设置和获取接收UDP包中的ECN标记，并提供了相关平台的示例代码。此外，还介绍了安全考虑和IANA注册要求。 文稿主要总结了以下几点： 1. 在Linux、Apple和FreeBSD等平台上，可以使用setsockopt()函数启用ECN报告。 2. Windows上的ECN配置需要单独使用WSASetRecvIPEcn()函数或setsockopt()函数进行。 3. 在发送端，可以选择在每个连接上指定ECN标记，或者在每个数据包上指定一个特定的ECN值。 4. 使用不同的平台方法会导致不同的结果，因此文档建议开发者选择最适合自己的平台方式。 总的来说，本文总结了ECN在UDP上的使用情况，并提到了一些限制和挑战。尽管有这些限制，但该技术对于提高网络性能仍然具有潜力。