IRTF Open Meeting, 20 July 2017 ------------------------------- Minute-Taker: Melinda Shore Chair’s Intro IETF Note Well applies to IRTF, as does IETF harassment policy. Agenda bashing, time permitting will discuss what sort of publication stream people would like. Covered IRTF mission - longer term research issues related to internet, organized into research groups. These can be formed for a year of trial before formal chartering. Every research group met at IETF 99, including proposed PANRG, starting its year of trial, and and initial organizing meeting for DIN. Applied Networking Research Workshop (IRTF/ACM/ISOC) The 2nd annual ANRW was held on Saturday, materials at http://irtf.org/anrw/2017/program.html Applied Networking Research Prize (IRTF/ISOC) ANRP papers were already published elsewhere and nominated on the basis of exceptional quality. Six awards are made, and two are announced and presented at each IETF in the award year. The nominations process, papers published in 2017, for awards in 2018, will begin again around November. ANRP talk 1 - Philipp Richter, TU Berlin. "A Multi-perspective Analysis of Carrier-Grade NAT Deployment" [1] ---------------------------------------------------------- Was presented at last year's IMC conference. In 2017, 4 out of 5 RIR IPv4 allocations exhausted, about ~1% of the IPv4 address space unallocated. Other than using v6, ISPs can buy addresses on address markets or use CGN. There are no CGN deployment statistics available and not much is known about deployed CGN configurations. Surveyed more than 75 ISPs from all regions of the world. 38% said they'd deployed it already and about 12% said they had plans. Operational concerns include application problems (gaming), traceability, addresses becoming blacklisted. Challenges include resource allocation, troubleshooting, and internal address space fragmentation/shortage (RFC 1918). Comments suggested that ISPs don't like CGN but v6 deployment is costly and complicated Objectives: develop detection methods, develop methods to extract properties. Eventually found 2 methods to detect CGN presence. First is to detect "from the outside" via BitTorrent. The BitTorrent DHT can be used as vantage points. Constructed a graph of leaking relationships and then look at those graphs on a per-AS basis. They tested more than 2700 ASes with his methodology, detecting CGN in over 250. Benefits of this method include broad coverage and no probing devices. Caveats are that BitTorrent activity is necessary, no cellular networks Second method is from the inside, with Netalyzr from ICSI Berkeley. Looked at more than 550,000 sessions in 1500 ASes. Access to device/router/public IP addresses. Runs in both cellular and non-cellular networks, and allows the use of customized tests. Caveats are partial visibility, and crowdsourced (users need to run Netalizer). More than 20% of the ASes use multiple internal address ranges. 25.0.0.0/8 is mostly unrouted but in internal use by at least 4 major networks. Up to 20% of ASes use arbitrary pooling. No dominant port allocation behavior, often inconsistent within same AS. IP address and port allication: most ASes show non-uniform behavior. Some ASes allocate chunks of ports, can reason about how many subscribers per IP. Largest number they could empirically detect was 512 per IP address. STUN-based testing: symmetric NAT binding turns out to be surprisingly common in CGNs (40% in cellular CGNs). Conclusions: CGN is very broadly deployed, stunning variety of configurations across ASes, degree of resource sharing varies widely, and NAT mappings and timeouts of some CGNs more restrictive than CPE NAT. Measuring end-user internet performance might be extended to measure maximum concurrent connections and type of NAT mappings. CGNs reduce how much internet subscribers receive, so there may be a need for guidelines or regulation of resource allocation. Question: did you compare against v6-only networks and NAT64? Public BitTorrent DHT v6 table is only sparsely populated. Question: routable addresses that you found - do you have a published list to finer granularity than /8? Q: how many deployments are compliant to the standards? They don't specify all the things we measured, but they do specify arbitrary pooling. At least 20% violate that. There are a large percentage that are not RFC-compliant. Number of ports and sessions not specified Q: you had port behaviors and restrictiveness - did you look at correlations? No, not yet Q: When STUN was introduced it was discovered that some NATs change their behavior as they reach exhaustion - did you measure that in CGNs? We noticed it but did not measure Q: Why do you think reputation systems can work? I don't know how they can or should deal with that but I would be very interested in talking with people who run such systems Q: Did you go back to survey respondees to establish whether or not there were false positives? We did not find false positives so far, but we found a few false negatives. Q: regulation - Belgium is concerned about the growing use of CGN and the difficulty it introduces for law enforcement. Given that you might see it starting to go away Q: if someone could tell us which devices they are, that would be fascinating. WRT reputation, there are pieces of software with unique identifiers, and sometimes you see hundreds or thousands behind same IP address. Also interesting to look at how IPv4 addresses map onto v6 addresses ANRP talk 2 - Stephen Checkoway, UI Chicago, "A Systematic Analysis of the Juniper Dual EC Incident" [2] ------------------------------------------------------------ Was presented at ACM CCS 2016. In late 2015 Juniper announced that unauthorized parties had accessed source code and introduced backdoors, including a decryption vulnerability Affected Juniper's Secure Services Gateway. Introduced hardcoded administrative access password. The announcement was vague about the other backdoor. HD Moore ran strings over both affected version and fix, and diffed them. The first 5 of the long hex digits are P-256 parameters. To figure out what the difference actually meant required reverse-engineering the binary. Turned out to be backdooring PRNG in Dual EC, allowing attacker to recover internal state. [description of EC and dual EC operation, and Shumow-Ferguson attack] Attacker needs secret value d, and at least 28 bytes of r sub k for some k, and some public function of "enough of the following output. For example, a protocol that has a >= 28 byte nonce, and a diffie-hellman public key. In this attack, attacker substituted their own nonstandard Q point. Drew on a body of firmware revisions, which the speaker reversed engineered. Global output buffer used as both reseed temporary buffer and outut of prng_generate. Index var is global for some reason. X9.31 is never used as a result. In this case the nonce is generated *after* exponent, so Shumow-Ferguson attack doesn't recover x. But, SreenOS contains queues of pre-generated nonces and DH key pairs. Queues filled once/second, nonces first. So, in many cases ideal Shumow-Ferguson attack works. WIth IKEv1 with preshared keys, attacker needs to know key. For PK encryption, attack failes due to encrypted nonces. In IKEv2 key derivation independent of mode and attack just works. Built a proof-of-concept, created modified firmware wth their own Q. Attacked VPN configurations and found their conclusions were correct. History of ScreenOS PRNG code: changed to reseeding every call, reseed bug exposes DualEC, and nonces were increased to 32 bytes. Why was Dual EC added to seed X9.31? No engineering reasons he could think of, and no standardization reason. Why reseed on every call? No engineering reasons he could think of, maybe backtracking resistence, could be a bug. The reseed bug: both output and index become globals and are reused by reseed procedure. No good reason, could be a bug Why increase in nonce size? No engineering reason, no (good) cryptographic reason, but at 20 bytes the Shumow-Ferguson attack takes infeasible number of iterations, but at 32 takes only 2^16 Why nonce pre-generation? Dual EC is about 125 times slower than X9.31. First four required for passive VPN decrption, last enables single connection decryption. Are the versions of ScreenOS with Juniper's Q vulnerable? Maybe. How was their Q generated? Impossible to say with data we have. Lessons learned: consider hashing output before putting it on the wire, scrutinize any PRNG changes closely, use separate PRNG instances for public and secret data Don't allow nonces to vary in length or be longer than necessary - IKE's 256-byte nonces are unnecessarily long, variable length enables implementation fingerprinting, long/variable length nonces privde implementations the opportunity to expose secrets Include even low-entropy secret into key derivation. We should not build exceptional access mechanisms into protocols Q: what public statements did Juniper make? They eventually decided to remove Dual EC altogether, but made no public statements about remediation, etc. Q: QUIC is having debates about what to leave some fields in the clear on the wire - have you thought about whehter there are other places in protocols where we might be exposing randomness? I hadn't thought about sequence numbers but if they are not sequential, then yes, this should be considered. Q: Is it a biased RNG? Yes, but it seems fairly low to me. (I don't know why anybody would use Dual EC) The room was extremely hot so the Chair adjourned the meeting 15 minutes early rather than take up the publication streams discussion in the heat. But she asked for people to look for mail and join in discussion on the IRTF-discuss mailing list. References [1] Authors:Philipp Richter and Florian Wohlfart and Narseo Vallina-Rodriguez and Mark Allman and Randy Bush and Anja Feldmann and Christian Kreibich and Nicholas Weaver and Vern Paxson Title: A Multi-perspective Analysis of Carrier-Grade NAT Deployment Conference: Proceedings of ACM IMC 2016 PDF: https://net.t-labs.tu-berlin.de/~prichter/imc176-richterA.pdf [2] Authors: Stephen Checkoway and Jacob Maskiewicz and Christina Garman and Joshua Fried and Shaanan Cohney and Matthew Green and Nadia Heninger and Ralf-Philipp Weinmann and Eric Rescorla and Hovav Shacham Title: A Systematic Analysis of the Juniper Dual EC Incident Conference: Proceedings of CCS 2016 PDF: https://www2.cs.uic.edu/~s/papers/juniper2016/juniper2016.pdf