OPSEC, session 1 ========== Jabber (Joel J), Meeting Minutes (Stefan W) selected Administrivia slide State of the Union slide Agenda Bashing - no changes Presentation: SACM Vulnerability Assessment Scenario - see slide deck - ———————————— Mic: questions about Security Considerations - What is done do prevent endpoints contacting an unauthorized server? Dave: service discovery = DNS SRV records -> DNSSEC can secure this That is not currently in the draft though: should be added. Dave: two drafts that add information repository considerations… draft-ietf-mile-rolie will be discussed in MILE session. Presentation: STRIDE towards IPv6 - see slide deck - ———————————— (narrative of slide 15 incomprehensible, skipped to 16, ended with 16) Joel: recaps comments from mailing list regarding references author will update draft accordingly Presentation: Operational Security Considerations for IPv6 networks - see slide deck - ———————————— at least four volunteers for review of -08 version: Fred Baker, Fernando Gont, Lee Howard and Markus de Bruen (session 1 ends 5 min ahead of schedule) opsec, session 2 ============== Presentation: A Configuration File Format for Network Services on Leaf Devices - see slide deck - ———————————— 2 people read the draft; 4 willing to review and comment: Eric Vyncke, Fernando Gont, Stig Venaas and Joel Jaeggli Presentation: draft-vyncke-pim-mld-security - see slide deck - ———————————— Stig: multicast-problem: only off-link attacks? or others? flooding and amplification, disruption of multicast streams Stig: multicast on layer 2 (Wi-Fi) has its own problems Stig: understand security issues around unicast - but making it illegal is questionable there are good reasons for unicast in some scenarios Stig: 255 hop limit - can be done, but will take a long time to get hosts upgraded to honor this routers should never forward link-local anyway (do some OSes do this?) Tim Chown: how do the unicast attacks work? What scope? is happening on an adjacent link. Some OSes accept with hop limit > 1; some with non-local source address. Tim: okay, if limited to on-link then filtering as envisaged is easier. Stig: could guess router address (64-prefix and ::1 is often router) and pretend to have more listeners. Offlink attacks on multicast are really hard. Presentation: Network Ingress Filtering - see slide deck - ———————————— empty queue three volunteers for reading draft: Joel Jaeggli, Eric Vyncke, Markus de Bruen Presentation: On Firewalls in Network Security - see slide deck - ———————————— Joel: document has generated some controversy, just not in this group. It’s challenging to generate enough inertia to get it into a WG state. Gunter: suggest to discuss more on the mailing list before adoption decision is taken Presentation: Requirements for IPv6 Enterprise Firewalls - see slide deck - ———————————— Tim: had a glance, looks useful. Eric: is this an OPSEC topic? Is it even an IETF topic at all? Tim: it seems to be in the spirit of RIPE-554. Eric: asks to remove/rename three requirement sections (DoS, VPN, GEN); there are many MUSTs in other sections which looks inappropriate. Author: aware that the document talks about two different things: technology vs. products. Chairs ask for general comments on OPSEC working group mailing list: Tim: v6ops discusses what should/should not be IETFs business regarding extension filtering. Eric: if the IETF were to produce a list of things to filter in 2016, would be a runaway document and be obsolete in the moment it is published. Tim: maybe turn around, and produce a whitelist of things to allow in any case. Joel: tension between what operators find necessary and what people say IETF should or not do. Documenting what is being done maybe, but without making value judgements. This could inform further processes. Fernando: did that, just described something that was done in v6ops - but was still controversial. Joel: this was about „Extension headers in real world“ - is a good example: community passed it, IESG did not like it precisely because it had no value judgements in it.