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

Ben Campbell <ben@nostrum.com> Wed, 20 February 2019 19:13 UTC

Return-Path: <ben@nostrum.com>
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 17EFB130E7B; Wed, 20 Feb 2019 11:13:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level:
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 9ABGbv-FM6Y8; Wed, 20 Feb 2019 11:13:12 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A48CA130E7A; Wed, 20 Feb 2019 11:13:12 -0800 (PST)
Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1KJD7qC095919 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Feb 2019 13:13:09 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550689990; bh=Ep2r+b9MobPHYKVRhViu9gi91gJc5aSn2/i8ecYhiFU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=A153xxxmYfi2+IVaTdX4o5enPo7joTkzBSDuMGbr9JkZ2cYiMtTVkbcDBwf6Nh5DK hD0lQj4Q4qa3/rfPPI0fZDju0HooPdK/jYHlHgyPdLO2Xd5TWJ2arNt7EOu+WfkpdO v3pSTahrDMvTe3wUl3CnGJH34FYzBSA0eSMxtZNg=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <80E70150-AD8D-4279-BD2C-DFE554E3ED71@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_3C2A772F-50DC-448E-8637-039D18F69335"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 20 Feb 2019 13:13:06 -0600
In-Reply-To: <8402099d-8d98-34b6-7de4-ae5a162888ae@alum.mit.edu>
Cc: draft-ietf-mmusic-rfc4566bis.all@ietf.org, mmusic WG <mmusic@ietf.org>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com> <8402099d-8d98-34b6-7de4-ae5a162888ae@alum.mit.edu>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/0fTcRdiAwedTb7_BBCCjwDGG2MU>
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:13:14 -0000


> On Feb 20, 2019, at 1:10 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> 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!

Works for me.

Thanks!

Ben.