From Ted.Lemon@nominum.com Fri Feb 1 12:11:28 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FE921F8FDA for ; Fri, 1 Feb 2013 12:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnvDz5gx8J8R for ; Fri, 1 Feb 2013 12:11:27 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id CC0AA21F8FD9 for ; Fri, 1 Feb 2013 12:11:27 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUQwhb9IU3qn0eC0iPPKo2x3NdfjPHTVJ@postini.com; Fri, 01 Feb 2013 12:11:27 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7653D1B84C8 for ; Fri, 1 Feb 2013 12:11:27 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6C3D4190043; Fri, 1 Feb 2013 12:11:27 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 12:11:27 -0800 From: Ted Lemon To: GangChen Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHN/4Aj7tWKNy2hlkOFimKY6NCZjZhl97wA Date: Fri, 1 Feb 2013 20:11:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <764D1CF95ADE12478C3453A7AFF21E94@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 20:11:28 -0000 On Jan 31, 2013, at 1:56 AM, GangChen wrote: > Therefore, RFC6731 should be recommended as the proper solution for > DNS selections. RFC6731 is only applicable in a very restricted set of use cases, and canno= t be counted upon to resolve this issue in the majority of use cases. I w= ould expect it to be helpful in the case of some enterprise situations (but= not with BYOD) and with some mobile handsets (but only for the mobile prov= ider's private domains). So we simply can't use this to address the probl= em. From phdgang@gmail.com Sun Feb 3 06:12:32 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E152921F846C for ; Sun, 3 Feb 2013 06:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCihAMNLwCb2 for ; Sun, 3 Feb 2013 06:12:32 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id C963921F8E97 for ; Sun, 3 Feb 2013 06:12:31 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id j8so951878qah.0 for ; Sun, 03 Feb 2013 06:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=E2rf1oFb5VmsgFf/uksrA3zdzGV1XIu/KfehDSXSMAs=; b=e8jt2tbzIRcvu77J1/ZKU8VtES2RIz9Mx3uyx+3imt686pEJNCEjyeCqfJFAKWDIps rdlC+oMLNqtHfPixnGT/4UI5RKqa4exeRvxWfUFD/+dBZECOT5TUsvKG7//JwMD0PnU5 QguyukwZW25Bk9wRFQDxC9iIyPlPBoWJVcELWr5O/K/mcNYfWm9USsCOnnAm0+0YdilI HfuZhMdE9Mq06ThcbMUUP0PamUDYfwMZbLANVZ5Dr9YYVxtr1mcEMPVaef2q+gYdW9Fx dOq9rsEC9+EroX3Owye4Gh8eXO6VUibVpT05UiLTKAA6ymQlQGeHj5hbkiOrjvOf4KiU MTSw== MIME-Version: 1.0 X-Received: by 10.224.207.72 with SMTP id fx8mr17066169qab.66.1359900751107; Sun, 03 Feb 2013 06:12:31 -0800 (PST) Received: by 10.49.48.12 with HTTP; Sun, 3 Feb 2013 06:12:30 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> Date: Sun, 3 Feb 2013 22:12:30 +0800 Message-ID: From: GangChen To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 14:12:33 -0000 2013/2/2, Ted Lemon : > On Jan 31, 2013, at 1:56 AM, GangChen wrote: >> Therefore, RFC6731 should be recommended as the proper solution for >> DNS selections. > > RFC6731 is only applicable in a very restricted set of use cases, and cannot > be counted upon to resolve this issue in the majority of use cases. I Acknowledged. RFC6731 listed the use cases. The described case 1, 2 in the previous message can be likely solved through RFC6731. So the statement of applicability is particularly for those cases. > would expect it to be helpful in the case of some enterprise situations (but > not with BYOD) and with some mobile handsets (but only for the mobile > provider's private domains). So we simply can't use this to address the > problem. I would like to learn more about the problems. One description I found was documented in http://tools.ietf.org/html/rfc6418#section-4.1. If I understand correctly, it mainly talk about the issues of coordination with private name space among different interfaces. I guess those issues are also the targets of RFC6731. If there is anything missing, it would be helpful you could kindly point out. Best Regards Gang > From Ted.Lemon@nominum.com Sun Feb 3 07:04:45 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A7621F8488 for ; Sun, 3 Feb 2013 07:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1szgXApthsV for ; Sun, 3 Feb 2013 07:04:44 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id CACBA21F8468 for ; Sun, 3 Feb 2013 07:04:44 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ58jJaxCF83YsUy+vcv3FPGFEOiIxcx@postini.com; Sun, 03 Feb 2013 07:04:44 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CB8AB10809F for ; Sun, 3 Feb 2013 07:04:43 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 55310190052; Sun, 3 Feb 2013 07:04:43 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 3 Feb 2013 07:04:37 -0800 From: Ted Lemon To: GangChen Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmA Date: Sun, 3 Feb 2013 15:04:36 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8B1A4007C092B44F8787E7CC70E6B98F@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 15:04:45 -0000 On Feb 3, 2013, at 9:12 AM, GangChen wrote: > I would like to learn more about the problems. There are quite a few separate issues. We generally treat DNS results as = if they are essentially stateless=97regardless of who asks the question, th= ey should get the same answer. However, there are a lot of situations whe= re this simply isn't true. Some of them are covered by RFC6731, but most = are not. The most obvious cases are situations where there is in fact a split dns ar= chitecture, but RFC6731 isn't applicable. This is probably most split dns= situations. The second set of cases are cases where DNS is used to operate a captive po= rtal. In these cases, the DNS server on the captive portal will give diff= erent answers than a DNS server on a working 3G link, for instance. So if= HE treats DNS responses as if they were generally equivalent, either we wi= ll be unable to ever see the captive portal web page, or we will be unable = to use the 3G network without logging in to the captive portal. Neither s= ituation is desirable. A third, less obvious, set of cases are where DNS is used to optimize CDN d= elivery. In this case, suppose I have a 3G interface that doesn't have CD= N-optimized DNS, and a connection through my ISP on the wireless LAN that d= oes have CDN-optimized DNS. In this situation, if I treat the two DNS ser= vers as equivalent, then I may use the 3G DNS server to look up information= I will then use to connect to the CDN over the wireless LAN interface. T= his will likely result in suboptimal routing, and unacceptable performance. This is why when I've discussed this issue in the past, I've always argued = that each provisioning domain needs to be treated separately. We should n= ot look up names in one provisioning domain and use them in another; if we = want to try connecting across multiple provisioning domains, we should do D= NS lookups on each such provisioning domain, and use the results we get onl= y for connecting within that provisioning domain. From moore@network-heretics.com Sun Feb 3 07:47:02 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0505521F8521 for ; Sun, 3 Feb 2013 07:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN5LNhJy28tx for ; Sun, 3 Feb 2013 07:47:01 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5A58821F851F for ; Sun, 3 Feb 2013 07:47:01 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7AF1C20E54 for ; Sun, 3 Feb 2013 10:47:00 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 03 Feb 2013 10:47:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=eoiqr9Tcuff1cNPZIQ60z7 ZmbOk=; b=QFPVbekygktqkaHwbmj7+pk9Wgmdnd7NuSP8ajCYglEIdAE7nYthTF pkEW38mVpdK+ydw8tarvGSd4kbf6JvSTtYULLyrgy5nWA17dD+7TQ47WdrgkrVdt eJXGUfkfOOkx080ZNFtkMkNjNWCzjLZvVYsyYV/r6r4NszL0z2/ro= X-Sasl-enc: VK3RI1pefDBxZxzHmHGpb/eZ1ZGrz0BWIRj0sNY+zawq 1359906420 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D660848263F; Sun, 3 Feb 2013 10:46:59 -0500 (EST) Message-ID: <510E8667.3020608@network-heretics.com> Date: Sun, 03 Feb 2013 10:46:47 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 15:47:02 -0000 On 02/03/2013 10:04 AM, Ted Lemon wrote: > This is why when I've discussed this issue in the past, I've always argued that each provisioning domain needs to be treated separately. We should not look up names in one provisioning domain and use them in another; if we want to try connecting across multiple provisioning domains, we should do DNS lookups on each such provisioning domain, and use the results we get only for connecting within that provisioning domain. Problem is, this is bad for the Internet architecture, as it basically encourages using DNS as a routing protocol. Keith From Ted.Lemon@nominum.com Sun Feb 3 08:06:01 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4040821F8605 for ; Sun, 3 Feb 2013 08:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FcEqn2z9LD6 for ; Sun, 3 Feb 2013 08:06:00 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9C58421F84E0 for ; Sun, 3 Feb 2013 08:06:00 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ6K6OYVtGlmVaQF7Wl8nIkVFMw8R4sQ@postini.com; Sun, 03 Feb 2013 08:06:00 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 390571B8536 for ; Sun, 3 Feb 2013 08:06:00 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 30934190043; Sun, 3 Feb 2013 08:06:00 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 3 Feb 2013 08:05:55 -0800 From: Ted Lemon To: Keith Moore Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmAgAALy4CAAAVXAA== Date: Sun, 3 Feb 2013 16:05:54 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747BCF6@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <510E8667.3020608@network-heretics.com> In-Reply-To: <510E8667.3020608@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <35AEE5C94A04CA40A9EB956D5B89BEDB@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 16:06:01 -0000 On Feb 3, 2013, at 10:46 AM, Keith Moore wrote= : > Problem is, this is bad for the Internet architecture, as it basically en= courages using DNS as a routing protocol. I think using DNS for CDNs is a bad idea, and it's also something that I th= ink people are moving away from, but it is an issue, so I described it. A= ll of the use cases I described are essentially abuses of the DNS; the ques= tion is whether we will spec out something that is robust in the face of th= ese abuses, or whether we will spec out something that simply falls over an= d dies when people abuse the DNS. In my mind, these scenarios are essentially DoS attack scenarios: the end u= ser is being attacked by the DNS provider in a provisioning domain, who is = giving them corrupt data that will negatively impact their use of the netwo= rk. The question is, do we allow that attack to spill over into other pro= visioning domains, or do we spec out a standard that prevents such spill-ov= er? From brian.e.carpenter@gmail.com Sun Feb 3 08:32:17 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713F121F8447 for ; Sun, 3 Feb 2013 08:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.13 X-Spam-Level: X-Spam-Status: No, score=-101.13 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNNqeZhgtqUc for ; Sun, 3 Feb 2013 08:32:17 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9C21F843E for ; Sun, 3 Feb 2013 08:32:16 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so2134650wid.6 for ; Sun, 03 Feb 2013 08:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qstMXA9jN2Nv86y80/IJVYiNWYOcUCO3F84whA9HjFE=; b=EZhhLr/0hGBiHGJG1083njenbwKjRMxudvtcH0BprHtKWP+lnHPlDxozhHXHZI2/si qkhLv5QES7AZGwmTkmBm6xqN0PO9n9tBCKD+LY60H7v5xYqAogFFanHAf5dk74RQ8HV9 hjaAT/UaMIb1OdHNX7J5HKvzBccC1CDQ2+VQwM9phN2KZN1OtEFaPmMKZAuC674AZorK ywQbZvVCIUz8fxLwXgeIePwypN3ltGht9knL2WRWNaPMpgzzXocvuhDkEpmYYWzFzlhC hXLt3KDcjUnHGKTWBSsb4zXtt4zc+qQ2tyUgCfOsEyot9RnVkSh5POIm+7JGhpCBXyfR TfJg== X-Received: by 10.194.119.5 with SMTP id kq5mr30621541wjb.48.1359909135962; Sun, 03 Feb 2013 08:32:15 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-151.as13285.net. [2.102.218.151]) by mx.google.com with ESMTPS id eo10sm16445129wib.9.2013.02.03.08.32.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 08:32:15 -0800 (PST) Message-ID: <510E910E.6090806@gmail.com> Date: Sun, 03 Feb 2013 16:32:14 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <510E8667.3020608@network-heretics.com> In-Reply-To: <510E8667.3020608@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 16:32:17 -0000 On 03/02/2013 15:46, Keith Moore wrote: > On 02/03/2013 10:04 AM, Ted Lemon wrote: >> This is why when I've discussed this issue in the past, I've always >> argued that each provisioning domain needs to be treated separately. >> We should not look up names in one provisioning domain and use them in >> another; if we want to try connecting across multiple provisioning >> domains, we should do DNS lookups on each such provisioning domain, >> and use the results we get only for connecting within that >> provisioning domain. > Problem is, this is bad for the Internet architecture, as it basically > encourages using DNS as a routing protocol. It also means that the resolver performing the lookup needs to understand this concept of "provisioning domain" and to know which such domain(s) matter for the lookup in question. My big book of Internet magic doesn't seem to explain how the resolver would know this, or how the RR would be tagged to designate which domain(s) it applies to. Brian From Ted.Lemon@nominum.com Sun Feb 3 08:35:20 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749E121F86C1 for ; Sun, 3 Feb 2013 08:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fQzZ9+6To0n for ; Sun, 3 Feb 2013 08:35:20 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id E5D5C21F8464 for ; Sun, 3 Feb 2013 08:35:19 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ6Rx5TY2+pNGxxPhUrWBBkaOl3cnEkF@postini.com; Sun, 03 Feb 2013 08:35:19 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 936961080A2 for ; Sun, 3 Feb 2013 08:35:19 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8AB46190043; Sun, 3 Feb 2013 08:35:19 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 3 Feb 2013 08:35:13 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmAgAALy4CAAAyyAIAAANUA Date: Sun, 3 Feb 2013 16:35:12 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747BDF8@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <510E8667.3020608@network-heretics.com> <510E910E.6090806@gmail.com> In-Reply-To: <510E910E.6090806@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Keith Moore Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 16:35:20 -0000 On Feb 3, 2013, at 11:32 AM, Brian E Carpenter wrote: > My big book of Internet magic doesn't seem to explain how the > resolver would know this, or how the RR would be tagged to > designate which domain(s) it applies to. Right, this is why this working group exists (IMHO). From moore@network-heretics.com Sun Feb 3 08:36:20 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81AF21F8964 for ; Sun, 3 Feb 2013 08:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxdf9PP6bNkO for ; Sun, 3 Feb 2013 08:36:19 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 278A021F8703 for ; Sun, 3 Feb 2013 08:36:19 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BBD23207CD; Sun, 3 Feb 2013 11:36:18 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 03 Feb 2013 11:36:18 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=6dqloP4xn14xlgh3hkD3M3 Lb0aU=; b=FL/GTgwvTsypRRMhrjjTLSG25u+s7yT/k7K1nb/3OgqNHe+QUaQtv9 Tg5IIND+p+iJF9ACx7jJHxQ/Z7+FAyUKqNabMnVKbJbVLbTaT8bKsDiF69wdBLrz kE7HBSZzg5b1cR8DmQFs8ji8GI09gOL2W0tDjs5ykW8ceEcHItio4= X-Sasl-enc: KaLk0OVXaegEaVUrF9pSaLoYiHhMYKNGcqTGDQuVMmSf 1359909378 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id CF4AC8E0917; Sun, 3 Feb 2013 11:36:17 -0500 (EST) Message-ID: <510E91F5.4030005@network-heretics.com> Date: Sun, 03 Feb 2013 11:36:05 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <510E8667.3020608@network-heretics.com> <8D23D4052ABE7A4490E77B1A012B63074747BCF6@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BCF6@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 16:36:20 -0000 On 02/03/2013 11:05 AM, Ted Lemon wrote: > On Feb 3, 2013, at 10:46 AM, Keith Moore wrote: >> Problem is, this is bad for the Internet architecture, as it basically encourages using DNS as a routing protocol. > I think using DNS for CDNs is a bad idea, and it's also something that I think people are moving away from, but it is an issue, so I described it. All of the use cases I described are essentially abuses of the DNS; agree. > the question is whether we will spec out something that is robust in the face of these abuses, or whether we will spec out something that simply falls over and dies when people abuse the DNS. I think this is a case where IETF has failed (over a long period of time) to devote sufficient attention to managing the Internet architecture. In this case, IETF has failed to recognize the cases where people were tempted to abuse DNS, and to either adapt DNS or provide alternative solutions. There was little about the Internet architecture, and nothing about DNS, that was incompatible with having multiple network interfaces on a host. It's only when DNS is abused that this problem crops up. And now IETF has essentially asked a working group with a very narrow scope to fix a fairly broad architectural issue that has been exacerbated by 15 or so years of neglect. Of course, IETF does this all the time - MIF isn't the only group that's been asked to patch deficiencies in the architecture that were really beyond its proper scope. But this particular issue seems thornier, and to have worse long-term consequences, than most. This is in some sense a structural problem with IETF - its division of work into areas based loosely on layers of the protocol stack, and its habit of trying to do everything in narrowly-scoped working groups, almost entirely precludes resolution of architectural issues, particularly when those issues involve conflicts (and require compromises) between different layers and/or different interests. But my point isn't to make a speech. My point is to say that any real solution to this problem is probably beyond a reasonable scope of the MIF WG. Though perhaps MIF could propose a solution as a starting point, it should not be trying to define the solution. It doesn't, and cannot, represent a wide enough set of interests to dictate the changes that need to occur to DNS and DNS configurations and/or ICMP and/or network configurations and/or applications and/or network stacks, to resolve this satisfactorily. > In my mind, these scenarios are essentially DoS attack scenarios: the end user is being attacked by the DNS provider in a provisioning domain, who is giving them corrupt data that will negatively impact their use of the network. The question is, do we allow that attack to spill over into other provisioning domains, or do we spec out a standard that prevents such spill-over? Or maybe the thing to do is document the problems, and explain why they're architectural issues, and perhaps suggest that IAB and/or IESG should undertake to bring a broad set of interests to the table to resolve such issues. Keith From moore@network-heretics.com Sun Feb 3 08:37:40 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C54021F86CA for ; Sun, 3 Feb 2013 08:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2Pw2uBhFOHa for ; Sun, 3 Feb 2013 08:37:39 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9832621F8681 for ; Sun, 3 Feb 2013 08:37:39 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4F87D208E2; Sun, 3 Feb 2013 11:37:39 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 03 Feb 2013 11:37:39 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=RR2EsiWzQK5YXCbjNkPb1M R2t2c=; b=M3yenger55ONnPUpx9ya//k8qPtogSFGZKcmB65X7y6aX2dh5RrJ/g BIRyVZfDxeIpxjEDLY4dykiGRSY31eiCQBHOBSIeEFZuxeDBNyAeJ08KMebVTbTO yL3S93lVrjtwQaZc9j9vVVFI9PAGor0vWrzV5ylzbueNIY0F3hntc= X-Sasl-enc: 5fDBE1cUpZnzgUwZztjMMs6u42TCjmGaxQ4vxVKCPtVx 1359909458 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 588098E090E; Sun, 3 Feb 2013 11:37:38 -0500 (EST) Message-ID: <510E9246.1070502@network-heretics.com> Date: Sun, 03 Feb 2013 11:37:26 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <510E8667.3020608@network-heretics.com> <510E910E.6090806@gmail.com> <8D23D4052ABE7A4490E77B1A012B63074747BDF8@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BDF8@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 16:37:40 -0000 On 02/03/2013 11:35 AM, Ted Lemon wrote: > On Feb 3, 2013, at 11:32 AM, Brian E Carpenter > wrote: >> My big book of Internet magic doesn't seem to explain how the >> resolver would know this, or how the RR would be tagged to >> designate which domain(s) it applies to. > Right, this is why this working group exists (IMHO). > And IMO, it's far beyond a reasonable scope for this, or any, WG that is limited to a single area. And perhaps a traditional IETF WG isn't the right structure for tackling this kind of problem. Keith From Ted.Lemon@nominum.com Sun Feb 3 08:48:33 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9FB21F8906 for ; Sun, 3 Feb 2013 08:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrP6fOrjTCfK for ; Sun, 3 Feb 2013 08:48:33 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4C21521F884F for ; Sun, 3 Feb 2013 08:48:33 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ6U4MFWoVUTZ/cEDaMC2St0vrBub+dQ@postini.com; Sun, 03 Feb 2013 08:48:33 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5A2D91080A3 for ; Sun, 3 Feb 2013 08:48:32 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4FB84190043; Sun, 3 Feb 2013 08:48:32 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 3 Feb 2013 08:48:32 -0800 From: Ted Lemon To: Keith Moore Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmAgAALy4CAAAyyAIAAANUAgAAAnwCAAAMZgA== Date: Sun, 3 Feb 2013 16:48:31 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747BEED@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <510E8667.3020608@network-heretics.com> <510E910E.6090806@gmail.com> <8D23D4052ABE7A4490E77B1A012B63074747BDF8@mbx-01.win.nominum.com> <510E9246.1070502@network-heretics.com> In-Reply-To: <510E9246.1070502@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <44F80910C8811242BF9C6683A8E5473F@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 16:48:33 -0000 On Feb 3, 2013, at 11:37 AM, Keith Moore wrote= : > And IMO, it's far beyond a reasonable scope for this, or any, WG that is = limited to a single area. And perhaps a traditional IETF WG isn't the righ= t structure for tackling this kind of problem. This seems like a fairly nonsensical statement. The IETF has areas, and w= orking groups. It is frequently the case that work being done in a workin= g group affects more than one area. The IETF has not burst into an explos= ion of pure energy as a result of the streams being crossed thus far. I s= uspect we are safe in the future as well. If you have some concrete proposal to make, I think it would be worth heari= ng it, but if you are just going to take pot shots, there's not much the re= st of us can do except to try to continue getting work done while ducking y= our occasional volley. From moore@network-heretics.com Sun Feb 3 09:12:59 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF6E21F8889 for ; Sun, 3 Feb 2013 09:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-Zw5qH26MHg for ; Sun, 3 Feb 2013 09:12:58 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B3CE721F867B for ; Sun, 3 Feb 2013 09:12:58 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C986220722; Sun, 3 Feb 2013 12:12:57 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 03 Feb 2013 12:12:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=EBP69b667f1BvghjlU4ceG 6CbMI=; b=ImrU6wHuMGNDQjJAs1uPZNtZO67suJEPvo146ITOqRU/h0FMPAIQlu 7OSckpNq1AAfcA3z5E2pnDiPqdoDiyfMbuZyEwsjdffxhTzqtoCaEk/NqqwVdRsM KoThG3FGUHDTY7m3+B4WyhbrSsrHO23tXkYtiP32nV9VcFSNDSl9E= X-Sasl-enc: aGmt5HhCxDd9TI1d3IN9n3X4UlfZcEG/u/H8Q1VTwsPD 1359911577 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D4B954827D7; Sun, 3 Feb 2013 12:12:56 -0500 (EST) Message-ID: <510E9A8C.6030103@network-heretics.com> Date: Sun, 03 Feb 2013 12:12:44 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <510E8667.3020608@network-heretics.com> <510E910E.6090806@gmail.com> <8D23D4052ABE7A4490E77B1A012B63074747BDF8@mbx-01.win.nominum.com> <510E9246.1070502@network-heretics.com> <8D23D4052ABE7A4490E77B1A012B63074747BEED@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BEED@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 17:12:59 -0000 On 02/03/2013 11:48 AM, Ted Lemon wrote: > On Feb 3, 2013, at 11:37 AM, Keith Moore wrote: >> And IMO, it's far beyond a reasonable scope for this, or any, WG that is limited to a single area. And perhaps a traditional IETF WG isn't the right structure for tackling this kind of problem. > This seems like a fairly nonsensical statement. The IETF has areas, and working groups. It is frequently the case that work being done in a working group affects more than one area. The IETF has not burst into an explosion of pure energy as a result of the streams being crossed thus far. I suspect we are safe in the future as well. My view is that the Internet (with IETF's help) has been painting itself into increasingly smaller corners for at least 15 years now, maybe longer. NATs, DNS hacks, interception proxies, various kinds of packet filters, all basically make the Internet less predictable for applications, and thus increase development, operation, and support costs for everybody. Trying to work around them all just makes the Internet more complex without making it more functional. The IETF needs to get out of the habit of treating every problem as something that can be solved by spinning up a narrowly-focused working group, that functions just like every other working group because "that's the way we do things". I realize, of course, that MIF can't change IETF's habits. But if you're looking for a sane way forward, it's essential to realize that IETF's habits are a huge part of the problem. Otherwise you keep trying to use the same working habits to address problems that they fundamentally cannot address. > If you have some concrete proposal to make, I think it would be worth hearing it, but if you are just going to take pot shots, there's not much the rest of us can do except to try to continue getting work done while ducking your occasional volley. My proposal is to document the problems as best you can, and make concrete suggestions for areas in which the Internet architecture might be tweaked, but don't try to resolve the conflicts within MIF. Instead, ask IAB to look at the matter and provide IESG with advice as to how to proceed. Keith From alexandru.petrescu@gmail.com Sun Feb 3 10:49:19 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CF221F86EA for ; Sun, 3 Feb 2013 10:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.717 X-Spam-Level: * X-Spam-Status: No, score=1.717 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ze-1XcYugds for ; Sun, 3 Feb 2013 10:49:19 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id CA7E421F86D2 for ; Sun, 3 Feb 2013 10:49:17 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3AD2294018C for ; Sun, 3 Feb 2013 19:49:10 +0100 (CET) Message-ID: <510EB125.7050406@gmail.com> Date: Sun, 03 Feb 2013 19:49:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <051.4d985ba8b84efb9439103b8a750e564a@trac.tools.ietf.org> <50A60314.6020307@gmail.com> In-Reply-To: <50A60314.6020307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130203-0, 03/02/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [mif] #25: Should document that it updates RFC 6434 (node requirements) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 18:49:19 -0000 Le 16/11/2012 10:10, Brian E Carpenter a écrit : > On 15/11/2012 23:33, mif issue tracker wrote: >> #25: Should document that it updates RFC 6434 (node requirements) >> >> Just found some more text that this document needs to note that >> it's updating. This time it's in the IPv6 Node Requirements doc: > > Hmm. 6434 is Informational and is intentionally a snapshot. I'm not > sure that formally updating it is appropriate. We didn't > systematically update 4294 for each new IPv6 spec prior to 6434. I tend to agree. However, it is worth noting that v6ops WG has almost two WG items about Cellular Host requirements, and that the DHCP Route Option draft is something that may be pertinent to it. Alex > > Regards Brian > >> >> http://tools.ietf.org/html/rfc6434#section-7.2.2 >> >> """ 7.2.2. Use of Router Advertisements in Managed Environments >> >> Nodes using the Dynamic Host Configuration Protocol for IPv6 >> (DHCPv6) are expected to determine their default router information >> and on- link prefix information from received Router >> Advertisements. """ >> >> This should not be an onerous edit either. >> > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From alexandru.petrescu@gmail.com Sun Feb 3 10:54:08 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4E121F874B for ; Sun, 3 Feb 2013 10:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.251 X-Spam-Level: ** X-Spam-Status: No, score=2.251 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5HbcXoxtxcB for ; Sun, 3 Feb 2013 10:54:07 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id ACCD421F8745 for ; Sun, 3 Feb 2013 10:54:06 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 8EB7E940134 for ; Sun, 3 Feb 2013 19:54:00 +0100 (CET) Message-ID: <510EB247.6050906@gmail.com> Date: Sun, 03 Feb 2013 19:53:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130203-0, 03/02/2013), Outbound message X-Antivirus-Status: Clean Subject: [mif] Advancement of draft-ietf-mif-dhcpv6-route-option? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 18:54:08 -0000 Hello, I wonder what is the advancement direction about of draft-ietf-mif-dhcpv6-route-option. I remember an advantageous voting procedure in Atlanta, and I hoped to see confirmation on the email list if necessary. That voting and its confirmation could help close many of the raised issues, right? Tickets are at: http://trac.tools.ietf.org/wg/mif/trac/report/1 Regards, Alex From Ted.Lemon@nominum.com Sun Feb 3 10:54:31 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6EB21F87A3 for ; Sun, 3 Feb 2013 10:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92zRCa2kaaAW for ; Sun, 3 Feb 2013 10:54:30 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 83F7D21F8745 for ; Sun, 3 Feb 2013 10:54:30 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ6yZqvTImjCv6kd8Ujb1qMgKPBHV+Hs@postini.com; Sun, 03 Feb 2013 10:54:30 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 286761B8536 for ; Sun, 3 Feb 2013 10:54:30 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1C854190043; Sun, 3 Feb 2013 10:54:30 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 3 Feb 2013 10:54:24 -0800 From: Ted Lemon To: Keith Moore Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmAgAALy4CAAAyyAIAAANUAgAAAnwCAAAMZgIAABsQAgAAcZ4A= Date: Sun, 3 Feb 2013 18:54:24 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747C23D@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <510E8667.3020608@network-heretics.com> <510E910E.6090806@gmail.com> <8D23D4052ABE7A4490E77B1A012B63074747BDF8@mbx-01.win.nominum.com> <510E9246.1070502@network-heretics.com> <8D23D4052ABE7A4490E77B1A012B63074747BEED@mbx-01.win.nominum.com> <510E9A8C.6030103@network-heretics.com> In-Reply-To: <510E9A8C.6030103@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2AE12133F9BDFF44953767DDC5E12496@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 18:54:31 -0000 On Feb 3, 2013, at 12:12 PM, Keith Moore wrote= : > My proposal is to document the problems as best you can, and make concret= e suggestions for areas in which the Internet architecture might be tweaked= , but don't try to resolve the conflicts within MIF. Instead, ask IAB to = look at the matter and provide IESG with advice as to how to proceed. This isn't bad advice. It's worth noting that at least one member of the = IAB has in fact been participating in the discussion already, however, so i= t's been my ongoing assumption that this issue is already on their radar, a= nd that if we were doing the wrong thing, we would have heard something abo= ut it already. I say that not to express resistance to your proposal, but= simply to observe that I don't think we are _quite_ as far off the rails a= s you are suggesting. From mcr@sandelman.ca Sun Feb 3 12:10:58 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE1421F8512 for ; Sun, 3 Feb 2013 12:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbRj+NUE4aP3 for ; Sun, 3 Feb 2013 12:10:58 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 1217E21F8510 for ; Sun, 3 Feb 2013 12:10:58 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 031022016D; Sun, 3 Feb 2013 15:16:45 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4AB086376A; Sun, 3 Feb 2013 15:09:58 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 29EF663765; Sun, 3 Feb 2013 15:09:58 -0500 (EST) From: Michael Richardson To: mif In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 20:10:58 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ted" =3D=3D Ted Lemon writes: Ted> The second set of cases are cases where=20 "where DNS is incorrectly used"=20 Ted> to operate a captive portal.=20=20 The IETF needs to write a BCP on captive portals. Abusing DNS is never the right answer due to DNSSEC, the MIF situation just makes that obvious to more users. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUQ7EFYqHRg3pndX9AQLdPAP/WYU3yiwlsvFZcgpZbTWbhDuNggqUH53c zPg7DBGZkr426GHyp/GlRoZoLWQUCJJcgNEwEi0VLrwbl0APF/dF4Dj3387kmYgt gFRNFNMQ8TaZqlmCZJBEMHrNwJPcIg4q4yVegcDxT39A0zHMkVOMZ+GY+sP/QpQz u0xilAjeXCI= =E2yR -----END PGP SIGNATURE----- --=-=-=-- From Ted.Lemon@nominum.com Sun Feb 3 20:03:37 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0CF21F89CE for ; Sun, 3 Feb 2013 20:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySoEFv-bPJk0 for ; Sun, 3 Feb 2013 20:03:37 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 751C821F8955 for ; Sun, 3 Feb 2013 20:03:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ8zGW2CkbcwYps1AxlbYiD9ucneqlQG@postini.com; Sun, 03 Feb 2013 20:03:37 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CB5901080C9 for ; Sun, 3 Feb 2013 20:03:36 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BF3BB190043; Sun, 3 Feb 2013 20:03:36 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 3 Feb 2013 20:03:36 -0800 From: Ted Lemon To: Michael Richardson Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmAgABVUwCAAIRSAA== Date: Mon, 4 Feb 2013 04:03:36 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747CDEA@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <20162.1359922198@sandelman.ca> In-Reply-To: <20162.1359922198@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <758672BC68096347AF2BC03FBCA8A1E4@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 04:03:38 -0000 On Feb 3, 2013, at 3:09 PM, Michael Richardson wrote: > The IETF needs to write a BCP on captive portals. Abusing DNS is never > the right answer due to DNSSEC, the MIF situation just makes that > obvious to more users. It would be nice if we had a solution to offer, and not just a set of pract= ices to follow. Right now there is no IETF protocol that can be used to s= ay "you have connected to a captive portal, please do BLAH so that you can = access the network." From brian.e.carpenter@gmail.com Mon Feb 4 00:09:04 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2247021F8A6C for ; Mon, 4 Feb 2013 00:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.629 X-Spam-Level: X-Spam-Status: No, score=-100.629 tagged_above=-999 required=5 tests=[AWL=1.062, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJK6NLILmupN for ; Mon, 4 Feb 2013 00:09:03 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2B95621F841F for ; Mon, 4 Feb 2013 00:09:02 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l13so2026148wie.2 for ; Mon, 04 Feb 2013 00:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=20LpMRqU9p11e/F2Ejh6OHRw2FO4SykpbPK/jmQ9Wt4=; b=iDYbFF0QCbOj828Hr0ay0nDJo64+Lf2CydwTdUXA01nKPM+nVodNeC1ei8CLn/4+J0 0iXJ/xdmmSQDeMi59HrwGttQc65NUNlsJrzqzKgf/+kBB2h4oCdfGTcCf4q2pKtMXzrW JRzu6sd0xMvlgq1qw117MWnSZiZVcflHVtNoyoRdgH2OAC7Nl+LtQqihw45XzzM8k07F rqkdCiFknWfdgU7jaJ98ZB3Uc3fPEVmz/svDVLp2KT6kSKwpZvui+dZcKdA4u8vO8qAz k6cnLOqDG1Oa0z2KldWbdudBGAb+6cxMdrM+TWL+bPKXCiEE+Pg3GBTDQCvq/FWNSlAp LcWA== X-Received: by 10.194.239.167 with SMTP id vt7mr11306292wjc.33.1359965342134; Mon, 04 Feb 2013 00:09:02 -0800 (PST) Received: from [192.168.1.65] (host-2-101-189-53.as13285.net. [2.101.189.53]) by mx.google.com with ESMTPS id e12sm19893923wiw.5.2013.02.04.00.09.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 00:09:01 -0800 (PST) Message-ID: <510F6C9E.7030300@gmail.com> Date: Mon, 04 Feb 2013 08:09:02 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <510E8667.3020608@network-heretics.com> <510E910E.6090806@gmail.com> <8D23D4052ABE7A4490E77B1A012B63074747BDF8@mbx-01.win.nominum.com> <510E9246.1070502@network-heretics.com> <8D23D4052ABE7A4490E77B1A012B63074747BEED@mbx-01.win.nominum.com> <510E9A8C.6030103@network-heretics.com> <8D23D4052ABE7A4490E77B1A012B63074747C23D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747C23D@mbx-01.win.nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org, Keith Moore Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 08:09:04 -0000 On 03/02/2013 18:54, Ted Lemon wrote: > On Feb 3, 2013, at 12:12 PM, Keith Moore wrote: >> My proposal is to document the problems as best you can, and make concrete suggestions for areas in which the Internet architecture might be tweaked, but don't try to resolve the conflicts within MIF. Instead, ask IAB to look at the matter and provide IESG with advice as to how to proceed. > > This isn't bad advice. It's worth noting that at least one member of the IAB has in fact been participating in the discussion already, however, so it's been my ongoing assumption that this issue is already on their radar, and that if we were doing the wrong thing, we would have heard something about it already. I say that not to express resistance to your proposal, but simply to observe that I don't think we are _quite_ as far off the rails as you are suggesting. Although it isn't about this precise problem, I have been banging on about referrals for several years now (the most recent attempt being at http://tools.ietf.org/html/draft-carpenter-referral-ps-02). I mention this because despite a BOF at IETF76 and at least two IAB members having showed interest in the problem, no traction has been gained whatever. I think there's a strong temptation to put this whole topic on the "too hard" heap, so we (collectively) continue to fiddle with the edges of it, e.g. expecting DNS server selection to solve the problem. Brian From phdgang@gmail.com Mon Feb 4 02:44:57 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45F221F844F for ; Mon, 4 Feb 2013 02:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kvlhmud2Qmem for ; Mon, 4 Feb 2013 02:44:57 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1091321F8447 for ; Mon, 4 Feb 2013 02:44:56 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id o13so1188601qaj.12 for ; Mon, 04 Feb 2013 02:44:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=qTTHryuWZYAU3fxEWfF4KMXXKwjBpqSPAJuNuaCahLE=; b=yqFzuvjYmH0lit8cRxvz8vpTJ3pQRL7UTVIKUXM1S9vJqSMEUAYdR6mQcLwp3IHt9N unT6OsfX6V3EUf0YX7JtYD0alryQwhbHe+BOMNwMy4WxrtVc8AT3PaUzebAOIVQSPf2V Ft1ICrIZEgK57P5eDPL4Rw9Ox0roftZaLwabKNKHMmmWHdabOJMJChiyMOPt6MX0D9vz rQM1gzYak5fW43uFW/ozSW7SEeM7QVtzcjZRpOJP7cw8gNUecDELUFcRz4Ui2mdm5xcs FTd2Prl1jIgr+1q3mETJ8qjRiumRnFTeeiVfFDwWc8Zj9U5esuDzp4HDShJBytbChhls GbKw== MIME-Version: 1.0 X-Received: by 10.224.44.197 with SMTP id b5mr17952575qaf.65.1359974696512; Mon, 04 Feb 2013 02:44:56 -0800 (PST) Received: by 10.49.48.12 with HTTP; Mon, 4 Feb 2013 02:44:56 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> Date: Mon, 4 Feb 2013 18:44:56 +0800 Message-ID: From: GangChen To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 10:44:57 -0000 2013/2/3, Ted Lemon : > On Feb 3, 2013, at 9:12 AM, GangChen wrote: >> I would like to learn more about the problems. > > There are quite a few separate issues. We generally treat DNS results a= s > if they are essentially stateless=97regardless of who asks the question, = they > should get the same answer. However, there are a lot of situations wher= e > this simply isn't true. Some of them are covered by RFC6731, but most a= re > not. > > The most obvious cases are situations where there is in fact a split dns > architecture, but RFC6731 isn't applicable. This is probably most split > dns situations. I suppose you indicate the issue which is probably described in http://tools.ietf.org/html/rfc6731#section-2.3. RFC6731 claimed that "these problems might be solvable ONLY by manual user intervention. > The second set of cases are cases where DNS is used to operate a captive > portal. In these cases, the DNS server on the captive portal will give > different answers than a DNS server on a working 3G link, for instance. = So The second set of cases seems a variant of a split dns. A captive portal is represented by RR with masquerading IP. That make different answers returned with same FQDN. > if HE treats DNS responses as if they were generally equivalent, either w= e > will be unable to ever see the captive portal web page, or we will be una= ble > to use the 3G network without logging in to the captive portal. Neither > situation is desirable. will add the case into the description of failed support in HE-MIF draft > A third, less obvious, set of cases are where DNS is used to optimize CDN > delivery. In this case, suppose I have a 3G interface that doesn't have > CDN-optimized DNS, and a connection through my ISP on the wireless LAN th= at > does have CDN-optimized DNS. In this situation, if I treat the two DNS > servers as equivalent, then I may use the 3G DNS server to look up > information I will then use to connect to the CDN over the wireless LAN > interface. This will likely result in suboptimal routing, and unaccepta= ble > performance. If there is no configuration from 6731, HE-MIF would send DNS request on both interface in parallel. The node may generate a list to indicate remote peers. HE will help to pick fast interface. I guess it may rectify the unexpected suboptimal routing in some extents. But I think HE-MIF is not intended to resolve DNS selection issue initially. > This is why when I've discussed this issue in the past, I've always argue= d > that each provisioning domain needs to be treated separately. We should > not look up names in one provisioning domain and use them in another; if = we > want to try connecting across multiple provisioning domains, we should do > DNS lookups on each such provisioning domain, and use the results we get > only for connecting within that provisioning domain. The problems are caused since DNS answers may not be kept with information of the provisioning domain from which the answer comes. HE-MIF may alleviate the issues with failover ability as best as it can. Backing to the target of this thread, we intent to describe issues within HE-MIF context. For issues in general and concrete recommendations, would it make sense to draft new I-D? Best Regards Gang > > From Ted.Lemon@nominum.com Mon Feb 4 05:56:34 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663F221F8682 for ; Mon, 4 Feb 2013 05:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o68tGKqF64lr for ; Mon, 4 Feb 2013 05:56:34 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id E06D221F84FC for ; Mon, 4 Feb 2013 05:56:33 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ++EZtvPNlvSKjO7E2n1TqOehfnjd2D@postini.com; Mon, 04 Feb 2013 05:56:33 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5FBB41B8446 for ; Mon, 4 Feb 2013 05:56:33 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 52B6C190043; Mon, 4 Feb 2013 05:56:33 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 05:56:33 -0800 From: Ted Lemon To: GangChen Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmAgAFJyQCAADWJAA== Date: Mon, 4 Feb 2013 13:56:32 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747D7F7@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <35DD9E9E06335846AF25B425030B3F30@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 13:56:34 -0000 On Feb 4, 2013, at 5:44 AM, GangChen wrote: > Backing to the target of this thread, we intent to describe > issues within HE-MIF context. For issues in general and concrete > recommendations, would it make sense to draft new I-D? No. The point of HE-MIF is to solve the problem. So not talking about t= he full problem in the HE-MIF solution means that we're producing something= that's probably harmful. It sounds like you think there's some value to doing DNS queries within one= provisioning domain, and then using the results in the other provisioning = domain. Can you explain why? From mcr@sandelman.ca Mon Feb 4 11:54:10 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4755221F8A9B for ; Mon, 4 Feb 2013 11:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DF5dGjiP79Pr for ; Mon, 4 Feb 2013 11:54:09 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 1950A21F8A89 for ; Mon, 4 Feb 2013 11:53:51 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id D79412016D; Mon, 4 Feb 2013 14:59:39 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D79FB6376A; Mon, 4 Feb 2013 14:52:48 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9118C63769; Mon, 4 Feb 2013 14:52:48 -0500 (EST) From: Michael Richardson To: Ted Lemon X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: mif Subject: [mif] DNS (ab)use in captive portals X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 19:54:10 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ted" =3D=3D Ted Lemon writes: >> The IETF needs to write a BCP on captive portals. Abusing DNS is >> never the right answer due to DNSSEC, the MIF situation just >> makes that obvious to more users. Ted> It would be nice if we had a solution to offer, and not just a Ted> set of practices to follow. Right now there is no IETF Ted> protocol that can be used to say "you have connected to a Ted> captive portal, please do BLAH so that you can access the Ted> network." I was under the impression that something was being proposed (a dhc option?) to say, "here is the URL you must visit to authenticate" I know that MS and Android (and Apple?) mobile devices can sometimes detect that there is a portal. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAURARkIqHRg3pndX9AQIFAgP/VoG7p01UXsa2KdGci8zbBYUS8y7goBcg lKhCjYOFNeCYrW7SkIg7kTaLeX7tM/6E69ZzbYqP9YFXfoVPKuP6MsijSufUW06q S0QwHgtCV3AS2p0JL5POleti5k91QD4aYF7zd13M502T5FrIm7LZnWBFRwk0MVS2 XCrZeHY5c0w= =kFJL -----END PGP SIGNATURE----- --=-=-=-- From marc.blanchet@viagenie.ca Mon Feb 4 18:04:19 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9898721F8AA3 for ; Mon, 4 Feb 2013 18:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJ4z0DaPTkt2 for ; Mon, 4 Feb 2013 18:04:19 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA9021F8A90 for ; Mon, 4 Feb 2013 18:04:19 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E2721412D6; Mon, 4 Feb 2013 21:04:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <11283.1360007568@sandelman.ca> Date: Mon, 4 Feb 2013 21:04:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <49FBAF42-056D-48B3-B569-5641D28B6E4B@viagenie.ca> References: <11283.1360007568@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1283) Cc: mif Subject: Re: [mif] DNS (ab)use in captive portals X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 02:04:19 -0000 Le 2013-02-04 =E0 14:52, Michael Richardson a =E9crit : >=20 >>>>>> "Ted" =3D=3D Ted Lemon writes: >>> The IETF needs to write a BCP on captive portals. Abusing DNS is >>> never the right answer due to DNSSEC, the MIF situation just >>> makes that obvious to more users. >=20 > Ted> It would be nice if we had a solution to offer, and not just a > Ted> set of practices to follow. Right now there is no IETF > Ted> protocol that can be used to say "you have connected to a > Ted> captive portal, please do BLAH so that you can access the > Ted> network." >=20 > I was under the impression that something was being proposed (a dhc > option?) to say, "here is the URL you must visit to authenticate" >=20 > I know that MS and Android (and Apple?) Apple: yes. > mobile devices can sometimes > detect that there is a portal. Apple does by trying to contact via http a well-known url with a well = known content. If the content does not match, then you are behind a = portal. Marc. >=20 >=20 > --=20 > Michael Richardson , Sandelman Software Works=20= >=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From phdgang@gmail.com Mon Feb 4 20:02:12 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A368121F8558 for ; Mon, 4 Feb 2013 20:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VktO-palkeNq for ; Mon, 4 Feb 2013 20:02:12 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7436B21F8A6C for ; Mon, 4 Feb 2013 20:02:07 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id hg5so1622352qab.13 for ; Mon, 04 Feb 2013 20:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pi9oxx3rzYrUr8IMCzMryhz9TyaFxiLhbiOqGfzROFM=; b=uYEg16NLjqO0lv2wF/K9podzlUM4NH92lvwl/5mf6/wU4keL0AbnyjwYubRMrwIgUf KouMHqFRCaEZcZXw8LRDOTEeOd2sRnEQzIzi74BlNnJR03rfJ4GKrjZDTFLgFClAM+J0 znLyOnLJV+mfeA+rOR3gNNQShhfx+5K6d0uK1xmadHCyxh3jZ/uSmyFYQY7gbxxYQSZw HMU1xia47MtKlQhb/AWqQ2qcGWTw/+5iEEGrhhlIhVgdPSHR3fNYNL3hPPBao3QU5Kz1 u0nwzNYN8iRVBHxJ+FRkHxcruM76+wvUS6S1mgV0os2Bj1mzhNW5MSxcWwLpD+4dM1Fl 7Y/A== MIME-Version: 1.0 X-Received: by 10.229.179.23 with SMTP id bo23mr4589141qcb.104.1360036926914; Mon, 04 Feb 2013 20:02:06 -0800 (PST) Received: by 10.49.48.12 with HTTP; Mon, 4 Feb 2013 20:02:06 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747D7F7@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747D7F7@mbx-01.win.nominum.com> Date: Tue, 5 Feb 2013 12:02:06 +0800 Message-ID: From: GangChen To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 04:02:12 -0000 2013/2/4, Ted Lemon : > On Feb 4, 2013, at 5:44 AM, GangChen wrote: >> Backing to the target of this thread, we intent to describe >> issues within HE-MIF context. For issues in general and concrete >> recommendations, would it make sense to draft new I-D? > > No. The point of HE-MIF is to solve the problem. So not talking about > the full problem in the HE-MIF solution means that we're producing something > that's probably harmful. Allow me to explore *the problem* a bit. Following the discussion, I realize there are actually two seperated problems. 1) Using HE-MIF (no domain information provisioned) to select DNS 2) Once domain name is resolved, using answer only within the provisioning domain For 1), If there is no domain information provisioned (e.g. RFC6731),HE-MIF selects DNS server using *connection speed* other than provisioning domain information. I guess it desirable to do DNS query within a matched provisioning domain. So pre-provisioned domain information(e.g. RFC6731) would prioritize the interface sending DNS query. # For 2),# I can't comment on benefits of "doing DNS queries within one provisioning domain, and then using the results in the other provisioning domain." But HE-MIF has to do in some cases, because that maybe a normal node behavior, like stated in RFC6418 "A node usually has a node-scoped routing table". This issue may retrospect to basic Internet host design in RFC1122. Changing the model would go beyond HE-MIF scope. We would surely document full problem in HE-MIF solution at next update. > > It sounds like you think there's some value to doing DNS queries within one > provisioning domain, and then using the results in the other provisioning > domain. Can you explain why? See above # For 2),# Best Regards Gang > From Ted.Lemon@nominum.com Mon Feb 4 21:35:27 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB95A21F8941 for ; Mon, 4 Feb 2013 21:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+RYSEQgNUbP for ; Mon, 4 Feb 2013 21:35:26 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 396AF21F87D3 for ; Mon, 4 Feb 2013 21:35:26 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKURCaHeg36lBeh3yKw0grkvQEVcNLNTHD@postini.com; Mon, 04 Feb 2013 21:35:26 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A1CC4F8016 for ; Mon, 4 Feb 2013 21:35:25 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 96DED190043; Mon, 4 Feb 2013 21:35:25 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 21:35:19 -0800 From: Ted Lemon To: GangChen Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmAgAFJyQCAADWJAIAA7D8AgAAaCwA= Date: Tue, 5 Feb 2013 05:35:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747F348@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747D7F7@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 05:35:27 -0000 On Feb 4, 2013, at 11:02 PM, GangChen wrote: > I can't comment on benefits of "doing DNS queries within one > provisioning domain, and then using the results in the other > provisioning domain." But HE-MIF has to do in some cases, because that > maybe a normal node behavior, like stated in RFC6418 "A node usually > has a node-scoped routing table". This issue may retrospect to basic > Internet host design in RFC1122. Changing the model would go beyond > HE-MIF scope. Okay, so your point is that we can't do connections within a provisioning d= omain, because we don't have control over how a connection is routed. I agree that this is a problem, but it is explicitly within the scope of th= e MIF charter to consider this problem and document it. It is quite likel= y the case that solving the problem is outside of the current MIF charter, = and that such work, if attempted, ought not to occur in MIF. However, if in fact the HE-MIF document can't work correctly without solvin= g this problem, then it is certainly within the scope of the current charte= r for the MIF working group to draw that conclusion. For my part, what I am saying is that HE-MIF can't really be very useful wi= thout solving this problem. It is not in fact the case that a MIF node ca= n have a single node-scoped routing table and still succeed in communicatin= g on the network in the face of, for example, an interface that's connected= to a captive portal but providing a default route, as such captive portals= typically do. From phdgang@gmail.com Tue Feb 5 02:47:11 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A0021F853A for ; Tue, 5 Feb 2013 02:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Npa0k2JZpLB for ; Tue, 5 Feb 2013 02:47:11 -0800 (PST) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2393121F8319 for ; Tue, 5 Feb 2013 02:47:11 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id d1so2989945qca.2 for ; Tue, 05 Feb 2013 02:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sDQynWxJxUaM8Ky8STZoOSgnRvxXl+Hv0S3TeEHRXL4=; b=RF9YNyQLgAWDHVqoHZMPw+CDEOjsNVoC7vG2Bsj5pcSuE5AgBsSR+zUEZjzsOEQuHA Mtn1+pTkohvD1jCnbDBjir5Oet9iNQXDZZSkQSOZLb5AmWm0ZCSWI8X5en3kNxrO7m+2 T7MGk9NXshB6nHww9ADQhojfPni9j6ng/fOKYPSOfabJ0yOqOny1eD4GO3wy9Bd66sZn M9d0SobTeMIgtpQlBD4P8Xl3Usm2tmHycF0waGyQOqi9114U36+TgZGli5fRL2iOkPuw ncMk/jxIW6LxgHKwxfkxZ6//ScpmrN3MvPLTbYrkA+bLLNpBspu+fSQvGpbtRVxYvtFG JE7Q== MIME-Version: 1.0 X-Received: by 10.49.84.104 with SMTP id x8mr23194686qey.5.1360061230501; Tue, 05 Feb 2013 02:47:10 -0800 (PST) Received: by 10.49.48.12 with HTTP; Tue, 5 Feb 2013 02:47:10 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747F348@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747D7F7@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747F348@mbx-01.win.nominum.com> Date: Tue, 5 Feb 2013 18:47:10 +0800 Message-ID: From: GangChen To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 10:47:11 -0000 2013/2/5, Ted Lemon : > On Feb 4, 2013, at 11:02 PM, GangChen wrote: >> I can't comment on benefits of "doing DNS queries within one >> provisioning domain, and then using the results in the other >> provisioning domain." But HE-MIF has to do in some cases, because that >> maybe a normal node behavior, like stated in RFC6418 "A node usually >> has a node-scoped routing table". This issue may retrospect to basic >> Internet host design in RFC1122. Changing the model would go beyond >> HE-MIF scope. > > Okay, so your point is that we can't do connections within a provisioning > domain, because we don't have control over how a connection is routed. > > I agree that this is a problem, but it is explicitly within the scope of the > MIF charter to consider this problem and document it. It is quite likely > the case that solving the problem is outside of the current MIF charter, and > that such work, if attempted, ought not to occur in MIF. > > However, if in fact the HE-MIF document can't work correctly without solving > this problem, then it is certainly within the scope of the current charter > for the MIF working group to draw that conclusion. > > For my part, what I am saying is that HE-MIF can't really be very useful > without solving this problem. It is not in fact the case that a MIF node > can have a single node-scoped routing table and still succeed in > communicating on the network in the face of, for example, an interface > that's connected to a captive portal but providing a default route, as such > captive portals typically do. May I raise two points. 1) Interface selection is not only goal of HE-MIF. Essentially, HE-MIF will make MIF node with automatic fallback ability. On the interface selection stage, HE-MIF is actually hand the power to RFC4191, 6731, I-D.ietf-mif-dhcpv6-route-option, etc. If there is a failure or no such provisioning information, HE-MIF will take over by sending the probing message on all potential interfaces. 2) I guess the problem is happened when the host is implemented with a weak model. The problem occurred when a interface in provisioning domain A to reach a peer that is answered by DNS server in provisioning domain B Since it's a single node-scoped routing table, there maybe a failed case when an interface in provisioning domain A using parameters of provisioning domain B(e.g. default gw) to make probing. The probe likely would fail. Ideally, HE-MIF could choose the right interface matching the provisioning domain. However, if the interface in provisioning domain A using default gw could reach the peer, it will have a problem. I believe the problem is similar with http://tools.ietf.org/html/rfc6731#section-2.3. The only solution is manual user intervention as far as I can say. Best Regards Gang From Ted.Lemon@nominum.com Tue Feb 5 06:23:18 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEB721F85C2 for ; Tue, 5 Feb 2013 06:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcKv+ut+CT9p for ; Tue, 5 Feb 2013 06:23:17 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9C56D21F85BC for ; Tue, 5 Feb 2013 06:23:12 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUREV0JJUprVxBMkmPFrFgoBbaTmIpIse@postini.com; Tue, 05 Feb 2013 06:23:12 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1714D1B824A for ; Tue, 5 Feb 2013 06:23:12 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 09404190043; Tue, 5 Feb 2013 06:23:12 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 06:23:00 -0800 From: Ted Lemon To: GangChen Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmAgAFJyQCAADWJAIAA7D8AgAAaCwCAAFciAIAAPEsA Date: Tue, 5 Feb 2013 14:22:59 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747F7EF@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747D7F7@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747F348@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5AB08D86425BBD49A909897715F3112A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 14:23:18 -0000 On Feb 5, 2013, at 5:47 AM, GangChen wrote: > Ideally, HE-MIF could choose the right interface > matching the provisioning domain. However, if the interface in > provisioning domain A using default gw could reach the peer, it will > have a problem. I believe the problem is similar with > http://tools.ietf.org/html/rfc6731#section-2.3. The only solution is > manual user intervention as far as I can say. No, this is not true. Furthermore, this failure mode happens to me on a r= egular basis when my handset connects to a Wifi SSID it recognizes; everyth= ing IP-dependent stops until I either disable WiFi or authenticate to the c= aptive portal. This is a trivially easy attack to do on handsets with WiFi= (which is most handsets nowadays). Similarly, some web gateways, particularly in airports and hotels, only off= er service on ports 80 and 443. I'd like to be able to use this transport = where it works, because it's cheaper than my 4G LTE service (at least hypot= hetically). But a solution that follows the weak host model will not succ= eed in this situation=97it will either always use LTE, or always use the Wi= Fi. If HE-MIF does not address this use case, it seems to me that we simply are= n't addressing the bulk of the use cases that motivated the formation of th= is working group. If that's the case, why do the work? From phdgang@gmail.com Tue Feb 5 23:29:07 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A3521F8921 for ; Tue, 5 Feb 2013 23:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th2Iwcmd7Bd5 for ; Tue, 5 Feb 2013 23:29:07 -0800 (PST) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id F034C21F8900 for ; Tue, 5 Feb 2013 23:29:06 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id 1so498420qec.5 for ; Tue, 05 Feb 2013 23:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=z7B+WyGRBYhTUCqhXyQdZcp8d/LHqeX75Iz1VZaCI4g=; b=vOtFT0iA6cQECZ9q+TNGdMG4eC1p73CH1wVS1Qkk5T4QZ40SnaB01zo5jV9xPVrMg/ kJ32LWniJfy4FG411xrlfREVyAvO9MBtfYr6O92MzGGrgIcBJRpIzM481OpsafPOMlqB 5nWmD2QdBW4Sxy5B/8NBPYZvVZgpIgw/0uGRI/5wwvtUJ/l7voPuf1eHurq7oh8Zlhw0 8qmA1bIhSQu0lkaXsMbpsgeZ7apYlIyy2XkAn1Tw1ZS6zLAN5GJ7Ep8trMZoOQ6e8Tgz WsaN5quLzY8HB0GSAN+k+KdoS7VCO9P/DX2OBQjrvxQa3goNQHOPXmELWHhgH0ckbPhu Uwpw== MIME-Version: 1.0 X-Received: by 10.224.207.72 with SMTP id fx8mr20808898qab.66.1360135746391; Tue, 05 Feb 2013 23:29:06 -0800 (PST) Received: by 10.49.48.12 with HTTP; Tue, 5 Feb 2013 23:29:06 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747F7EF@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747D7F7@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747F348@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747F7EF@mbx-01.win.nominum.com> Date: Wed, 6 Feb 2013 15:29:06 +0800 Message-ID: From: GangChen To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 07:29:07 -0000 2013/2/5, Ted Lemon : > On Feb 5, 2013, at 5:47 AM, GangChen wrote: >> Ideally, HE-MIF could choose the right interface >> matching the provisioning domain. However, if the interface in >> provisioning domain A using default gw could reach the peer, it will >> have a problem. I believe the problem is similar with >> http://tools.ietf.org/html/rfc6731#section-2.3. The only solution is >> manual user intervention as far as I can say. > > No, this is not true. Furthermore, this failure mode happens to me on a > regular basis when my handset connects to a Wifi SSID it recognizes; > everything IP-dependent stops until I either disable WiFi or authenticate= to > the captive portal. This is a trivially easy attack to do on handsets wi= th > WiFi (which is most handsets nowadays). > > Similarly, some web gateways, particularly in airports and hotels, only > offer service on ports 80 and 443. I'd like to be able to use this > transport where it works, because it's cheaper than my 4G LTE service (at > least hypothetically). But a solution that follows the weak host model > will not succeed in this situation=97it will either always use LTE, or al= ways > use the WiFi. > > If HE-MIF does not address this use case, it seems to me that we simply > aren't addressing the bulk of the use cases that motivated the formation = of > this working group. If that's the case, why do the work? I guess the information on this link may relieve your concerns. http://www.ietf.org/mail-archive/web/mif/current/msg01138.html I have tested hotspots in our network. The captive portal systems do not reply with their own IP address, but reply with the IP address of the queried FQDN, and then do IP masquerading as the destination IP address. It's using HTTP redirection to the captive portal. In this way, HE-MIF would work well. Since TCP handshake would be broken if there is a captive portal, HE-MIF node would fallback to other interfaces automatically. Best Regards Gang From Ted.Lemon@nominum.com Wed Feb 6 18:15:16 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E5021F8518 for ; Wed, 6 Feb 2013 18:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L40c0wJVNxwc for ; Wed, 6 Feb 2013 18:15:15 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 32CC321F8522 for ; Wed, 6 Feb 2013 18:15:12 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKURMOL6zeSUDMizRX8D5tj3KSFz8PTuLf@postini.com; Wed, 06 Feb 2013 18:15:12 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A7910128004 for ; Wed, 6 Feb 2013 18:15:11 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9C7A8190043; Wed, 6 Feb 2013 18:15:11 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 6 Feb 2013 18:14:59 -0800 From: Ted Lemon To: GangChen Thread-Topic: [mif] DNS selection with HE-MIF Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmAgAFJyQCAADWJAIAA7D8AgAAaCwCAAFciAIAAPEsAgAEeswCAATqQAA== Date: Thu, 7 Feb 2013 02:14:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747481F51@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747D7F7@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747F348@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747F7EF@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <557B5DBB53425248AC831746F1225871@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 02:15:16 -0000 On Feb 6, 2013, at 2:29 AM, GangChen wrote: > I guess the information on this link may relieve your concerns. > http://www.ietf.org/mail-archive/web/mif/current/msg01138.html I am not looking to be reassured. I would like the proposal to address th= e real and serious issues I have raised. You are of course free to say "n= o, we do not intend to address these concerns." From phdgang@gmail.com Wed Feb 6 18:50:25 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4366621E804B for ; Wed, 6 Feb 2013 18:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol4AWHG2YiOT for ; Wed, 6 Feb 2013 18:50:24 -0800 (PST) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA7A21E8049 for ; Wed, 6 Feb 2013 18:50:24 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id 1so977741qec.33 for ; Wed, 06 Feb 2013 18:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bj2FyblybWSwESFAEFAiD1sFsQM1KDoQfrQelO82hn0=; b=sM0PsWXvbRHzxOgpKEYYEFnBJsdp51kB9t+aJqRNV3Rno5eaX+0coN/vP1QMsITf7z N6GQEuyTkEVnBjZ29PAATfcsyKZvieun9GFN7GwGLxMVBbDx70/l+x2AXrcaX0X+aCkK tP/xEsw0sbiCCajWuwpqm3fFDDq+6an7piMtEmQzCHLjGkl9AbIlEg7+x698HzTkRqm+ kygRLVX1/ABs15ek517a31d18J8Lt2tS+Ubv8g7TW/muj+tuGfO6YK/jTOfDJ859tjhB Yovi7lY18pOWUjMSwbnqBXBTDRhsXuOqMmgMGwOMnUjXehPuhmujvvNM2iGIODVUpHzJ VTtQ== MIME-Version: 1.0 X-Received: by 10.224.17.198 with SMTP id t6mr74987qaa.84.1360205424124; Wed, 06 Feb 2013 18:50:24 -0800 (PST) Received: by 10.49.48.12 with HTTP; Wed, 6 Feb 2013 18:50:23 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747481F51@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747D7F7@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747F348@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074747F7EF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747481F51@mbx-01.win.nominum.com> Date: Thu, 7 Feb 2013 10:50:23 +0800 Message-ID: From: GangChen To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] DNS selection with HE-MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 02:50:25 -0000 Hello Ted, 2013/2/7, Ted Lemon : > On Feb 6, 2013, at 2:29 AM, GangChen wrote: >> I guess the information on this link may relieve your concerns. >> http://www.ietf.org/mail-archive/web/mif/current/msg01138.html > > I am not looking to be reassured. I would like the proposal to address the > real and serious issues I have raised. You are of course free to say "no, > we do not intend to address these concerns." Your concern has been understood well. It would be seriously considered at next update. Hopefully, we could come up with a thoughtful solution after checking with other co-authors. If there is a proposal in your mind, that is highly appreciated. Best Regards Gang From ivo.sedlacek@ericsson.com Thu Feb 7 07:30:41 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D88C21F8751 for ; Thu, 7 Feb 2013 07:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.828 X-Spam-Level: X-Spam-Status: No, score=-4.828 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDqRvGs7NgDo for ; Thu, 7 Feb 2013 07:30:40 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 76DD321F862A for ; Thu, 7 Feb 2013 07:30:34 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-8d-5113c8992e5a Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 21.10.32353.998C3115; Thu, 7 Feb 2013 16:30:33 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 16:30:32 +0100 From: Ivo Sedlacek To: Alexandru Petrescu , mif Thread-Topic: [mif] Advancement of draft-ietf-mif-dhcpv6-route-option? Thread-Index: AQHOAj/jLX07DU9W5UuXy+HMWn/PA5huiuSw Date: Thu, 7 Feb 2013 15:30:31 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010830DD@ESESSMB301.ericsson.se> References: <510EB247.6050906@gmail.com> In-Reply-To: <510EB247.6050906@gmail.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/mixed; boundary="_002_39B5E4D390E9BD4890E2B310790061010830DDESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12SbUiTURTHuc/m9jg1btP0qAkpBr3QtCiUEPVDylIE/WIRRM6culzD5ktG BYbkUjOyGrWVL8UMTCrUlU6lmOa7ri1TVHQWivhCYg7Kd9vz3AnSt9//3P8599xzLs0RlvB8 aJkiW6pUSOQBPAFXc37z1jFNt3tCcGeJT6hmccUptLh1hIqkxAbtBF+s061S8dQFQViKVC7L lSqDwpME6dbRNk7m3xIqr3LFLR8NLaFi5EwDPgmPesedCHuC2fqeV4wEtBC3IbjT3ssl4hWC 3yt9bAYPi6BM/4XN8MBnYbR12m6iaXccBWbVRRKOho3qKUT4BDSae/iMhYsDwaaKZcJuOBas lgEew0J8CExzzRTDzvgwjHWa2eoI+8HQRilbhoO9YGy6kiJ9esBPSx+P8D6Ym9py9O8PhgEV h/hlMPOjkUvu2gs9mmnuQ+Sh3VVKu8um3WUjcRGMqJ/wCB+F1y8XOIT3Q4O6CGntU+Hguwge N/ewQoibEWzrbBQRdQierpY6EdGCYKWoiUeEGoHV9N0hahGsbaw7bGYEdTUNDvEJwUxFtcPW j6BqtpNtRogNCFRLCeRAh8DSMMi+ZGctWnbm/rC50GLvmFlLJNR23SThCOgwVXMIi2B+uRAx 7I5PQV/5MstcfBDuvVPzmVRmR6X9KQy62i2DzTmMwxUrYLq0jCJ8DR58aGcv3dnW/yMGfAZG bV+RdtfmqlDsG8S/KpHJ066H1CP7hzbq14ObUP2kZxvypbkBXm7noszxQpwmyZZmSKWZUuUl ZY5cmtWGKNrZJx/17/FOjChP/PVMXvCqTJXkl33FGwXO16xahqNiwp+bcsdqXIJSQFyw5Pv5 W5itV3/fsN0eouavTWzHHAgc91/QgGL8rblrsnq2Rf3xT6o5eXBKhWTWF0G3M+Kj4xQV4jic apQs6MovDxdFnDYaqRvJ+T0ueSI/QWHH1qK+O4CblS45foSjzJL8A0QcVUKeAwAA Subject: Re: [mif] Advancement of draft-ietf-mif-dhcpv6-route-option? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:30:41 -0000 --_002_39B5E4D390E9BD4890E2B310790061010830DDESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, can you please also correct the errors identified in the attached mail? Kind regards Ivo Sedlacek=20 This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: 3. =FAnora 2013 19:54 To: mif Subject: [mif] Advancement of draft-ietf-mif-dhcpv6-route-option? Hello, I wonder what is the advancement direction about of draft-ietf-mif-dhcpv6-r= oute-option. I remember an advantageous voting procedure in Atlanta, and I hoped to see = confirmation on the email list if necessary. That voting and its confirmation could help close many of the raised issues= , right? Tickets are at: http://trac.tools.ietf.org/wg/mif/trac/report/1 Regards, Alex _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --_002_39B5E4D390E9BD4890E2B310790061010830DDESESSMB301ericsso_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Thu, 07 Feb 2013 15:30:31 GMT"; modification-date="Thu, 07 Feb 2013 15:30:31 GMT" Received: from esessmw0184.eemea.ericsson.se (153.88.115.81) by ESESSHC011.ericsson.se (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 24 Oct 2012 14:34:42 +0200 Received: from sesbmg11.ericsson.net (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.83) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Oct 2012 14:34:38 +0200 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by sesbmg11.ericsson.net (Symantec Mail Security) with SMTP id 7B.14.25995.D50E7805; Wed, 24 Oct 2012 14:34:37 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB52821F8939; Wed, 24 Oct 2012 05:34:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6494A21F894C for ; Wed, 24 Oct 2012 05:34:33 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM3tyx8D0TBz for ; Wed, 24 Oct 2012 05:34:27 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D3F3121F8939 for ; Wed, 24 Oct 2012 05:34:26 -0700 (PDT) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E5.6E.04547.050E7805; Wed, 24 Oct 2012 14:34:24 +0200 (CEST) Received: from ESESSHC023.ericsson.se (153.88.183.87) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 24 Oct 2012 14:34:24 +0200 Received: from ESESSMB301.ericsson.se ([169.254.1.169]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 14:34:24 +0200 From: Ivo Sedlacek To: "mif@ietf.org" Subject: [mif] Question to draft-ietf-mif-dhcpv6-route-option-05 Thread-Topic: Question to draft-ietf-mif-dhcpv6-route-option-05 Thread-Index: Ac2x48yO3q8p/vbGSI+GbiRys+ZsVQ== Sender: "mif-bounces@ietf.org" Date: Wed, 24 Oct 2012 12:34:23 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610101A1DC@ESESSMB301.ericsson.se> List-Help: List-Subscribe: , List-Unsubscribe: , Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Exchange-Organization-AuthSource: esessmw0184.eemea.ericsson.se X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-brightmail-tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUyM+JvrW7Ag/YAg499ZhZde24wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48XhJcwF7ZcYK9bsec3ewHhvD2MXIyeHhICJxJNDe5kgbDGJ C/fWs3UxcnEICZxilOj9+ZcdwtnJKDFx/loWCGcJo8Thv30sIC1sAnoSE7ccYQWxRQQUJf6+ 3s0MYgsLWEms7Z7PBhG3lzh6bikzhK0n8epTG9hqFgFViY51U4E2cHDwCnhL9J5JAQkzCshK XP3TC1bCLCAucevJfKjrRCQeXjzNBmGLSrx8/I8VwlaU2Hm2nRnkNmaBbkaJj9OusYMkeAUE JU7OfMICMl9IQE3i46r8CYwis5CMnYWsZRaSFoiifImrfZfZIWwdiQW7P7FB2NoSyxa+Zoax zxx4zIQpriOx+dJOqDmKEm2ds6GWLWWUWHngMRtM0e6/PawwRVO6H8ItW9o2DaiGAyzedacM rvf3qhOsMDUv7r9mQ9a7gFFoFaNwbmJmTnq5kV5qUWZycXF+nl5x6iZGYEI5uOW36g7GO+dE DjFKc7AoifNab93jLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRaVNrs3mK0cZ9zsVpNQdD WPVbp85jYnnzJcG4terBN2/B/bzsEz82mmx8s5WXLZ3Juzxv68/p06QaTp3KL1+aeYg5o/zN cTmZrQXrzb/u/N6bsVBj6ezOxtuP267GrLgkaL/oZfOh4t0+xcfZgtUsj8+aq3lirlJbN9dh dqVrnw++UdO94K2txFKckWioxVxUnAgATC0ID/YCAAA= x-auditid: c1b4fb39-b7fe96d00000658b-74-5087e05c4ee0 x-originating-ip: [153.88.183.16] x-virus-scanned: amavisd-new at amsl.com list-id: Multiple Interface Discussion List x-mailman-version: 2.1.12 delivered-to: mif@ietfa.amsl.com x-beenthere: mif@ietf.org x-original-to: mif@ietfa.amsl.com list-post: x-spam-flag: NO list-archive: errors-to: mif-bounces@ietf.org dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1351082076; bh=e/GsMgu/rmtP+a5HUnPhFdU4vLnfw+DDK+NJtc68RNc=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=THGHTZc6T28Lrou3/TIgsjKcTG82uL+BaEke++9nN5wX50P6cYtxR6YseC52i6aaY 9MnycEJhbA+1xAlsZLKnrx56PVDaZqScyUEhQYuCZ7GAIK01AeHKKoie0FydfbgULy iXv0MYT7isapBfFHQt3zx6dPTdaxzx7/5Rw6G23g= x-spam-level: x-spam-status: No, score=-5.038 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] x-spam-score: -5.038 Content-Type: multipart/mixed; boundary="_007_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_" MIME-Version: 1.0 --_007_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: multipart/related; boundary="_006_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_"; type="multipart/alternative" --_006_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_" --_000_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, draft-ietf-mif-dhcpv6-route-option-05 states in section 7.1: Metric field (available in previous version of this draft) has been replaced with 2-bit preference field that is in line with RIO information. Issue1: the section 4 states: In terms of the high level operation of the solution defined in this draft, a DHCPv6 client interested in obtaining routing information request the route options using the DHCPv6 Option Request Option (ORO) sent to a server. A Server, when configured to do so, provides the requested route information as part of a nested options structure covering; the next-hop address; the destination prefix; >>the route metric<<; any additional options applicable to the destination or next- hop. Given the statement in section 7.1, is "the route metric" above correct or = is it an obsolete text? Issue2: section 5.2 states: .... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RT_PREFIX | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Length |Resvd|Prf|Resvd| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix | | (up to 16 octets) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . RT_PREFIX sub-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Route Prefix Option Format .... Metric: Route Metric. 8-bit signed integer. The Route Metric indicates whether to prefer the next hop associated with this prefix over others, when multiple identical prefixes (for different next hops) have been received. .... There is no "Metric" field shown in the Figure 3. Thanks for clarification. Kind regards Description: Description: line IVO SEDLACEK Ericsson Mobile +420 608 234 709 ivo.sedlacek@ericsson.com www.ericsson.com Description: Description: http://www.ericsson.com/ This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer --_000_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <428A8BEC820CE344B1B309605C4B1E97@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hello,

 

draft-ietf-mif-dhcpv6-route-option-05 sta= tes in section 7.1:

 

   Metric field (available in previous version o= f this draft) has been

   replaced with 2-bit preference field that is = in line with RIO

   information.

 

Issue1:

 

the section 4 states:

 

   In terms of the high level operation of the solution defi=
ned in this
   draft, a DHCPv6 client interested in obtaining routing in=
formation
   request the route options using the DHCPv6 Option Request=
 Option
   (ORO) sent to a server.  A Server, when configured t=
o do so, provides
   the requested route information as part of a nested optio=
ns structure
   covering; the next-hop address; the destination prefix; <=
u>>>the route
   metric<<; any additional options applicable =
to the destination or next-
   hop.

 

Given the statement in section 7.1, is &q= uot;the route metric" above correct or is it an obsolete text?

 

 

Issue2:=

 

section 5.2 states:

....

 

      0      &n=
bsp;            1&nb=
sp;            =
      2       &=
nbsp;           3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9=
 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;
     |       OPTION_=
RT_PREFIX        |   &nbs=
p;      option-len     &n=
bsp;     |
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;
     |       &n=
bsp;            =
;     Route lifetime      =
;            &n=
bsp;     |
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;
     | Prefix-Length |Resvd|Prf|Resvd|  =
            &nb=
sp;            =
    |
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+   &=
nbsp;           &nbs=
p;            &=
nbsp;  |
     |       &n=
bsp;            =
;        Prefix    &=
nbsp;           &nbs=
p;            |=

     |       &n=
bsp;            =
;      (up to 16 octets)    &n=
bsp;            =
;   |
     |       &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;     |
     |       &n=
bsp;            =
;           +-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+
     |       &n=
bsp;            =
;           |  =
            &nb=
sp;            =
    |
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+   &=
nbsp;           &nbs=
p;            &=
nbsp;  |
     .       &n=
bsp;            =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;    .
     .       &n=
bsp;            =
;     RT_PREFIX sub-options    &nbs=
p;            .=

     .       &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;     .
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;
 
            &nb=
sp;      Figure 3: Route Prefix Option Format=

 

....

 

   Metric:   Route Metric. 8-bit signed integer.&n=
bsp; The Route Metric
           &nbs=
p; indicates whether to prefer the next hop associated with

           &nbs=
p; this prefix over others, when multiple identical prefixes

           &nbs=
p; (for different next hops) have been received.


....


 


There is no "Metric" field show=
n in the Figure 3.


 


Thanks for clarification.


 


Kind regards<=
/o:p>


 


3D"Description:=



IVO SEDLACEK





Ericsson

Mobile +420 608 234 709

ivo.sedlacek@ericsson.com

www.ericsson.com 





3D"Description=


 


This Communication is Confid=
ential. We only send and receive email on the basis of the terms set out at

www.ericsson.com/email_disclaimer
--_000_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_-- --_006_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1417; creation-date="Wed, 24 Oct 2012 12:34:23 GMT"; modification-date="Wed, 24 Oct 2012 12:34:23 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqiLQCN XwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZopFYaag6U P8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3gqcKWpoNXACF nnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwcbDShL7kHVg9Dijwf b3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2pJQtTlQCHiyyeMyEldVut HwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCEqgCCtgCEpwCFnACJfwCKdgCL bWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlbmwCHjQ1Kjw5GjACLaz+kKgCQSRE5 g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQORRHO1FHsTYxaXPJEPXo++CYe7DACPSkkd bU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIYaAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwG VQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88C USecNRMwfq0JWACCs3m3EgCGmQCJgACIgpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYES YQF/tACBtQCJfZQOXQCKdEinJ4m8CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVu qCckdACFogCGkwCDsQJ7sQCKcgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4 rwCLagCNXgCOUwpYmQuUQLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMA AAj/AP/9y8cPFiFhUT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYV ulihsuWFgSNXrULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV 6tBOyBU9PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCp UIUdOejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgLESLA 5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUUUkox5RRU UlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHmGWiikWYaaqqx 5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLRZx9++t3yBSL//bMP PgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFHJbVUU09FNVVVV2W1VVdf hWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZZ5+FNlppp6W2WmuvxTZbbbfl tltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3X3335bffF/79ExAAOw== --_006_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1809; creation-date="Wed, 24 Oct 2012 12:34:23 GMT"; modification-date="Wed, 24 Oct 2012 12:34:23 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh9AFRAPcAAId6ryxvsAtXo8zr6BBJmdIaXiuWxACZi5nW17ritehtmC6skFWWx3YdbtfD 2ffg6qpUjgCXpb3X6gCYnGvHjKbbqaypzHvCQSmsSpnXzI3RjQCcZxKkauLx1OWUtcXjpq3ftkQj ed7r9ACMuieltdekwo5Xlbvh6ur25oy118MaYQiiUwCaeM7s3tc5dNbV5u71+hg7jnfE1tjuzZnS 4qbUcZXPb6bXiLIvcojM3MfmswN8uVW7tKrY5rWWve6jv+zh7ENysSpGlJ2bw5vZvaoaZWa8Q4TQ npYvd2g/iCwqgBGatpsbZ7R3p1m5RILEQMeVuunR4YUca3m32fL68wCeW5rM47Xfp/Tw9gCTsm9v qUu6cEahywOCurMaY3JRlG6Yxse10b3l1YjQuRSmT2e41UyFvZSjyhGhhEi6gt4oZ8tIgZ+52HbH cYrD3sOlxtTu223AUk62RY6v04jO00S2ld7y6+749atonUKzRka2U1W8nLTiw9SVuM3m8X3NoJDV rfXR3/rw9WbDpyhYobqGsTGFvq3M4zOiyFEgdeCjwamYwHMtemO/Wd3w9TQnfTq0ZTq1drW713fK s+NHfarezK6Hs+TC1tSzzmbCuL/iptmFrKGz1FtTmIGbxtrw2rXdms/c7BGdqnuu07qmyFas0glg qiKpe4k7gRWFvj+yR8rqzojJW14fc1S6VHSKu8V2pCEyh/Oyya6Xv4jPy2qp0fPC1Krd1BKSwIjS shpmrFW5xrfcjBd5t+azyzg6isLL4YvGPwZusjKvSO73+u+Us94ZXHvGXFikz2GDuY7JTbHA2w6k UUSww+Dm8ZGozn2mzjayVojFQCuvaavgx1aw0ojHTsLhmZzA3ZTKTFfAjMSFr4jQwpegx37ET1M6 iEBehn+Trr/J1xA1aJ+uwu/y9t/k68/X4WB5mzBQfCBDcprYqnCGpY+huK+8zE9rkqatz9brv7/R 5ZbNWRhusshmmI+r0Kvbm3TAQiKrW5dpobvfmt1XiaGJtgAoXv///ywAAAAA9AFRAAAI/gD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1L1qC5duHC iSvLtq3bqeTe+Zs7F93bu3jz/hSHbhzdv/7I6R1MuPBKc+zUAV4MzrDjx5AxlmuXbrFlf40ja97M uWDcy6Azdx5NWi9fv6BBCy7NurVYxIpTp2bnurZtrJMrywatjp2528CDPz0Xe7dldO6EK1+eVLfx v+nIlWNOvXrQc8/p9v5tvbt3neKe/o9Dt7bgOXbg3q3+zr49yvCywUkveLb4XNHu8+v3aP+vunbc DVQOOeCA1s5+CCZ40TmozTXeOQa5g85u+Clo4YULTYYOO+sNdF6D8WEo4ogOneXcc++QqOKKAg0o V3Z/JcfijBZKCCKM43RI447swQYjYOm0Mx2PRH7H4I/a+Vbkkt/19xxyTEbZHXzZyTeklFgyR6Vs 6oQT4EBxgQNOOFdmaeZo2KU2XnkEndMXkGWeKWdkBVqmnlnhOElXOHP2GVk5J/735T8DnnhZhX4m Opg7aUFYkDsvGoeoopQW5uaNu6VY6aaDmZMnknOxyemoZRUK6lzqyEjqqmGdEymo/u+oyuqsXblz qj/RxUnrrllhutt2vAbL1Za7jSersMheRWxo8yXrLFZp8ubls9RmVSdgD1arLW7X+nPntuBCS447 g4Zr7rnopqvuuuy26+678MYr77z01mvvvfiqe444/PKr0IBpkeMowOG0MzA5aRk8kDkIh+NovvRa tla3/uQoUKgChbPYP0fS1Rg5IGbGDpCO0lVegXxCfO5c6YgpJoQUzzUdxiOjCk5l/8TWcsv/oLZz Yxrf5/PF9wmEssor+yOq0XMRqttaoZpD14EC/eaggPClI2DPcx1YDmqC/TWxPykjDW7X/Z4cqjt+ jUO0OOSwbBBqvUFYTpK/wee2+UA181kXZv8cbfbZGweOrYyhBl02mIDZVfOe8InWTtFzSR2Y4INr W1daaTENWHmhTu7tQZfSBeFpdMWN60BB09a0xupgnjm1GBdU5z+i2/VPqNE+bNCLbAI6l62VC6Tb gU1/XTHZs2vuDzqcT3v73RW/bfjmef7zDjrttIOaOL2hhZo5E+L6WcUz+5Pxns1XK/H1Ar0YttKE xizOjY0tZpfwf42DuPqEQs3i2oes6HHuN+jJjDvExKe0BEhCLvNNOFwGDiH9I4Fi6lCYwKGkjJVN HGlZGgFHSMISmvCEKEyhClfIwha68IUwjKEMZ0jDGtrwhjjMYUUCAgA7 --_006_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_-- --_007_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=124; creation-date="Wed, 24 Oct 2012 12:34:42 GMT"; modification-date="Wed, 24 Oct 2012 12:34:42 GMT" Content-ID: <6D66C49811004B40B298667FB1B4AFD6@ericsson.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1pZiBtYWls aW5nIGxpc3QNCm1pZkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9taWYNCg== --_007_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_-- --_002_39B5E4D390E9BD4890E2B310790061010830DDESESSMB301ericsso_-- From dwing@cisco.com Thu Feb 7 09:13:10 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6DB21F890D for ; Thu, 7 Feb 2013 09:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.639 X-Spam-Level: X-Spam-Status: No, score=-109.639 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68BqqIoJtsWz for ; Thu, 7 Feb 2013 09:13:09 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC7821F87AB for ; Thu, 7 Feb 2013 09:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2776; q=dns/txt; s=iport; t=1360257189; x=1361466789; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=+t9uY6OyGLlRMMQg04eMZgmGFYhsJX8wp7dviZtkYJ8=; b=SjZ9JZGTOY5mdcG6hGzcItC5fYKA/Ota8uofaShSPXRgBvLb8VTu4Cm5 MZOEUt1C59CUNEdaOg7ekQ7QitxUx7AiDig0d7iFOxIG++IO5scMFc0oC AhJuJz8XoLuf/Yl+6+LR5x03IdSBC/yHMTffdyMYKfp+w5ACtLW0nMvlC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOrfE1GrRDoH/2dsb2JhbABFwGgWcz2BYgEBAQQIAjAPMAwBBRoEAQEBFgEMBCAIJQkJAQQBEgsFh28DDg21Ow2JVowWfYEcAYMsA4hmhSGGQoFYgR2KIoUTgyGBRwcXBg X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; d="scan'208";a="71363627" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 07 Feb 2013 17:13:08 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r17HD8vR014555; Thu, 7 Feb 2013 17:13:08 GMT From: "Dan Wing" To: "'Ted Lemon'" , "'GangChen'" Date: Thu, 7 Feb 2013 09:13:08 -0800 Message-ID: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4FVmZSGKWVpQUTTQOUBfohgFXrhQ== Content-Language: en-us Cc: 'mif' , 'draft-ietf-mif-happy-eyeballs-extension' Subject: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 17:13:10 -0000 > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: Monday, February 04, 2013 9:35 PM > To: GangChen > Cc: mif; draft-ietf-mif-happy-eyeballs-extension > Subject: Re: [mif] DNS selection with HE-MIF > > On Feb 4, 2013, at 11:02 PM, GangChen wrote: > > I can't comment on benefits of "doing DNS queries within one > > provisioning domain, and then using the results in the other > > provisioning domain." But HE-MIF has to do in some cases, because that > > maybe a normal node behavior, like stated in RFC6418 "A node usually > > has a node-scoped routing table". This issue may retrospect to basic > > Internet host design in RFC1122. Changing the model would go beyond > > HE-MIF scope. > > Okay, so your point is that we can't do connections within a > provisioning domain, because we don't have control over how a connection > is routed. > > I agree that this is a problem, but it is explicitly within the scope of > the MIF charter to consider this problem and document it. It is quite > likely the case that solving the problem is outside of the current MIF > charter, and that such work, if attempted, ought not to occur in MIF. > > However, if in fact the HE-MIF document can't work correctly without > solving this problem, then it is certainly within the scope of the > current charter for the MIF working group to draw that conclusion. > > For my part, what I am saying is that HE-MIF can't really be very useful > without solving this problem. It is not in fact the case that a MIF > node can have a single node-scoped routing table and still succeed in > communicating on the network in the face of, for example, an interface > that's connected to a captive portal but providing a default route, as > such captive portals typically do. The technique used by both Apple and Microsoft is, when joining a new network, to attempt to retrieve a certain URI. Microsoft's procedure is described in http://technet.microsoft.com/en-us/library/cc766017%28v=ws.10%29.aspx, which queries www.msftncsi.com and needs to see 131.107.255.255 as the answer, and then does an HTTP GET. If anything is abnormal, it assumes there is a proxy on the path. Apple does something similar by attempting to retrieve https://www.apple.com/library/test/success.html. Unfortunately, this seems the best technique available to detect such DNS interception and HTTP interception proxies that force a login or force a click-through. For MIF -- not just HE-MIF, but all of MIF -- we should not declare an interface "up" until such a validation succeeds. It is unfortunate this is not solved at layer 2, where it arguably belongs. -d From alexandru.petrescu@gmail.com Thu Feb 7 09:44:28 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3503021F8473 for ; Thu, 7 Feb 2013 09:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.212 X-Spam-Level: X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIybar04f3+z for ; Thu, 7 Feb 2013 09:44:27 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA0121F8460 for ; Thu, 7 Feb 2013 09:44:26 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r17HiOBW019614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Feb 2013 18:44:24 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r17HiNuA010214; Thu, 7 Feb 2013 18:44:24 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r17HiK9T010584; Thu, 7 Feb 2013 18:44:23 +0100 Message-ID: <5113E7F4.5080405@gmail.com> Date: Thu, 07 Feb 2013 18:44:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ivo Sedlacek References: <510EB247.6050906@gmail.com> <39B5E4D390E9BD4890E2B310790061010830DD@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061010830DD@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] Advancement of draft-ietf-mif-dhcpv6-route-option? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 17:44:28 -0000 Ivo, If I understand correctly, in that email you point to an incoherency about the 'Metric' field. You name them Issue1 and Issue2. Issue1 suggests there may be some obsolete text in the draft, whereas Issue2 points to the absence of Metric field in a figure whose text talks Metric. I also consider these two to be issues. I opened a ticket about it. But. Do you think other resolution about this Metric should be suggested? How would you like to see these Metric issues fixed? Thanks for pointing to this issue. Alex Le 07/02/2013 16:30, Ivo Sedlacek a écrit : > Hello, > > can you please also correct the errors identified in the attached > mail? > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on > the basis of the terms set out at www.ericsson.com/email_disclaimer > > > -----Original Message----- From: mif-bounces@ietf.org > [mailto:mif-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > 3. února 2013 19:54 To: mif Subject: [mif] Advancement of > draft-ietf-mif-dhcpv6-route-option? > > Hello, > > I wonder what is the advancement direction about of > draft-ietf-mif-dhcpv6-route-option. > > I remember an advantageous voting procedure in Atlanta, and I hoped > to see confirmation on the email list if necessary. > > That voting and its confirmation could help close many of the raised > issues, right? > > Tickets are at: http://trac.tools.ietf.org/wg/mif/trac/report/1 > > Regards, > > Alex _______________________________________________ mif mailing > list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From moore@network-heretics.com Thu Feb 7 09:53:01 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163AB21F8596 for ; Thu, 7 Feb 2013 09:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXixz8jRhGMC for ; Thu, 7 Feb 2013 09:52:59 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B268221F858E for ; Thu, 7 Feb 2013 09:52:59 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 06A6620E1F for ; Thu, 7 Feb 2013 12:52:58 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 07 Feb 2013 12:52:59 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=KBu6muRMh7b4tOi/5Z/xgl B3Bsw=; b=Yfr/VVWaj3BTKozCxiydkOAhKq6BouIPnh+NUjXK/NAf7B6Uww2ZCf pgsL3w3bxjN+k/1uE2dPd8UJaabOxWZAxbJjZZk+bvykBCdOsTGF8Wfj/JJK6MYH Aco8UczSr24bfajAGXRSiJ8tYCNEJKNqZJghksDeNkzG/XBTdjjco= X-Sasl-enc: U0qC6cZMHxQxs88X7nhMS09b8Ntf3V9d0wHU5+Wm9RpC 1360259577 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 71E524825E7; Thu, 7 Feb 2013 12:52:57 -0500 (EST) Message-ID: <5113E9EF.5090400@network-heretics.com> Date: Thu, 07 Feb 2013 12:52:47 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com> In-Reply-To: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 17:53:01 -0000 On 02/07/2013 12:13 PM, Dan Wing wrote: > The technique used by both Apple and Microsoft is, when joining a new > network, to attempt to retrieve a certain URI. Microsoft's procedure > is described in > http://technet.microsoft.com/en-us/library/cc766017%28v=ws.10%29.aspx, > which queries www.msftncsi.com and needs to see 131.107.255.255 as > the answer, and then does an HTTP GET. If anything is abnormal, it > assumes there is a proxy on the path. Apple does something similar by > attempting to retrieve https://www.apple.com/library/test/success.html. > Unfortunately, this seems the best technique available to detect such > DNS interception and HTTP interception proxies that force a login or > force a click-through. > > For MIF -- not just HE-MIF, but all of MIF -- we should not declare an > interface "up" until such a validation succeeds. It is unfortunate > this is not solved at layer 2, where it arguably belongs. Would it be worthwhile for MIF to start making a list of things that really need solutions elsewhere? Even if there are hacks or heuristics that are used in the absence of such solutions? Keith From william.d.ivancic@nasa.gov Thu Feb 7 12:58:58 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D71121F86FB for ; Thu, 7 Feb 2013 12:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.132 X-Spam-Level: X-Spam-Status: No, score=-4.132 tagged_above=-999 required=5 tests=[AWL=-1.533, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNVtkNl61KDc for ; Thu, 7 Feb 2013 12:58:58 -0800 (PST) Received: from ndmsnpf01.ndc.nasa.gov (NDMSNPF01.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6D521F86F5 for ; Thu, 7 Feb 2013 12:58:58 -0800 (PST) Received: from ndjsppt104.ndc.nasa.gov (NDJSPPT104.ndc.nasa.gov [198.117.1.198]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id BF855260743; Thu, 7 Feb 2013 14:58:54 -0600 (CST) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt104.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r17KwsQj010978; Thu, 7 Feb 2013 14:58:54 -0600 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Thu, 7 Feb 2013 14:58:54 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: Keith Moore , "mif@ietf.org" Date: Thu, 7 Feb 2013 14:59:06 -0600 Thread-Topic: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF] Thread-Index: Ac4FW/tA4gVeoPfBQW2ax/+iafP4ggAGfwjG Message-ID: In-Reply-To: <5113E9EF.5090400@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-07_06:2013-02-07, 2013-02-07, 1970-01-01 signatures=0 Subject: Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 20:58:58 -0000 > Would it be worthwhile for MIF to start making a list of things that > really need solutions elsewhere? Even if there are hacks or heuristics > that are used in the absence of such solutions? >=20 > Keith >=20 >=20 I would certainly think that should be a good idea. Will From mcr@sandelman.ca Fri Feb 8 05:49:58 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2295421F8A51 for ; Fri, 8 Feb 2013 05:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzsUfHeTnYNu for ; Fri, 8 Feb 2013 05:49:57 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2E221F851C for ; Fri, 8 Feb 2013 05:49:57 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C5222016D; Fri, 8 Feb 2013 08:56:00 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id F03DA6376A; Fri, 8 Feb 2013 08:48:54 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D79F963769; Fri, 8 Feb 2013 08:48:54 -0500 (EST) From: Michael Richardson To: mif@ietf.org In-Reply-To: <5113E9EF.5090400@network-heretics.com> References: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com> <5113E9EF.5090400@network-heretics.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Keith Moore Subject: Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 13:49:58 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Keith" =3D=3D Keith Moore writes: >> For MIF -- not just HE-MIF, but all of MIF -- we should not >> declare an interface "up" until such a validation succeeds. It >> is unfortunate this is not solved at layer 2, where it arguably >> belongs. Keith> Would it be worthwhile for MIF to start making a list of Keith> things that really need solutions elsewhere? Even if there Keith> are hacks or heuristics that are used in the absence of such Keith> solutions? Yes. In the portal case, we need a DHCP "login required" message. It would be nice if we also had a BCP on how to signal and upgrade From=20HTTP login to some DHCP EAP, perhaps using a EAP-TLS resume=20 From=20the HTTP session state. This would permit captive portals to=20 recognize re-logins. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAURUCRoqHRg3pndX9AQLZcwQA3yKt9l9Xj67ov9UhQ1gLDWFZnnuG3iWV UdxQGM+E9qL+2GwVwobJ0bzNIXMTfNE5VXNElL3cSQs3mpGQgthi4vGwKvQSD6W4 L47p2tQDH0Maj/uK4QeWOLMwIUfBTriB/OBfVSWSC7m/i+xKCWLjSvAPXfZgbFGk 81xD9vfrRLI= =J89e -----END PGP SIGNATURE----- --=-=-=-- From brian.e.carpenter@gmail.com Fri Feb 8 06:50:11 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC6321F8A61 for ; Fri, 8 Feb 2013 06:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.855 X-Spam-Level: X-Spam-Status: No, score=-98.855 tagged_above=-999 required=5 tests=[AWL=-1.340, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_34=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MpshMIpa6BA for ; Fri, 8 Feb 2013 06:50:10 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3822E21F8A64 for ; Fri, 8 Feb 2013 06:50:10 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id r5so3089208wey.32 for ; Fri, 08 Feb 2013 06:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cyEMBXEvJ/IYLCHrk2WTeY7L4/z1Zb5jL/KxkramBr8=; b=PWS7XDRWt9hsB5VR/TJg6WXXhDhIawY19I6Iqn+lGSJgmrViAMosQeWDAd6Tj3id2S Wnv34Yl/9mURx8W3fOIjGV9tDbiqTALKxH/MlTRJa91g5xO+2GKcScn1ohXigDLiZtjA eWi5q8itRvU2BUcbLu8jBtLfxV7MOO6QtEddqiSlfN8h3uBokTk6VMQ5uILlvwPB7rjy tIW73QdR3dD0B/0/ok/nlTIdW/Wou4DBZkcyF3Xjvyz2QZiMq5l0CfO9jrjewIbdwT4x fXNXvlZ8+NOnGqN8inHwy0E534S85Tp5dBh9bh1GrQGLM9aY2dL/lqMybdZwu5vZT+9z wu9Q== X-Received: by 10.194.78.207 with SMTP id d15mr10251614wjx.52.1360335006583; Fri, 08 Feb 2013 06:50:06 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-26.as13285.net. [2.101.188.26]) by mx.google.com with ESMTPS id be1sm15930680wib.10.2013.02.08.06.50.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 06:50:05 -0800 (PST) Message-ID: <511510AA.1060704@gmail.com> Date: Fri, 08 Feb 2013 14:50:18 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com> <5113E9EF.5090400@network-heretics.com> In-Reply-To: <5113E9EF.5090400@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 14:50:11 -0000 On 07/02/2013 17:52, Keith Moore wrote: > On 02/07/2013 12:13 PM, Dan Wing wrote: >> The technique used by both Apple and Microsoft is, when joining a new >> network, to attempt to retrieve a certain URI. Microsoft's procedure >> is described in >> http://technet.microsoft.com/en-us/library/cc766017%28v=ws.10%29.aspx, >> which queries www.msftncsi.com and needs to see 131.107.255.255 as >> the answer, and then does an HTTP GET. If anything is abnormal, it >> assumes there is a proxy on the path. Apple does something similar by >> attempting to retrieve https://www.apple.com/library/test/success.html. >> Unfortunately, this seems the best technique available to detect such >> DNS interception and HTTP interception proxies that force a login or >> force a click-through. >> >> For MIF -- not just HE-MIF, but all of MIF -- we should not declare an >> interface "up" until such a validation succeeds. It is unfortunate >> this is not solved at layer 2, where it arguably belongs. > > Would it be worthwhile for MIF to start making a list of things that > really need solutions elsewhere? Even if there are hacks or heuristics > that are used in the absence of such solutions? The MS hack does a WGET on http://www.msftncsi.com/ncsi.txt and requires the correct text to be returned. An extension is http://ipv6.msftncsi.com/ncsi.txt, used to verify IPv6ness. It's supposed to resolve to 2001:450:2002:384::40d6:ce0b and again return the correct text. [Thanks to Dan Wing over on another list for this info.] Brian From alexandru.petrescu@gmail.com Fri Feb 8 09:12:17 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D6021F8B70 for ; Fri, 8 Feb 2013 09:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.213 X-Spam-Level: X-Spam-Status: No, score=-10.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3gV2tBN3z13 for ; Fri, 8 Feb 2013 09:12:16 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 63D7521F8A7B for ; Fri, 8 Feb 2013 09:12:16 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r18HCFJH015563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 8 Feb 2013 18:12:15 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r18HCEtO030127 for ; Fri, 8 Feb 2013 18:12:15 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r18HCA4Q003753 for ; Fri, 8 Feb 2013 18:12:14 +0100 Message-ID: <511531EA.7060507@gmail.com> Date: Fri, 08 Feb 2013 18:12:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com> <5113E9EF.5090400@network-heretics.com> <20067.1360331334@sandelman.ca> In-Reply-To: <20067.1360331334@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 17:12:17 -0000 Le 08/02/2013 14:48, Michael Richardson a écrit : > >>>>>> "Keith" == Keith Moore >>>>>> writes: >>> For MIF -- not just HE-MIF, but all of MIF -- we should not >>> declare an interface "up" until such a validation succeeds. It >>> is unfortunate this is not solved at layer 2, where it arguably >>> belongs. > > Keith> Would it be worthwhile for MIF to start making a list of > Keith> things that really need solutions elsewhere? Even if there > Keith> are hacks or heuristics that are used in the absence of such > Keith> solutions? > > Yes. > > In the portal case, we need a DHCP "login required" message. YEs, tool useful. Or an ARP reply message which could carry same "login required". This could be sent by the default router to the Client when it presents its MAC address. Rather ARP than DHCP because the end effect of the portal authentication is the opening of a firewall filter which is based on the MAC address. ARP is at the same level. > It would be nice if we also had a BCP on how to signal and upgrade > From HTTP login to some DHCP EAP, perhaps using a EAP-TLS resume > From the HTTP session state. This would permit captive portals to > recognize re-logins. Same with ARP... Alex > > > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From marc.blanchet@viagenie.ca Fri Feb 8 09:14:18 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B404921F8B47 for ; Fri, 8 Feb 2013 09:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Jme3jvs3f25 for ; Fri, 8 Feb 2013 09:14:17 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 18F9B21F8B46 for ; Fri, 8 Feb 2013 09:14:17 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 74B1D40109; Fri, 8 Feb 2013 12:14:16 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <20067.1360331334@sandelman.ca> Date: Fri, 8 Feb 2013 12:14:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <314C70F4-1E2F-47C8-822E-319DBF38358E@viagenie.ca> References: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com> <5113E9EF.5090400@network-heretics.com> <20067.1360331334@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1283) Cc: mif@ietf.org, Keith Moore Subject: Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 17:14:18 -0000 Le 2013-02-08 =E0 08:48, Michael Richardson a =E9crit : >=20 >>>>>> "Keith" =3D=3D Keith Moore writes: >>> For MIF -- not just HE-MIF, but all of MIF -- we should not >>> declare an interface "up" until such a validation succeeds. It >>> is unfortunate this is not solved at layer 2, where it arguably >>> belongs. >=20 > Keith> Would it be worthwhile for MIF to start making a list of > Keith> things that really need solutions elsewhere? Even if there > Keith> are hacks or heuristics that are used in the absence of such > Keith> solutions? >=20 > Yes. >=20 > In the portal case, we need a DHCP "login required" message. specially in more open portals, IPv6 deployments may use RA, so it has = to also involve RA. Marc. > It would be nice if we also had a BCP on how to signal and upgrade > =46rom HTTP login to some DHCP EAP, perhaps using a EAP-TLS resume=20 > =46rom the HTTP session state. This would permit captive portals to=20= > recognize re-logins. >=20 > --=20 > Michael Richardson , Sandelman Software Works=20= >=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From phdgang@gmail.com Wed Feb 20 21:39:39 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90AF21E809C for ; Wed, 20 Feb 2013 21:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfXvUqxayUxS for ; Wed, 20 Feb 2013 21:39:36 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1EC21E809E for ; Wed, 20 Feb 2013 21:39:35 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id j8so2823706qah.14 for ; Wed, 20 Feb 2013 21:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OYYs6FYG1Y2NAKvpB9jGsFqi26budNrP28+j1x07h6Y=; b=BsjZ+479PAHDFKV73vgyge+JX2JfJXB7zjxIXY3p0lk060dbomO/FJNlt3CVCHISfp Jg+78n5OJ9947IAhoQb9vLQIZ3/MdIHSgpvnh0rPwyJhovu26SgAM/tLnBwHhZ6ZF8mF WGx8eNEv5aQYYhyd8YTinBYCfzXyBRr7d/vbU+GryVQwYY7yOfYdKLryCDv6l3GVSjgV Tvig4Q9LnCDSVCqjfiG8CXh7hrVT2XfhhaSeIr8yXuwzbRdjlWL2cvGDNKux1AKBy6dG inGYRGFCVHZAhtz0dJKF4vMPng8MS2FB/POlFNqM75/u0/VFOQb1brPVFpfbrHPc+7aV lF7Q== MIME-Version: 1.0 X-Received: by 10.49.84.104 with SMTP id x8mr11702754qey.5.1361425174937; Wed, 20 Feb 2013 21:39:34 -0800 (PST) Received: by 10.49.48.12 with HTTP; Wed, 20 Feb 2013 21:39:34 -0800 (PST) In-Reply-To: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com> References: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com> Date: Thu, 21 Feb 2013 13:39:34 +0800 Message-ID: From: GangChen To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: mif , draft-ietf-mif-happy-eyeballs-extension Subject: Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 05:39:39 -0000 2013/2/8, Dan Wing : >> -----Original Message----- >> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of >> Ted Lemon >> Sent: Monday, February 04, 2013 9:35 PM >> To: GangChen >> Cc: mif; draft-ietf-mif-happy-eyeballs-extension >> Subject: Re: [mif] DNS selection with HE-MIF >> >> On Feb 4, 2013, at 11:02 PM, GangChen wrote: >> > I can't comment on benefits of "doing DNS queries within one >> > provisioning domain, and then using the results in the other >> > provisioning domain." But HE-MIF has to do in some cases, because that >> > maybe a normal node behavior, like stated in RFC6418 "A node usually >> > has a node-scoped routing table". This issue may retrospect to basic >> > Internet host design in RFC1122. Changing the model would go beyond >> > HE-MIF scope. >> >> Okay, so your point is that we can't do connections within a >> provisioning domain, because we don't have control over how a connection >> is routed. >> >> I agree that this is a problem, but it is explicitly within the scope of >> the MIF charter to consider this problem and document it. It is quite >> likely the case that solving the problem is outside of the current MIF >> charter, and that such work, if attempted, ought not to occur in MIF. >> >> However, if in fact the HE-MIF document can't work correctly without >> solving this problem, then it is certainly within the scope of the >> current charter for the MIF working group to draw that conclusion. >> >> For my part, what I am saying is that HE-MIF can't really be very useful >> without solving this problem. It is not in fact the case that a MIF >> node can have a single node-scoped routing table and still succeed in >> communicating on the network in the face of, for example, an interface >> that's connected to a captive portal but providing a default route, as >> such captive portals typically do. > > The technique used by both Apple and Microsoft is, when joining a new > network, to attempt to retrieve a certain URI. Microsoft's procedure > is described in > http://technet.microsoft.com/en-us/library/cc766017%28v=ws.10%29.aspx, > which queries www.msftncsi.com and needs to see 131.107.255.255 as > the answer, and then does an HTTP GET. If anything is abnormal, it > assumes there is a proxy on the path. Apple does something similar by > attempting to retrieve https://www.apple.com/library/test/success.html. > Unfortunately, this seems the best technique available to detect such > DNS interception and HTTP interception proxies that force a login or > force a click-through. Thanks for providing the information. I guess that could be a way to resolve the issue of captive portal with DNS selections. Let's see, Those network connectivity probes could be performed prior to DNS-selections. A captive portal would likely fail to pass the examination. The interface can be declared as "down" unless users pass the authentication. HE-MIF could therefore be able to automatically rely upon other interfaces to select DNS server by excluding the un-examined interfaces. Best Regards Gang > For MIF -- not just HE-MIF, but all of MIF -- we should not declare an > interface "up" until such a validation succeeds. It is unfortunate > this is not solved at layer 2, where it arguably belongs. > > -d > > > From internet-drafts@ietf.org Mon Feb 25 07:09:40 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D67B21F946B; Mon, 25 Feb 2013 07:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIOwSqyGdMtE; Mon, 25 Feb 2013 07:09:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6978021F9355; Mon, 25 Feb 2013 07:09:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225150939.18370.73595.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 07:09:39 -0800 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-happy-eyeballs-extension-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:09:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of the = IETF. Title : Happy Eyeballs Extension for Multiple Interfaces Author(s) : Gang Chen Carl Williams Dan Wing Andrew Yourtchenko Filename : draft-ietf-mif-happy-eyeballs-extension-02.txt Pages : 12 Date : 2013-02-25 Abstract: Currently the interface selection in multi-interface environment is exclusive - only one interface can be used at the time, frequently needing manual intervention. Happy Eyeballs in MIF would make the selection process smoother by using the connectivity checks over a pre-filtered interfaces according to defined policy. This would choose "best" interface with an automatic fallback. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-happy-eyeballs-extension-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sarikaya2012@gmail.com Mon Feb 25 12:18:18 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135BC21F8F43; Mon, 25 Feb 2013 12:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqbMtfsYvcqS; Mon, 25 Feb 2013 12:18:17 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id DA29C21F8FAA; Mon, 25 Feb 2013 12:18:13 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id go11so2559634lbb.36 for ; Mon, 25 Feb 2013 12:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=red1U+EGqr8lg4a21Y4//WCl+KyBuqbpm0YKxB2TXLQ=; b=yHoadUJ5bVD7aOqtgOwtPM4UJUtP1oNXQ1yh6BGnnEZlblMxr0kFBWNEgBbyjTOaXu C3c/dUM+7CmULbRwVdu6Eg8opV1Xb6+T3Ex+Ax2bL0hMkJxqpys2gS0vrMo8c2hjFsL5 +qGZHfsRdwLsDyIwo48AgHe/X6CTEJGA4thdqU9HVL4mpyOvwwAT2+0DjuuWLqvFoCsG sUSTqrocW1ser73gDVqN3Tq7R/fpJX4JV1JBVDVc3VtbkbTFe3Rqqi3LehOqHA0c1l3x +prNfCmYG963n15UmFrGbwrfTCi0ckfs/GD8c7UuaHdzP6F/tjL1SAzA2VTNZjPL02y5 crxQ== MIME-Version: 1.0 X-Received: by 10.152.104.36 with SMTP id gb4mr11193184lab.13.1361823492823; Mon, 25 Feb 2013 12:18:12 -0800 (PST) Received: by 10.114.28.168 with HTTP; Mon, 25 Feb 2013 12:18:12 -0800 (PST) In-Reply-To: <20130225201655.26126.49424.idtracker@ietfa.amsl.com> References: <20130225201655.26126.49424.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 14:18:12 -0600 Message-ID: From: Behcet Sarikaya To: 6man@ietf.org, mif@ietf.org Content-Type: multipart/alternative; boundary=f46d04083d1589587d04d6923dc9 Subject: [mif] New Version Notification for draft-sarikaya-mif-6man-ra-route-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 20:18:18 -0000 --f46d04083d1589587d04d6923dc9 Content-Type: text/plain; charset=ISO-8859-1 A new version of I-D, draft-sarikaya-mif-6man-ra-route-02.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-mif-6man-ra-route Revision: 02 Title: IPv6 RA Options for Multiple Interface Next Hop Routes Creation date: 2013-02-25 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-02.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route Htmlized: http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-02 Abstract: This draft defines new Router Advertisement options for configuring next hop routes on the mobile or fixed nodes. Using these options, an operator can easily configure nodes with multiple interfaces (or otherwise multi-homed) to enable them to select the routes to a destination. Each option is defined together with definitions of host and router behaviors. The IETF Secretariat --f46d04083d1589587d04d6923dc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


A new version of I-D, draft-sarikaya-mif-6man-ra-route-02.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sarikaya-mif-6man-ra-route
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 IPv6 RA Options for Multiple Interface Next Hop = Routes
Creation date: =A0 2013-02-25
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 9
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf= .org/internet-drafts/draft-sarikaya-mif-6man-ra-route-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/= doc/draft-sarikaya-mif-6man-ra-route
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft= -sarikaya-mif-6man-ra-route-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/= rfcdiff?url2=3Ddraft-sarikaya-mif-6man-ra-route-02

Abstract:
=A0 =A0This draft defines new Router Advertisement options for configuring<= br> =A0 =A0next hop routes on the mobile or fixed nodes. =A0Using these options= ,
=A0 =A0an operator can easily configure nodes with multiple interfaces (or<= br> =A0 =A0otherwise multi-homed) to enable them to select the routes to a
=A0 =A0destination. =A0Each option is defined together with definitions of<= br> =A0 =A0host and router behaviors.




The IETF Secretariat


--f46d04083d1589587d04d6923dc9-- From brian.e.carpenter@gmail.com Tue Feb 26 04:54:38 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2228D21F89A5 for ; Tue, 26 Feb 2013 04:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5bFgTdAOnBi for ; Tue, 26 Feb 2013 04:54:37 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 776F421F858E for ; Tue, 26 Feb 2013 04:54:37 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id dr13so3445243wgb.14 for ; Tue, 26 Feb 2013 04:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CmKHWGB5LEecs4LxX+bzBXBH9nN7KxkZqwlqNHDp7T0=; b=lfEGKWgzD6oIt0oFr844Xm738+CwO/WdhfyCgjuUPaTqtOZNQdizTMnEWA0DvDDJHr TaCMW5I5ad6L7dN0TMftsLGLiyhmurwLbnZ0jxHgaPCKX3RQWf849ktBqlQGeYisi8is Kc7CczDbw70q2CajAfc1+5RkOLIID8Y7z3wjAvVwGTnEbmB/1UUoMB6/9SzWZ73iC25B KND/ZMzrJVrccI/hnSpx7sIxHhAYmgg13ia2W2o38WefT53Xh5sNo+2MawA+Sl9bQU8k trGPhEinmYOikRuH8cg+SuooN4kNBrulfwnS3RA5Jeke8OpcBCyO2/JXl0l+m/lRiPxH ts1A== X-Received: by 10.194.83.105 with SMTP id p9mr26236195wjy.56.1361883276471; Tue, 26 Feb 2013 04:54:36 -0800 (PST) Received: from [128.232.110.102] (c102.al.cl.cam.ac.uk. [128.232.110.102]) by mx.google.com with ESMTPS id j4sm20912190wiz.10.2013.02.26.04.54.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 04:54:35 -0800 (PST) Message-ID: <512CB090.8070403@gmail.com> Date: Tue, 26 Feb 2013 12:54:40 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mif@ietf.org References: <20130225201655.26126.95321.idtracker@ietfa.amsl.com> In-Reply-To: <20130225201655.26126.95321.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [mif] I-D Action: draft-sarikaya-mif-6man-ra-route-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:54:38 -0000 Looking again at this draft after some time, I think it lacks some explanation of the scenario. In particular: > It should be noted that the proposed options in this document will > need a central site-wide configuration mechanism. The required > values can not automatically be derived from routing tables. What site is that? A mobile MIF node might find itself receiving RAs from two completely different "sites" simultaneously, which are completely uncoordinated. Regards Brian From sarikaya2012@gmail.com Tue Feb 26 08:56:07 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAF221F8A04 for ; Tue, 26 Feb 2013 08:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F54SCMASN+GC for ; Tue, 26 Feb 2013 08:55:54 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9DA21F87EA for ; Tue, 26 Feb 2013 08:55:42 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id fs12so4073812lab.39 for ; Tue, 26 Feb 2013 08:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NivXt2TYj+aPwnUWUtATP/L+Ae/kY2fVBGgaECvBJvg=; b=mQFFTk/QhDDLlAwFswP0UZ4htfg2UgaNygnsHdM+KIqc49a0ck4wn+jtca/V+fU7UF CypZ+rP0wiCuwoSmlDebG3wGqzdfehXYhBm7cC9mQV3bKyggQ+BSmOF2DTNm8Ktz3/VP XrESbEeOT1Pb7YyoYm6VyPd5mClEb6y9ShbWfCU7wfQXXgIP88+cW+0UH5TAcY7rioDT JXdItF6QcJcs7cFAjLJCDVfzOKzYia4I+selO8275AD1VouigIQtlEnHKdjxVw4sh7NL o1Q+aXojF2+qkIDpQ8JIxE1+W3qdjeYRG/voeZJfdJvQabLSW0eE7MD2nBT3LH+ZPu3l J3xA== MIME-Version: 1.0 X-Received: by 10.112.27.106 with SMTP id s10mr864739lbg.27.1361897741096; Tue, 26 Feb 2013 08:55:41 -0800 (PST) Received: by 10.114.28.168 with HTTP; Tue, 26 Feb 2013 08:55:40 -0800 (PST) In-Reply-To: <512CB090.8070403@gmail.com> References: <20130225201655.26126.95321.idtracker@ietfa.amsl.com> <512CB090.8070403@gmail.com> Date: Tue, 26 Feb 2013 10:55:40 -0600 Message-ID: From: Behcet Sarikaya To: Brian E Carpenter Content-Type: multipart/alternative; boundary=bcaec554d95215674f04d6a38703 Cc: mif@ietf.org Subject: Re: [mif] I-D Action: draft-sarikaya-mif-6man-ra-route-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:56:08 -0000 --bcaec554d95215674f04d6a38703 Content-Type: text/plain; charset=ISO-8859-1 Hi Brian, I made this revision based on the feedback I got from my 6man presentation in Atlanta. More inline: On Tue, Feb 26, 2013 at 6:54 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Looking again at this draft after some time, I think it lacks some > explanation of the scenario. > > In particular: > > > It should be noted that the proposed options in this document will > > need a central site-wide configuration mechanism. The required > > values can not automatically be derived from routing tables. > > I had added this text based on your comments. > What site is that? A mobile MIF node might find itself receiving RAs from > two completely different "sites" simultaneously, which are completely > uncoordinated. > > Appreciate if you could provide some text? Regards, Behcet > Regards > Brian > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --bcaec554d95215674f04d6a38703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian,

I made this revision based on the feedback I got from my 6= man presentation in Atlanta.

More inline:

On Tue, Feb 26, 2013 at 6:54 AM, Brian E Carpenter <bria= n.e.carpenter@gmail.com> wrote:
Looking again at this draft after some time,= I think it lacks some
explanation of the scenario.

In particular:

> =A0 =A0It should be noted that the proposed options in this document w= ill
> =A0 =A0need a central site-wide configuration mechanism. =A0The requir= ed
> =A0 =A0values can not automatically be derived from routing tables.
I had added this text based on your comments.
=A0<= br>
What site is that? A mobile MIF node might find itself receiving RAs from two completely different "sites" simultaneously, which are comple= tely
uncoordinated.

Appreciate if you could provide some text?

Reg= ards,

Behcet
Regards
=A0 =A0Brian
_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

--bcaec554d95215674f04d6a38703-- From Ted.Lemon@nominum.com Tue Feb 26 15:15:06 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D837521F85D6 for ; Tue, 26 Feb 2013 15:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecRf7qKBuhAg for ; Tue, 26 Feb 2013 15:15:06 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id C757021F859B for ; Tue, 26 Feb 2013 15:15:05 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUS1B+TO5uk0LfhbCxh07jK6Sk7OXFuKY@postini.com; Tue, 26 Feb 2013 15:15:05 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 69049F8009 for ; Tue, 26 Feb 2013 15:15:05 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5D095190043; Tue, 26 Feb 2013 15:15:05 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 15:15:05 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] I-D Action: draft-sarikaya-mif-6man-ra-route-02.txt Thread-Index: AQHOFCBx3spooikmZki/p+nbiwoU8piMxfcd Date: Tue, 26 Feb 2013 23:15:04 +0000 Message-ID: <5FD3D4C6-0A91-4570-93D1-E7B26B644F92@nominum.com> References: <20130225201655.26126.95321.idtracker@ietfa.amsl.com>, <512CB090.8070403@gmail.com> In-Reply-To: <512CB090.8070403@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] I-D Action: draft-sarikaya-mif-6man-ra-route-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 23:15:07 -0000 On Feb 26, 2013, at 7:54 AM, "Brian E Carpenter" wrote: > What site is that? A mobile MIF node might find itself receiving RAs from > two completely different "sites" simultaneously, which are completely > uncoordinated. I think there are two models for MIF that people have, both of which are va= lid, but which are incompatible with each other. The first model is wher= e an interface is connected to something like a corporate network, over a V= PN. This connection is trusted because it has been authenticated. Routes= promulgated over such a connection can probably be trusted, and indeed it = may be important to use those routes and not just happy-eyeballs your way t= o the host you're trying to reach, because in the VPN case, you may also be= connected to a network that's offered you a default route, and you could b= e attacked over that connection if you attempt to connect to resources on t= he enterprise network over it. In the other scenario, none of the networks to which you are connected are = meaningfully more or less trustworthy, and in that scenario the "try everyt= hing" model of happy eyeballs is most likely to succeed in getting you conn= ected to the host that you are trying to reach; concerns about leaking info= rmation about the nodes you are contacting are less serious, because no mat= ter how you connect to those nodes, you are leaking that information to _so= meone_. So in the former case, Behcet's draft makes sense; in the latter case, it's= harmful. The trick is making it work in the case where it's desirable,= but preventing it working in the case where it's not. = From brian.e.carpenter@gmail.com Wed Feb 27 00:04:51 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8C21F84D3 for ; Wed, 27 Feb 2013 00:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.936 X-Spam-Level: X-Spam-Status: No, score=-100.936 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGdJIwwvGm6t for ; Wed, 27 Feb 2013 00:04:50 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 570B721F84CE for ; Wed, 27 Feb 2013 00:04:50 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id hm14so273992wib.16 for ; Wed, 27 Feb 2013 00:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Xupwo28uJhzO9RbxBYZnSGpujSuxbNCz64U61faGDAE=; b=ETIr9p4OglXDwcVDClmXfSJDt7p//ID19LFDSoKv9w+6SYLoISap/P1jzedTt0ALHw 48iSnFHBviGWoKDIyx2OAJnnRzE9hf3W4e0D4NfrqOHl80IAQ5h9W1+BUBZ5etJARu/k 75U4RqDWQwy2uiD8/Oax1/On2CzdJKXl0+aTzcT98s8UHP9w7YPTFTGJ7txa7vYQzRss jR6kaaQBifDfkFy+XDKPZGXxtHwABC930cmzIM1suFLkWRVtR/4BP7+xB7Q2NCKh8J4f U4/Vnick3krDReeVdctLXLkxmqod2rdxvPsU+4BGFm4qPC8rMatLcB/MjUdS2BSBXKCn b2cA== X-Received: by 10.194.77.129 with SMTP id s1mr2056113wjw.17.1361952289594; Wed, 27 Feb 2013 00:04:49 -0800 (PST) Received: from [192.168.1.65] (host-2-101-189-70.as13285.net. [2.101.189.70]) by mx.google.com with ESMTPS id m6sm6965653wic.2.2013.02.27.00.04.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 00:04:48 -0800 (PST) Message-ID: <512DBE27.3040804@gmail.com> Date: Wed, 27 Feb 2013 08:04:55 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <20130225201655.26126.95321.idtracker@ietfa.amsl.com>, <512CB090.8070403@gmail.com> <5FD3D4C6-0A91-4570-93D1-E7B26B644F92@nominum.com> In-Reply-To: <5FD3D4C6-0A91-4570-93D1-E7B26B644F92@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] I-D Action: draft-sarikaya-mif-6man-ra-route-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 08:04:51 -0000 On 26/02/2013 23:15, Ted Lemon wrote: > On Feb 26, 2013, at 7:54 AM, "Brian E Carpenter" wrote: >> What site is that? A mobile MIF node might find itself receiving RAs from >> two completely different "sites" simultaneously, which are completely >> uncoordinated. > > I think there are two models for MIF that people have, both of which are valid, but which are incompatible with each other. The first model is where an interface is connected to something like a corporate network, over a VPN. This connection is trusted because it has been authenticated. Routes promulgated over such a connection can probably be trusted, and indeed it may be important to use those routes and not just happy-eyeballs your way to the host you're trying to reach, because in the VPN case, you may also be connected to a network that's offered you a default route, and you could be attacked over that connection if you attempt to connect to resources on the enterprise network over it. > > In the other scenario, none of the networks to which you are connected are meaningfully more or less trustworthy, and in that scenario the "try everything" model of happy eyeballs is most likely to succeed in getting you connected to the host that you are trying to reach; concerns about leaking information about the nodes you are contacting are less serious, because no matter how you connect to those nodes, you are leaking that information to _someone_. > > So in the former case, Behcet's draft makes sense; in the latter case, it's harmful. The trick is making it work in the case where it's desirable, but preventing it working in the case where it's not. Yes, I think that is what I was worried about. Behcet - I haven't got exact words to suggest to you, but I think you need to add this analysis to the draft. I would add that a non-trustworthy network may be available at the same time as a trustworthy network, with the risk of bad consequences if the host gets confused between the two. Imagine that the untrustworthy network hands out routes that will capture traffic intended for the corporate VPN. In my experience, corporate VPNs install long lists of explicit routes in the host; your solution would replace this with routes from RAs, so they really need to be authenticated. Brian From ivo.sedlacek@ericsson.com Wed Feb 27 05:53:01 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2060B21F86C2 for ; Wed, 27 Feb 2013 05:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdyC9+dP2ZU8 for ; Wed, 27 Feb 2013 05:52:57 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20B21F86BE for ; Wed, 27 Feb 2013 05:52:54 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-ee-512e0fb58727 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B6.C2.32353.5BF0E215; Wed, 27 Feb 2013 14:52:53 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 14:52:53 +0100 From: Ivo Sedlacek To: Alexandru Petrescu Thread-Topic: [mif] Advancement of draft-ietf-mif-dhcpv6-route-option? Thread-Index: AQHOBVrFtY8bdcMxfUqLfUqE/j8XV5iN1Sfg Date: Wed, 27 Feb 2013 13:52:52 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610109DDAF@ESESSMB301.ericsson.se> References: <510EB247.6050906@gmail.com> <39B5E4D390E9BD4890E2B310790061010830DD@ESESSMB301.ericsson.se> <5113E7F4.5080405@gmail.com> In-Reply-To: <5113E7F4.5080405@gmail.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje5Wfr1Ag+lzdSxmvvvBatG15waT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx4t9m5oJnwhVfnzUyNTA2CnQxcnJICJhI bJ4xjw3CFpO4cG89kM3FISRwiFHi97MTjBDOEkaJx9O3s4BUsQnoSUzccoQVxBYRMJXYs/Ux WDczUPeLlplAcQ4OYQFXiQvtsRAlbhJ/lj5mhLCNJE5dWswEYrMIqEqc6bkGFucV8Jb4d2I+ E8SuTkaJq//mg+3iFNCU+Px9NzuIzSggK3H1Ty8jxC5xiVtP5jNBXC0gsWTPeWYIW1Ti5eN/ rBC2osTOs+3MEPV6EjemToG6U1ti2cLXzBCLBSVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZV jOy5iZk56eXmmxiBUXJwy2+DHYyb7osdYpTmYFES5w13vRAgJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgXHanVnxxezv1hg01p18qOLB7Pbm6Y4pJX2tpTOP7kpMYVxrb/vpMHO2pd7ckDSX 2OrK81OUArVNWe/ekDH9OOMg3+snIspckkVGB9ofKUoxyD6e9CZnWpTMrT9vt2X7WJbPjfBj /35CqiulLTDtRUH6x6/77rrf99JuWmxTUcWypEDNu+SfkhJLcUaioRZzUXEiAIwJqdBgAgAA Cc: mif Subject: Re: [mif] Advancement of draft-ietf-mif-dhcpv6-route-option? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:53:04 -0000 Hello, I do not have a preference on a solution.=20 However, I noticed that section 7.1 states: ---------------------------- Metric field (available in previous version of this draft) has been replaced with 2-bit preference field that is in line with RIO information. ---------------------------- If so, it would be sufficient for me to remove any text referring to the Me= tric. Sorry for later answer. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: 7. =FAnora 2013 18:44 To: Ivo Sedlacek Cc: mif Subject: Re: [mif] Advancement of draft-ietf-mif-dhcpv6-route-option? Ivo, If I understand correctly, in that email you point to an incoherency about = the 'Metric' field. You name them Issue1 and Issue2. Issue1 suggests ther= e may be some obsolete text in the draft, whereas Issue2 points to the abse= nce of Metric field in a figure whose text talks Metric. I also consider these two to be issues. I opened a ticket about it. But. Do you think other resolution about this Metric should be suggested? How would you like to see these Metric issues fixed? Thanks for pointing to this issue. Alex Le 07/02/2013 16:30, Ivo Sedlacek a =E9crit : > Hello, > > can you please also correct the errors identified in the attached=20 > mail? > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on=20 > the basis of the terms set out at www.ericsson.com/email_disclaimer > > > -----Original Message----- From: mif-bounces@ietf.org=20 > [mailto:mif-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > 3. =FAnora 2013 19:54 To: mif Subject: [mif] Advancement of=20 > draft-ietf-mif-dhcpv6-route-option? > > Hello, > > I wonder what is the advancement direction about of=20 > draft-ietf-mif-dhcpv6-route-option. > > I remember an advantageous voting procedure in Atlanta, and I hoped to=20 > see confirmation on the email list if necessary. > > That voting and its confirmation could help close many of the raised=20 > issues, right? > > Tickets are at: http://trac.tools.ietf.org/wg/mif/trac/report/1 > > Regards, > > Alex _______________________________________________ mif mailing list=20 > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From sarikaya2012@gmail.com Wed Feb 27 13:23:07 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEC021F861C for ; Wed, 27 Feb 2013 13:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U0enTcRk9Gg for ; Wed, 27 Feb 2013 13:23:06 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 656CF21F8546 for ; Wed, 27 Feb 2013 13:23:06 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id fq12so1078025lab.33 for ; Wed, 27 Feb 2013 13:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fLk+SBfttTWy9eZohNyAt5tbxrTTjwRCRbevM8GOx1c=; b=pxGqXLM5GyaZO7XCKdx3tsNL02LIsZ+VD/g/B3Ymczm+GnS9Cx48OZgKX8BPZh7Bnb UJrYtX9Ja+iC5SsRb2yIbtUCREjLaTJapygpXGrkPyeNo7KE4vXT8/fMXyAClQj41aNW PphcydMoav4dO5cmQRJlUODhpsmD249zxH4M88lCzhWPrNYQJwXo7Qg5I0bbzUW68Wzi CCYqVpNPIeb89Gj5eGLskWhfHKx8WzKe00JM/5xF/au1VsPyJ0xt7s9W86WCmFfftKW1 RcEIHOHXKHMoIPJQAgkbbkUNl7e0k0RGcW/ATzyFkx6vLWz5RMAJvrNMAAuQ623a3yn3 wVWg== MIME-Version: 1.0 X-Received: by 10.152.122.100 with SMTP id lr4mr3364956lab.28.1362000185210; Wed, 27 Feb 2013 13:23:05 -0800 (PST) Received: by 10.114.28.168 with HTTP; Wed, 27 Feb 2013 13:23:05 -0800 (PST) In-Reply-To: <512DBE27.3040804@gmail.com> References: <20130225201655.26126.95321.idtracker@ietfa.amsl.com> <512CB090.8070403@gmail.com> <5FD3D4C6-0A91-4570-93D1-E7B26B644F92@nominum.com> <512DBE27.3040804@gmail.com> Date: Wed, 27 Feb 2013 15:23:05 -0600 Message-ID: From: Behcet Sarikaya To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d042ef661393b1a04d6bb610d Cc: "mif@ietf.org" Subject: Re: [mif] I-D Action: draft-sarikaya-mif-6man-ra-route-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 21:23:07 -0000 --f46d042ef661393b1a04d6bb610d Content-Type: text/plain; charset=ISO-8859-1 Ted, Brian, Thanks, will do and issue Rev. 03 as soon as the contributions are allowed. Regards, Behcet On Wed, Feb 27, 2013 at 2:04 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 26/02/2013 23:15, Ted Lemon wrote: > > On Feb 26, 2013, at 7:54 AM, "Brian E Carpenter" < > brian.e.carpenter@gmail.com> wrote: > >> What site is that? A mobile MIF node might find itself receiving RAs > from > >> two completely different "sites" simultaneously, which are completely > >> uncoordinated. > > > > I think there are two models for MIF that people have, both of which are > valid, but which are incompatible with each other. The first model is > where an interface is connected to something like a corporate network, over > a VPN. This connection is trusted because it has been authenticated. > Routes promulgated over such a connection can probably be trusted, and > indeed it may be important to use those routes and not just happy-eyeballs > your way to the host you're trying to reach, because in the VPN case, you > may also be connected to a network that's offered you a default route, and > you could be attacked over that connection if you attempt to connect to > resources on the enterprise network over it. > > > > In the other scenario, none of the networks to which you are connected > are meaningfully more or less trustworthy, and in that scenario the "try > everything" model of happy eyeballs is most likely to succeed in getting > you connected to the host that you are trying to reach; concerns about > leaking information about the nodes you are contacting are less serious, > because no matter how you connect to those nodes, you are leaking that > information to _someone_. > > > > So in the former case, Behcet's draft makes sense; in the latter case, > it's harmful. The trick is making it work in the case where it's > desirable, but preventing it working in the case where it's not. > > Yes, I think that is what I was worried about. > > Behcet - I haven't got exact words to suggest to you, but I think you need > to > add this analysis to the draft. I would add that a non-trustworthy network > may > be available at the same time as a trustworthy network, with the risk of > bad consequences if the host gets confused between the two. Imagine that > the > untrustworthy network hands out routes that will capture traffic intended > for the corporate VPN. > > In my experience, corporate VPNs install long lists of explicit routes in > the host; your solution would replace this with routes from RAs, so > they really need to be authenticated. > > Brian > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --f46d042ef661393b1a04d6bb610d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted, Brian,

