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 19:18 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 B02C613129A for <mmusic@ietfa.amsl.com>; Fri, 1 Feb 2019 11:18:15 -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 9aCQMhiFSwlZ for <mmusic@ietfa.amsl.com>; Fri, 1 Feb 2019 11:18:13 -0800 (PST)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 E27B8131295 for <mmusic@ietf.org>; Fri, 1 Feb 2019 11:18:12 -0800 (PST)
Received: by mail-pg1-x52c.google.com with SMTP id z11so3386011pgu.0 for <mmusic@ietf.org>; Fri, 01 Feb 2019 11:18:12 -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=ksCmdtoHl28Hj3jY7BQmUL1XIbv8XQSylwigR5lyfRM=; b=ay9s+HVbcLON6dyEUg81WA2c/r+GX+qsIGVJUKxNGKRA9LQdxgVwAv/gc8TPpRK6xT uO3GvlCn9mShMaQQnmM8ACR6Nxa9jGp+h/eBl46fVBt3ey9QfHwDjg8Tgur2RUnCTHFE wuevjgnSKvvHhUMb5VKRRF8ayJIXGGBN/LTVmy+GHOhFtBGSLGKAOQL4oeT69005FlQK +c5YLvfNBsM4s2heJ0KMvbi+I9L2gXxd3ACZEb2/WGQZg5fJAnuCHzsEV86bvPBo9F25 nfaG9TC12vTG2h/q9lOWxOe1aVjUuml/BTvCdGhGr0WdeP7apg+CfK4Agn9Wa39X+vzO YFNA==
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=ksCmdtoHl28Hj3jY7BQmUL1XIbv8XQSylwigR5lyfRM=; b=j6nTPtEzbzd44SR5/3B9I9iOZAcXwjcDg+1R7dmih1OrTA2zREMC1ElxgEhBwZ+TDI 39sQe8EmpMPBzW0n/r9lLz+vz6e2mQY4Md9ALODogYIaJedwZnEnFD+tMmbgXcovqYAo U0AQkknlY3BhuO592cxxiBlmxS3Tr66G8DGRTmrxQHGBEVYGoub84o5FihDbUGVJ0D/k pENPsVMeDEIF3eN98RIUEaYWryP3kSnF9bSXIFIBhCWIRoi6QEtdfAPBsl8ijyvEAHEA 91XXMN/l61WiFO6YNRYlag3HQaJ/vv764E85xC3BEl9oEiHGSEqCVoPdQJlbvu503QoR Ka3A==
X-Gm-Message-State: AHQUAub0QvduXJaGghouqlmdnigcbUH6mkOr+mkoMkxjI61iSA/xV11S NgFcDXIlpzSqkca2YfCKOFR11A==
X-Google-Smtp-Source: AHgI3IZ1WeFfXUicROyXm+ZU3p+DJqPSM9LBVUVjNJUHumlnmpZ/VCYJni5GOmWhjzrbbiMgEhuNXA==
X-Received: by 2002:a62:3a8b:: with SMTP id v11mr9399110pfj.81.1549048692269; Fri, 01 Feb 2019 11:18:12 -0800 (PST)
Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com. [209.85.210.180]) by smtp.gmail.com with ESMTPSA id g190sm10014309pgc.28.2019.02.01.11.18.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 11:18:11 -0800 (PST)
Received: by mail-pf1-f180.google.com with SMTP id w73so3671778pfk.10; Fri, 01 Feb 2019 11:18:11 -0800 (PST)
X-Received: by 2002:a62:160d:: with SMTP id 13mr40326587pfw.203.1549048690972; Fri, 01 Feb 2019 11:18:10 -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>
In-Reply-To: <CAOJ7v-1MXjLtBKJ8gN4nVm-Z9m0HB=ye9E6Wcm5zeOx5y2zkSw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 1 Feb 2019 14:18:01 -0500
X-Gmail-Original-Message-ID: <CAD5OKxuZPX3DbDEEVXbVamHynazJkv5G6CDMqMPmdMwiW4SNdg@mail.gmail.com>
Message-ID: <CAD5OKxuZPX3DbDEEVXbVamHynazJkv5G6CDMqMPmdMwiW4SNdg@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: "Dale R. Worley" <worley@ariadne.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>, Simon Perreault <sperreault@jive.com>
Content-Type: multipart/alternative; boundary="000000000000f71ef00580da00c6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/UwaJA6L2qcnwqxCbphsVhABQk80>
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 19:18:16 -0000

