Re: [MMUSIC] ICE candidate pairing and NAT64

Jonathan Lennox <jonathan@vidyo.com> Wed, 22 July 2015 15:14 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830A81A010C for <mmusic@ietfa.amsl.com>; Wed, 22 Jul 2015 08:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 trXWYNQLqscZ for <mmusic@ietfa.amsl.com>; Wed, 22 Jul 2015 08:14:23 -0700 (PDT)
Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 734491A0123 for <mmusic@ietf.org>; Wed, 22 Jul 2015 08:14:23 -0700 (PDT)
Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6MFCKkW002758; Wed, 22 Jul 2015 11:14:13 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1vndjeut54-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 11:14:13 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 10:14:12 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Dan Wing <dwing@cisco.com>
Thread-Topic: [MMUSIC] ICE candidate pairing and NAT64
Thread-Index: AQHQrerP8Bq8S0QLeECkbf43H8WpDZ27MEeAgADuiwCAAAYGgIAr0lCAgAANvQCAABU0gA==
Date: Wed, 22 Jul 2015 15:14:11 +0000
Message-ID: <0C2E7D07-5C1D-4082-982E-DF1AE4B0A7B9@vidyo.com>
References: <CA8D917B-8C7C-42B9-BF65-F7209DFCA15C@vidyo.com> <64FC711B-0B70-4489-A08B-8218DA80BF77@cisco.com> <5BA416A3-E8B9-4A28-95C2-6CCF31072A83@vidyo.com> <4C0411C4-02C7-4B19-B8F8-2E6E4E277008@cisco.com> <55AF95F1.4080005@ericsson.com> <2E9BA34A-8F2E-4ABC-8678-960A2F7998C1@cisco.com>
In-Reply-To: <2E9BA34A-8F2E-4ABC-8678-960A2F7998C1@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.179.79]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D2A6E0C99C11854CBF0FF3C2A5643830@vidyo.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-22_04:2015-07-22,2015-07-22,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507220232
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/y_NfoevSfhqvGbuNkPPWgdvc64I>
Cc: Ari Keränen <ari.keranen@ericsson.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE candidate pairing and NAT64
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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, 22 Jul 2015 15:14:24 -0000

> On Jul 22, 2015, at 3:58 PM, 🔓Dan Wing <dwing@cisco.com> wrote:
> 
> 
> On 22-Jul-2015 03:09 pm, Ari Keränen <ari.keranen@ericsson.com> wrote:
>> 
>> Hi,
>> 
>> I agree that candidates from NAT64 setups would be useful. But I wonder what's the best way to discover them without adding too much complexity. In particular I'd prefer single mechanism that works across all (/many) cases.
>> 
>> If there is also DNS64 in use, discovering IPv4 STUN/TURN server via that would result in NAT64 translated server reflexive addresses. This seems to be fine according to the STUN RFC [1] and STUN bis [2].
> 
> Yes, that should work with NAT64.
> 
>> In that case prefix discovery would not be needed.
> 
> Well, prefix discovery can still be useful, because the NAT64 might not be BEHAVE-friendly (specifically I am referring to address-dependent mapping, where the local ICE client has to send packets towards the remote ICE peer).  Maybe there aren't any NAT64s with address-dependent mapping behavior, but I worry there is a vendor or two that implemented such a thing.  I wonder if RIPE Atlas probes could do such testing of NAT64s they are behind?

It’s not just address-dependent mapping on the NAT64 that’s an issue — address-dependent filtering is enough for the prefix discovery to be necessary.

>> Or if it is used in parallel, one should probably check that the same prefix is not discovered twice?
> 
> Yeah, that's another check that should be written down.
> 
>> And how about the 464XLAT case?
> 
> I don't know, because I don't know if the ICE client would be aware of 464xlat; the IPv4 interface could look very 'real'.  And if 

Presumably you could check whether the server-reflexive IP address for a v4 also appears on some v6 candidate — if they are, the v4 is very likely to be 464xlat. That’s a heuristic, though, with both false positives and false negatives.

>> I think these should be prioritized like IPv4 server reflexive candidates.

This is an interesting case in that the prefix-mapped remote candidates are entirely “synthetic”, i.e. the remote endpoint doesn’t necessarily even know the local side is using them, and has no way to assign priorities to them.   I’m also uncertain whether inserting these this has any effects on pacing.

>>>> It’s not just a matter of which interface you use to send the request, but which interface’s configuration information you use to discover the DNS server.  (Consider a dual-SIM device which can connect to  two different carriers’ cellular data networks, both of which are using NAT64.)
>>> 
>>> Yes, good point.  I agree if all the DNS & DNS64 servers learned from each interface is munged together (like it is with the traditional /etc/resolv.conf), we can't be successful at building synthetic NAT64 addresses.  That's what MIF was going to fix.  I know Dmitry Anipko was making good progress at keeping the learned DNS server from each interface separate on Windows, mostly for split-horizon support [e.g., enterprise VPN] but per-interface DNS64 is exactly the same split-horizon problem.  The learned DNS servers, and the interface each DNS server was learned from, need to be available to the application.  On OSs where that isn't possible, I think worst case is some additional ICE candidates and additional ICE connectivity checks, which will fail?

(Just noticed this in the thread history.)

It’s not clear to me whether the implementations that don’t expose split horizon send out DNS requests to all interfaces (and thus combine them), or just to one preferred one and return its answer.  In the former case you’d get redundant ICE candidates, but in the latter you’d have no way of doing prefix discovery for the non-preferred interfaces at all.  As I understand the classic libresolv, it has the latter behavior; but I don’t known what modern OSes do.