【每日文稿】2025-01-13
今日共有11篇文稿更新，涉及4个area里的7个WG
INT
dtn
- Title: DTN Bundle Protocol Security (BPSec) COSE Context
- Authors: Brian Sipos(brian.sipos+ietf@gmail.com)
- Summary: 这篇文稿主要讨论了DTN包协议安全(BPSec)中的CoSE安全上下文。它定义了一种适用于使用CBOR对象签署和加密算法的包协议安全性(BPSec)完整性块和保密块的安全上下文。文稿还详细描述了如何在这些上下文中使用CBOR对象，以及对一些相关概念如附加数据、参数、结果等进行了详细的说明。另外，还提到了几个关键点，如：COSE用于包协议中的作用，如何在包协议中使用CBOR对象进行安全处理等。总的来说，这篇文稿为实现基于CoSE的安全上下文提供了很好的指导。 总之，这篇文稿对于理解如何在包协议中使用CoSE和如何确保包协议的安全性具有重要的参考价值。
- Diff: 摘要：本文定义了一个适合用于使用CBOR对象签名和加密（COSE）算法在Bundle Protocol Security（BPSec）完整性与保密性块中的安全上下文。同时，针对COSE，也定义了聚焦于非对称加密算法和PKIX证书的COSE的profile。该规范为使用COSE在BPSec安全块中应用那些算法提供一个单个的安全上下文。此外，还定义了可以包括完整COSE消息的BPSec安全块参数，以及结果类型的约束。 对比旧版的英文标准文稿，主要区别如下： 1. 新版文档引入了额外的头部映射表项，允许包含任何块作为附加数据（AAD）。这使得安全性上下文中能够包含更多元的信息，而不是仅限于包内的特定块。 2. 对象签名和加密算法的范围得到了扩展，不再局限于传统的COSE框架，而是支持非对称加密算法和PKIX证书。 3. 安全上下文的编码方式简化了使用COSE的消息，消除了需要进行价值映射的需求。 4. 定义了用于生成AAD的接口，并规定了如何处理由多个AAD项构成的结果。这确保了每个结果都有唯一对应的AAD，并且不会出现混淆的情况。 总的来说，新版文档通过添加额外头部映射、增强功能以支持非对称加密算法和PKIX证书，以及简化结果编码，提高了COSE在BPSec安全块中的可用性和灵活性。
OPS
v6ops
- Title: Prefer use of RFC8781 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis
- Authors: Nick Buraglio(buraglio@forwardingplane.net), Tommy Jensen(tojens.ietf@gmail.com), Jen Linkova(furry13@gmail.com)
- Summary: 本文讨论了在使用IPv6地址合成和网络地址和协议翻译时，发现IPv6前缀的一种方法。这种方法依赖于一个已知的IPv4只可用全名域域名"ipv4only.arpa."。然而，随着最近开发的方法可以解决一些[RFC7050]限制，这种方法不推荐用于所有新的部署以及实现应采用一致的方法来获取IPv6前缀信息。建议首选[RFC8781]。此外，移动网络环境可能需要等待更复杂的网络控制信号或更慢的网络组件升级周期来采用[RFC8781]。客户端应该从路由器公告中获得IPv6前缀信息，而不是使用[RFC7050]方法。如果[RFC7050]没有提供IPv6前缀信息，则可以选择回退到[RFC7050]。 文中还总结了如何确保IPv6前缀信息的安全，并指出尽管[RFC7050]定义了一个"安全通道"的概念，但这个概念与定义为"安全通道"的其他标准不相容。另外，IPv6前缀的发现可以通过路由器公告进行，因此不需要保留[RFC7050]中的"ipv4only.arpa."这一名字。 最后，文稿指出了[IANA]仍然需要维护“ipv4only.arpa.”这一名称，同时建议继续使用[RFC7050]作为唯一发现IPv6前缀信息的机制。
RTG
bfd
- Title: BFD Encapsulated in Large Packets
- Authors: Jeffrey Haas(jhaas@pfrc.org), Albert Fu(afu14@bloomberg.net)
- Summary: 本文提出了一种使用BFD协议进行多路测试的方法，可以验证路径MTU。在传统的BFD场景下，通过配置适当的bfd.PaddedPduSize参数，可以确保连接的最小可达路径MTU满足要求。 文稿讨论了如何实现这种功能，并提供了相应的模块和文档参考。它还提出了对安全性、IANA注册等细节进行了简要说明。总的来说，本文提供了一个通用的框架来支持多路测试，并给出了详细的实施指导，帮助开发者实现这一功能。 然而，需要注意的是，这种方法需要根据具体的应用环境调整参数值，以保证测试的有效性。此外，如果应用中有不一致的接口参数设置，可能会导致单向连通性问题。因此，在部署前应该仔细考虑这些因素。
- Diff: 上述新版本的英文标准文稿主要在以下方面进行了改进和更新： 1. 引入了BFD Encapsulated in Large Packets（大包封装）功能：允许使用UDP小包携带BFD控制数据。 2. 在配置层面增加了对BFD大包大小的可选配置，即bfd.PaddedPduSize，默认值为24或26字节。这个设置将影响到实际发送的大包大小，以适应特定的应用场景。 3. 改进了部署和实施方面的考虑，比如如何选择合适的MTU大小、检测路径MTU等。这些都旨在更好地支持多路径测试。 4. 提供了一个统一的BFD大包管理器group，使得不同类型的设备能够方便地提供此功能。 5. 对安全特性进行了补充，包括如何保护用户数据免受攻击，并限制网络操作权限。 6. 定义了一组通用的数据节点，使得不同类型的BFD客户端可以更容易地获取并利用此特性。 总体来说，新的标准文档更侧重于引入和优化BFD大包的功能性细节，以及提供更广泛的接口和管理机制，从而提高其适用性和灵活性。
lsvr
- Title: BGP Link-State Shortest Path First (SPF) Routing
- Authors: Keyur Patel(keyur@arrcus.com), Acee Lindem(acee.ietf@gmail.com), Shawn Zandi(szandi@linkedin.com), Wim Henderickx(wim.henderickx@gmail.com)
- Summary: 本文主要讨论了BGP协议和BGP链接状态（BGP-LS）扩展，以及如何使用BGP SPF算法来实现高效的路由计算。文稿首先定义了相关术语，包括BGP、BGP SPF、BGP-LS、IPv4/IPv6等，并介绍了它们之间的关系。 接着，文稿详细描述了BGP与BGP SPF的关系，包括它们在工作中的相互作用，以及如何使用BGP SPF算法进行高效路由计算。文稿还讨论了不同的BGP SPF部署模型，如单节点会话、直接连接、密集会话等，以及这些模型的优点和适用性。 最后，文稿对BGP SPF算法进行了详细介绍，包括选择最佳路径的方法、SPF计算的过程，以及如何处理路由更新和错误。文稿总结指出，BGP SPF能够提供更好的路由收敛效率，支持快速收敛和Loop-Free Alternatives，同时也可以支持更灵活的网络拓扑结构。 总的来说，本文为实现高效、可靠和可扩展的BGP路由计算提供了理论基础和技术框架，对于改进现有BGP解决方案具有重要意义。
- Diff: 新版本的英文标准文稿描述了在简化三层(L3)路由的基础上使用BGP Link-State Distribution和最短路径优先算法(BGP SPF)的新方案。 主要内容上的主要区别如下： 1. 相比于旧版，新版文档对BGP协议做了重要改动，如删除了决定过程中的某些部分，并引入了新的决策过程，包括选择路由、计算权重等步骤。 2. 新版文档定义了BGP-LS SPF安全信息格式(SAFI)，并指出了其适用范围。 3. 新版文档提出了多种BGP SPF部署模型，如单跳模型、直接连接节点模型等。 4. 新版文档为BGP SPF引入了新的扩展，比如支持双栈、基于BGP-LS-SPF NLRI的流量选择等。 5. 新版文档增加了错误处理机制和安全性要求，确保网络稳定性和数据安全。 6. 新版文档讨论了管理层面的问题，如配置、链路度量等，以及如何实现地址族隔离。 总的来说，新版文档旨在提供一种更加灵活且高效的L3路由解决方案，满足大规模数据中心的需求。
pce
- Title: Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP).
- Authors: Samuel Sidor(ssidor@cisco.com), Zoey Rose(atokar@cisco.com), Shaofu Peng(peng.shaofu@zte.com.cn), Shuping Peng(pengshuping@huawei.com), Andrew Stone(andrew.stone@nokia.com)
- Summary: 这一标准草案详细描述了将SR算法扩展到PCEP协议的能力，以支持Segment Routing（SR）以及使用段标识符(SIDs)和SR算法进行流量工程（TE）。该草案提出了一种机制来通知PCEP对等体关于特定SID使用的SR算法的信息，以及向PCE发送SR算法约束作为其请求的一部分。此外，它还定义了一些新的METRIC对象类型用于支持基于SR算法的路径计算。 总结文档主要关注以下几点： 1. 引入了一个新标志S，表示支持SR算法。 2. 对于ERO和SRv6-ERO子对象，都新增了包含算法字段。 3. 对LSP对象进行了扩展，包括SR算法约束项。 4. 提出了几个新的METRIC对象类型，满足特定的TE需求。 5. 描述了如何控制功能和策略、信息和数据模型、验证操作等方面的考虑。 6. 标准草案概述了实施状态，包括实现情况和现有状态等内容。 总的来说，本文旨在为PCEP协议提供更灵活的特性，以便运营商可以更好地利用SR算法设计高效路径。
- Diff: 这篇新的英文标准文稿是关于Segment Routing（SR）的，它扩展了Flexible Algorithm定义在路径计算元素协议（PCEP）中的适用范围。 主要内容包括： 1. 定义了一个支持SR算法的新标识符和类型，并允许控制头部端路由器关于每个用于SR-TE路径的SID使用的SR算法信息。 2. 提供了新的编码格式来表示SR-ERO、SRv6-ERO以及包含SR算法约束的标签交换路径属性对象（LSPA）。 3. 规定了一个新的METRIC对象的类型，以便更好地支持SR算法路径计算。 4. 完善了Path Computation Element（PCE）的扩展，使得它可以接收并使用特定于SR算法的路径计算规则。 5. 提供了信号SR算法约束给PCE的功能，从而优化路径计算以满足运营商指定的需求。 6. 比较老版文档，重点介绍了新功能和改进点。 总的来说，与之前的文档相比，新版本增加了对灵活算法的进一步扩展，增强了通过路径配置元素协议（PCEP）管理SR-TE路径的能力，并提供了一种更精确地执行路径计算的方法。
- Title: Procedures for Communication between Stateful Path Computation Elements
- Authors: Haomian Zheng(zhenghaomian@huawei.com), Stephane Litkowski(slitkows.ietf@gmail.com), Siva Sivabalan(msiva282@gmail.com), Cheng Li(c.l@huawei.com)
- Summary: 本文主要讨论了在多路径计算环境中实现状态同步的方法。文稿首先定义了状态同步的概念，并探讨了其在分布式环境中的重要性，特别是在需要跨多个路径执行计算的情况下。接着，它提出了通过创建一个状态同步会话来实现这种同步的方法。该方法涉及在PCE之间建立基于优先级的连接，以确保单个PCE负责所有路径的计算。此外，还介绍了如何维护不同来源的状态信息以及如何避免计算循环。 总结来说，文稿展示了在支持状态同步的情况下，可以提高PCE之间的通信效率和稳定性，从而增强网络的可扩展性和可靠性。
- Diff: 的新版本标准文档为《Path Computation Element Communication Protocol (PCEP)》。该文档提供了在状态机路径计算元素（Stateful Path Computation Elements, PCEs）之间进行通信的规范，并详细描述了如何通过协商建立交互性的同步机制来防止计算循环。新版本增加了关于优先级关系、主备关系的概念，以及优化的状态同步流程等内容。此外，还提供了一些具体的示例来展示这些新功能的实际应用。总体来说，新版本增加了更多细节和实际应用场景，使其更适合应用于实际网络设计和实现中。
- Title: PCEP Extension for Distribution of Link-State and TE Information for Optical Networks
- Authors: Yang Zhao(zhaoyangyjy@chinamobile.com), Young Lee(leeyoung@huawei.com), Haomian Zheng(zhenghaomian@huawei.com), Daniele Ceccarelli(dceccare@cisco.com), Wei Wang(weiw@bupt.edu.cn), Peter Choongul Park(peter.park@kt.com), Bin Yeong Yoon(byyun@etri.re.kr)
- Summary: 本文主要讨论了在光网络中的路径计算元素（PCE）需要准确及时的流量工程数据库（TED）的问题。现有实验文档扩展了Path Computation Element Communication Protocol（PCEP）协议，增加了对Link-State和Traffic Engineering信息的收集功能。这些信息以前是通过支持流量工程扩展的链路状态路由协议获得的。 本文还提出了在光网络中使用PCEP-LS方案的两种情况：一是当有IGP运行时，可以定期从特定节点获取链路状态和TE资源信息；二是没有IGP运行时，可以从光节点处获取链路状态和TE资源信息。此外，文稿详细介绍了如何将这些参数用于光网络，包括是否需要报告可达源-目标节点对、光延迟等参数，并给出了具体的实现方式。 总的来说，该文提出了一种新的方案来收集光网络的链路状态和TE信息，以供路径计算使用。这种方案可以提供更准确的路径计算结果，缓解光网络节点进行路径计算的压力。
- Diff: 以上新版本的英文标准文稿提供了对光网络路径计算和传输工程（PCE）信息收集的新功能，包括在光网络中的节点和链路属性、以及PCEP-LS扩展到支持光学网络的功能。 与旧版文档相比，本版本的主要区别在于： 1. 提供了更具体的物理网络参数，如可达源-目标节点对和光缆限制，以确保路径计算的有效性。 2. 在节点属性中增加了新的子标签，如连接矩阵、资源块信息等，这些都适用于光网络场景。 3. 增加了新的链路属性子标签，适用于LS链路对象类型。 4. 对于光学网络，还提供了解决最大带宽可聚合的问题，比如按lambda/frequency或分层抽象处理。 5. 安全措施也得到了进一步的考虑，通过增加子标签来携带安全相关的TLVs。 总的来说，新版文稿是基于现有协议PCEP发展起来的一个实验性的补充，旨在解决光网络中路径计算的需求，同时保留必要的LS和TE信息，并为未来的光网络操作提供支持。
- Title: Extensions to the Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation
- Authors: Xian Zhang(zhang.xian@huawei.com), Haomian Zheng(zhenghaomian@huawei.com), Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com), Victor Lopez(victor.lopez@nokia.com), Yunbin Xu(xuyunbin@caict.ac.cn)
- Summary: 本文主要讨论了PCEP协议中的资源共享特性。文中提出了一种新的资源共享类型，允许PCC在请求路径计算时要求网络元素共享资源，并详细介绍了这种新类型的定义、处理规则和实现方法等。此外，还讨论了相关的管理和安全性问题。该文档为未来的网络设计提供了一定参考。
- Diff: 该文档是关于扩展Path Computation Element（PCE）协议以支持资源共享功能的新版本。 与旧版本的主要区别在于： 1. 增加了新的资源共享类型和TLV定义。 2. 支持使用其他路径指示对象（如IRO/XRO）来指定特定资源需求。 3. 更多管理性考虑被包含在内，包括控制功能、数据模型、网络操作等。 总体来说，这个版本引入了更多的灵活性和选择性，并提供了更强大的资源配置能力，使网络规划者能够根据具体的需求调整网络资源分配策略。
SEC
acme
- Title: Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names
- Authors: Q Misell(q@as207960.net)
- Summary: 文档主要讨论了在自动化证书管理环境中使用ACME来为".onion"特殊用途域名（Special-Use Domain Names）提供证书的问题。文档详细介绍了ACME挑战的定义、验证方法以及相关的安全性考虑。其中，特别强调了如何防止未授权CA对".onion"域名进行恶意证书的颁发，并指出使用新的"onion-csr-01"挑战来解决这一问题。 总的来说，《ACME for ".onion"》文档提供了ACME实现对".onion"域名认证的方法和建议，旨在提高此类域名的可信度并减少可能的安全风险。
- Diff: 本文档定义了扩展到自动证书管理环境（ACME）以允许在隐藏服务（".onion" 特殊用途域名）上使用自动发证的挑战。这些挑战可以验证控制DNS标识符。同时，还定义了一个替代的基于隐式CA资源记录（CAA）的方法来与".onion"特殊用途域名上的隐藏服务交互。 比较旧版本和新版本的主要区别如下： 1. 新增加了关于".onion"特殊用途域名的扩展挑战。 2. 对于".onion"特殊用途域名，提出了一个新的认证方法，即“onion-csr-01”挑战，该挑战支持颁发对隐藏服务的全路径证书。 3. 在".onion"特殊用途域名的隐藏服务之间，不再需要进行客户认证，而是在".onion"特殊用途域名内部直接验证。 4. 提供了一种新的方式，在线将CAB协议发布给ACME服务器，用于在请求获取隐藏服务描述时提供CA的Ed25519公钥。 5. 定义了一个新的字段，用于指示隐藏服务是否需要在线认证，以及如何处理此信息。 6. 引入了在线验证CAB政策的新方法，并在ACME最终端点中定义了一个新的对象，其中包含每个".onion"特殊用途域名的CAB记录集。 7. 确定了适用于.".onion"特殊用途域名的新CAB资源记录集合格式。 总的来说，新版本提供了更多针对".onion"特殊用途域名的解决方案和改进，使得ACME能够更灵活地支持隐藏服务的发证过程。
lamps
- Title: Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
- Authors: Russ Housley(housley@vigilsec.com), Scott Fluhrer(sfluhrer@cisco.com), Panos Kampanakis(kpanos@amazon.com), Bas Westerbaan(bas@westerbaan.name)
- Summary: 本文主要描述了SLH-DSA哈希签名算法在加密消息语法(CMS)中的使用方法。它是一个基于哈希的无状态签名算法，可用于数字签名和用于验证签名的有效性。文稿还提供了相关的安全性和操作方面的考虑。最后，给出了相关的参考文献。 总的来说，这篇文稿详细介绍了如何使用SLH-DSA哈希签名算法与加密消息语法结合使用，并强调了其安全性、性能以及与其他签名算法的区别。
- Diff: 本文详细介绍了SLH-DSA哈希签名算法及其应用。相较于之前的文档，该版本的主要区别在于： 1. 更详细的介绍：提供了关于SLH-DSA的详细介绍，包括其历史背景、工作原理等。 2. 增加了安全性考虑：详细阐述了安全措施，如防止攻击和保护私钥等。 3. 提供了新的公钥标识符：新增了用于SLH-DSA公钥的新的标识符。 4. 实施指南：提供实施指南，指导开发者如何正确使用SLH-DSA。 总的来说，这篇新的文档对SLH-DSA进行了更深入的研究，并提供了更加全面的安全性和实施指南，以支持用户更好地利用这一技术。
Unknown
Unknown
- Title: Flooding Reduction Algorithms Interoperability Framework
- Authors: Tony Przygienda(tonysietf@gmail.com), Shraddha Hegde(shraddha@juniper.net)
- Summary: 本文提出了一个框架，允许在同一个IGP域内部署多个洪水减少算法。这意味着可以在网络中同时运行多种算法，以满足迁移过程中对网络稳定性的要求。 文稿首先定义了洪水减少算法（称为“洪水削减者”或“削减者”）以及它们之间的关系。随后介绍了洪水削减者的必要属性，包括不改变现有操作模式、不改变计算和通信方式、节点可以自由选择不同的算法等。最后讨论了网络安全考虑，并提到了相关的参考文献。