今日共有6篇文稿更新，涉及4个area里的6个WG

ART

dmarc

  1. I-D: draft-ietf-dmarc-dmarcbis-35
  • Title: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
  • Authors: Todd Herr(todd@someguyinva.com), John R. Levine(ietf@johnlevine.com)
  • Summary: 这篇文档描述了域名验证、报告和一致性(DMARC)协议。它允许域主发布DNS记录，以指示他们希望处理失败验证的消息，并要求报告关于使用该域名的消息。这样可以减少欺诈性使用域名的行为。 这个协议避免了需要第三方或预发送协议的情况，保持了当前电子邮件基础设施的积极方面。虽然DMARC引入了第三方发送者（即授权向操作员发送邮件的代理），但它们仍然自由提供服务与DMARC结合。它专注于防止对作者域名未经授权使用的具体形式的精确域名欺骗直接。它不解决其他问题，如类似域名名称的视觉相似或滥用可读的人机阅读显示名称（“表亲域名”）以及对RFC5322.From人类可读显示名称中的展示名攻击的拒绝访问。 它还定义了一个叫做标识器对齐的概念，要求两个主体之间有相同的组织域或严格一致。这个概念是通过比较两个实体之间的域来实现的。如果一个实体具有另一个实体相同或相同的组织域，则它们被认为是进行了识别对齐。这个概念允许在某些情况下接受一个没有明确表示的值的验证结果，从而降低垃圾邮件的发送率。 此外，这个协议也包括了用于收集定期聚合报告到域主的或公分母运营商的特定信息的功能。这些报告可以用来检测欺诈性使用域名的方法，并且可以用来标记自己的认证实践有问题的地方。然而，发送报告是根据用户的决定来进行的，并不需要发送所有可能的报告。由于这些原因，它有助于提高网络安全性，减少了垃圾邮件的数量，提高了电子邮件的安全性，同时也提供了更多的过滤选择。

emailcore

  1. I-D: draft-ietf-emailcore-rfc5321bis-35
  • Title: Simple Mail Transfer Protocol
  • Authors: Dr. John C. Klensin(john-ietf@jck.com)
  • Summary: 本文主要概述了简单邮件传输协议(Simple Mail Transfer Protocol, SMTP)的基本架构、扩展模型和通信模式。它澄清了之前的文档，包括早期版本的RFC 5321，为当前的互联网环境提供了新的功能和改进。该标准定义了基本的邮件传输协议，以及如何在不同的网络环境中进行发送和接收邮件。文稿总结了其历史背景，指出它是现代电子邮件系统的基础，并介绍了其最新的版本——RFC 5321。

RTG

lisp

  1. I-D: draft-ietf-lisp-group-mapping-01
  • Title: LISP Multicast Overlay Group to Underlay RLOC Mappings
  • Authors: Vengada Prasad Govindan(venggovi@cisco.com), Dino Farinacci(farinacci@gmail.com), Aswin Kuppusami(aswkuppu@cisco.com), Stig Venaas(stig@venaas.com)
  • Summary: 本文是关于LISP（Locator/ID分离协议）多播覆盖组到下层路由记录映射的研究。主要讨论了如何通过两种方法来选择下层路由记录（Group Routing Record，GRR），包括基于哈希的选择和基于映射系统的查找。这两种方法都有其优缺点：基于哈希的方法可以实现完美的复制，但需要更多的底层状态；而基于映射系统查找的方法则可以在一些情况下解决冲突。 此外，还提出了一个处理非LISP接收器的问题：当LISP源节点连接多个接收者时，这些接收者不能直接接收到LISP源节点发送的LISP流。为了解决这个问题，LISP设计了一种新的机制，允许接收者通过注册并提供自己的U-ROUTING地址来进行代理转发。 总的来说，本文提供了LISP多播覆盖组到下层路由记录映射的一种新方法，并给出了相应的技术细节和安全性考虑。它是一个重要的研究工作，有助于改善多播网络中的通信效率和可靠性。

savnet

  1. I-D: draft-ietf-savnet-intra-domain-problem-statement-07
  • 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源地址验证机制存在的问题，并提出了改进的需求。文稿首先介绍了Intra-Domain源地址验证的基本概念和需求语言，然后对现有的Intra-Domain源地址验证机制进行了分析，指出了它们在准确性和动态适应性方面的不足，并提出了一些改进建议。最后，文稿总结指出未来需要开发能够自动适应网络变化、提供增量保护、快速收敛等特性的Intra-Domain源地址验证新机制。

SEC

radext

  1. I-D: draft-ietf-radext-deprecating-radius-04
  • Title: Deprecating Insecure Practices in RADIUS
  • Authors: Alan DeKok(aland@freeradius.org)
  • Summary: 《Deprecating Insecure Practices in RADIUS》这篇文档主要讨论了RADIUS协议的安全性问题。该文档指出，由于MD5等旧有安全措施已不再适用，需要采用更安全的加密和认证机制来保护RADIUS协议。其中，对RADIUS/UDP、RADIUS/TCP和RADIUS/DTLS协议进行了推荐，并提出了一系列具体的改进措施。 具体来说： 1. 应用TCP或TLS进行传输，以确保数据在互联网上传输时的隐私性和安全性。 2. 对Access-Request包中的所有信息（除了MD5验证）进行加密处理，从而减少个人信息泄露的风险。 3. 应用Message-Authenticator字段，作为RADIUS通信中的额外身份验证手段，增强安全性。 4. 对于包含敏感信息的Access-Request包，应使用MD5校验和进行完整性检查。 这些措施可以显著提高RADIUS系统的安全性，防止未经授权的用户接入网络，以及攻击者利用MD5碰撞等问题实施攻击。此外，文档还强调了对于RADIUS/UDP、RADIUS/TCP和RADIUS/DTLS协议的应用，需要综合考虑各方面的因素，如网络环境、设备性能等因素，以便实现最佳的防护效果。

WIT

tsvwg

  1. I-D: draft-duke-tsvwg-udp-ecn-03
  • Title: Configuring UDP Sockets for ECN for Common Platforms
  • Authors: Martin Duke(martin.h.duke@gmail.com)
  • Summary: 本文主要讨论了如何在UDP上启用ECN，以及在Linux、Apple和FreeBSD等平台上实现这个功能的方法。它还介绍了如何在Windows平台上设置ECN并接收和发送ECN标记，并探讨了这些平台的安全考虑。最后，文稿提到了IANA对UDP ECN的支持。 总的来说，本文为用户提供了一个了解如何在不同平台下使用UDP ECN的功能指南，有助于其他用户或开发者更好地利用此功能。同时，它也提醒读者注意ECN可能带来的安全问题，并提出了相应的解决方案。