Re: [MMUSIC] FQDN support in ice-sip-sdp

Suhas Nandakumar <suhasietf@gmail.com> Wed, 10 April 2019 05:40 UTC

Return-Path: <suhasietf@gmail.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 54CD2120155 for <mmusic@ietfa.amsl.com>; Tue, 9 Apr 2019 22:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9amWwKbMU1NI for <mmusic@ietfa.amsl.com>; Tue, 9 Apr 2019 22:40:36 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 E387B120137 for <mmusic@ietf.org>; Tue, 9 Apr 2019 22:40:35 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id n4so652068vsm.3 for <mmusic@ietf.org>; Tue, 09 Apr 2019 22:40:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Lm9xJZbVV6Tj/iaKCy6Uscwbhg4eE8Hk6P/lSMD3Gg=; b=ATitx8qzg2WCkPOS6ZFsrX2Q8d56Z3xXhCjeK7okTR+QPKlkEawLRQ2mLBCtmmjUzP L113aw7k44UQGh4yyqBk1PIWvllfhCdWmGCUZf1RDIbjiMcm93oVPaE+ndq6zHymbKWY WpVtZvcvFHzUufbOzMNKqCDRPNssF+XQzPy2lk38SuFxHOxMRDpeBwoqgLP/lxNuo1t+ vIxbw3lb1JPKhONlUw3q2m6cdhKqO787k1pbzb0GBnnNUPRZf3OO0RT99TGOZqXeDT5R gu8FclOc95sy/JQ/n2+5/uZa8Kko7v/VCtNMU5tCmUtJWWwPWAs+Kk7R8sdhvAba+krq 7AmQ==
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=4Lm9xJZbVV6Tj/iaKCy6Uscwbhg4eE8Hk6P/lSMD3Gg=; b=m2KXiCqmG2piT5DfJtrsDt6dxds8hernjDab3WYZ50obEAPC11eekLzWZgVIjBs6og 1+1627XYBzWEpxFr5NSXw/lvksdDjZ+WzSqIPQBKwOkHUxpdfWq1LATKT/1D6GIt9TzD ATg/ijUi+lMdYwAld0wZP5JKzRtLOx0D5EkFNQkgWDlITygK4rhqKBcUdAr7I7RKRRas umDGE7G7tE612zOtfv7u5+xED9PPjv1bHjDnwrRNk5W++FM36GSMLkqm2ymL1fbBJogH Kdu2Og/LLxPfh2r9dsW6XsRzFp4QPbRZQXeT3mssci7ouDMP4HYnxPfjBh9rpGZ758A5 RgAQ==
X-Gm-Message-State: APjAAAWWPn41giBd42uYjqH0zuoyeCkNTSIEyJh0z31dQAUkQzDeZS/P GsXEs1KXOU5kTHJnAvOxvdmB3dHdmNXEO+dbeEY=
X-Google-Smtp-Source: APXvYqylnNLY9wlKDJbUsuvUDk459rIdzFl1R9SKrrRYzMeOUO+/dDYv14VC7ti9hfNpSJdnOsZLJML3vau5lLkUW8o=
X-Received: by 2002:a05:6102:147:: with SMTP id a7mr17520342vsr.210.1554874834922; Tue, 09 Apr 2019 22:40:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5OKxux4s=4TtA7vQT0X-u+3RS+MVHG=RjgGDHWQ5H1k0OdLg@mail.gmail.com>
In-Reply-To: <CAD5OKxux4s=4TtA7vQT0X-u+3RS+MVHG=RjgGDHWQ5H1k0OdLg@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
Date: Tue, 9 Apr 2019 22:40:23 -0700
Message-ID: <CAMRcRGTmYB-CMXA5ToPhdPtLrTeKmdeZCLT-ecxfTYGHEh-HMQ@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: mmusic WG <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="00000000000034b0c10586268270"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/4HFMljwByNiOp7osXVdCxmvjENg>
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
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, 10 Apr 2019 05:40:39 -0000

Hi Roman & Chairs

Thanks for the text

I feel we should restrict the scope for FQDN resolution to just one address
for this specification. Future specifications may define handling of
multiple resolutions (or  DNS64/NAT64 ) scenarios

If others are fine with this, I would want to get an updated draft and move
this forward


Please let  me know

Thanks
Suhas

On Wed, Apr 3, 2019 at 9:47 AM Roman Shpount <roman@telurix.com>; wrote:

> Reposting er Flemming's advise as a new thread:
>
> Hi All,
>
> I have created a pull request to ice-sip-sdp (
> https://github.com/suhasHere/ice-sip-sdp/pull/1), which among other
> things added back support for FQDN to ice-sip-sdp.
>
> In order to do this, I've done the following:
>
> 1. I have changed "IP address" to "connection address" throughout the
> document whenever address in c= line or ICE candidate attribute is
> mentioned. I hope this is not controversial since it matches ABNF.
>
> 2. I have changed the definition of <connection-address>
>
> Old:
>
> <connection-address>: :: is taken from RFC 4566 <<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.
>
>
> New:
>
> <connection-address>: :: is taken from RFC 4566 <<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 both AAAA record (assuming the agent supports IPv6),
> and using an A
> record (assuming the agent supports IPv4). If, and only if, the DNS query
> returns
> only one IP address it is then used for the remainder of ICE processing.
> If DNS query
> returned more then one result, including situation where single IPv4 and
> single IPv6
> results are returned, an agent MUST ignore the candidate. Handling of
> multiple DNS
> results for a candidate can be defined in the future specification. If
> candidate
> with FQDN <connection-address> is the default destination/candidate, the
> the "c="
> address type MUST be set the IP address family for the FQDN DNS resolution
> result
> and the "c=" connection address MUST be set to FQDN.
>
>
>
> This change reflects what was discussed previously.. I am, personally,
> less then happy with this change. My biggest issue is requirement for FQDN
> to resolve to a single address or be ignored. In practice, this is
> problematic when things like DNS64/NAT64 are used. When DNS64 is used, even
> when FQDN was supposed to only resolve to IPv4, AAAA will also return
> result which will point to the NAT64 gateway. Based on the current
> language, this will result in candidate being ignored even though it should
> work with either IPv4 or IPv6 address. Most immediately, this will mean
> FQDN resolving to IPv4 will be ignored on a lot of mobile networks.
>
> I have also added language that defines what is supposed to be placed in
> c= line when default candidate is an FQDN candidate. What happens when FQDN
> resolution result and address family in c= line do not match was not
> specified.
>
> To summarize, this no worse then RFC 5245, but still fairly messy. I see
> two possible ways to clean this up:
>
> a. Add a candidate extension which specifies candidate address type,
> something like addrtype which can be set to "inipv4" or "inipv6". If IP
> address is used and it does not match the addrtype candidate extension,
> this candidate is ignored. When FQDN is used, it is resolved using A DNS
> request when addrtype is inipv4 or not present and using AAAA DNS request
> when addrtype is inipv6. Address family in c= line, when FQDN is a default
> candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be
> IP IPV6 if addrtype is inipv6
>
> b. Specify that during ICE nomination all DNS resolution results for the
> candidate should be added as separate candidates to the candidate list.
> This is likely to cause more problems then option a. One of these problems
> that I see is priority values for these candidates. Candidate priorities
> should be different for all of them but only one value is specified in SDP
> candidate attribute.
>
> In order to simplify tracking changes, I will write different emails about
> other changes I've done in the pull request.
>
> I have also included people who shown previous interest in this topic.
> Please let me know if I need to cross post to rtcweb and ice WG.
>
> Thank you for your attention,
> _____________
> Roman Shpount
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>