OPSEC Notes IETF 114

26th July 2022

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)

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

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

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