Most likely mDNS draft will need to update RFC 8445 to specify how ICE
nomination procedures are modified, when mDNS is used as candidate-address.

As far as mmusic-ice-sip-sdp is concerned, one option would be to allow
FQDN as candidate-address. The guidance for handling FQDN in
candidate-address should be updated from RFC 5245 and should specify that
FQDN names should be ignored. mDNS ICE draft then will update ice-sip-sdp
and specify that mDNS FQDN should be handled according the procedures of
this draft.

Another option, which I think word work better with existing specifications
is to add a new candidate type -- mdns. This way, instead of magic DNS
suffix, candidate type will be used to determine that this candidate should
be handled differently. I do not think MDNS candidates can be used for
anything except host candidates, so making then a special candidate type
might be the least painful option. It might even make sense to make
separate types for IPv4 and IPv6 MDNS candidates which would save a DNS
query for each candidate.

Regards,
_____________
Roman Shpount


On Fri, Feb 1, 2019 at 12:39 PM Justin Uberti <juberti@google.com> wrote:

> I understand there were questions about the general case (e.g. regular DNS
> names), but how do we plan to reconcile this removal with the need for mDNS
> hostnames?
>
> On Fri, Feb 1, 2019 at 9:09 AM Roman Shpount <roman@telurix.com> wrote:
>
>> Hi Justin,
>>
>> I agree regarding #1 in theory, even though in practice a lot of (most)
>> devices will not accept FQDN in either c= or ICE candidate.
>>
>> Regarding #2, mmusic-ice-sip-sdp was updated (
>> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-4.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.  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.
>>
>>
>> Specifically, support for FQDN names there was removed due to RFC 8445
>> implementation issues. I believe Simon Perreault suggested this change.
>>
>> Regards,
>> _____________
>> Roman Shpount
>>
>>
>> On Fri, Feb 1, 2019 at 12:02 AM Justin Uberti <juberti@google.com> wrote:
>>
>>> My recommendation here would be that we do c=IN IP6
>>> 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 or IP6
>>> depending on which type of address is being wrapped.
>>>
>>> Re #1: RFC 4566 seems to indicate you can use either IP4 or IP6 for FQDN
>>> in the c= line.
>>>
>>>      unicast-address =     IP4-address / IP6-address / FQDN / extn-addr
>>>
>>>
>>> Re #2: Quoth 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jan 31, 2019 at 8:43 PM Roman Shpount <roman@telurix.com> wrote:
>>>
>>>> On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti <juberti@google.com>
>>>> wrote:
>>>>
>>>>> We can however all agree that "c=IN IP6" is busted:
>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=927309
>>>>>
>>>>>>
>>>>>>>
>>>> I guess one way to interpret this that each address should have a MDNS
>>>> alias. So, if you are dealing with dual stack host, it should provide two
>>>> MDNS candidates, one of which is IPv4 and another IPv6. The c= line should
>>>> specify FQDN for one of those candidates and specify the type (IP4 or IP6).
>>>>
>>>> There are two problems:
>>>>
>>>> 1. There is no way to know which address type is in the
>>>> candidate-address when FQDN is used there. Guidance in ice-sip-sdp is
>>>> talking about the presence of column in IP6 address, but this definitely
>>>> does not apply to FQDN. It would've been better to specify something like
>>>> local4 and local6 as FQDN suffix in MDNS alias to specify the
>>>> candidate-address type so that correct DNS request can be issued.
>>>>
>>>> 2. A lot (if not most) SDP/ICE implementations do no support parsing
>>>> FQDN in candidate-address or c= line. This might create interop problems
>>>> since RFC 5245 specified that candidate-address is an IP Address.
>>>>
>>>> Regards,
>>>> _____________
>>>> Roman Shpount
>>>>
>>>>
>>>