Minutes IETF102: opsec
minutes-102-opsec-00

OpSec 102
  Overview of active drafts - urpf-improvements - no updates
                              draft-opsec-ipv6 - no updates

                              eh-filtering - in IESG


  Ron Bonica - refresh discussion on: RFC4778 && RFC6192 && RFC7872
    OpSec Current Practices in ISP networks - 4778
    Protecting the Router Control Plane - 6192
      Stefan/David stepping in to add refresh
    IPv6 header extension processing RFC7872 -> refresh testing/work.
      Identify some ASN where EH's are dropped, discuss why with droppers.

  Gorry Fairhurst <missed> - pathspider may be useful in the testing.

  Benno - Recommedations for DNS Privacy Service Providers
    Context for draft/work:
      dns privacy - never meant to be private
                    snowden revelations brought forward dprive/work
                    public resolves experimenting as of 11/2017
        options: DNS over TLS, DNS over DTLS, DNS over HTTPS
                    DOT, <>, DOH
      requirements for operation being codified in draft.
      both traffic and at rest data security / retention policies
      current at-scale solutions from 1.1.1.1/9.9.9.9
        code in firefox-nightly - possibly 25k users only
        (comment from kumari @ mic)
      draft submitted with new context this week
      
      Data about on-the-wire considerations as well, possibly some logging
      tracking, cachesnooping problems to avoid. Text required from group.

      review required for sections about:
        anonymoziation/etc of data on server as well as analysis considerations
      protocol considerations as well (qname min, ecs, local root)
      DNS Privacy/PolicyStatement (DP-PS) - a formal statement of what a
        provider does with the data/server/etc. Review by sara ongoing.

      Seeking consistency in the policies across providers, and potentially
        automated review + user evaluation of policies.

      review feedback requested on document.
      aim for this document is BCP, with need for a living document
        longer term.

    Questions: martin <> - likes big tables (hates small pedastals)
       questions about how the table in the preso is going to be maintained.
     benno - table is actually from sara's website on this topic, probably
       best long-term storage.

  Dave O'Reilly - Carrier Grade Nat Information Gap and source port logging
    Context + draft disucssion ->
      produces information gap when LEA investigations occurs.
      solution could be logging of source-ports
      ISP 'everywhere' required to maintain logs which can ID subs.
        RFC6888 - common requirements for CGN
         time, ext-ip, ext-port, port, subscriber
      most victims don't currently log src-port.
      Clearly a gap :(
      To deal with the gap, 4 options:
        1) 6888 says record ip/port + dest info (connection logging)
          privacy considerations are grave.
        2) ipv6 migration - no CGN necessary
        3) don't use CGN at all - severely limit cgn via regulation or
           code of practice at ISP... limit users/IP so scope is smaller.
           "what about the innocents?"
        4) victim should log src port.
          rfc6302 calls out this requirement already.
          "why does no one do this?"
       Challenges - awareness, softwaresupport,
         storage - much more data storage required,
         tools breakage - tooling today may not account for port/field,
         time/etc - ntp synch required in ~1s granularity always.
       logging on most server software don't log port unless 'debug' enabled.
       review of current software is grim - not much support/capability

     draft published: daveor-cgn-logging-04 - not so favorably recieved
       in INT area - resistance to logging/privacy concerns.
       good dicussion aside from acrimony... says dave.
     further reading:
       http://www.ftrsolutions.com/index.php/resources/carrier-grade-nat

     Source port logging possibly the best answer...
     Questions:
       Stephen Farrell - long discussion note, question about draft change?
         'no change really'
         encourage int area discussion and discuss there.
         Stephen's impression - proper analysis of privacy impacts
         possibly larger discssion attempted, no replies forthcoming
       daniel - ACLU - notes about how badly privacy could get here.
         if there are logging recommendations - please think through this
         more clearly and more completely...

  Gorry Fairhurst - Impact of transport header confidentiality 
                    on network operation and evolution of the internet

    draft at rev9 - is more readable... IS MORE READABLE!!!
    Goal to discuss how current practices could / are impacted by
      changes in transport header management.

    Find in-netowrk use of transport header use for ops.
    Find encrypted transport info, and impacts on transport design
      keep in mind operations requirements for this as well.
    Since ietf101:
      expanded security consideratiosn
      put infront of TSV-WG for action
      more neutral view of trade-offs
    note related work here as well - pervasive  encryption effects on ops
    Differences in work: focus on neutral point of view.
      'why do people want to use encryption?'
      'ops needs for packet header inspection during troubleshooting/etc'
      'net neutrality accountability as well'

    security considerations section added - review requested
    conclusions section could use more review
    Supported for adoption in TSV-WG - comments on TSV-WG list requested.

    "Thanks to stephen for comments!"

  Q: Stephen Farrell - 'thanks' - looking for abuses of header info in the past?
    "no, of course not." - Could bring forth a list of points where
      'not encrypting' hasimpacted in transport level.
        mss-clamping, multi-path-tcp, etc...
    point being: "Maybe if noting good things, also include bad things"
    Stephen wants more than 3 legs on the stool.

  Mirja Kuhlewind - The wire image of a network protocol
    Most of this owrk from IAN stack evolution work.
    Defines what a wire-image is for a protocol
    Original stack had 4 layer cake, not 7.
      no inclusion of security explicitly
      transport layer has end-to-end data as required
    people now do things with this data:
      measurement, filtering, forwarding, in-network-inspection
        this data is used for good AND bad
      If you change this, then you've made assumptions which may not
        be clean, for a long term system
    Security of this information clearly seperates the pokers from the pokees.
      TLS gives you opacity in the payload and some transport layer parts.
    With protocols like QUIC some of the data previously exposed now encrypted
      and some is hidden, and only available to the endpoints.

    Wire image now changes substantially from the original image.
      timing, length, unencrypted bits are all that's available.

    intermediate devices no longer have access to payload/etc.
    There's a clear boundary upon which to decide what should be exposed
      and what should not.

    Operations has less bits to deal with, which may not matter for opsec.
    Example of tcp-timestamp - not required (option!) may be available
      for research/etc... long bits of discussion ...

    End discussion in drafts:
      draft-trammell-wire-image
      draft-iab-path-signals

    Discussion: stack-evo mailing list.

    Q: Gorry - notes on blob color ... notes there are possibly
      extensions/headers being made by ops to get measurement done?
    A: tunnel headers may not go away, so... not super important.
       if there's no explicit info to network ops, inferrence happens.
       "Maybe this doesn't matter for intermediate measurers?"

    Q: Stephen - defintion may not include many measages in single flight?
    A: wire image covers all of this, so the wire image is all that's on the
       wire. If many things in same packet, it's just one packet?

    Q: eric - timing and size distribution is important
       propose anything to keep this harder to identify?
    A: Yes, better to addrss in design.

    Q: dkg - for proto designers keep track of this set of requirements.
       if the location of proto / packet-edge are different...
       for Gorry - people can still stack headers... can't stop the signal!
       endpoints need to clearly think about leakage of parts of the comms.

    Q: gorry - what about mobile ops leaking gpp across boundaries?
       transport considerations of squeezing infomration away ... 
       incentive to bring some of that back may happen.
    A: agree.

    Q: Gorry - overall this may improve security, but may cause additions
       of information/oam/managemnet to address these problems concernts.

    Q: Stephen - we sadly make decisions poorly with respcet to security/privacy
    A: if operator adds timestamp and leaks this, oops.
       if you could get the data without adding data perhaps won't need
       to add and then be dumb :(

    Q: dkg - meta-data leakages happen today, people MAY do this again, of
       course. Better off hiding as much as possible :(

    Q: Gorry - posibly this means more machineleaning to do the same work.
    A: none of the drafts say: "hide all the data"
       They say: "be explicit and careful about what you hide"

  Ron Bonica - ip-fragmentation considered fragile
    this is the last presentation - brains on ietf <sizzle>
    Question is for AD - Would you agree that DNS is one of the most
      essential applications on the internet?

    A: "yes"

    DNS and dns-sec relies on IP fragmentation?
    with DNS over UDP it's possible that fragments will occur with larger dns
      packets...

    notes about lots of potentially sketchy work :( in dnsext/ops.
    If you believe v6 fragmentation is problematic? Would people pay attention?
    "People should not be shocked... warren"

    "How does fragmentation work?"
      large packet in, small link out :( sadness.
        v6 header + fragment ext header + salami-packet

        The first packet has TCP header, follow-on packets do not...
        stateful firewalls may be ok :(
        stateless firewalls are certainly sad-pandas
        loadbalancers stateful/stateless also could be sad making

        fragmentation is hard on stateless systems (and often on stateful ones)

        Security concerns such as:
          incomplete fragmentation attacks
          overlapping fragment attacks

        draft talks about ops/protocol-designers should avoid fragmentation
          For those that require this, find a way out of the long dark scary

      Time to go! (questions?)