Re: [MMUSIC] [rtcweb] What goes into c= line address when FQDN is used for the default candidate?

Roman Shpount <roman@telurix.com> Fri, 01 February 2019 21:06 UTC

Return-Path: <roman@telurix.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 1448C130EB0 for <mmusic@ietfa.amsl.com>; Fri, 1 Feb 2019 13:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.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 LDIr3YGfAjuh for <mmusic@ietfa.amsl.com>; Fri, 1 Feb 2019 13:06:30 -0800 (PST)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 81EDE130EAB for <mmusic@ietf.org>; Fri, 1 Feb 2019 13:06:30 -0800 (PST)
Received: by mail-pg1-x535.google.com with SMTP id n2so3498508pgm.3 for <mmusic@ietf.org>; Fri, 01 Feb 2019 13:06:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iff0lhNlCF7xnZCR8/in3v6Cm0JzBcSy7qWsRAEn5xQ=; b=ZBiT+H/KeUmADUCSeNXUlryUQgRc6jlbi/oQw7251D/PclCLhZw1vFzArTCEVIAd+0 taVGOnp3oUnooA2/MurSgrsgFlLlF1V4rAFk4EYo3rLbD9FEwpyv6ydf6u4yTRX8bAZI OYzcpZpI3zODgX+ew5b3QjxDzjIzFjxPNe807faDLECfqiP1qjHOpbpIQW+4rmJV3L7c l6Sy94wBvOxXLXJ5ydvEAwKXyBhMOP96ZukIEQxdRduDPfG4E1GCGxiVVsZ+CXWJhEtf DCxJSHMSnjHkYm2FqmVZBBX2McO05FXswgjIYax66Lx316ZebGYdyG1bosdiD++zdUWS yIpw==
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=iff0lhNlCF7xnZCR8/in3v6Cm0JzBcSy7qWsRAEn5xQ=; b=aDrNJd/ZabXsRR5IiabwR1kJQcUJ436QS54wKTFPrG3FdEYWpl4+LpTkJdclfdXbBT VoAHVpyv4Tx0YwoI/W/n8945/lnAx7m04FOBOMH3uTKK49ytx4610gB1+wfD7K4nq3kV gGiyVhyB9TSjp8FBBa2zVu+1BkcV9ewowKDvebvDOjdJloA6TggVqBjFF4mWCVv3fwAL /DrWw2mIC14LyvB9nCOgBU7ezgTyf42nIu7OZaBr6d3LfPuPK+NZkdB0jI3EnolWZ0WU jN8EBYpJQNFA20Z06N0XN1c/OzjH3sOZJ1KjWtnJUl3kSMcHjYJVZ3hkpj9iUJ8x0p3s flfQ==
X-Gm-Message-State: AHQUAuac4kfysX74JCCk9m371DBeQQwXz6x93WG9+LFVaBDx7c6VwtMN Gyhdq2xBQ4lfrfY6DDJfVlVXTw==
X-Google-Smtp-Source: AHgI3Ibastm4ax3ZdmStPFs0pN31bCDPf/GfUnI/Y2STxSjxwm1sgSF2+tXLKnVWCB2krfUIiGEtCA==
X-Received: by 2002:a63:d157:: with SMTP id c23mr2158612pgj.170.1549055189986; Fri, 01 Feb 2019 13:06:29 -0800 (PST)
Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com. [209.85.214.171]) by smtp.gmail.com with ESMTPSA id h129sm27548879pfb.110.2019.02.01.13.06.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 13:06:29 -0800 (PST)
Received: by mail-pl1-f171.google.com with SMTP id p8so3829127plo.2; Fri, 01 Feb 2019 13:06:29 -0800 (PST)
X-Received: by 2002:a17:902:720c:: with SMTP id ba12mr41396137plb.79.1549055188791; Fri, 01 Feb 2019 13:06:28 -0800 (PST)
MIME-Version: 1.0
References: <CAD5OKxuGEPccJUJ1E0bSmz9RW6CWhhSqW+Dke1Cywrjp-dvaoA@mail.gmail.com> <874l9ousuk.fsf@hobgoblin.ariadne.com> <CAD5OKxut+Y8NnL2FbFQkubU-8up4eu6F9hOxs-8oBOJoCnTQwg@mail.gmail.com> <CAOJ7v-2GC2UWBaqSccZh1MKg6E93NrNKQJagzMCOfuE6SxuptA@mail.gmail.com> <CAOJ7v-2ZWxDFAtfoXTB4OsfJBAaFFqZ1jt0SSCCm4Qi3Qqfj6g@mail.gmail.com> <CAD5OKxuAUaCcO8X+ESoekHMq2Ba5-hviZ08G1Vyg_qSh4mR73Q@mail.gmail.com> <CAOJ7v-0T8gbNtr22MiZzVSsAX8+4ZP-pVueKFVOuSSJLBmv8RA@mail.gmail.com> <CAD5OKxtqxcqrQGCWc_2L1np9ftk_Q=prU3MMXk7Y+wbLCq0rYA@mail.gmail.com> <CAOJ7v-1MXjLtBKJ8gN4nVm-Z9m0HB=ye9E6Wcm5zeOx5y2zkSw@mail.gmail.com> <CAD5OKxuZPX3DbDEEVXbVamHynazJkv5G6CDMqMPmdMwiW4SNdg@mail.gmail.com> <CAOJ7v-2c7baQ9UUzxxuA41jbNqeOD8SdqJgCTDAUPXwOZ7r_4Q@mail.gmail.com> <CAD5OKxsc4F4DOW6=u3XU5N3NJ4jPx35Q-8WNF_0MGZziy7=b=g@mail.gmail.com> <HE1PR07MB31617DB79BE41B64AECF082693920@HE1PR07MB3161.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB31617DB79BE41B64AECF082693920@HE1PR07MB3161.eurprd07.prod.outlook.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 1 Feb 2019 16:06:18 -0500
X-Gmail-Original-Message-ID: <CAD5OKxu7Sjnp6zLo1jxnqS5_3URM6Fj9KrijSLKXERHBqr1Pkw@mail.gmail.com>
Message-ID: <CAD5OKxu7Sjnp6zLo1jxnqS5_3URM6Fj9KrijSLKXERHBqr1Pkw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Justin Uberti <juberti@google.com>, Simon Perreault <sperreault@jive.com>, "Dale R. Worley" <worley@ariadne.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004403690580db84ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/Bb4u9wizU528OzLi_FM9VzcbySM>
Subject: Re: [MMUSIC] [rtcweb] What goes into c= line address when FQDN is used for the default candidate?
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: Fri, 01 Feb 2019 21:06:33 -0000

