# OPSEC Notes IETF 114   {#opsec-notes-ietf-114}

26th July 2022

## Indicators of Compromise (IoCs) and Their Role in Attack Defence   {#indicators-of-compromise-iocs-and-their-role-in-attack-defence}

draft-ietf-opsec-indicators-of-compromise, Andrew Shaw

*   History of the draft - brought to secdispatch at IETF 107, adopted
    by OPSEC in January 2022, latest version published earlier this
    month
*   Motivation - document technique and capture best practice, share
    knowledge, prevent technique being overlooked in protocol design,
    bring cyber defence expertise to the IETF.
*   Definition of IoCs - opservable artefacts relating to attacker or
    activities (see draft)
*   Draft covers fundamentals, effective use, limitations and best
    practice. Case studies are included.
*   Further reviews and comments from the WG are welcomed.
*   Is the document ready for WGLC?
*   Jen Linkova (JL) - Who has read the draft? 2 raise hand, 4 did not
    raise hand.
*   **Decision: Will start last call on the list, but needs reviewers,
    so would like volunteers to review.**

## Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV)   {#source-address-validation-using-bgp-updates-aspa-and-roa-bar-sav}

draft-sriram-sidrops-bar-sav, Igor Lubashev

*   Much interest in the community in Source Address Validation (SAV) to
    reduce unauthorised source address spoofing. Have been trying to
    solve this problem for 20 years: BCP 38, RFC 3704, RFC 8704. People
    are looking at this in Savnet at this IETF.
*   The problem is that RFC 8704 still blocks too much. This is hard
    because we're trying to infer data plane forwarding from BGP and it
    wasn't designed for this.
*   Also challenges with CDNs and Direct Server Return.
*   In both 2015 and 2022 only 15% of networks were doing SAV.
*   Proposal is BAR-SAV - use information from BGP, ASPA and ROA as an
    improvement on RFC 8704. Requires no change on the wire for any
    protocols, so easy to deploy and immediately beneficial.
*   Overview of how the algorithm works. Iterative, getting information
    from ASPA and BGP AS\_PATH in the first stage, then look for
    prefixes from ROA and BGP.
*   Application to CDN use case.

## Attribution of Internet Probes   {#attribution-of-internet-probes}

draft-vyncke-opsec-probe-attribution, Éric Vyncke

*   Many research projects require sending 'strange' packets (probes)
    over the internet e.g. extension headers. Sometimes these trigger
    security alarms or harm network. Would like to have a way to label
    those probe packets saying it isn't an attack and giving a way to
    contact sender.
*   Draft proposes a Probe Description URI. That could be a link to the
    probe description, a contact email address, a contact phone number
    etc.
*   Two ways of doing this URI:
    1.  In-band - put attribution URI in all packets. Could be at the
        beginning of data or at end of data (with appropriate
        delimitation by null byte(s))
    2.  Out-of-band - rely on the source address, then put the details
        at a .well-known address.

*   ID used by draft-vyncke-v6ops-james-latest.
*   Suggestions/comments welcome. Would like to call for adoption if
    there's interest by OPSEC.
*   Ron Bonica - This draft might allow network operators to filter
    packets that contain this URI. That might bias the results of the
    experiment. Eric Vyncke (EV) - Yes, that's a good point, we should
    include it in the draft.
*   Nalini Elkins - What stops me putting someone else's name and phone
    number in the URI? EV - As a good researcher you want to do
    something good for the network, but everything can be bypassed.
*   Warren Kumari - Which v6ops JAMES thing did you do this for and did
    anyone contact you? EV - No one contacted us, the mail2 (sp?)
    example with in-band URI.
*   Fernando Gont - Good idea in theory, the challenge is that quite
    often it would affect the packets being sent.
*   Robert Story (RS) - On the in-bound approach have you thought about
    putting some identifier in the packet so that wireshark/tcpdump
    could identify it? EV - Like magic bytes? RS - The fact networks
    could filter these out could be considered a feature, you can
    normally opt out of this sort of research problem.
*   Jen Linkova - When the measurement is performed from large number of
    enpoints (e.g. RIPE Atlas probes or just hosts), it might not be
    possible to run any service on the source IP of the probe pakcets
    itself.
*   Igor Lubashev - This might mean we need an identifier address
    validation draft. EV - Keep it simple.
*   Warren Kumari - Don't want the perfect to be the enemy of the good,
    at the moment we don't have anything like this, so something would
    be better than nothing.
*   **Decision: Run adoption call on the list after meeting**

## AOB   {#aob}

Warren Kumari - please consider running for OPS AD, come and speak to me
if you're interested.