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