[MMUSIC] FQDN support in ice-sip-sdp

Roman Shpount <roman@telurix.com> Tue, 02 April 2019 21:26 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 130EC1202FA for <mmusic@ietfa.amsl.com>; Tue, 2 Apr 2019 14:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 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, T_SPF_PERMERROR=0.01] 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 LJjezI8-a5Q1 for <mmusic@ietfa.amsl.com>; Tue, 2 Apr 2019 14:26:44 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 1B1D21202E6 for <mmusic@ietf.org>; Tue, 2 Apr 2019 14:26:44 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id i17so7009447pfo.6 for <mmusic@ietf.org>; Tue, 02 Apr 2019 14:26:44 -0700 (PDT)
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=EzxR8mmz6KhM21WUIHxpdKh+KV7LZamNVr4Iab6V+pU=; b=cugAADdhtWwOGszjeKq2ULz75fx2Z8dYbz4qcHJoK50ivw6u81kEUBQZvEgqRcF42z dEY+pw/cBZRdlb3JoaK0lgKf3sjpGwhQwNZ328b90llx7S76VMabyd8Nf8ROJOrLJMn7 mYJ7s04+ZoUYaRA1UKh6k7l9+1z+GDwX4M5Y0bgUM7ewy9P9cpUXtou8Th5mDL+dReyH DATNSL0SuJN4hWtk7kxpgefBpf1N4A6FqqP20pYbDdTb36clPI1JhualFG4xMrrk8O8K UZr8ZWjEQBHJBRhotfCz+xHGdFcbnrpa85wcxUD/x/GzP8AvRofzPOC4ctYMRL36rGzV DLPA==
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=EzxR8mmz6KhM21WUIHxpdKh+KV7LZamNVr4Iab6V+pU=; b=Z9UrxCClcK5Ck1TtfX2uLLxUUuFQ4syErkp8wD3o/W6SyZdlscfBjkGLh7cuy/nF96 DoeP6y3GMFezXjzBYU7sFSutgx123/mYpbDfoF2oWw5wEdyGPyRqqrIGib3tUL9a/EVs KpQM+v/cUDyJZqvR9XvvCDk7W5PFDvsebTiYevXnzyduZVJOqTmIFoCxd1Lbm7A8/Z18 jFzoogcSvsvUeDJFHbTRMKzs3ih3eLQu2jjUC26oMd0f/drsuCIwj8Me6Lf1i1wsltjk yon/ipZjAKJyDytiEnRwgB73GBPzk3YI4XNxThZSyXFkTsp0RDxysJcTUnX1S3NJe8pk 1T4A==
X-Gm-Message-State: APjAAAXqxD41oU1UVH3XuX2zzMrWU7XLzEjsk202KH15dbYQwnFAzpiI StYiU+dAOe0VvmrRDJ6CU2y49yB1KFE=
X-Google-Smtp-Source: APXvYqxk4KcdLxlNM702n+/NuRr8F13A5ZutCJuTIp0sniZ0Gev0yZvG2SG2t0lHGTIlj6fqolPEBw==
X-Received: by 2002:a63:c204:: with SMTP id b4mr68326060pgd.335.1554240403127; Tue, 02 Apr 2019 14:26:43 -0700 (PDT)
Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com. [209.85.210.169]) by smtp.gmail.com with ESMTPSA id y12sm37692942pgq.64.2019.04.02.14.26.42 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Apr 2019 14:26:42 -0700 (PDT)
Received: by mail-pf1-f169.google.com with SMTP id z5so5984111pfn.3 for <mmusic@ietf.org>; Tue, 02 Apr 2019 14:26:42 -0700 (PDT)
X-Received: by 2002:a62:2a97:: with SMTP id q145mr72325643pfq.22.1554240402188; Tue, 02 Apr 2019 14:26:42 -0700 (PDT)
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> <CAD5OKxu7Sjnp6zLo1jxnqS5_3URM6Fj9KrijSLKXERHBqr1Pkw@mail.gmail.com> <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> <CAD5OKxtn4TCZCgV_4r17AqUgbFxgk1NjMBNCR0Gcn-67zRJCwQ@mail.gmail.com> <CAOJ7v-1z4P-=RQfUb1o2JGduuVNs3G-HmXNXxuvrM-4XhRH_9w@mail.gmail.com> <CAD5OKxv72sfohGx1pYwsfb8hki8NPRvJ=2bbv+MrX88gk7xg1g@mail.gmail.com> <CAD5OKxui3MtNmjG+S1jNdo-D6QiLg_Y2=fSXV+XO6U8HXT5fEA@mail.gmail.com>
In-Reply-To: <CAD5OKxui3MtNmjG+S1jNdo-D6QiLg_Y2=fSXV+XO6U8HXT5fEA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 2 Apr 2019 17:26:33 -0400
X-Gmail-Original-Message-ID: <CAD5OKxsgk+mi7Pa+PD2OtCFDwXwVUy5h7qw=7VYk4wMV-x2Amg@mail.gmail.com>
Message-ID: <CAD5OKxsgk+mi7Pa+PD2OtCFDwXwVUy5h7qw=7VYk4wMV-x2Amg@mail.gmail.com>
To: mmusic WG <mmusic@ietf.org>
Cc: Justin Uberti <juberti@google.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="0000000000001171d8058592cb0e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/Cbl35JijtgEmXe95qdVWZuLFShc>
Subject: [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: Tue, 02 Apr 2019 21:26:47 -0000

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