Minutes IETF104: opsec
minutes-104-opsec-01

Meeting Minutes Operational Security Capabilities for IP Network Infrastructure (opsec) WG
Title Minutes IETF104: opsec
State Active
Other versions plain text
Last updated 2019-03-26

Meeting Minutes
minutes-104-opsec

Meeting: OPSEC at IETF-104
Day: Monday 3/25/2019
Jabber: Warren Kumari
Notes: Chris Morrow (retyped by Eric Vyncke) and ???

draft-ietf-opsec-v6-14, Operational Security Considerations for IPv6 Networks,
K. Chittimaneni
==============================================================================================

The speaker could not make it due to plane having issues...
Co-chair and co-author Éric Vyncke presenting from his own laptop, video not
displayed. Slides not available.  Éric: "Slides are hard.. we're doing this
freehand!"

Document started in 2012.

Main change since last version (present 15, diff from -14):  (actually,
datatracker says newest version is -16, so diff of -16 and -15 from -14. Added
by Éric after the WG meeting: there are 2 days between -15 and -16, I should
have been clearer though.

We do not cover IoT world, just ISP, residential or enterprise.

Various disucssion about ULA, the discussion was very fraugt with peril, point
now to ULA usage considerations document instead of trying to cover this in the
opsec document.  Now we simply say "go to ULA considerations" we say what ULA
is, and "go there".

Jen Linkova try not to introduce confusion ULA RFC1918, (text draws similarity
to 1918 private address space): "ULAs are like 1918, please don't do that?"
Éric: "great! 3 lines to 2 lines!! w00t!"

Bunches of followup from Fernando Gont and Ron Bonica, thank you for those.

section about SLAAC and generating MAC addresses (2.1.4) has many changes,
mostly reductions in text.  also discussion of MAC addresses wrt SAVI in 2.6
section 2.3.2 SAVI updated section 2.3.3 on securing DHCP is all new text

Éric: the authors would like to have a second WGLC.

Ron Bonica, speaking as regular member, not co-chair, like to bring up some
document issues: 1) first section says "we should use PI for security" - do we
really want to recommend that?  would explode routing tables.
  Eric: maybe we need to address wording
   Eric: "better to get PI so you are independent from your ISP, etc"
     Jen: "should not be in the document... not really security?"
     Rudiger: "Can't find security reasoning for PI? Where is it?"
     RonBonica: "Idiosyncracies of ipv6...." don't often translate to security
        considerations... linkage between idiosyncracies and security
        considerations ought to be linked better.
  JenL: have written IRR words about PA and PI.  PI words should not be in this
  document.  private

2) there are other points that talk about quirks of IPv6, but not about whether
these are security consideration.  For example, it says some networks drop
extension headers.  that may be true but it is not a security consideration.
  Eric as author: yes, we need to address text.

RonB: as co-chair:  how many have read this document in the last year?  how
many would be willing to comment in the next year? about 5 to 10.

Nathalie Trenaman of RIPE NCC: have been following for years:  Yes, words about
PI addresses should not be in the document.  I agree with Jen's comments about
1918 private address space. But aside from that "move forward please".

Ron B: as co-chair again.  will look for a new version and will perhaps do wg
last call.

Tim Chown:  some people consider some of the topics to be risk management, not
security consideration.  Some people conflate the two.  Maybe there should be a
section about risk. Eric: I will re-read 7381 that we co-authored to check
whether there is a section about risk management.

enhanced-feasible-path-reverse-path-filtering, Sriram Kitapuldi
===============================================

Sriram Kitapuldi NIST: have reviewed document and think it is good shape and
ask for wg last call.

RobB: as co-chair.  I agree and will do wg last call.

Meeting Ajorned....  11:45am