Session Date/Time: 23 Oct 2024 14:00

CORE

Summary

This meeting primarily focused on advancing Pull Request (PR) 40, which addresses issues related to CoAP source address trustworthiness, including denial-of-service (DoS) amplification and replay protection. Key discussions covered existing mitigations from other protocols (QUIC, DTLS) and their applicability to CoAP, as well as specific considerations for OSCORE. The group outlined a plan to refine PR 40 for an upcoming merge and resubmission. Other issues, such as clarifying CoAP URI requirements and the Proxy-Scheme option, were also briefly discussed for future work.

Key Discussion Points

PR 40: Source Address Issues
- Problem Statement: Source addresses in CoAP requests are often untrustworthy due to spoofing, roaming, or NAT-induced changes. This leads to operational instability (e.g., difficulty managing observation requests) and DoS opportunities.
- Existing Mitigations:
  - RFC 7252's Echo option.
  - DTLS Connection IDs provide a way to continue work with a different source address.
  - QUIC defines an anti-amplification limit (factor of 3), which is considered a good approach for UDP-based protocols in the IETF.
  - DTLS also has a return routability check draft, which requires negotiation, unlike CoAP's Echo option.
- OSCORE Considerations: The discussion touched on how return routability and Echo option usage would apply in OSCORE contexts, differentiating between inner and outer options, and the complexity of addressing active attackers or triangle routing while maintaining proxy compatibility. It was noted that this discussion might be too detailed for the current section of the document, which aims to provide concrete help.
- Document Structure of PR 40:
  - Amplification Mitigation: The PR clarifies CoAP's adoption of the anti-amplification factor from RFC 9175 (which updates RFC 7252) and recommends the Echo option as the normal way to handle this.
  - Replay Protection: Concerns were raised that the text in PR 40's replay protection section was not clearly relating replay protection to address changes or the Echo option. Further clarification is needed.
  - General Point: The document correctly emphasizes that "safety is an application concept."
Other Issues for Future Discussion
- Issue 41: "What do you really need to take to send a CoAP request?": This issue seeks to define the necessary context (e.g., URI, DNS server, certificate roots) for sending a CoAP request, drawing parallels with HTTP and highlighting CoAP's potentially greater complexity in this area. The discussion noted the importance of the URI information model (RFC 7252 Section 6).
- Issue 10: "Request URI not defined": This relates to the broader URI discussion and the taxonomy of different proxy scenarios.
- Proxy-Scheme Option: A clarification was proposed for Proxy-Scheme regarding its default behavior. The suggestion is to align it with URI-Host, where the scheme associated with the transport (e.g., coap, coaps, coap+tcp) would be the implied default. This would simplify implementation for transports like CoAP over TCP and Transport Indication.
  - It was agreed that a clarification in core-clar that this choice would lead to the same result (even if not explicitly defined that way) would be beneficial, allowing other documents (like CoAP over TCP or CoAP over DNS) to reference this clarification.
  - The behavior regarding changes in transport or omission across hops was discussed, confirming that the hope-by-hope relevance of the option would handle such scenarios.
Session Resumption/Continuation: Aim provided input on PR 40, clarifying that session resumption is a sequence of messages, and it was a common approach to continue encryption if a peer assumes an IP address change. The term "continuation" or "recovery" was discussed for describing this aspect of CoAP relationship management.
Pull Request Management: The mechanics of making changes to Christian's pull request (PR 40) from the working group repository were discussed, highlighting the occasional need to synchronize branches.

Decisions and Action Items

Decision: The working group will prioritize completion of PR 40 (addressing source address issues, amplification, and replay protection) for the upcoming draft submission window.
Action (Christian): Polish the text of PR 40, specifically clarifying the replay protection section to better explain its relation to address changes and the Echo option.
Action (Christian): Review other open issues to determine if any are closed or superseded by PR 40's content.
Action (Christian): Continue work on issues 41 and 10, and incorporate proposed clarifications for the Proxy-Scheme option into core-clar.
Action (Christian): Ensure his local branch for PR 40 is synchronized with the main repository to incorporate any external contributions.

Next Steps

Continue refining PR 40 based on the discussions, aiming for a merge.
Resubmit the updated draft including PR 40 when the IETF draft repository reopens (Sunday morning, Dublin time).
Further discussions on PR 40, as well as issues like URI context (Issue 41, Issue 10), and DTLS over CoAP aspects, are anticipated during the upcoming hackathon and in-person meetings in Dublin.