[irtf-discuss] Draft Minutes for IRTFOPEN Meeting in Prague

Allison Mankin <allison.mankin@gmail.com> Mon, 24 July 2017 12:47 UTC

Return-Path: <allison.mankin@gmail.com>
X-Original-To: irtf-discuss@ietfa.amsl.com
Delivered-To: irtf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A804131CE1; Mon, 24 Jul 2017 05:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTA54io018-c; Mon, 24 Jul 2017 05:47:37 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0315B131C58; Mon, 24 Jul 2017 05:47:37 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id l81so19099234wmg.1; Mon, 24 Jul 2017 05:47:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=TaSraoFUCkGkaRG21pA3x03UDjhOM1RiqIc6CGC3/AU=; b=lRBeuyqVjcElopync5GLOA3EbdrnF4ubxhiDqEp2YVUy/IdklbyTDV2swu4v05vZdt 64c38c35mmy9zmPLen7IrrLizrAZRrz/rdeXyy3rb9fYl7MZ7EouZ0GvQxa1pTtOWNOS vIZrG505Lf1cuDjrqzpE3uF1Rp7uXdK0kH8Vd8r9oQmQAOY737rcl16pj8BC/wEkVXFd fRW80rdM5azZep6T40IhgshiVl0pUvb9NZF9S5lLTsLMPkQxar8Gjw+uxR6woeW1cQ08 nSuCgqD9hWEgNft1ny60vxN0YJTTNeXJgjs6eSfjKCEZumiGfOYRQ7r6aWJtgoqfubm5 ppeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=TaSraoFUCkGkaRG21pA3x03UDjhOM1RiqIc6CGC3/AU=; b=tq+03IQmvIAIbFn68ISGJPmZxeWO7hTcfNqLwUGNkTB1ltv66cBN9uhoSARNh2nB0Y VUMfR+x5B392gM5bqWTpZPzKXB7d56oUBg5KGoRXv0LqRAvzr4+8rbxOYSowcBkcrDO6 +dSnHIS38we18y+XutxR0hmfNmmW5FOlvJfxC6dtXgPEFBcQdwuKJh8D/zcdS8dLQlGI g8ljsVB9NpSE01jzyg+PsqJO0x2bwEQ2aVwoNWKpEfrIKEGHml0ZlLgzkGEzOkXb0J6R Ttgz6kIgowtqbfUdEplRwsRwGhitDiXRdmhkH0ukmpP69jSpbnAxzG2FkIcyCv+ERcCp 7DcQ==
X-Gm-Message-State: AIVw110Ku9218WKr6POaeNZPdWU9DZSI24oBnmIL5MlSnUoz//6MmdHH ITvKLlwcD/IZawbzzpfays9xhxUcGayA
X-Received: by 10.80.215.7 with SMTP id t7mr15367595edi.19.1500900455003; Mon, 24 Jul 2017 05:47:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.138.69 with HTTP; Mon, 24 Jul 2017 05:47:34 -0700 (PDT)
From: Allison Mankin <allison.mankin@gmail.com>
Date: Mon, 24 Jul 2017 14:47:34 +0200
Message-ID: <CAP8yD=siaN+E3y2ePKsG94zGOhra-y_yKm-enHcJCiJDUuUNNQ@mail.gmail.com>
To: irtf-discuss@irtf.org, "Internet Research Steering Group (irsg@irtf.org)" <irsg@irtf.org>
Cc: Philipp Richter <prichter@inet.tu-berlin.de>, Stephen Checkoway <sfc@uic.edu>
Content-Type: multipart/alternative; boundary="f403045dbe9476bd6205550f9e39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/irtf-discuss/BUOhhs-ooXUFCDnQvlAgTlvdeMY>
Subject: [irtf-discuss] Draft Minutes for IRTFOPEN Meeting in Prague
X-BeenThere: irtf-discuss@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IRTF general and new-work discussion list <irtf-discuss.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/irtf-discuss/>
List-Post: <mailto:irtf-discuss@irtf.org>
List-Help: <mailto:irtf-discuss-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jul 2017 12:47:41 -0000

I've posted a draft of minutes for the IRTFOPEN meeting.  Thank you to
Melinda Shore for the excellent minute-taking.  If anyone has anything to
add or correct, let me know.

Congratulations and thanks again to Steve and Phillip for their excellent
ANRP papers!

Draft
-------

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, as well as the new 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