Thanks, will do and issue Rev. 03 as soon as the contrib= utions are allowed.

Regards,

Behcet

On Wed, Feb 27, 2013 at 2:04 AM, Brian E Carpenter <bri= an.e.carpenter@gmail.com> wrote:
On 2= 6/02/2013 23:15, Ted Lemon wrote:
> On Feb 26, 2013, at 7:54 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>= wrote:
>> What site is that? A mobile MIF node might find itself receiving R= As from
>> two completely different "sites" simultaneously, which a= re completely
>> uncoordinated.
>
> I think there are two models for MIF that people have, both of which a= re valid, but which are incompatible with each other. =A0 =A0The first mode= l is where an interface is connected to something like a corporate network,= over a VPN. =A0 This connection is trusted because it has been authenticat= ed. =A0Routes promulgated over such a connection can probably be trusted, a= nd indeed it may be important to use those routes and not just happy-eyebal= ls your way to the host you're trying to reach, because in the VPN case= , you may also be connected to a network that's offered you a default r= oute, and you could be attacked over that connection if you attempt to conn= ect to resources on the enterprise network over it.
>
> In the other scenario, none of the networks to which you are connected= are meaningfully more or less trustworthy, and in that scenario the "= try everything" model of happy eyeballs is most likely to succeed in g= etting you connected to the host that you are trying to reach; concerns abo= ut leaking information about the nodes you are contacting are less serious,= because no matter how you connect to those nodes, you are leaking that inf= ormation to _someone_.
>
> So in the former case, Behcet's draft makes sense; in the latter c= ase, it's harmful. =A0 =A0 The trick is making it work in the case wher= e it's desirable, but preventing it working in the case where it's = not.