In this case section 4.1 of ice-sip-sdp should be updated to allow FQDN in
connection-address and, perhaps specify that FWDN which return multiple
results should be ignored.

Would this work for everyone?

Regards,
_____________
Roman Shpount


On Fri, Feb 1, 2019 at 4:02 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> I have no problem with allowing FQDNs - as long as they result in a SINGLE
> address:port.
>
>
> If we want to define ICE usage of FDNSs resulting in MULTIPLE
> addresses:ports, I really think that should be a separate document - it
> should NOT be added as a last minute thing to draft-ice-sip-sdp.
>
>
> ...and, yes, perhaps such work would also affect 8445.
>
>
> Regards,
>
>
> Christer
>
>
>
>
>
>
> ------------------------------
> *From:* rtcweb <rtcweb-bounces@ietf.org> on behalf of Roman Shpount <
> roman@telurix.com>
> *Sent:* Friday, February 1, 2019 10:22 PM
> *To:* Justin Uberti
> *Cc:* Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG
> *Subject:* Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN
> is used for the default candidate?
>
> On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <juberti@google.com> wrote:
>
> This has all been discussed at length in rtcweb and I don't think any
> significant changes are needed, although I tend to think that we should
> restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only
> thing not in alignment at this point in time.
>
>
> I agree that FQDN should be put back into connection-address definition,
> but  the portion which talks about handling it is completely broken.
>
> Quoting 5245 <https://tools.ietf.org/html/rfc5245#section-15.1>:
>
>    <connection-address>:  is taken from RFC 4566 <https://tools.ietf.org/html/rfc4566> [RFC4566 <https://tools.ietf.org/html/rfc4566>].  It is the
>       IP address of the candidate, allowing for IPv4 addresses, IPv6
>       addresses, and *fully qualified domain names (FQDNs).*  When parsing
>       this field, an agent can differentiate an IPv4 address and an IPv6
>
>       address by presence of a colon in its value - the presence of a
>       colon indicates IPv6.  An agent MUST ignore candidate lines that
>       include candidates with IP address versions that are not supported
>       or recognized.  An IP address SHOULD be used, but an FQDN MAY be
>       used in place of an IP address.  In that case, when receiving an
>       offer or answer containing an FQDN in an a=candidate attribute,
>       the FQDN is looked up in the DNS first using an AAAA record
>       (assuming the agent supports IPv6), and if no result is found or
>       the agent only supports IPv4, using an A.  If the DNS query
>       returns more than one IP address, one is chosen, and then used for
>       the remainder of ICE processing.
>
>
> I think it was discussed in quite a detail why using a random DNS
> resolution result is not going to work here..
>
> The only options we have here are:
>
> a. Fix FQDN connection address handling. Probably the most logical way of
> dealing with this would be to specify that candidate with FQDN should be
> converted as a result of DNS resolution into multiple candidates, with each
> candidate corresponding to A or AAAA record in DNS query result. We will
> also need to specify how FQDN candidate gets applied to c= line address.
> Something that says IN IP4 FQDN, if any A records exist for this DNS name
> and IN IP6 FQDN if only AAAA records exist. Once candidate is nominated,
> address family in c= line should match address family used for
> communications. This will definitely require a lot more work and discussion.
>
> b. Specify that FQDN connection addresses should be ignored until their
> handling is defined in a future specification. This seems easy and only
> requires a sentence or two to fix.
>
> Regards,
> _____________
> Roman Shpount
>
>