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

Roman Shpount <roman@telurix.com> Wed, 10 April 2019 19:36 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 6E3CC1205E2 for <mmusic@ietfa.amsl.com>; Wed, 10 Apr 2019 12:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 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, 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 a26aVlRBdVC4 for <mmusic@ietfa.amsl.com>; Wed, 10 Apr 2019 12:36:08 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 9C0451205CD for <mmusic@ietf.org>; Wed, 10 Apr 2019 12:36:05 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id j26so2151625pgl.5 for <mmusic@ietf.org>; Wed, 10 Apr 2019 12:36:05 -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=vMZPgsy4LyxC4rDAsT70WvnfDXVoc86SN1cg/Bg7Sko=; b=LS1w21404tl2R5EtwMUtP86ulT7qxin/HYt5P/LuuTiFrAoKJoHgjkl+qi0DbLNenC YYOQ9UhnmfKrlNZVVoEvAQnhmyKAnG9KIJcyZDPXIDVI9asRi3BIbZ8zhWCCv/hF4olv zvdE+eIlWTZzdNe1BNjNrH2IzXDHp9yw5gFEYKAeKTFGcH7rLXfayq+da50KP4dxL6/H PJipLQASJkzu3FdSWaiYvdOgJgo2MIy685MbLq8LpNGa6XR75551d9dak0xiyDdF5H8c 537ZeCIeYdiyxtCg/OdH9n7TWg+WI67xMFXfsjrVzLXI1GWtcT7f99mq63lMABrwPqO6 gung==
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=vMZPgsy4LyxC4rDAsT70WvnfDXVoc86SN1cg/Bg7Sko=; b=qL7o+ohOB87o4HNL2ZUIllJDdBgtEnAyWf32C1jEfsg9H2DpE8vNybrkMJjsMKVqkO vDWEXBOYOr0/bsBsnk7zGq+6zxPP5Gy6C14TcPK9SX1G3MdXAmwg6V4ool/yg0ApwgJ1 WQbD6dzZsaqz6iOioGSSUg9m2HU4fUjND0B4Jc0GhJgeX0wjuPgnFk1cPNRODOG/PrA1 +EXZ7zsFr2pashzjj0vqhOtKlEw2PkYTkQSYJLwzFziV5E8KLCqybMtLO6uQMPPmKkqb 7jdUcOVmxca38jYs2Dbc+vEYkVbZoxpM9TGe8U9edNXJDLIP24m/13wUNcH3vm8dBlEh iN9w==
X-Gm-Message-State: APjAAAUT4CmUX+DA+R9XfFx+qQFpnMX7CIjieAyqb0iYpzmHmydNtHgT PnhZwc7pOgGSyZErfZYNjkP9x7kbJ2g=
X-Google-Smtp-Source: APXvYqwWzqurK2fGhK3un1om8+AYUGzAcBorSqAR9gIk2h29BZfc4k7YFqQFFha3QYp/3er/F9dB7Q==
X-Received: by 2002:a63:ed10:: with SMTP id d16mr42588841pgi.75.1554924964735; Wed, 10 Apr 2019 12:36:04 -0700 (PDT)
Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com. [209.85.214.170]) by smtp.gmail.com with ESMTPSA id v12sm48670355pfe.148.2019.04.10.12.36.03 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 12:36:03 -0700 (PDT)
Received: by mail-pl1-f170.google.com with SMTP id t16so2036567plo.0 for <mmusic@ietf.org>; Wed, 10 Apr 2019 12:36:03 -0700 (PDT)
X-Received: by 2002:a17:902:b686:: with SMTP id c6mr45967095pls.14.1554924963307; Wed, 10 Apr 2019 12:36:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5OKxux4s=4TtA7vQT0X-u+3RS+MVHG=RjgGDHWQ5H1k0OdLg@mail.gmail.com> <CAMRcRGTmYB-CMXA5ToPhdPtLrTeKmdeZCLT-ecxfTYGHEh-HMQ@mail.gmail.com> <CAD5OKxsPDagYEFFMhxGnm3H+gAWEsKmt41rw44GCmorneVytzQ@mail.gmail.com> <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>
In-Reply-To: <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>
From: Roman Shpount <roman@telurix.com>
Date: Wed, 10 Apr 2019 15:35:49 -0400
X-Gmail-Original-Message-ID: <CAD5OKxsbQhU_1ADsnbcHUtfoiK96We004AEmtajO-EvY0dRd7Q@mail.gmail.com>
Message-ID: <CAD5OKxsbQhU_1ADsnbcHUtfoiK96We004AEmtajO-EvY0dRd7Q@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Suhas Nandakumar <suhasietf@gmail.com>, mmusic WG <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com>
Content-Type: multipart/alternative; boundary="0000000000001725c80586322ec7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/roeubKrYjELhS06gBDKgfJxcHyU>
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 19:36:17 -0000

On Wed, Apr 10, 2019 at 3:13 PM Christer Holmberg <
christer.holmberg@ericsson.com>; wrote:

> >Limiting FQDN scope to resolving to just one address is an
> unimplementable requirement. Currently on large number of devices, FQDN
>
> >which is supposed to resolve to IPv4 address only, will resolve to both
> IPv6 and IPv4 addresses. For instance on virtually all IOS and most
> >of the Android devices on mobile networks FQDN pointing to IPv4 returns
> results for IPv6 as well. Essentially what we are specifying now is
> >that ICE candidates with FQDN address MUST be ignored.
>
>
>
> Isn’t the main reason for allowing FQDN to enable usage of mDNS?
>

 It is now. Nothing in the latest language that I propose prohibits mDNS
draft define how FQDN are supposed to work when mDNS is used. All my
language states that default treatment for FQDN is to ignore it which keeps
mDNS backwards compatible. I would also suggest adding an ICE option to
specify that mDNS is supported. This being said, I am not sure mDNS
prevents IPv4 address being resolved as IPv6 through DNS64, so mDNS is
likely going to end up with two addresses for a single candidate.

In my opinion, the current ICE procedures assumes one IP address:port per
> candidate. If we allow a candidate to be associated with multiple IP
> addresses:ports, we would have to modify the ICE procedures in order to
> handle that: how a candidate can be part of multiple foundations (one for
> each resolved IP address:port), how the freezing/unfreezing procedure work,
> whether connectivity checks are sent to all resolved addresses, how the
> state of the candidate is set if one IP address:port succeeds but another
> doesn’t. Or, should the candidate be split into multiple candidates (one
> for each resolved IP address:port)? Etc etc etc etc etc. All of that could
> probably be done, but I think it would be quite a bit of work- an update
> (or even a bis) to RFC 8445. It is **NOT** an ice-sip-sdp specific issue
> in my opinion.
>

I am not suggesting changing that only one address is supported per
candidate. What I am suggesting is that candidate needs some sort of hint
when FQDN is used to specify how address should be resolved. Here is my
proposed solution:

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

Example:
a=candidate:2319437384 1 udp 2122260223
8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local
60454 typ host *inipv4*
a=candidate:2319437384 1 udp 2122260223
8a2fd7b5-41d5-4c15-ad83-d33a0d66a78b.local
60454 typ host *inipv6*

This keeps each candidate line to one address and works in cases when FQDN
resolves to one IPv4 and one IPv6 address due to something like DNS64.

Regards,
 _____________
Roman Shpount