Yes, I think that is what I was worried about.

Behcet - I haven't got exact words to suggest to you, but I think you n= eed to
add this analysis to the draft. I would add that a non-trustworthy network = may
be available at the same time as a trustworthy network, with the risk of bad consequences if the host gets confused between the two. Imagine that th= e
untrustworthy network hands out routes that will capture traffic intended for the corporate VPN.

In my experience, corporate VPNs install long lists of explicit routes in the host; your solution would replace this with routes from RAs, so
they really need to be authenticated.

=A0 =A0 Brian
_____________________= __________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

--f46d042ef661393b1a04d6bb610d-- From phdgang@gmail.com Wed Feb 27 20:04:31 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0C721F8A67 for ; Wed, 27 Feb 2013 20:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOnOtIfTKEPu for ; Wed, 27 Feb 2013 20:04:30 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1F521F89E5 for ; Wed, 27 Feb 2013 20:04:27 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id g10so3945859qah.11 for ; Wed, 27 Feb 2013 20:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=BGFIPL9OPovGe6HAApJaJzXt92YTYv5+LLSZ8QPkgZM=; b=jJz+BYegbKQ+/iJybp8lPQvRakpnsU9OJnt+WYhqRlebD86BNu/ssEKrquf3WRhxUL camrSkDprIBOAGhBTFdL9ZayhiptUtS8LRc1SOU9rij0ph2XcZE6ppji5/FSZDCxo1zM XRaPEP9Df3+DB9GuQNZt1jC7jTxqNkHMobecsuyAXK1C06Y1JqLStLcn1DQrwp5DJTzj tSa4ZzDp6C9EBu7N47Jf0LCgw2jhVbsHSl+KL0wSPfNp+03iD73twzRJY6JVf7x2evOt tt5sQBVa1UZhqO8OlJdLLobm9cM0iNAMekophFssiIIXbBCXIaYxEIAe1hvBdGRbiPDX FV9g== MIME-Version: 1.0 X-Received: by 10.229.179.23 with SMTP id bo23mr1697382qcb.104.1362024266973; Wed, 27 Feb 2013 20:04:26 -0800 (PST) Received: by 10.49.71.18 with HTTP; Wed, 27 Feb 2013 20:04:26 -0800 (PST) In-Reply-To: <20130225150939.18370.73595.idtracker@ietfa.amsl.com> References: <20130225150939.18370.73595.idtracker@ietfa.amsl.com> Date: Thu, 28 Feb 2013 12:04:26 +0800 Message-ID: From: GangChen To: mif Content-Type: text/plain; charset=ISO-8859-1 Subject: [mif] I-D Action: draft-ietf-mif-happy-eyeballs-extension-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 04:04:31 -0000 Hello all, We have posted a new draft trying to address the discussions of DNS selections with HE-MIF The updates includes: 1) add NCSI implementation of Microsoft and apple description into the sort process(see section 4.2) 2) add a separated section 6.3 to discuss the relation of HE-MIF with DNS selections Your review and futher comments are welcome. Best Regards Gang 2013/2/25, internet-drafts@ietf.org : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiple Interfaces Working Group of the > IETF. > > Title : Happy Eyeballs Extension for Multiple Interfaces > Author(s) : Gang Chen > Carl Williams > Dan Wing > Andrew Yourtchenko > Filename : draft-ietf-mif-happy-eyeballs-extension-02.txt > Pages : 12 > Date : 2013-02-25 > > Abstract: > Currently the interface selection in multi-interface environment is > exclusive - only one interface can be used at the time, frequently > needing manual intervention. Happy Eyeballs in MIF would make the > selection process smoother by using the connectivity checks over a > pre-filtered interfaces according to defined policy. This would > choose "best" interface with an automatic fallback. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-happy-eyeballs-extension-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >