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

"Ali C. Begen" <ali.begen@networked.media> Wed, 20 February 2019 20:39 UTC

Return-Path: <ali.begen@networked.media>
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 98584129B88 for <mmusic@ietfa.amsl.com>; Wed, 20 Feb 2019 12:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.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 3PvaKqxlRDv9 for <mmusic@ietfa.amsl.com>; Wed, 20 Feb 2019 12:39:17 -0800 (PST)
Received: from mail-yb1-xb42.google.com (mail-yb1-xb42.google.com [IPv6:2607:f8b0:4864:20::b42]) (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 56E3812950A for <mmusic@ietf.org>; Wed, 20 Feb 2019 12:39:17 -0800 (PST)
Received: by mail-yb1-xb42.google.com with SMTP id j189so10140347ybj.9 for <mmusic@ietf.org>; Wed, 20 Feb 2019 12:39:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VGyaU1AJm3cqHvyo0P43wnJLXPaggkRfJt5obycUn1E=; b=vCvUYDNTICopv7fJsJil9O9eOjadd3lAqL9eTOrfR+H537rfn3lphnGiy/BjP/sUx/ ikv3/OMfV9EkhQLDEd03IPvVC1GjOPUfohZvYTN1g5lZYJrmao3UiqeijKKaCCi9+ojq KvCjuYwE/TE3VBeUAFEhdYAUrLTfLKklr5ML2Rtbv/YawrvCcadZGyoB26nSl6t4cy/M 56B86mMbrFtc/I9WO/zLfdqvGmoXrFtbK70YKWiavWejlH3chynzmaV0cY8rHqo4ryrR WkAw6ERVhkhGB/Efkbj68scJndCIOZ6T1HPDyZRoRTayryct8Mhen/++70cKN99XQ7AD treQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VGyaU1AJm3cqHvyo0P43wnJLXPaggkRfJt5obycUn1E=; b=n+YJst/BQTnxBlQU+wXxWD8lJmFJKbHiFExOAdnZxyWSJax526rWBiBSQPvUq5ZlK5 mLZcDSLPtNJfvvX2lnTP6ic8ELkJXa9oHHkYkRwoGxOUh6+s+IOY3Cj0FwCj9xtaUidM he8lethIQ5zasPq1VgF3fyy+lfsoCggmyyS2nO6Er7xhnxMOnvZVWsB6IB0PN1ISTD8U rjS3+m8wgFL5z3dhefgjhR7ZZFPG41j1bAOAzr3MupI2GbruA0SblDrgzUIxQTQFtXNj cy/+rmjNEjbja3xMy2GyNBaWfmXbSd35WFdSmrziUEraCZOUq7ZSIw3r46wuLO5MNf4J Nrsw==
X-Gm-Message-State: AHQUAuZwIcXqKIRtrBuPoc95GJvVZ7ci6oRVRMdqgwStb9nULI7z3kOB Mxc5LwIkEfshjpVrjLA1RZCeGbPgaFQr6bw1OWcDRA==
X-Google-Smtp-Source: AHgI3Ib/uHAGmLKmYUbkxEm7VoUfZOyYxo+v8qKW/nxJ3yi8KEjQmrpAGjlcrJtYxNCEiwOxm/5gpFp+60RWtWkiXNU=
X-Received: by 2002:a25:bd4b:: with SMTP id p11mr30579358ybm.251.1550695156278; Wed, 20 Feb 2019 12:39:16 -0800 (PST)
MIME-Version: 1.0
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com> <8402099d-8d98-34b6-7de4-ae5a162888ae@alum.mit.edu>
In-Reply-To: <8402099d-8d98-34b6-7de4-ae5a162888ae@alum.mit.edu>
From: "Ali C. Begen" <ali.begen@networked.media>
Date: Wed, 20 Feb 2019 23:39:05 +0300
Message-ID: <CAA4McztV9b_VET6bycyspXiNPXr2J6VE3g+o9t3nKvwf2DmbrQ@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: Ben Campbell <ben@nostrum.com>, draft-ietf-mmusic-rfc4566bis.all@ietf.org, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f200d70582595919"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/bjYMVz3oNtS6AO-MeePz6EzeeKw>
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 20:39:20 -0000

On Wed, Feb 20, 2019 at 10: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.
>

Maybe use RFC 7022 for the privacy goal?


>
> I would like some feedback here!
>
>         Thanks,
>         Paul
>
>