Re: [dnssd] Fwd: New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt

Bob Bradley <bradley@apple.com> Mon, 11 March 2019 07:03 UTC

Return-Path: <bradley@apple.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCA41310BF for <dnssd@ietfa.amsl.com>; Mon, 11 Mar 2019 00:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 TxGIk18hTbjn for <dnssd@ietfa.amsl.com>; Mon, 11 Mar 2019 00:03:14 -0700 (PDT)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BDAA1310B5 for <dnssd@ietf.org>; Mon, 11 Mar 2019 00:03:14 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x2B6v6MT051059; Mon, 11 Mar 2019 00:03:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=HEK0OYFSjJZji1ONSYeB2jIYVpYFRa+IWMk9dC0VNpI=; b=V9J8IKOxJsd5VQOkim1vKF+1KAyBdoKRjwufbNZj7rkIryd0/wOcAB9jgEdtT5WuHzmS cHXyFibg7Go1D9XRRq2nLDbQ52yB5ff5Cq7he7x8BdXsY8puwV/SJ2qmcjaFKXGFX9GG i5u/N/bkbvtXcaBtnZmeQEg/KO5YnplNUudqPhhQjzmWFtDo2ts3rhIeEGGztrJEzAPr AnIrub/clAd0jJ9UfUIQBuU2Q1K/70Ahnqm4M1TMmm9myWCIibplXNq/x3CFXXBT2h4P khxufYRJYHCU8l/aXMSZ93hW19dYSxYz4+y+n8MGFUIRxQ4Jv0rKRBUO/yyUaF7BRhUS zA==
Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2r4da786js-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Mar 2019 00:03:07 -0700
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PO60029EWX5I480@ma1-mtap-s02.corp.apple.com>; Mon, 11 Mar 2019 00:03:06 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PO600M00WS2KH00@nwk-mmpp-sz12.apple.com>; Mon, 11 Mar 2019 00:03:05 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 058bbac8ca772bcfc9e38720b87faa94
X-Va-E-CD: 1d0bcb06104f6ef6c8d207c9abde8e01
X-Va-R-CD: 1766e3bf804fb0608209bc33f08e9ab8
X-Va-CD: 0
X-Va-ID: e43c8f8c-aec7-46e3-8537-5602c9fa28cf
X-V-A:
X-V-T-CD: 058bbac8ca772bcfc9e38720b87faa94
X-V-E-CD: 1d0bcb06104f6ef6c8d207c9abde8e01
X-V-R-CD: 1766e3bf804fb0608209bc33f08e9ab8
X-V-CD: 0
X-V-ID: 5466c5ee-2888-4d5a-81be-d9726924ae7c
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-11_06:,, signatures=0
Received: from [17.234.9.252] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PO600AZBWX4HF00@nwk-mmpp-sz12.apple.com>; Mon, 11 Mar 2019 00:03:05 -0700 (PDT)
Sender: bradley@apple.com
From: Bob Bradley <bradley@apple.com>
In-reply-to: <2f106571-676b-8852-5c3e-38601306f2f1@huitema.net>
Date: Mon, 11 Mar 2019 00:03:03 -0700
Cc: dnssd <dnssd@ietf.org>
Message-id: <D2A9DCCA-C61C-42BD-BDAD-D18EFBAE9C3C@apple.com>
References: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> <14d1ad00-61de-af75-8a8f-3e5bcf1fa1ef@huitema.net> <C1B9DD22-52B0-4292-AFDE-698E3CE24DAB@apple.com> <2f106571-676b-8852-5c3e-38601306f2f1@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.3445.104.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_06:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/AQdfMOUNsEngn8s4HcSSFkjlGTQ>
Subject: Re: [dnssd] Fwd: New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2019 07:03:17 -0000

> On Mar 10, 2019, at 10:53 PM, Christian Huitema <huitema@huitema.net> wrote:
> 
> On 3/10/2019 9:55 PM, Bob Bradley wrote:
>> It looks like this is intended to find a specific server on the
>> network using that server's discovery key to encrypt the request. If
>> the client doesn't know which servers might be on the network, would
>> it need to send a multicast packet for each server it has a key for?
>> For example, if I'm paired with 20 devices then when discovery starts,
>> would I send 20 multicast packets?
> 
> As designed, the answer is yes, the client would send 20 packets. I
> understand very well that there is an alternative design in which the
> server sends a packet announcing its arrival, and then every interested
> client discovers the server and contacts it. I believe that the scaling
> is actually equivalent:
> 
> 1) In my design's worst case, the client sends N packets, and P servers
> who are present perform O(N) trial decryptions. Total O(P.N2).
> 
> 2) In the server announce design, P arriving servers send P packets upon
> arrival on the network, and O(N) clients perform N trial decryptions.
> Total O(P.N2) as well.

In (1), there are N multicast packets per client and P unicast responses from paired servers. In (2), there is 1 multicast request per client and P unicast from paired servers. Many devices act as both client and server. Multicast vs unicast can make a big difference in the number of packets processed by each device.

As an example, my device has 40 paired devices and the network has about 300 devices browsing for and offering services (by looking at mDNS). If we assume other devices have a similar number of paired devices then:

Approach 1: 12000 multicast requests (and trial decryptions) and 40 unicast responses.
Approach 2: 300 multicast requests (and trial decryptions) and 40 unicast responses.

> It is pretty hard to resolve that discussion without actual statistics,
> application scenario, etc. For example, it is not clear at all that
> "servers" will be listening all the time, versus listening only when the
> corresponding app is in focus, e.g. when several users start the same
> app and explain app instances to find each other.
> 
>> 
>> Are there plans for a mechanism to announce the availability of a
>> server? For example, if I start discovery (which sends an initial
>> batch of multicast packets) and then a few seconds later a server
>> becomes available, will server have a way to notify the client of its
>> availability?
> 
> Again, this depends a lot on application scenario. In a peer-to-peer
> scenario, the roles of server and client are flexible. Peer A comes
> first, finds nobody there, starts listening in server mode. Peer B
> arrives a moment later, starts in client mode, engages in discovery,
> succeeds.
> 
> -- Christian Huitema
> 
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd