【每日文稿】2025-01-17
今日共有14篇文稿更新，涉及6个area里的10个WG
ART
wimse
- Title: WIMSE Service to Service Authentication
- Authors: Brian Campbell(bcampbell@pingidentity.com), Joe Salowey(joe.salowey@gmail.com), Arndt Schwenkschuster(arndts.ietf@gmail.com), Yaron Sheffer(yaronf.ietf@gmail.com)
- Summary: 本文是关于工作负载身份在多系统环境中的服务到服务认证架构。本文定义了最基础的原子级别单位，即两个需要相互验证身份的工作负载之间的协议，用于确保它们的安全通信。本文提出两种方案：一种是基于DPoP[RFC9449]的鉴权机制，另一种是在HTTP消息签名RFC基础上建立的。 两种方案兼容性好，一个链路可以同时使用其中的一种或另一种。服务A可以与服务B进行互信的TLS鉴权，而服务B对服务C的下一个请求则需要通过应用层保护来完成。 文中还讨论了如何防止中间件劫持、隐私考虑等安全问题，并给出了相应的解决方案。最后，提出了将WIT和POPS绑定到TLS端点的建议。
- Diff: 该文档定义了在服务间通信时用于验证工作负载身份的安全协议。对比旧版文档，主要区别如下： 1. 相比旧版，新增了应用级别的保护方案，可以应用于多种部署环境。 2. 指出了两种认证机制：基于OAuth的DPoP激励机制和基于HTTP消息签名的方案。这两种方案将在后续讨论中选择一个作为最终标准。 3. 描述了两种方案的工作原理、流程以及如何实现互操作性。对于每个方案，都提供了详细的实现方法。 4. 概述了安全性考虑点，包括WIMSE证书、令牌和JWT之间的兼容性问题。 5. 对于未来的标准化工作提出了建议，例如对媒体类型进行注册等。
INT
6man
- Title: Entering IPv6 Zone Identifiers in User Interfaces
- Authors: Brian E. Carpenter(brian.e.carpenter@gmail.com), Bob Hinden(bob.hinden@gmail.com)
- Summary: 本文是关于IPv6地址在用户界面输入规范的研究。文稿讨论了当前使用的IPv6地址格式、IPv6ScopedAddressArchitecture（RFC 4007）中的zone标识符以及如何将它们正确地转换成IPv6地址的一部分。它还提到了一些现有的文档，如RFC 6874和RFC 4007。 本文指出，一个完整的IPv6地址可以通过切割字符串来插入到用户界面中，例如“fe80::1234%eth0”或者“fe80::4321%7”。然而，如果这些操作对于特定的操作系统来说是不可能或不经济的，那么使用区位符的另一个方式可能会更合适，比如将一个字符串分成两个部分，并通过inet_pton()函数将第一个部分转换为接口索引，然后使用if_nametoindex()函数将第二个部分转换为接口索引。 此外，为了支持IPv6地址，软件应该避免传输任何包含非全球地址作为数据的文本消息，因为这种行为可能违反网络安全性规定。这个建议也适用于浏览器，因为HTTP起源模型需要一个有效的HTTP源。 最后，作者提到，由于IPv6地址的扩展性和潜在的IPv6网络规模，现在支持完整链接本地地址的需求变得越来越迫切。这使得了解如何处理IPv6地址成为一种紧迫的问题，特别是在IPv6专用网络（IPv6MOST）、缺少内核IPv4支持的节点出现的情况下。
- Diff: 本文档描述了用户界面（UI）如何输入IPv6地址中的区标识符，以及其对实现功能的重要性。它保留了原始文档的主要内容和结构，并更新了一些细节以适应当前的网络环境。 主要区别： 1. 文档从RFC 6874中删除了引用，因为实施者发现该方案不可行。 2. 对HTTP“起源”问题进行了澄清，不再要求浏览器支持链接本地地址。 3. 更新了RFC 7622和RFC 8089，删除了它们对RFC 6874的引用。 4. 在引入新的规范性术语后，增加了三个规范性关键词，如“SHOULD”，以进一步说明接口索引应如何用于后续socket调用。 5. 提到了IPv6多播地址和IPv6最主流网络（IPv6-MOSTLY Networks），强调这些扩展的重要性。 6. 删除了旧版文档中的一些参考文献，包括在IPv6-ONLY和IPv6-MOSTLY网络出现之前就已经存在的文件。 7. 在结束语中，作者列出了与撰写本文档相关的参与者名单和日期。 总的来说，本文档是对RFC 6874的替代品，旨在提供一个通用的用户界面需求，使得输入完整的IPv6链路本地地址成为可能。
dtn
- Title: DTNMA Application Data Model (ADM) YANG Syntax
- Authors: Edward J. Birrane(edward.birrane@jhuapl.edu), Brian Sipos(brian.sipos+ietf@gmail.com), Justin Ethier(justin.ethier@jhuapl.edu)
- Summary: 是关于描述一种用于表示延迟容错网络管理架构（DTNMA）应用数据模型（ADM）的文本格式，以及如何将这种格式与应用管理模型（AMM）结合使用。本文定义了特定的语法来表示一个具体的DTNMA ADM，不涉及动态对象和属性的具体编码。 文档首先概述了范围、术语等，并详细解释了DTNMA ADM模块的语法结构，包括命名空间、组织信息、版本号、数据类型和数据节点等元素。接着，文稿讨论了如何使用预设的YANG语法处理这些ADM模块，保留了现有的工具支持和部分语义特征，同时避免了与其他领域YANG模块共存的潜在冲突。最后，文稿提出了在不同的应用场景下如何利用DTNMA ADM模块的数据模型。 总之，《DTNMA ADM YANG》为实现DTNMA ADM的代码编写提供了具体指导，有助于开发者构建符合标准的ADM代码。
- Diff: 以上新版本的英文标准文稿定义了一个具体语法来编码延迟容忍网络管理架构（DTNMA）应用程序数据模型（ADM）。与旧版本不同的是： 1. 它定义了特定语法来表示单个DTNMA ADM版本为文本文件。 2. 它不定义一个ADM对象和值映射的运行时对象和值。AMM值的编码在AMM值标识符规范（[I-D.ietf-dtn-ari]）中定义。 3. 它使用了与YANG语法紧密耦合的预存YANG语法来利用YANG模块工具，如命名空间处理、导入等，并保留了部分YANG模块基础设施。 4. 它将抽象语法树（AST）中的类型和结构与AMM的静态定义区分开来，以提供一种在ADM模块内捕获静态管理信息的方法。 总之，该文档扩展了现有YANG语法，使其可以用来编码基于AMM的应用程序数据模型。
- Title: DTNMA Application Resource Identifier (ARI)
- Authors: Edward J. Birrane(edward.birrane@jhuapl.edu), Emery Annis(emery.annis@jhuapl.edu), Brian Sipos(brian.sipos+ietf@gmail.com)
- Summary: (DTNMA)定义了延迟可信赖网络管理架构(AMM)的应用管理模型(AMM),用于描述自管的DTN节点配置。本文定义了AMM中的应用资源标识符(ARI),基于统一资源标识符(URI)结构和Concise Binary Object Representation(CBOR)格式。 主要特点包括: 1. 支持参数化命名以减少数据量和避免数据协商。 2. 支持压缩编码,提高通信效率和传输资源利用。 3. 提供可编程性以满足不同类型的数据选择需求。 4. 定义了丰富的命名规范和表达式形式,支持多种类型的数据元素表示。 5. 为文本、数值和元数据提供了不同的处理方式。 总结来说,ARI提供了一种简洁、层次化的命名体系,满足AMM对数据元素的标识需求,简化了网络管理和通信过程中的命名工作。
- Diff: 摘要 本文定义了延迟网络管理架构（DTNMA）应用管理系统模型（AMM）中的对象标识符（ARI），用于支持延迟Tolerant Networking （DTN）管理解决方案描述的DTNMA文档中的挑战性网络管理解决方案。本文定义了ADI，基于统一资源标识符（URI）结构，并使用可压缩格式支持更少的数据传输、更少的处理资源和更低的传输资源消耗。 主要区别： 1. 使用了不同的语法结构，如文本形式和二进制形式。 2. 支持参数化结构，通过参数过滤条件减少通信数据量并消除数据交换往返协商需求。 3. 提供了可压缩编码功能，以更好地表达信息。
- Title: DTNMA Application Management Model (AMM) and Data Models
- Authors: Edward J. Birrane(edward.birrane@jhuapl.edu), Brian Sipos(brian.sipos+ietf@gmail.com), Justin Ethier(justin.ethier@jhuapl.edu)
- Summary: 本文讨论了在延迟容错网络管理架构（DTNMA）下如何创建应用程序数据模型（ADM）。它定义了一个对象和元值模型，用于同步管理和被管理节点之间的应用。该模型包括静态结构和基本类型定义，以及动态操作如参数处理、执行等。同时，还介绍了操作数据模型（ODM），支持不同类型的代理初始化、解析和处理等。 此外，文档详细描述了ADM、ODM的内容及其相互关系，并提供了相关的规范。最后，也指出了未来可能需要解决的一些问题和改进的方向。总的来说，本文为实现DTNMA提供了一种统一的数据模型框架。
- Diff: 本文是一篇关于延迟容忍网络管理架构（DTNMA）数据模型的英文标准文档。与旧版相比，主要有以下区别： 1. 文档定义了一个两层的数据模型，用于在DTNMA架构下管理应用程序。 2. 主要对象类型包括值、值生产者和代理处理活动等。 3. 基于这些对象的属性和行为，定义了AMM模型，该模型定义了所有可用类型的对象及其关系。 4. 对象之间存在严格的区分，如长生命周期的对象实例和瞬时的值实例。 5. 定义了基于语义类型的转换活动，允许将不同类型的值合并在一起。 6. 提供了AMM模型中对象的命名规则和内部/外部类型等信息。 7. 提供了AMM模型中执行、评估和报告活动的相关定义。 8. 在数据模型中的其他部分，如应用数据模型（ADM）、操作数据模型（ODM）、代理初始化、参数处理、变量生成等活动也被详细描述。 综上所述，本文档提供了一种新的结构来表示DTNMA架构下的应用程序，并为动态和静态对象之间的交互提供了规范。相较于旧版，它更加具体和细致地规定了DTNMA的应用程序管理和管理过程。
OPS
grow
- Title: Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
- Authors: Paolo Lucente(paolo@ntt.net), Yunan Gu(guyunan@huawei.com)
- Summary: 本文讨论了如何为网络设备供应商提供一种机制，允许他们定义自己的信息元素（Enterprise Bit 或 E-bit），以支持企业特定的信息。E-bit可以用于标记新引入的企业特定信息类型，同时保留了现有TLV编码的兼容性。此外，本文还探讨了在使用TLV数据时可能存在的安全和操作考虑。最后，本文指出了对IANA进行的操作建议，并提供了有关如何处理现有TLV类型的TLV编码的相关指导。
- Diff: 摘要 本文提出了一种在BGP监测协议(BMP)消息类型中定义企业特定TLV的方法。目前，BMP消息中已有支持TLV的数据格式，但需要引入一种新的机制来允许使用企业特定信息元素。本文提出的这种机制是通过引入一个名为E比特的额外位来实现的。此外，本文还定义了与企业相关的TLV编码规则，并对现有的TLV编码进行了更新。 与旧版不同的是，本文不仅修改了现有TLV编码规范以支持企业特定的信息元素，而且还添加了新的TLV编码规则和注释说明。此外，本文对TLV编码进行了调整，以便兼容当前和未来的新消息类型。同时，本文也考虑到了安全性和操作性方面的考虑，提出了相应的建议。总的来说，本文是对现有TLV编码规范的一个改进，有助于提高BGP网络监控系统的灵活性和可扩展性。
- Title: BMP v4: TLV support for BMP Route Monitoring and Peer Down Messages
- Authors: Paolo Lucente(paolo@ntt.net), Yunan Gu(guyunan@huawei.com)
- Summary: 本文是关于BGP监测协议（BMP）的一个标准文档，该文档定义了在当前版本4下对BMP消息类型进行扩展以支持TLV数据的方法。主要更新有： 1. 版本：将BMP版本从4变更为4，以便兼容现有文档。 2. TLV编码：对于Route Monitoring消息，引入了一个新的BGP消息TLV，它包含一个指向NLRIs的组TLV。对于Peer Down通知消息，允许使用额外的数据项，并可以将其与BGP Update PDU一起序列化。 3. 路由监视和同伴下降消息：这些消息不支持TLV数据，但文稿提出了一种解决方案来支持这种数据格式，使得所有BMP消息类型都可以支持TLV数据。通过定义一组TLV，可以为不同的需求提供不同类型的TLV数据。 4. 错误处理：文稿提供了错误处理策略，包括如何正确解析带有TLV数据的BGP消息。 5. 安全考虑：没有提及具体的安全措施。 6. 操作考虑：文稿建议根据实际需求灵活调整TLV数据的位置和数量。 7. 保留旧的TLV类型：尽管需要改变一些TLV结构，但保留了一些已存在的TLV类型，如Per-Peer Header、Reason等。 8. 网元地址：作者提供了联系方式，供读者联系作者获取更多信息。 总的来说，这篇文稿是一个关于扩展BMP协议中的TLV数据支持的技术指南，旨在使所有BGP消息类型都能支持TLV数据，从而实现更高效的信息传递。
- Diff: 该文档的主要区别在于引入了新的TLV数据类型支持（Type = TBD1、Type = TBD2、Type = TBD3、Type = TBD4），以及定义了新的TLV值域（如Type = TBD5、Type = TBD6）。此外，还对Route Monitoring和Peer Down消息进行了结构上的调整，使其能够承载额外的数据，并且允许所有定义的消息类型都提供TLV数据。这些变化使TLV能够在多种不同的应用场景下进行扩展和使用，为用户提供了更灵活的选择空间。 总结来说，相较于旧版本，该文档在TLV编码和扩展能力上做出了重大改进，增强了协议的可扩展性和灵活性，为未来的扩展和应用奠定了基础。
netconf
- Title: Support of Versioning in YANG Notifications Subscription
- Authors: Thomas Graf(thomas.graf@swisscom.com), Benoît Claise(benoit@claise.be), Alex Huang Feng(alex.huang-feng@insa-lyon.fr)
- Summary: 本文主要探讨了在当前版本的YANG推订阅机制上，如何扩展来支持版本化。首先定义了“ietf-yang-push-revision”模块，该模块包含模块名称、版本和版本标签等信息，并通过RPC请求中的修订、修订标签等字段来区分不同的版本。此外，还讨论了如何扩展YANG推订阅状态通知，包括修改后的订阅开始或修改的通知，以及新增的基于版本化的新属性，如修订、修订标签等。最后介绍了如何发现这个新特性并使其能在现有的网络管理系统中被识别。总的来说，这是对现有YANG推订阅机制的一个重要扩展，使得它能够处理不同版本的YANG模块，并且提供了一种更灵活的方式来指定订阅的版本。
- Diff: 这个新的标准文档（RFC8641）对原标准RFC8641进行了扩展，允许在订阅中指定特定的版本或最新版本的语义版本。例如，在订阅开始和修改时，它包括了模块名称、版本和版本标签。此外，它还提供了“ietf-yang-push-revision”模块，该模块可以扩展到支持版本化订阅状态通知，并能定义特定的版本或最新版本的语义版本。 与旧版本相比，主要的区别在于： 1. 增加了支持版本化的YANG订阅机制，可以在订阅开始和修改时使用特定的版本标识。 2. 提供了一个新的“ietf-yang-push-revision”模块，该模块支持版本化订阅状态通知，以及定义特定版本或最新版本的语义版本的能力。 3. 在更新消息中添加了支持特定版本或最新版本的语义版本的信息。 这些差异使得新版本更加灵活和可扩展，能够更好地适应网络管理和通信的需求。
- Title: YANG Notification Transport Capabilities
- Authors: Qin Wu(bill.wu@huawei.com), Qiufang Ma(maqiufang1@huawei.com), Alex Huang Feng(alex.huang-feng@insa-lyon.fr), Thomas Graf(thomas.graf@swisscom.com)
- Summary: 本文主要描述了网络配置访问控制模型（NACM）在限制特定NETCONF或RESTCONF用户对预配置所有可用NETCONF或RESTCONF操作和内容集进行访问方面的功能。本文讨论了使用HTTPS和UDP传输协议以及支持的消息编码格式等特性，旨在提供一个可扩展且安全的框架来处理和管理数据通知传输能力。 文稿详细介绍了如何在NETCONF和RESTCONF上下文中实现这些功能，并强调了它们的安全性要求，例如使用SSH、TLS和QUIC等安全传输层协议。此外，还提供了如何通过YANG数据模型来管理和认证特定用户的示例。 总之，本文为实现网络数据传输能力的灵活性和安全性提供了有用的指南，特别是对于那些需要在不同的环境中管理和保护数据的通知服务。
- Diff: 以上新版本的英文标准文稿为NETCONF协议下新增加的一个关于YANG通知传输能力的通知模型。该模型在原有的YANG模块体系基础上提供了更多的运输相关属性和功能，如对YANG推送的通知进行进一步的扩展，增加了HTTPS和UDP配置的传输连接、编码格式和安全机制等特性。 相较于旧版，主要区别如下： 1. 增加了新的YANG模块名称：ietf-notification-transport-capabilities。 2. 新增了新的YANG树结构图（Tree Diagram）。 3. 提供了新的YANG模块接口信息（IANA Considerations）。 4. 加入了新的安全性考虑部分（Security Considerations）。 5. 对于使用.NETCONF/RESTCONF API访问的数据节点进行了描述性限制。 6. 改进了文档的规范性和可用性说明。 总的来说，该新版本文稿在原有基础上做了一些重要的补充和完善，更加完整地满足了用户的需求，并且增强了其灵活性和实用性。
RTG
detnet
- Title: DetNet multidomain extensions
- Authors: Carlos J. Bernardos(cjbc@it.uc3m.es), Alain Mourad(alain.mourad@interdigital.com)
- Summary: 本文主要讨论了多域DetNet的问题。DetNet是一种无线多域网络，它可以在不同的物理媒体上运行，并使用分布式路径计算元素（PCE）来计算可能的路径。但是，这种架构在处理多个独立的DetNet域时遇到了问题，因为每个域都需要了解其他域的信息和资源以确保可靠的通信。 为了解决这个问题，作者提出了Multi-domain DetNet（MDDetNet），这是一种扩展的DetNet框架，允许跨不同域进行通信。该框架通过定义新的机制和信号扩展，使得不同域之间的连接变得更加容易和可靠。例如，它可以利用PAREO技术，以及快速时间尺度下的传输选择决策，来提供高可靠性和服务水平。 MDDetNet的引入将有助于解决当前无线多域网络面临的挑战，如延迟、丢失率和带宽限制等问题。同时，它还可以支持多种类型的多域通信，包括无线和有线通信等。 总的来说，MDDetNet是一个重要的多域通信解决方案，有望改善无线多域网络的性能和效率。
- Diff: 新的英文标准文档“DetNet Multidomain Extensions”详细描述了无线多域（Raw）问题，并提出了扩展以实现无线多域操作的新机制和信号扩展。主要有以下不同点： 1. 新文档详细解释了Wireless Raw（即无线多域）问题，而老文档则只是提到这个概念。 2. 新文档提出了多域间的协调机制来解决跨域RAW连接的问题，包括定义多域内的OAM机制等。 3. 新文档引入了PAREO技术，这是一个结合了无线特性的增强转发能力的技术。 4. 在处理无线多域场景时，新增了对多个无线和有线网络之间的互联场景的支持，以及如何在这些场景中确保可靠性与可用性。 5. 这个文档还更新了原来的术语“PLR”为现在的“PSE”，以便更好地反映当前的技术架构。 总的来说，新的文档提供了更全面、深入的信息，并且增加了更多关于无线多域通信的细节。
rtgwg
- Title: Dynamic Networks to Hybrid Cloud DCs: Problems and Mitigation Practices
- Authors: Linda Dunbar(dunbar.ll@gmail.com), Andrew G. Malis(agmalis@gmail.com), Christian Jacquenet(christian.jacquenet@orange.com), Mehmet Toy(mehmet_toy@cable.comcast.com), Kausik Majumdar(kausikm.ietf@gmail.com)
- Summary: 本文主要讨论了企业与云数据中心连接时面临的一些问题以及相应的解决方案。这些问题包括但不限于： 1. 增加的BGP peering错误和解决方法，如过滤不必要的路由、使用默认路由等。 2. 站点失效和减少影响的方法，如利用DNS进行站点选择。 3. DNS在混合工作负载中的实践问题，如依赖于客户端行为和无法考虑网络层条件（如邻近性）。 4. 动态连接到云数据中心的企业分支机构的问题，如如何扩展私有VPN以访问云数据中心的服务。 5. 解决IPsec隧道到云数据中心的距离问题的方法，如动态地将IPsec隧道连接到不同的CPE上。 6. 对连接到云数据中心网络的需求，如支持灵活的流量管理策略。 7. 安全方面的考虑，如防范DDoS攻击和数据泄露风险。 8. IANA关注事项，即不需要关注IANA的相关行动。 总的来说，本文旨在为解决上述问题提供一些建议性的解决方案，并强调协调方案的重要性。
- Diff: 本文是一篇关于动态网络连接到云数据中心（DC）的问题和解决措施的文稿。该文稿指出，由于企业需要利用现有的VPN服务来连接到云数据中心，因此面临着一系列的网络问题，如BGP连接错误、站点失效等。此外，DNS选择云数据中心的位置也存在问题。针对这些问题，文中提出了相应的解决方案，包括配置策略以减少BGP连接错误、优化DNS查找路径、避免DNS记录冲突、使用异步DNS缓存刷新技术等。 总的来说，该文稿对如何通过动态连接的方式将分支机构与云数据中心进行连接进行了探讨，并提出了一些有效的解决措施。这些措施对于企业实现高效且安全地连接到云数据中心具有重要的参考价值。
SEC
lamps
- Title: Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
- Authors: Ben S(ben.s3@ncsc.gov.uk), Adam R(adam.r@ncsc.gov.uk), Daniel Van Geest(daniel.vangeest@cryptonext-security.com)
- Summary: 本文是关于使用模块- lattice 基于数字签名算法（ML-DSA）在加密消息语法（CMS）中的标准。文稿详细介绍了使用ML-DSA的定义，包括纯模式和预哈希模式。此外，它还讨论了安全考虑、操作考虑和可能的影响。 总的来说，本文提供了一个详细的指南来使用ML-DSA进行CMS的签名。它强调了使用纯模式的优势以及预哈希模式的潜在优势，并指出了未来保护这种攻击的技术方向。它还给出了可能影响和建议的实施措施。
- Diff: 新的（Intelligent Protocol Security Key Information）草案提供了关于使用模块型基于分组密码数字签名算法（Module-Lattice-Based Digital Signature Algorithm, ML-DSA）在加密消息语法（Cryptographic Message Syntax, CMS）中的规则和约定。 关键的区别在于： 1. 该草案定义了用于标识ML-DSA签名算法的算法标识符OID。 2. 定义了如何使用ML-DSA在CMS中生成和验证签名。 3. 描述了如何处理没有包含签名属性的情况，以及对使用时需要考虑的一些因素。 4. 提出了一个可能的预哈希模式，允许在不同的可信计算模块中执行预哈希操作。 5. 强调了防止算法置换攻击的重要性，并指出未来保护这些样式攻击的方法可能会涉及改进实现内部功能的互操作性。 6. 指出了使用定态随机数生成器的风险，并建议实施相关保护措施以适应特定用途。
oauth
- Title: OAuth 2.0 for Browser-Based Applications
- Authors: Aaron Parecki(aaron@parecki.com), David Waite(david@alkaline-solutions.com), Philippe De Ryck(philippe@pragmaticwebsecurity.com)
- Summary: 是关于如何在浏览器内执行OAuth 2.0应用的技术指南。文稿分析了不同架构模式（如前端代理、后端中介和直接客户端）对于实施浏览器中的OAuth 2.0应用程序的安全挑战，并提供了相应的解决方案。主要威胁包括恶意JavaScript攻击，它能够窃取令牌并进行其他恶意活动。文稿还讨论了使用OAuth 2.0替代方案时需要注意的安全性考虑。 总结而言，这篇文稿指出虽然浏览器环境提供了一些优势，但它们也带来了一些新的安全挑战，需要开发者采取措施来保护用户数据和隐私。例如，为了防止恶意JavaScript代码损害用户的数据或访问未经授权的服务，开发者应遵循最佳实践，如限制权限、使用强身份验证以及定期更新软件。同时，开发者还应该注意使用跨域资源共享(CORS)，以减少被攻击的风险。
- Diff: 以上新版的中文总结： 该文档详细讨论了在浏览器环境中使用OAuth 2.0进行应用开发的安全威胁、攻击后果和最佳实践。它对恶意JavaScript代码执行攻击场景进行了分析，并提出了解决方案。这些解决方案涉及到后端前端（BFF）、令牌中介后端和直接浏览器客户端等三种架构模式。每种模式都有其自身的安全性和局限性。 相比于旧版，主要区别在于： 1. 现行的最佳实践是使用OAuth 2.0授权码获取方式，而不是Implicit grant或其他类型的方式，以防止跨源资源共享(CORS)问题导致的攻击。 2. 在后端前端(BFF)模式下，可以实现更安全的访问令牌管理和刷新令牌管理。 3. 直接浏览器客户端模式下的安全性相对较低，因为它依赖于用户浏览器的行为，因此更容易受到攻击。 4. 两种模式都存在潜在的问题，如用户交互要求高、资源服务器配置复杂等。 总的来说，这个新版比旧版增加了更多关于安全性的分析，强调了不同架构模式的安全性和局限性，并提供了相应的建议来解决这些问题。
WIT
tsvwg
- Title: DCCP Extensions for Multipath Operation with Multiple Addresses
- Authors: Markus Amend(markus.amend@telekom.de), Anna Brunstrom(anna.brunstrom@kau.se), Andreas Kassler(andreas.kassler@kau.se), Veselin Rakocevic(veselin.rakocevic.1@city.ac.uk), Stephen Johnson(stephen.h.johnson@bt.com)
- Summary: 本文主要讨论了DCCP协议中的多路径支持扩展，即Multipath DCCP（MP-DCCP）。它允许在同一连接上同时建立多个数据流，通过不同的路径。这个扩展提供了多种功能，如分发、重排序和断开连接等。文稿详细介绍了MP-DCCP的工作模式、操作规范以及如何在各种使用场景下应用它。 总结而言，本文是关于将现有的DCCP协议扩展到支持多路径传输的技术文档，从而为用户提供更灵活的网络连接解决方案。它的设计目标是在保证通信可靠性的前提下，提升网络资源利用率，改善用户体验。本文还提出了一些关键概念和技术细节，并定义了相关术语和操作流程，以便于实现和维护。
- Diff: 新的英文标准文稿比之前的版本在功能扩展方面做出了重大改进。它允许应用同时使用多条路径来传输数据，从而提高了网络资源利用率和用户体验。此外，该协议还支持延时敏感服务的不同需求，并具有延迟、可靠性和顺序交付能力。 相比之前版本，新的文档增加了以下特点： 1. 支持多个子流（分道扬镳）：将应用程序的数据流分割成不同的子流，这些子流可以在不同路径上传输。 2. 支持多种路由：通过修改连接标识符来支持多种路由。 3. 允许重排序数据：通过协商选择用于路由的优先级来支持重排序。 4. 重新启动断开连接：允许通过重置请求关闭断开连接。 5. 安全性考虑：提供了额外的安全措施以保护从一个连接转移到另一个连接的应用程序通信。 6. 与中间件的交互：定义了如何处理非DCCP流量穿过中间件的情况。 7. 实施细节：提供了一个完整的实施指南。 总的来说，这个新版本的文档为多路传输协议(DCCP)添加了丰富的扩展特性，使其能够更好地满足用户的需求。