Session Date/Time: 26 Jul 2022 17:30

opsec

Summary

The opsec session featured three presentations: a working group draft on Indicators of Compromise (IoCs), an individual draft on Source Address Validation (SAV) using AS-Path and RPKI (BAR-SAV), and an individual draft on attributing Internet measurement traffic. The working group draft on IoCs is nearing Working Group Last Call, while the other two drafts were presented for discussion and potential adoption. Discussions covered technical aspects, deployability, and potential side effects of the proposals.

Key Discussion Points

Indicators of Compromise (IoCs) - draft-ietf-opsec-indicators-of-compromise
- Motivation: To document a widely used operational security technique, share best practices with the IETF, raise awareness for protocol designers regarding IoC usability, and bring cyber defense expertise into the IETF.
- Definition: IoCs are artifacts (tactics, techniques, tools, IP addresses, domain names, hashes) used to identify attackers. The "Pyramid of Pain" illustrates the inverse relationship between the ease of finding an IoC and the difficulty for an attacker to change it.
- Draft Content: Covers fundamentals (Pyramid of Pain, IoC lifecycle), effective usage, benefits, case studies, limitations (e.g., lightweight defense, precision vs. effort), and best practices for sharing IoCs.
- Status: The draft has undergone several rounds of review and is considered stable. The authors are seeking final reviews.
- Discussion: The chair emphasized the need for volunteers to review the draft during Working Group Last Call, stating that silence should not be taken as an indicator of consensus to progress.
Source Address Validation (SAV) with AS-Path and RPKI (BAR-SAV) - draft-lubachev-opsec-sav-aspa-raw
- Problem Statement: Address spoofing remains a significant problem after 22 years. Existing SAV techniques, primarily relying on BGP inferences (like RFC 8704), are often insufficient because BGP's reachability signal isn't designed for data plane forwarding validation. They fail in common scenarios like route filtering, traffic engineering, and Direct Server Return (DSR) use cases. Adoption rates for SAV remain low (around 15%).
- Proposal (BAR-SAV): An improvement over RFC 8704 that augments BGP information with data from AS-Path Authorization (ASPA) and RPKI Route Origin Authorizations (ROAs). The key principle is deployability without requiring changes to existing protocols on the wire.
- Algorithm: A two-phase process:
  1. Discover Customer Cone: Starting from the local AS, infer customer relationships by analyzing AS-Path data in BGP messages (any AS-Path hop) and ASPA records.
  2. Discover Valid Prefixes: For each AS in the discovered customer cone, use ROA information and BGP updates (where the AS is the origin AS) to build the SAV list for the interface.
- Use Cases: BAR-SAV addresses the limitations of RFC 8704, enabling scenarios like DSR (by requiring ROAs for prefixes that might be sourced from non-originating ASes) and aiding in route leak detection by leveraging ASPA.
- Discussion: No questions or comments were raised during the session.
Attributing Internet Measurement Traffic - draft-hoffman-opsec-measurement-attribution
- Motivation: Internet measurement campaigns inject synthetic traffic that can trigger security alerts, unusual traffic patterns, or even system crashes. Researchers need a standard way to attribute this traffic to an experiment and provide contact details, distinguishing it from malicious activity.
- Proposal: Embed a Uniform Resource Identifier (URI) describing the experiment (including contact details) into the measurement traffic. The URI could be a URL, mailto, or phone number, following principles similar to RFC 9116 (security.txt).
- Methods:
  - In-band: Placing the URI directly into the packet's payload (e.g., ICMP, UDP, TCP SYN data) or within an IPv6 extension header option, terminated by null bytes.
  - Out-of-band: Relying on reverse DNS (e.g., a .well-known/probing.txt file on the source IP's domain, requiring an IANA registry) or running a web server on the source IP address that hosts the URI.
- Discussion:
  - Concerns were raised about potential filtering of packets containing the URI by network operators, which could bias measurement results. This was also noted as a potential feature, allowing operators to opt-out or for researchers to gauge network behavior.
  - The risk of abuse (e.g., false attribution) was acknowledged, but the authors emphasized the intent for good-faith researchers to provide attribution.
  - Using in-band data, especially in TCP SYN packets, might alter how the packet is processed by some systems. Out-of-band methods were suggested as potentially less disruptive to the probe's characteristics.
  - A suggestion was made to include a specific identifier (e.g., a magic number) in the packet to allow tools like Wireshark to easily recognize and display the attribution information.
  - The feasibility of running web servers on source IPs for measurements from numerous vantage points (e.g., RIPE Atlas) was questioned, with reverse DNS or generic flags being more practical alternatives.
  - There was a general sentiment that even an imperfect attribution mechanism is better than none.

Decisions and Action Items

Indicators of Compromise: The chairs will initiate a Working Group Last Call (WGLC) for draft-ietf-opsec-indicators-of-compromise on the mailing list next week.
Attributing Internet Measurement Traffic: The chairs will run an adoption call for draft-hoffman-opsec-measurement-attribution on the mailing list after this IETF meeting.

Next Steps

Indicators of Compromise: Reviewers are encouraged to read draft-ietf-opsec-indicators-of-compromise and provide comments during the upcoming WGLC.
BAR-SAV: Authors of draft-lubachev-opsec-sav-aspa-raw will continue to engage with the working group for feedback and potential progression.
Attributing Internet Measurement Traffic: The community is encouraged to review draft-hoffman-opsec-measurement-attribution and provide feedback during the adoption call.
Opsec AD Role: Warren Kumari encouraged interested individuals to consider running for the opsec Area Director position, whose term ends in March.