Re: [MMUSIC] FQDN support in ice-sip-sdp
Christer Holmberg <christer.holmberg@ericsson.com> Wed, 10 April 2019 19:13 UTC
Return-Path: <christer.holmberg@ericsson.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 D75BD1203B5 for <mmusic@ietfa.amsl.com>; Wed, 10 Apr 2019 12:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ericsson.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 ZjVfvwDuW7F6 for <mmusic@ietfa.amsl.com>; Wed, 10 Apr 2019 12:13:18 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10083.outbound.protection.outlook.com [40.107.1.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9D51203E1 for <mmusic@ietf.org>; Wed, 10 Apr 2019 12:13:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oDMI2jmAwFv0lgLmideMrK2urW7QSgVD2AGHAeQxsCQ=; b=V7juxbIRV6fEi6Hn3fx9oGsoD6uE2zRXNLfhDIIw96+nsr0WmTNMaY6kBhvDEAHKtfNsRaLp6DBqbf/AJVbWMpoOG0YSKbB3h9B0YrzemruHMKaT2JZaYXWaGaBH200tQkA/nhkOrq8EPOncN2bFf+lLubo/X7ue2V5w2DVBrMM=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4265.eurprd07.prod.outlook.com (20.176.166.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.9; Wed, 10 Apr 2019 19:13:13 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1792.007; Wed, 10 Apr 2019 19:13:13 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Suhas Nandakumar <suhasietf@gmail.com>
CC: mmusic WG <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com>
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAA==
Date: Wed, 10 Apr 2019 19:13:13 +0000
Message-ID: <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>
References: <CAD5OKxux4s=4TtA7vQT0X-u+3RS+MVHG=RjgGDHWQ5H1k0OdLg@mail.gmail.com> <CAMRcRGTmYB-CMXA5ToPhdPtLrTeKmdeZCLT-ecxfTYGHEh-HMQ@mail.gmail.com> <CAD5OKxsPDagYEFFMhxGnm3H+gAWEsKmt41rw44GCmorneVytzQ@mail.gmail.com>
In-Reply-To: <CAD5OKxsPDagYEFFMhxGnm3H+gAWEsKmt41rw44GCmorneVytzQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [178.55.193.218]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cc0c7832-0e82-482e-b8ad-08d6bde89460
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4265;
x-ms-traffictypediagnostic: HE1PR07MB4265:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <HE1PR07MB4265F9D06D28D8EA3DE757A4932E0@HE1PR07MB4265.eurprd07.prod.outlook.com>
x-forefront-prvs: 00032065B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(346002)(376002)(39860400002)(189003)(53754006)(199004)(51914003)(316002)(110136005)(54906003)(58126008)(8936002)(86362001)(81156014)(81166006)(8676002)(6246003)(53936002)(5660300002)(229853002)(236005)(33656002)(6486002)(54896002)(105586002)(6436002)(6512007)(6306002)(106356001)(36756003)(97736004)(44832011)(66066001)(14454004)(14444005)(256004)(478600001)(83716004)(71190400001)(71200400001)(4326008)(6116002)(606006)(102836004)(26005)(53546011)(966005)(6506007)(99286004)(68736007)(3846002)(2906002)(486006)(82746002)(7736002)(25786009)(2616005)(446003)(476003)(11346002)(186003)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4265; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DS+xA100HV0eSUIhwOWl2HY1JqMXXKqpx5xBmVx3CPaVfY+grXPslvMTqaWpnnKDdDjGnKN4oKdEAH0Kd2hUc7V/Q0RpDoZlGJhnA0zScx062vumCA3co2mDWvwMyJBeMCVvD1zW+F1ozte9QBQm6fPoajwYkQnB/hO+RoWuu4iWEU4Z0uORZQr6CL2pQOpBiG+V2RX1Bte4JY0JTHr5TDOzYvbKaG7/h/fbANiX8gckSB/1qqWeGHx71PBuOns9T7SgLTh/gGEkhuXuz2Jg1ZuBdOOH3kwqdg7O8sIoQ5saerimvRZUMhRbbTRYzZj8Uundhsk7M7ExTqDci8eN++cmS4wDZx4qKV8kdSYlIR2MYNCbUWAF407FBPTfOQ5NxRKCVov4CepnPr6asJNXd+xZ6jgZ97BD5ZiMJNv4up8=
Content-Type: multipart/alternative; boundary="_000_3DD3D8D69B134F9D80DDF89B69240708ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cc0c7832-0e82-482e-b8ad-08d6bde89460
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 19:13:13.7621 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4265
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/izFfHk7nDvguntql_dJ7Vmiv0NI>
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:13:21 -0000
Hi, >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? 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. Regards, Christer On Wed, Apr 10, 2019 at 1:40 AM Suhas Nandakumar <suhasietf@gmail.com<mailto:suhasietf@gmail.com>> wrote: 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<mailto: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<mailto:mmusic@ietf.org> https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Suhas Nandakumar
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Suhas Nandakumar
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Suhas Nandakumar
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg