Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Local addresses

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 20 February 2019 19:10 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1922130E7B; Wed, 20 Feb 2019 11:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 4q2zPaTYr3-H; Wed, 20 Feb 2019 11:10:29 -0800 (PST)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 0F650130E7A; Wed, 20 Feb 2019 11:10:28 -0800 (PST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x1KJAQE3009722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2019 14:10:26 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: Ben Campbell <ben@nostrum.com>, draft-ietf-mmusic-rfc4566bis.all@ietf.org
Cc: mmusic WG <mmusic@ietf.org>
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com>
Message-ID: <8402099d-8d98-34b6-7de4-ae5a162888ae@alum.mit.edu>
Date: Wed, 20 Feb 2019 14:10:26 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/LnO6q2B4q7Z2A5u91UeGitYA-0w>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Local addresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 19:10:31 -0000

Ben,

On 2/11/19 10:45 PM, Ben Campbell wrote:
...
> §5.2: "Unless an SDP extension for NAT traversal is used
> (e.g., ICE [RFC8445], ICE TCP [RFC6544]), a local IP address MUST
> NOT be used in any context where the SDP description might leave
> the scope in which the address is meaningful”
> 
> That doesn’t apply to just any NAT traversal extension does it? It seems to require extensions that have scope-resolution properties similar to those of ICE.

When I came back to this I realized it is talking about an address in an 
o= line, not c=. Hence there is no intent that anybody connect to this, 
and ICE doesn't apply here. The address is primarily here to add to the 
uniqueness of the o= line. And note that the <sess-id> is required to 
make up any lack of uniqueness in the combination of the other fields. 
And privacy is leading to people not wanting to put real addresses or 
names in here.

I suggest we trim this back to:

    <unicast-address>  is an address of the machine from which the
       session was created.  For an address type of IP4, this is either a
       fully qualified domain name of the machine or the dotted-decimal
       representation of an IP version 4 address of the machine.  For an
       address type of IP6, this is either a fully qualified domain name
       of the machine or the compressed textual representation of an IP
       version 6 address of the machine.  For both IP4 and IP6, the fully
       qualified domain name is the form that SHOULD be given unless this
       is unavailable, in which case a globally unique address MAY be
       substituted.

And perhaps we should recommend that something bogus may be used to 
preserve some privacy.

I would like some feedback here!

	Thanks,
	Paul