* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Opsec Status Pages

Operational Security Capabilities for IP Network Infrastructure (Active WG)
Ops Area: Ignas Bagdonas, Warren Kumari | 2004-Oct-14 —  
Chairs
 
 


IETF-102 opsec minutes

Session 2018-07-20 1150-1320: Viger - Audio stream - opsec chatroom

Minutes

minutes-102-opsec-00 minute



          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  - 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
              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?)
          
          



Generated from PyHt script /wg/opsec/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -