【每日文稿】2024-11-13
今日共有14篇文稿更新，涉及5个area里的11个WG
ART
extra
- Title: IMAP Support for UTF-8
- Authors: Pete Resnick(resnick@episteme.net), Jiankang Yao(yaojk@cnnic.cn), Arnt Gulbrandsen(arnt@gulbrandsen.priv.no)
- Summary: 本文主要介绍了国际编码支持对国际化电子邮件的支持。它扩展了Internet Message Access Protocol（IMAP）协议，以支持UTF-8编码的国际字符在用户名、邮件地址和消息头部字段中的使用。此外，还提供了一种机制来支持使用UTF-8表示的邮箱名称。 该规范允许服务器发布两个新的IMAP能力，一个标识服务器支持“UTF8=ACCEPT”，即接受包含UTF-8编码的字符串，另一个是“UTF8=ONLY”，意味着只有支持UTF-8的客户端才能使用这个服务器。同时，文稿讨论了如何处理不支持这种功能的客户端，并提供了相关安全考虑。最后，提出了可能的问题和解决方法，如与旧版本兼容性问题等。
wimse
- Title: OAuth 2.0 Client Assertion in Workload Environments
- Authors: Benedikt Hofmann(hofmann.benedikt@siemens.com), Hannes Tschofenig(Hannes.Tschofenig@gmx.net), Edoardo Giordano(edoardo.giordano@nokia.com), Yaroslav Rosomakho(yrosomakho@zscaler.com), Arndt Schwenkschuster(arndts.ietf@gmail.com)
- Summary: 本文主要讨论了在工作负载环境中使用OAuth 2.0客户端声明的挑战。传统的做法是通过手动提供客户凭证和轮换，或者将其存储在工作负载中并被盗取来获取访问令牌。一种解决方案是在平台内部证书服务器上签发一个凭据，并作为对不同授权服务器的凭据授予流中的客户端声明。这种架构要求认证服务器验证这些凭据以确保其正确性和合法性。此外，还强调了应根据具体平台选择不同的凭据格式、生命周期以及用于证明凭据拥有者身份的方法。最后，介绍了如何将这些凭据与工作负载进行绑定，并确保凭据所有者的持有权。
INT
madinas
- Title: Randomized and Changing MAC Address: Context, Network Impacts and Use Cases
- Authors: Jerome Henry(jhenry@ieee.org), Yiu Lee(yiu_lee@cable.comcast.com)
- Summary: 本文讨论了在无线网络环境中使用随机化和变化MAC地址(Randomized and Changing MAC Address)的问题。它指出，随着无线技术的发展，无线设备的MAC地址可以出现在全球各地，并且可能会发生碰撞以避免冲突。然而，这种变化也可能影响用户的体验，导致网络服务中断。文稿列举了一些可能受到影响的服务，包括认证、授权和会计（AAA）服务等，并提出了几种解决方案来维护用户隐私的同时保持用户体验和网络效率。 总结如下： 本文探讨了在无线网络环境中使用随机化和变化MAC地址的问题。它分析了可能受影响的服务，如认证、授权和会计（AAA）服务，并提出了解决方案来保护用户隐私并同时维持用户体验和网络效率。
OPS
grow
- Title: Near Real Time Mirroring (NRTM) version 4
- Authors: Sasha Romijn(sasha@reliablycoded.nl), Job Snijders(job@fastly.com), Edward Shryane(eshryane@ripe.net), Stavros Konstantaras(stavros.konstantaras@ams-ix.net)
- Summary: 本文主要介绍了近实时同步（NRTM）协议版本4，用于互联网路由登记机构（IRR）记录的可靠编码。NRTM允许实例上的IRR数据库服务器镜像IRR记录，指定在不同的服务器上。更新通知文件包含IRR数据库版本、Snapshot和Delta文件的位置等信息，并使用SHA-256哈希值验证签名。客户端从更新通知文件检索IRR对象，并初始化本地副本。 总结：本文详细介绍了NRTM协议的实施方法、安全考虑以及注意事项，强调了HTTPS的安全性。同时，还讨论了如何处理不同服务器之间的差异，以及如何防止数据丢失或延迟。
RTG
bess
- Title: Multicast Source Redundancy in EVPN Networks
- Authors: Jorge Rabadan(jorge.rabadan@nokia.com), Jayant Kotalwar(jayant.kotalwar@alcatel-lucent.com), Senthil Sathappan(senthil.sathappan@alcatel-lucent.com), Zhaohui (Jeffrey) Zhang(zzhang@juniper.net), Wen Lin(wlin@juniper.net)
- Summary: 本文主要讨论了在以太网虚拟私有网络(EVPN)环境下实现多源单一组播流复制的问题。它提出了两种解决方案：温备式（Warm Standby）和热备式（Hot Standby）。这两种方案都可以避免接收者收到多个源发送同一组播流导致的流量冗余。 对于温备式，上游端点通过选举单向转发器来确定哪些端点应该使用，从而只选择一个端点发送组播流到下游端点。对于热备式，每个连接到冗余源的下游端点都必须知道其关联的组播源，并为其分配特定的Ethernet段标识符，以便他们可以识别这些组播源并防止流量重叠。这种解决方案提高了系统的可扩展性和可靠性，但增加了额外的部署成本和复杂性。
- Title: EVPN Anycast Multi-Homing
- Authors: Jorge Rabadan(jorge.rabadan@nokia.com), Kiran Nagaraj(kiran.nagaraj@alcatel-lucent.com), Alex Nichol(anichol@arista.com), Ali Sajassi(sajassi@gmail.com), Wen Lin(wlin@juniper.net), Jeff Tantsura(jefftant.ietf@gmail.com)
- Summary: 本文是关于一种名为EVPN Anycast Multi-homing的扩展，它是一种优化了的EVPN分段多归属方式。该扩展允许在EVPN控制平面中使用广播域中的多个多归属路径（Anycast Multi-homing），从而简化和优化流量路由。例如，在典型的Data Center环境中，如果一个叶路由器支持这种扩展，并且与同一个广播域共享多个多归属路径，则它可以利用这些多归属路径来实现更高效的负载均衡。 此外，文稿还提到了一些潜在的应用场景，如在不支持IP隧道的NVO3网络中使用多归属路径。然而，尽管有这些优点，作者也指出了一些可能的问题和挑战，比如需要额外的操作步骤来处理连接故障以及如何在不同的情况下使用多归属路径等。 总的来说，这篇文稿提供了一种解决EVPN网络中的多归属问题的方法，旨在提高网络效率并降低资源消耗。然而，需要注意的是，这种解决方案可能会带来新的复杂性，因此实施时需谨慎考虑。
idr
- Title: Extended Communities Derived from Route Targets
- Authors: Zhaohui (Jeffrey) Zhang(zzhang@juniper.net), Jeffrey Haas(jhaas@pfrc.org), Keyur Patel(keyur@arrcus.com)
- Summary: 本文主要讨论了如何从路由目标（Route Target）生成扩展社区（Extended Community），并提供了几个例子来说明这种用途。这些例子包括使用EVPN EVI-RT扩展社区、在控制器上指示BGP-MVPN以实现叶发现以及使用通用RT衍生扩展社区进行翻译。 文稿还讨论了安全性考虑，并指出了对新的扩展社区类型进行注册的可能性，特别是在定义有路由目标子类型的扩展社区时。最后，它提出了一个建议的子类型编号为0x0016的新类型——“UUID-RT衍生扩展社区”，并指出了相应的IANA注册信息。 总的来说，该文档提供了一个方法来从路由目标生成扩展社区，从而解决了某些场景中的特定需求，并且提出了一种可能的方法来管理新的扩展社区类型和它们的注册。
rtgwg
- Title: Topology Independent Fast Reroute using Segment Routing
- Authors: Ahmed Bashandy(abashandy.ietf@gmail.com), Stephane Litkowski(slitkows.ietf@gmail.com), Clarence Filsfils(cfilsfil@cisco.com), Pierre Francois(pierre.francois@insa-lyon.fr), Bruno Decraene(bruno.decraene@orange.com), Daniel Voyer(daniel.voyer@bell.ca)
- Summary: 本文提出了一种名为Topology Independent Fast Reroute (TI-LFA)的本地修复机制，旨在提供直接相连网络中节点和邻接段的保护。该机制通过预计算并安装快速重路由（FRR）路径来确保端到端连接。与现有解决方案相比，如远程LFA和环回备份路径，TI-LFA提供了更广泛的保护覆盖范围。 文稿讨论了在Segment Routing（SR）框架下使用SR技术来保护拓扑独立故障的重要性。SR技术允许运营商定义本地保护策略，并为特定类型的故障提供最优路径。然而，当SR政策涉及SR段间协议时，TI-LFA不能依赖于这些政策，而需要自己确定最优化的FRR路径。 TI-LFA的实现基于SR架构，它将SRSID映射到特定的SR算法。当一个节点发生故障时，TI-LFA会立即启动保护过程，建立一个可信赖的恢复路径。这种实时保护机制可以减少对内部路由器的额外维护和配置需求。 最后，作者总结了TI-LFA的几个关键优势：它可以在不同拓扑结构中提供全面保护；它可以利用SR支持的本地保护策略，而不需要额外的FRR选项；它具有灵活性，可以根据实际网络情况调整FRR策略等。
- Title: Reliability Framework for SRv6 Service Function Chaining
- Authors: Feng Yang(yangfeng@chinamobile.com), Xiaoqiu Zhang(zhangxiaoqiu@chinamobile.com), Changwang Lin(linchangwang.04414@h3c.com), Yuanxiang Qiu(qiuyuanxiang@h3c.com)
- Summary: 本文主要介绍了在源路由网络中保护服务功能链的框架。提出了三种可靠性保护机制：冗余备份保护方法、冗余备份保护方法和SFF bypass forwarding方法。还提出了一些接口建议，比如SRv6端口行为、SRv6端口口味等，并对可能的安全性考虑进行了讨论。 总的来说，该文档详细描述了在源路由网络中保护服务功能链的方法，包括故障场景分析、保护机制设计以及接口定义等内容。同时，也对安全性问题进行了探讨。总体上，文档提供了实现可靠服务功能链所需的必要技术方案和操作指南。
SEC
acme
- Title: Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge
- Authors: Antonios Chariton(daknob@daknob.net), Amir Omidi(amir@aaomidi.com), James Kasten(jdkasten@umich.edu), Fotis Loukos(fotisl@google.com), Stanislaw A. Janikowski(stanwise@google.com)
- Summary: 本文是关于DNS挑战类型的一种新的定义，该定义允许多个独立系统验证同一域名。这种新定义使用一个唯一的标签来构造验证记录名称，从而避免了CNAME重叠冲突，特别适合于多区域或多云部署需要在同一直接控制和管理同一域名的情况下。本文没有提及对现有DNS-01标准的降级，而是补充了一个新的DNS-ACCOUNT-01挑战，用于验证同一域名，并且支持跨不同区域或多云环境的多客户端操作。 总的来说，本文提出了一种新的DNS验证挑战类型——DNS-Account-01，它结合了ACME账户URL构建了一个稳定的验证域名，可以同时由多个独立系统的验证者进行验证，解决了当前多区域、多云环境下的网络运营问题。然而，为了使这项服务能够顺利实施，提出了相应的安全性考虑和规范要求。
lamps
- Title: Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure
- Authors: Daniel Van Geest(daniel.vangeest@cryptonext-security.com), Kaveh Bashiri(kaveh.bashiri.ietf@gmail.com), Scott Fluhrer(sfluhrer@cisco.com), Stefan-Lukas Gazdag(ietf@gazdag.de), Stavros Kousidis(kousidis.ietf@gmail.com)
- Summary: 《HSS和XMSS在X.509中的应用》这篇文稿主要讨论了如何使用Hierarchical Signature System (HSS)、Extended Merkle Signature Scheme (XMSS)以及其多树变体XMSS^MT来创建数字签名。这些算法用于提供安全的哈希签名，即使量子计算机出现也不受影响。 文稿详细描述了这些状态基于哈希签名(HBS)私钥的状态管理要求，并强调了正确处理这种管理的重要性。它还指出了各种策略可以用来正确地管理这种状态，包括备份和恢复管理等。 此外，文稿也讨论了使用这些状态机私钥时的一些限制条件，比如必须小心避免OTS密钥的意外重用，以及需要谨慎处理可能存在的OTS密钥泄露问题。总的来说，这篇文稿为使用HBS机制提供了指导性建议，适用于一些特定的应用场景，如软件和代码签名。 最后，这篇文稿提到了关于这一文档的相关考虑事项，包括可能的标准化工作，以及如何进行相关测试和验证。总体而言，《HSS和XMSS在X.509中的应用》是一个对这些技术应用的深入探讨，对于理解这些系统的安全性至关重要。
oauth
- Title: SD-JWT-based Verifiable Credentials (SD-JWT VC)
- Authors: Oliver Terbu(oliver.terbu@mattr.global), Daniel Fett(mail@danielfett.de), Brian Campbell(bcampbell@pingidentity.com)
- Summary: 本文是关于Verifiable Credentials的一种新的格式，称为SD-JWT。这种格式支持选择性披露，并且可以使用JSON Web Token（JWT）来表示。它主要用于安全验证和存储。本文还定义了与SD-JWT相关的数据结构、处理规则以及如何在持有者、验证者和状态提供者之间交换这些信息。此外，本文也提到了如何验证和生成一个有效的Verifiable Credential，以及如何检索类型Metadata以获得更多信息。总之，本文为创建更安全的验证系统提供了新方法。
scitt
- Title: An Architecture for Trustworthy and Transparent Digital Supply Chains
- Authors: Henk Birkholz(henk.birkholz@ietf.contact), Antoine Delignat-Lavaud(antdl@microsoft.com), Cedric Fournet(fournet@microsoft.com), Yogesh Deshpande(yogesh.deshpande@arm.com), Steve Lasker(steve.lasker@datatrails.ai)
- Summary: 这篇文稿主要讨论了在供应链中实现透明度和问责制的可能性。它定义了一个通用、互操作且可扩展的架构，以增强对数字供应链上任何实体发布信息的信任。这个架构的目标是提供一种方式，让依赖方能够独立验证其他参与者的声明，并检查供应链上的记录状态。 该文稿总结了以下关键点： 1. 网络需求：确保跟踪物理和数字艺术品在供应链中的行为是长期安全性的关键问题。 2. 概念定义：术语定义包括“头部”、“尾部”，以及“待签名的字节”等概念。 3. 定义透明度：明确说明如何通过发布供应商关于产品的信息来实现透明度。 4. 架构概述：描述了透明服务的功能，如注册政策、收据类型和协议，以及审计透明声明的过程。 5. 隐私考虑：涉及保护数据隐私的问题，以及如何处理可能面临的威胁情况。 6. 安全性考虑：强调了确保传输过程中数据完整性、不可抵赖性和可用性的必要性。
Unknown
Unknown
- Title: A Template for IANA Cryptographic Registries
- Authors: Rich Salz(rsalz@akamai.com)
- Summary: 本文主要为国际电联的工作组提供了指导，如何创建与加密算法相关的IANA登记册。它基于对TLS注册表多年经验的教训，并强调了在定义这些登记册时应遵循的最佳实践。 该文档总结了几个关键点： 1. 每个登记册都必须是“要求规格”，以确保它们包含永久和易于访问的规范性描述。 2. 如果由工作小组或IRTF研究组定义，则应包括一个参考文献字段，指向即将发布的RFC文档。 3. 命名空间值（必填）：表示数据结构或协议中的标识符。附加短语可能需要详细说明格式，例如固定数量的字节、文本字符串等。 4. 描述（必需）：简要描述项的概览，通常指出到引用文件的链接，如NTP扩展类型在NTP登记册中的作用。 5. 参考（必需）：定义工作定义工作的组织所引用的出版物。 6. 推荐（必需）：确定此项目是否推荐通用使用。如果项目已经从一个工作小组或IRTF研究组获得批准，则应填写“Y”或“D”。不建议重复提交，以保持一致性。 7. 评论（可选）：用于解释过渡或限制使用情况的信息。示例包括：“已废弃于RFC XXX” 8. 安全考虑因素：使用要求规格而非国际电联审查降低理论上的审查提供量，但经验表明，工作组成员普遍没有进行加密审查，尤其是在将国家密码套件与标准挂钩的情况下。 9. IANA考虑因素：本文讨论的是关于如何维持IANA管理的加密登记册最佳实践的问题，而未定义任何新的登记册，而是提供了有关维护这类登记册的最佳实践指南。