From phdgang@gmail.com Wed Mar 9 05:41:22 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376253A6855 for ; Wed, 9 Mar 2011 05:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZWs+Gq5xYLu for ; Wed, 9 Mar 2011 05:41:21 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 1D5183A69D3 for ; Wed, 9 Mar 2011 05:41:20 -0800 (PST) Received: by bwz13 with SMTP id 13so747029bwz.31 for ; Wed, 09 Mar 2011 05:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=xOFeIYpa/PnP6SjuiYiH/F9i9gMf0kb1vb07qN0qtIU=; b=oqXRfDUMZ7xrYtWwUbufrLOMHSwqXzKJqlzdy4dfEcR1sRF9SCXtB9P9FMF1Ls/1MV ccHUH6K25jTD/aTtLa9xZ7cmPKWy+ebh2YHXdPn8OechrYPD4E7wAKX4tBxWiqXF7scH yDOWxHWTzg9LiAVeakcP9foIUf6r8zu+G0EsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tVPyVUrC6gv5fndfljce/AbPZNT6rcICvE9SeLjeeY9yUxv1ekWqFD7BTAEOu4MBZk eXlj703dXbqk0hH8hsX+jN3lOuT5vSzQqCkz7Qu/TDZJ23ksdR41+e//EhCgYPiMKa9b 4BX2JZVJmU6+J56e3KvYR+ky/90tr1UXWWfTs= MIME-Version: 1.0 Received: by 10.204.74.152 with SMTP id u24mr5597937bkj.91.1299678156567; Wed, 09 Mar 2011 05:42:36 -0800 (PST) Received: by 10.204.53.81 with HTTP; Wed, 9 Mar 2011 05:42:36 -0800 (PST) Date: Wed, 9 Mar 2011 21:42:36 +0800 Message-ID: From: GangChen To: mif Content-Type: text/plain; charset=ISO-8859-1 Subject: [mif] Happy Eyeballs Extension for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 13:41:22 -0000 Hello all, A New Internet-Draft is available. Title : Happy Eyeballs Extension for Multiple Interfaces Author(s) : G. Chen Filename : draft-chen-mif-happy-eyeballs-extension-00.txt Pages : 6 Date : 2011-03-07 The memo has been proposed to extend happy eyeballs algorithm to fit into multiple interfaces environment. Based on this extended heuristic algorithm, a client with multiple interface could determine the optimal flow path in which specific interface has been chosen. Furthermore, an appropriate IP address family for each interface can be also identified to guarantee user experiences during IPv6 transition period. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-mif-happy-eyeballs-extension-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Please kindly review it. Comments are welcome. BRs Gang From Internet-Drafts@ietf.org Fri Mar 11 02:30:04 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E623A687F; Fri, 11 Mar 2011 02:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TeMznXCDWpL; Fri, 11 Mar 2011 02:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333643A687E; Fri, 11 Mar 2011 02:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110311103002.23659.51941.idtracker@localhost> Date: Fri, 11 Mar 2011 02:30:02 -0800 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-dns-server-selection-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 10:30:04 -0000 --NextPart 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 : Improved DNS Server Selection for Multi-Homed Nodes Author(s) : T. Savolainen, J. Kato Filename : draft-ietf-mif-dns-server-selection-01.txt Pages : 21 Date : 2011-03-11 A multi-homed node can be connected to multiple networks that may utilize different DNS namespaces. The node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When the multi-homed node needs to utilize DNS, it has to choose which of the servers to contact to. This document describes a policy based method for helping on selection of DNS server, for both forward and reverse DNS lookup procedures, with help of DNS suffix and IPv6 prefix information received via DHCPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mif-dns-server-selection-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-11022336.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Fri Mar 11 06:30:03 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2923A6C00; Fri, 11 Mar 2011 06:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFmJ38CFPrty; Fri, 11 Mar 2011 06:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A543A6B70; Fri, 11 Mar 2011 06:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110311143001.18437.92543.idtracker@localhost> Date: Fri, 11 Mar 2011 06:30:01 -0800 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-problem-statement-10.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 14:30:03 -0000 --NextPart 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 : Multiple Interfaces and Provisioning Domains Problem Statement Author(s) : M. Blanchet, P. Seite Filename : draft-ietf-mif-problem-statement-10.txt Pages : 20 Date : 2011-03-11 This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains where some configuration objects are global to the node, others are local to the interface. Issues such as selecting the wrong interface to send trafic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simulatenous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses single interface nodes situation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mif-problem-statement-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-11061850.I-D@ietf.org> --NextPart-- From pierrick.seite@orange-ftgroup.com Mon Mar 14 02:00:48 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB683A6C3E for ; Mon, 14 Mar 2011 02:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klV08uv4Dvj6 for ; Mon, 14 Mar 2011 02:00:47 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 557723A68E9 for ; Mon, 14 Mar 2011 02:00:47 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C63358B8084 for ; Mon, 14 Mar 2011 09:59:00 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 0DF608B8002 for ; Mon, 14 Mar 2011 09:55:10 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 09:53:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 09:53:10 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462018C5F76@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <20110311143001.18437.92543.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-mif-problem-statement-10.txt Thread-Index: Acvf+RsawXmiVKl9T3KeuY+jRbSEHgCKqfQg References: <20110311143001.18437.92543.idtracker@localhost> From: To: X-OriginalArrivalTime: 14 Mar 2011 08:53:11.0164 (UTC) FILETIME=[3F2AFBC0:01CBE225] Subject: Re: [mif] I-D Action:draft-ietf-mif-problem-statement-10.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 09:00:48 -0000 Hi all, Problem statement has been updated with session management issues, as = discussed during IETF79 (e.g. problems with on-going sessions). Pierrick =20 > -----Message d'origine----- > De=A0: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] > De la part de Internet-Drafts@ietf.org > Envoy=E9=A0: vendredi 11 mars 2011 15:30 > =C0=A0: i-d-announce@ietf.org > Cc=A0: mif@ietf.org > Objet=A0: I-D Action:draft-ietf-mif-problem-statement-10.txt >=20 > 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. >=20 >=20 > Title : Multiple Interfaces and Provisioning Domains > Problem Statement > Author(s) : M. Blanchet, P. Seite > Filename : draft-ietf-mif-problem-statement-10.txt > Pages : 20 > Date : 2011-03-11 >=20 > This document describes issues encountered by a node attached to > multiple provisioning domains. This node receives configuration > information from each of its provisioning domains where some > configuration objects are global to the node, others are local to the > interface. Issues such as selecting the wrong interface to send > trafic happen when conflicting node-scoped configuration objects are > received and inappropriately used. Moreover, other issues are the > result of simulatenous attachment to multiple networks, such as > domain selection or addressing and naming space overlaps, regardless > of the provisioning mechanism. While multiple provisioning domains > are typically seen on nodes with multiple interfaces, this document > also discusses single interface nodes situation. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement- > 10.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From Internet-Drafts@ietf.org Mon Mar 14 05:30:02 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2013A6A68; Mon, 14 Mar 2011 05:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2hEYzGVaINv; Mon, 14 Mar 2011 05:30:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C087D3A69C1; Mon, 14 Mar 2011 05:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314123001.26276.76048.idtracker@localhost> Date: Mon, 14 Mar 2011 05:30:01 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-dhcpv6-route-option-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 12:30:02 -0000 --NextPart 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 : DHCPv6 Route Option Author(s) : W. Dec, et al. Filename : draft-ietf-mif-dhcpv6-route-option-01.txt Pages : 11 Date : 2011-03-14 This document describes DHCPv6 Route Options for provisioning IPv6 routes on DHCPv6 client nodes. This is expected to improve the ability of an operator to configure and influence a nodes' ability to pick an appropriate route to a destination when this node is multi- homed and where other means of route configuration may be impractical. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-dhcpv6-route-option-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mif-dhcpv6-route-option-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14051741.I-D@ietf.org> --NextPart-- From teemu.savolainen@nokia.com Mon Mar 14 06:21:38 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6BD3A6D48 for ; Mon, 14 Mar 2011 06:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukXMCUB9xmSV for ; Mon, 14 Mar 2011 06:21:35 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 0FD943A6D44 for ; Mon, 14 Mar 2011 06:21:34 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2EDMuAS013378 for ; Mon, 14 Mar 2011 15:22:57 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 15:22:02 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 14 Mar 2011 14:21:58 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.61]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Mon, 14 Mar 2011 14:21:58 +0100 From: To: Thread-Topic: [mif] I-D Action:draft-ietf-mif-dns-server-selection-01.txt Thread-Index: AQHL39e5HX1W79JP8US7Fh4gLKyqy5Qs1Mqw Date: Mon, 14 Mar 2011 13:21:57 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3193C90A1@008-AM1MPN1-015.mgdnok.nokia.com> References: <20110311103002.23659.51941.idtracker@localhost> In-Reply-To: <20110311103002.23659.51941.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Mar 2011 13:22:02.0671 (UTC) FILETIME=[CE4B9BF0:01CBE24A] X-Nokia-AV: Clean Subject: Re: [mif] I-D Action:draft-ietf-mif-dns-server-selection-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:21:38 -0000 Hi, As you can see, a new revision is out. This revision contains a clean-up pass and also: - Clarification of deployment scenarios - Interaction with OPTION_DOMAIN_LIST - CNAME/DNAME record considerations - More DNSSEC considerations here and there - Conflict resolution improvements if same DNS server address is received m= ultiple times but with different suffix/prefix list - Valid lifetime consideration (using DHCPv6 Information Refresh Time Optio= n) Comments welcome. Best regards, Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext > Internet-Drafts@ietf.org > Sent: 11. maaliskuuta 2011 12:30 > To: i-d-announce@ietf.org > Cc: mif@ietf.org > Subject: [mif] I-D Action:draft-ietf-mif-dns-server-selection-01.txt >=20 > 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. >=20 >=20 > Title : Improved DNS Server Selection for Multi-Homed Nodes > Author(s) : T. Savolainen, J. Kato > Filename : draft-ietf-mif-dns-server-selection-01.txt > Pages : 21 > Date : 2011-03-11 >=20 > A multi-homed node can be connected to multiple networks that may utilize > different DNS namespaces. The node commonly receives DNS server configur= ation > information from all connected networks. Some of the DNS servers may hav= e > information about namespaces other servers do not have. When the multi-h= omed > node needs to utilize DNS, it has to choose which of the servers to conta= ct > to. This document describes a policy based method for helping on selecti= on of > DNS server, for both forward and reverse DNS lookup procedures, with help= of > DNS suffix and IPv6 prefix information received via DHCPv6. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-0= 1.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. From scott.brim@gmail.com Mon Mar 14 08:06:52 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235B23A6DB5 for ; Mon, 14 Mar 2011 08:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRSO8ZuCXhj3 for ; Mon, 14 Mar 2011 08:06:51 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 1442B3A6D09 for ; Mon, 14 Mar 2011 08:06:50 -0700 (PDT) Received: by gwb20 with SMTP id 20so2420802gwb.31 for ; Mon, 14 Mar 2011 08:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GmF7xibJ5vg7ulvlpZlKfo6i3FpCQsyquB3bRU1FRHM=; b=KZXfOo0QTh7fI+fQPmEj4zCmQWX91vurtZ5Z18S36+vig//U5JjoYaRaakiHfZ/3jf dgPgtYdPzXM7ns7sqfh657RKed/fg0yF2oDyfm7jHcZrJa1x83Fv2Vd/rnAsvVJ1RFCc nYftQG1uNyGQXF9zc4R9Qd8YrM34Q/Qp6Ktbo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=keUAy44RPxU/+YLHsZS4m6dytLilROcoVMLtxqrEuukgPllk9//3RGw2oq70tXoK5m 6HAMYIi1nE0HfR6Ar8MsnIfQwqNiaJyEjgOM7hFidgQ9cJzTQoew8sKM/K4sev/Ak6AL shtEyS/1c3YO5StIeLB4eSPIw0RxAlIMNl50s= Received: by 10.42.177.134 with SMTP id bi6mr2543491icb.368.1300115287842; Mon, 14 Mar 2011 08:08:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.114.81 with HTTP; Mon, 14 Mar 2011 08:07:45 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462018C5F76@ftrdmel0.rd.francetelecom.fr> References: <20110311143001.18437.92543.idtracker@localhost> <843DA8228A1BA74CA31FB4E111A5C462018C5F76@ftrdmel0.rd.francetelecom.fr> From: Scott W Brim Date: Mon, 14 Mar 2011 11:07:45 -0400 Message-ID: To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] I-D Action:draft-ietf-mif-problem-statement-10.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:06:52 -0000 On Mon, Mar 14, 2011 at 04:53, wrote: > Problem statement has been updated with session management issues, as discussed during IETF79 (e.g. problems with on-going sessions). A good start on session management. There are a few things I would change for next time: * terminology inconsistencies ("session" and "connection", "logical" and "virtual") * Session management is independent of address selection, and can deal with the multi-interface problem at one or more of several stack layers. * I would add more use case references, not just MIP/PMIP/Shim6. * I would add something about APIs. But we can do all of that later. This is pretty good for now. ... Scott From pierrick.seite@orange-ftgroup.com Mon Mar 14 10:58:38 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9523A6D80 for ; Mon, 14 Mar 2011 10:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZG6RrWpRIHN for ; Mon, 14 Mar 2011 10:58:37 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 899C03A6A3A for ; Mon, 14 Mar 2011 10:58:37 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0EB266F8002; Mon, 14 Mar 2011 19:00:33 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 04A726F8001; Mon, 14 Mar 2011 19:00:33 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 19:00:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 18:59:58 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620190B44F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] I-D Action:draft-ietf-mif-problem-statement-10.txt Thread-Index: AcviWaee0IzuJFS1S7uULWpfD+YaBgAE0Dyg References: <20110311143001.18437.92543.idtracker@localhost> <843DA8228A1BA74CA31FB4E111A5C462018C5F76@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 14 Mar 2011 18:00:00.0317 (UTC) FILETIME=[A2F26ED0:01CBE271] Cc: mif@ietf.org Subject: Re: [mif] I-D Action:draft-ietf-mif-problem-statement-10.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:58:39 -0000 Hi Scott, Thanks for comments. Please see inline for answers. Pierrick > -----Message d'origine----- > De=A0: Scott W Brim [mailto:scott.brim@gmail.com] > Envoy=E9=A0: lundi 14 mars 2011 16:08 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: mif@ietf.org > Objet=A0: Re: [mif] I-D Action:draft-ietf-mif-problem-statement-10.txt >=20 > On Mon, Mar 14, 2011 at 04:53, = wrote: > > Problem statement has been updated with session management issues, = as > discussed during IETF79 (e.g. problems with on-going sessions). >=20 > A good start on session management. There are a few things I would > change for next time: >=20 > * terminology inconsistencies ("session" and "connection", "logical" > and "virtual") >=20 In Beijing we said that connection manager was a poor name and that = session manager would be better. However, "connection manager" is = well-known in the mobile world. So, I could agree to use only "session = manager", but saying somewhere in the document that session manager is = sometimes called connection manager. Is it ok for the WG? I agree regarding inconsistency between virtual and logical. If no = opposition, the next version will use only "Virtual". > * Session management is independent of address selection, and can deal > with the multi-interface problem at one or more of several stack > layers. >=20 You're right, session management comes into play at different layers; = and my understanding is that address selection is a part of session = management. Am I missing something? =20 > * I would add more use case references, not just MIP/PMIP/Shim6. >=20 Ok, feel free to propose other use-cases. Anyway, we don't need to be = exhaustive, it's just examples. Note that we have also MPTCP. > * I would add something about APIs. >=20 Considering current text on session management, we could stress that, in = order to resolve the MIF issues, specific extensions to current socket = API should be defined. These extensions would aim to provide = information, or control services, to applications/session manager. Then = we should refer to the MIF API draft. Is it ok, or do you see specific = issues with API which should be described in the PS? > But we can do all of that later. This is pretty good for now. >=20 Thanks. > ... Scott From denghui02@gmail.com Tue Mar 15 17:50:31 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BF43A6BDB for ; Tue, 15 Mar 2011 17:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wefaoFNFJExM for ; Tue, 15 Mar 2011 17:50:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 54A753A6BA0 for ; Tue, 15 Mar 2011 17:50:30 -0700 (PDT) Received: by iyi12 with SMTP id 12so1352724iyi.31 for ; Tue, 15 Mar 2011 17:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=wMx4attPOir8OW8rMWAaAnudz0ZfwJJtFfRpSde/pPw=; b=MqSI0exrODCKfOhYvdNG1gqzNX+2vDLO18adWsS8zrHaexPltJUV3A8Q1CJwYI+bpZ R0tRgOJOX2h1Br0PS7b6eOiSb7D7WgEhUSdFZNI2949vm7FM90zadKHFKvXHYWsiyZ0t WaksI/Bx5EqevXdYL28IqzjFBrMpr8xKWuEAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mS6tDbD7fNYmGM+5T55Hrt3VXcvvTWa9k0uKO33X7jGlQVVGqI0qvC4Yk4jxbv4kDg Sw+Cap4HO0HBCLbEVQXqOKvGVSIjtYQi15Txe53SdCNH39sqQdqZ3YNJJXyffGXQvJ99 jNuR32iy4Bbx58b/aoAU0XyB5qutsiYG4NL8Y= MIME-Version: 1.0 Received: by 10.43.131.72 with SMTP id hp8mr61289icc.240.1300236715864; Tue, 15 Mar 2011 17:51:55 -0700 (PDT) Received: by 10.42.220.70 with HTTP; Tue, 15 Mar 2011 17:51:55 -0700 (PDT) Date: Wed, 16 Mar 2011 08:51:55 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman Content-Type: multipart/alternative; boundary=20cf307f367c92b13e049e8ef3ca Subject: [mif] MIF call for agenda X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 00:50:31 -0000 --20cf307f367c92b13e049e8ef3ca Content-Type: text/plain; charset=ISO-8859-1 Hello all Please send your request to chairs if you have something would like to present. thanks a lot -Hui --20cf307f367c92b13e049e8ef3ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Please send your request to chairs if you have something would like to= present.
=A0
thanks a lot
=A0
-Hui
--20cf307f367c92b13e049e8ef3ca-- From maxpassion@gmail.com Tue Mar 15 19:52:56 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60853A6BC8 for ; Tue, 15 Mar 2011 19:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2rpeH2qXQ9e for ; Tue, 15 Mar 2011 19:52:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id E01033A6C18 for ; Tue, 15 Mar 2011 19:52:55 -0700 (PDT) Received: by iyi12 with SMTP id 12so1443798iyi.31 for ; Tue, 15 Mar 2011 19:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JFs43Et4K0X+UzdLZzfMA6s25JPjbyQfg8QN9cBRscc=; b=ef9Sj/d+mriKBYOuRjmvO/4r5oSdM56JtiGK/VALqX2nI6mlJaI71s60HfFyHCqtHb NDUa4aSaNzeAdi2cMS1rdqljVfvz2yLK+Ze8lnXzdenzkdgF/D+7fK9zt+MhCrT/k86h xVbQy5/QF8VU2r+uPCL8p0+PIxyMME1NpjTu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GDWi1ecNsYf4nZ4NFHpN++oMsFzmijQAAh5vab+TMxDooPrKCsvQWvEiwBnLt7bopi jtszxfK6zO/hp74i66EEwff+xh57zzAq4Urst2bodvCe3pD4VAUQukYqJORNeluTy8+e Z4HauU31JwGexqwlp4F5rp8vsFKmCwPB+5gso= MIME-Version: 1.0 Received: by 10.43.57.200 with SMTP id wh8mr234550icb.29.1300244061359; Tue, 15 Mar 2011 19:54:21 -0700 (PDT) Received: by 10.42.240.7 with HTTP; Tue, 15 Mar 2011 19:54:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Mar 2011 10:54:21 +0800 Message-ID: From: liu dapeng To: Hui Deng , Margaret Wasserman Content-Type: text/plain; charset=ISO-8859-1 Cc: MIF Mailing List Subject: Re: [mif] MIF call for agenda X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 02:52:56 -0000 Dear Chairs, We'd like to present draft-liu-mif-api-extension-04 (https://datatracker.ietf.org/doc/draft-liu-mif-api-extension/), 10 minutes is enough. Thanks. Best regards, Dapeng Liu 2011/3/16, Hui Deng : > Hello all > > Please send your request to chairs if you have something would like to > present. > > thanks a lot > > -Hui > From denghui02@gmail.com Wed Mar 16 22:58:48 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD223A67AA for ; Wed, 16 Mar 2011 22:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sczGMy4dlxez for ; Wed, 16 Mar 2011 22:58:48 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 15A6B3A67A8 for ; Wed, 16 Mar 2011 22:58:48 -0700 (PDT) Received: by iyi12 with SMTP id 12so2896522iyi.31 for ; Wed, 16 Mar 2011 23:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=bcuy1VEDCtsiAyK/fPFExJHKHoofVW7Jt2dKehQgUbA=; b=vhaPT6hSgw1jKHfjN6fjtZbMbR/XjdeUM4DpgfQx7wGTnpo+hHW2wHIlDaQAsyd0/w d6MXMXkNkmwIrDPNGmgd+vKd/cy3UVwOO3+ZVtw3AahPjXEcDqgZEAGw6VQBTYXpdppC VK7/osU2rLA5ek0B7/1F3LhH0jgeIhW0XE7PY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bNILCOrK4v5vims1+ipHWkvlV/A+jhuXNskTn2IlRZcVUh5Ul3BoIuiauyyXXlQj5v L2uV+Q4m1s3SoPGN08y61lMhvd/U260g2as4nZrZYszoT4VUvq6KpbSBvNWafwgrPWae P2UyE/Ygx1tot89ZO8zgCKhzdkcuSPyXlWGbo= MIME-Version: 1.0 Received: by 10.42.147.9 with SMTP id l9mr1279464icv.476.1300341614618; Wed, 16 Mar 2011 23:00:14 -0700 (PDT) Received: by 10.42.224.71 with HTTP; Wed, 16 Mar 2011 23:00:14 -0700 (PDT) Date: Thu, 17 Mar 2011 14:00:14 +0800 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=90e6ba2121db06a8b7049ea76022 Subject: [mif] draft agenda MIF 80th X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 05:58:49 -0000 --90e6ba2121db06a8b7049ea76022 Content-Type: text/plain; charset=ISO-8859-1 Hello all Draft agenda, please review, http://tools.ietf.org/wg/mif/agenda?item=agenda80.html Thanks -Hui --90e6ba2121db06a8b7049ea76022 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Draft agenda, please review,
=A0
Thanks
=A0
-Hui
=A0
--90e6ba2121db06a8b7049ea76022-- From tomasz.mrugalski@gmail.com Thu Mar 17 02:14:18 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36893A6867 for ; Thu, 17 Mar 2011 02:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaNi4xYIVqNg for ; Thu, 17 Mar 2011 02:14:18 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E06323A67F4 for ; Thu, 17 Mar 2011 02:14:17 -0700 (PDT) Received: by wyb42 with SMTP id 42so2759898wyb.31 for ; Thu, 17 Mar 2011 02:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sSruLULGZbWejwyds4qTXJWbmuMxfYjlj6ZGhM6Ljq0=; b=hG/xWEmbGGs19QgzijY2Wmlssxs/c7YsOIzbxnB9b1n8elOputA+ZSXWxR5z2YNNTS hT4qq7I6jSda88yFFkqOqKUue10UfF1Sr8+CaYj3QJPl02bDDWJlHRjRtOV0rFha4uNe qUs2JOxy2lwa2TdZUMvE9/tseVYiPKsQKCj2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=gjrEqWQGQ4v/gcCmL6bfwpq9yV8Gwvv0unWiH/6jEmIn8rGfJHBPib3/Tu9780jHEb BqtMp8GpZb9uQHE6FhJSJJJghoWuJiIq8/j/nMrJPlxJb0bKPZXLvaIwELC0A5omLm7H RTJbnLMxwHcmS3l7r0jSyeoSqPaY/76LlKzWU= Received: by 10.227.140.77 with SMTP id h13mr1098068wbu.217.1300353344954; Thu, 17 Mar 2011 02:15:44 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl [109.107.11.157]) by mx.google.com with ESMTPS id h26sm519417wbc.8.2011.03.17.02.15.43 (version=SSLv3 cipher=OTHER); Thu, 17 Mar 2011 02:15:44 -0700 (PDT) Message-ID: <4D81D13F.2070209@gmail.com> Date: Thu, 17 Mar 2011 10:15:43 +0100 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: mif@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] draft agenda MIF 80th X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 09:14:19 -0000 On 17.03.2011 07:00, Hui Deng wrote: > Hello all > > Draft agenda, please review, > http://tools.ietf.org/wg/mif/agenda?item=agenda80.html The page says: "IETF-80 mif agenda Sorry, no agenda available as of today. Either no meeting was held, or the document has not yet been submitted." Tomek From denghui02@gmail.com Thu Mar 17 03:12:53 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451803A68D9 for ; Thu, 17 Mar 2011 03:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOr2+82M7BQe for ; Thu, 17 Mar 2011 03:12:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 78F6B3A6839 for ; Thu, 17 Mar 2011 03:12:52 -0700 (PDT) Received: by iyi12 with SMTP id 12so3121491iyi.31 for ; Thu, 17 Mar 2011 03:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uy+P39gz1cT9ChRSfvDEUKLrNv0h7gojO6tWB/9ZI4k=; b=vNBjhUvQZgxu+w/tg4QT+jsdk+KFp0LZMfgFuHbVA6s0MpUoGJG5WJOJhsWn4mE5ur +Zt+9Ynhyq4WMTjvDDwVDT3/C9A6hftVXerefrgR8iXnikOQWBXu93ZYqZDdZixvpyZR VVkpwT8uan9k1v5lenS2pSc454vimGkc21deI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rZMl0j25LtBoZreMLDB71/BwnEY0ZL04bpvjP4K7kIsxPkHGzP4rMJYnLNgRmWaMNl MnbYYph3+Rya3M0txr33t/+irRi8sxWejTJ2Vm7TSdPmMKiyFY4QqLDtgLN9uTU67Sk9 7AQWpbTWdwmE8q6nQnJnAqhkugdGDFi4jujHw= MIME-Version: 1.0 Received: by 10.42.221.196 with SMTP id id4mr1680510icb.141.1300356859942; Thu, 17 Mar 2011 03:14:19 -0700 (PDT) Received: by 10.42.224.71 with HTTP; Thu, 17 Mar 2011 03:14:19 -0700 (PDT) In-Reply-To: <4D81D13F.2070209@gmail.com> References: <4D81D13F.2070209@gmail.com> Date: Thu, 17 Mar 2011 18:14:19 +0800 Message-ID: From: Hui Deng To: Tomasz Mrugalski Content-Type: multipart/alternative; boundary=20cf305644d9b7d622049eaaec54 Cc: mif@ietf.org Subject: Re: [mif] draft agenda MIF 80th X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 10:12:53 -0000 --20cf305644d9b7d622049eaaec54 Content-Type: text/plain; charset=ISO-8859-1 What about this: http://www.ietf.org/proceedings/80/agenda/mif.txt -Hui 2011/3/17 Tomasz Mrugalski > On 17.03.2011 07:00, Hui Deng wrote: > > Hello all > > > > Draft agenda, please review, > > http://tools.ietf.org/wg/mif/agenda?item=agenda80.html > The page says: > > "IETF-80 mif agenda > > Sorry, no agenda available as of today. Either no meeting was held, or > the document has not yet been submitted." > > Tomek > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --20cf305644d9b7d622049eaaec54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What about this:
=A0
-Hui

2011/3/17 Tomasz Mrugalski <= ;tomasz.mrugalski@gmail.com>
On 17.03.2011 07:00, Hui Deng wrote:
> Hello all>
> Draft agenda, please review,
> http://tools= .ietf.org/wg/mif/agenda?item=3Dagenda80.html
The page says:

"IETF-80 mif agenda

Sorry, no agend= a available as of today. Either no meeting was held, or
the document has= not yet been submitted."

Tomek
____________________________= ___________________
mif mailing list
mif@ietf.org
https:= //www.ietf.org/mailman/listinfo/mif

--20cf305644d9b7d622049eaaec54-- From tomasz.mrugalski@gmail.com Thu Mar 17 03:41:09 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555643A68ED for ; Thu, 17 Mar 2011 03:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li3oxeGgXwBl for ; Thu, 17 Mar 2011 03:41:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6D3253A68D8 for ; Thu, 17 Mar 2011 03:41:08 -0700 (PDT) Received: by wyb42 with SMTP id 42so2835685wyb.31 for ; Thu, 17 Mar 2011 03:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aVb4GMMqSi0iQjf4gYPbdNEu3uSHTvDgMhRt3UHOOgw=; b=LJc7AEi2GV2kq2lRGIZQKjA/5W/Qxa2Xcmp/tCExSYBkS83qiX5o9kcxuxFfbCBiN6 oKSW+IsnVgG+ULgMtNrCtKMMu3a3jJqwoChs/O1jiC/DwEQEU/n0zYm2ysiQQOWPjNGs PwAMNDPTTqnDn5cRi5KygDDtH3UaR+9y+5M0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=aw/t746vfgHXHUpoO63+AtIRWtUo3wtUFlxkPj71RbdheDlTraPM7FHps1Q1X0oqGL o6N54hCwenYVUJrdqIFsjHxQQj+RSZ/ZhN01jF79t/fVI+tlLvJg2eU/Sl3WT+P/w5Zr 2sM/n3Mrg5yb9tMYx90FzKlN2ablXpIYp/ToA= Received: by 10.227.0.140 with SMTP id 12mr1242987wbb.122.1300358555354; Thu, 17 Mar 2011 03:42:35 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl [109.107.11.157]) by mx.google.com with ESMTPS id z13sm566312wbd.12.2011.03.17.03.42.34 (version=SSLv3 cipher=OTHER); Thu, 17 Mar 2011 03:42:34 -0700 (PDT) Message-ID: <4D81E599.6090006@gmail.com> Date: Thu, 17 Mar 2011 11:42:33 +0100 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Hui Deng References: <4D81D13F.2070209@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] draft agenda MIF 80th X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 10:41:09 -0000 On 17.03.2011 11:14, Hui Deng wrote: > What about this: > http://www.ietf.org/proceedings/80/agenda/mif.txt Now both links work. Tomek From denghui02@gmail.com Fri Mar 25 03:26:43 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C673A6996 for ; Fri, 25 Mar 2011 03:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv+hLAP3286N for ; Fri, 25 Mar 2011 03:26:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 78B393A67B0 for ; Fri, 25 Mar 2011 03:26:42 -0700 (PDT) Received: by iye19 with SMTP id 19so441117iye.31 for ; Fri, 25 Mar 2011 03:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=CQAViwZ0sAuN16jgBlt1ng0IMs7myNw0F22+QN9GhYU=; b=nEEqwTN4c9+xWn232V5fOVtISWuPJKZIjsLqdzmHBL0QvPOfeHdJV5XlUvXMtBPwqx eA9L+k+jDsJP9xJmmIOWAya+zUyDmTyC+dVnjG1mRkZO1SkOX+fWUcLVhb5aV3lhYTvx 0HrSJKPWXK89+u/Kn5d8iXa56llE7eK/b6rG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Si+a1CJpc1QcH+kSk2mtRodD9x3t4Zqsh/qpSwjrOe8X6tn2iZDGkekKJdDnifRWsD F0iWI8xAOZmT9goLpDLSUB/uIYedLHzQD+QFcvB8BdfNv8izEbiqtor14pAe0gGdUpII yX0DJ4QxA3OoTdGCV3MJM9PBRg/S4FupG19UY= MIME-Version: 1.0 Received: by 10.42.136.71 with SMTP id s7mr836564ict.476.1301048897752; Fri, 25 Mar 2011 03:28:17 -0700 (PDT) Received: by 10.42.224.71 with HTTP; Fri, 25 Mar 2011 03:28:17 -0700 (PDT) Date: Fri, 25 Mar 2011 18:28:17 +0800 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=90e6ba6e87cc62cf06049f4c0d70 Subject: [mif] presenter slides X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 10:26:43 -0000 --90e6ba6e87cc62cf06049f4c0d70 Content-Type: text/plain; charset=ISO-8859-1 Hi presenters, Could you kind help to send chairs your slide by sunday afternoon 3pm, thanks a lot -Hui --90e6ba6e87cc62cf06049f4c0d70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi presenters,
=A0
Could you kind help to send=A0chairs your slide by sunday afternoon 3p= m,
thanks a lot
=A0
-Hui
--90e6ba6e87cc62cf06049f4c0d70-- From margaretw42@gmail.com Sat Mar 26 03:33:32 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B133A67E7 for ; Sat, 26 Mar 2011 03:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdtZ9koV77bR for ; Sat, 26 Mar 2011 03:33:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 525AB3A67C3 for ; Sat, 26 Mar 2011 03:33:31 -0700 (PDT) Received: by fxm15 with SMTP id 15so1847114fxm.31 for ; Sat, 26 Mar 2011 03:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:content-type :content-transfer-encoding:mime-version:subject:date:x-mailer; bh=PtqOmkulNsYbuU7cUizhqw8ZXcu7eNAbVnz6nUvr5Vw=; b=mt7n8qZcn14DUpYQ3e0K4//c+3IPTynM2KKBlq7diyQyB5NM08fmXscCjCi2fU2j26 kCnS/u3ZAJWK8suU++XXvtGl8NL4y4AvK62Ic0/+FhtGUPjnqZQXYwXNekHTg5GHvpM6 0S4uARsPWmC12k86wDNP4paP7AvIvVfVq8MMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=au3lOkeFqi53UIEDOBy8eZFAtfyzbtbxx/oAPzbfLxm+btYOZh/5HNJTUD6qDjmQ9q CCxR5x1x7fo8Jq/OTRd6bvicEA3MuLOCuq3AmGrSuY/hRBHcUJV6VMgqHk/fuuw4cNN+ 0ku1Xfd9ifv+IMwaNF8KzGX6X3rlXZ7/DZZAk= Received: by 10.223.7.73 with SMTP id c9mr2069429fac.117.1301135706600; Sat, 26 Mar 2011 03:35:06 -0700 (PDT) Received: from [10.0.4.197] ([212.47.23.197]) by mx.google.com with ESMTPS id e17sm748099fak.0.2011.03.26.03.35.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Mar 2011 03:35:05 -0700 (PDT) Message-Id: <00B6468C-BA77-4B80-8980-D8D69BF0540B@lilacglade.org> From: Margaret Wasserman To: mif@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 26 Mar 2011 06:35:04 -0400 X-Mailer: Apple Mail (2.936) Subject: [mif] Meeting on MONDAY at 1:00pm X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 10:33:32 -0000 Just to make sure everyone is aware of our time slot... Although previous versions of the IETF Agenda had MIF scheduled on Friday morning, our meeting has been moved to MONDAY afternoon 1300-1500 in Congress Hall III. Our agenda can be found here: http://tools.ietf.org/wg/mif/agenda?item=agenda80.html Hope to see many of you there! Margaret From teemu.savolainen@nokia.com Sun Mar 27 07:41:45 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C693A6864 for ; Sun, 27 Mar 2011 07:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-IxB1MRlSb0 for ; Sun, 27 Mar 2011 07:41:43 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 736563A6823 for ; Sun, 27 Mar 2011 07:41:43 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2REhIl1030179; Sun, 27 Mar 2011 17:43:18 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Mar 2011 17:43:13 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 27 Mar 2011 16:43:12 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Sun, 27 Mar 2011 16:43:12 +0200 From: To: , Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: AQHL3l/iJmEbWFclwkO4Kq5pz2pNtJRBV29Q Date: Sun, 27 Mar 2011 14:43:12 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962014D2E@008-AM1MPN1-036.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.79.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Mar 2011 14:43:13.0654 (UTC) FILETIME=[4CFF6160:01CBEC8D] X-Nokia-AV: Clean Subject: Re: [mif] Happy Eyeballs Extension for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 14:41:45 -0000 Hi, This is interesting work. Couple of questions: Is the value of I initially zero for any destination/hostname that has not = yet been connected to? draft-ietf-mif-dhcpv6-route-option and RFC4191 allow definition of specific= routes. In the presence of specific routes it sounds, for me at least, som= ewhat odd to send connection attempts via all interfaces. What about increm= enting I for a destination address that matches a more specific route? Henc= e initial connection attempt would be sent over the interface that has matc= hing route and other interfaces would be tried only if no reply on the pref= erred one? How does the value of I relate to time? (i.e. if I is -1 does the node wait= 10ms before trying corresponding less-preferred interface). Why would the DNS query be sent over all interfaces? Is it because "I" for = a destination name is initially a zero? Like in routing case, if Improved D= NS Server Selection is in play, would the "I" be nonzero for those interfac= es over which DNS suffix matching the requested name has been received on? Best regards, Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext GangChen > Sent: 09. maaliskuuta 2011 14:43 > To: mif > Subject: [mif] Happy Eyeballs Extension for MIF >=20 > Hello all, >=20 > A New Internet-Draft is available. >=20 > Title : Happy Eyeballs Extension for Multiple > Interfaces > Author(s) : G. Chen > Filename : draft-chen-mif-happy-eyeballs-extension-00.txt > Pages : 6 > Date : 2011-03-07 >=20 > The memo has been proposed to extend happy eyeballs algorithm to fit > into multiple interfaces environment. Based on this extended > heuristic algorithm, a client with multiple interface could determine > the optimal flow path in which specific interface has been chosen. > Furthermore, an appropriate IP address family for each interface can > be also identified to guarantee user experiences during IPv6 > transition period. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-mif-happy-eyeballs- > extension-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Please kindly review it. > Comments are welcome. >=20 >=20 > BRs >=20 > Gang > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Sun Mar 27 11:29:16 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A134E3A68D2 for ; Sun, 27 Mar 2011 11:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifmrBXaskFoR for ; Sun, 27 Mar 2011 11:29:15 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id DB9EA3A68C1 for ; Sun, 27 Mar 2011 11:29:15 -0700 (PDT) Received: by pve39 with SMTP id 39so553689pve.31 for ; Sun, 27 Mar 2011 11:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=iUXljvPqXbEq4PLwadkF1npcjymnSv8oHOblYJatzKo=; b=Ii/nUX1LkH2ELCKcNVu4jUlNruYs8+rwWZ7slvPSH+ub+SUH12lhGRET8OoY/gU+6Q wn+IP5QXuMdZ8V0IJUhkBLwbyoY0QuEWsi5xlI1lYPqwH8XEb35cybSULxSfE0amyfRc Dx3QFfBLHXaG9jsrqY2+uFf72B0u6kdbnAZA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=P8OpSN2e3Mlxst0v3JrR6fE7XoOfxrcmo3275jqw49KYKud7BpRefxjLTAub8Jin8N 3J4u1jwJcx2TUVcMHBhWp33fSdyOrcNlXpuPEhIZoZmF8aKL2MlHlUWw3Wel9CR5/x8A SZZF/K1wtqDJRZ6FwWmrIqfJ6gxKujHfTmQBw= Received: by 10.143.26.6 with SMTP id d6mr2757294wfj.290.1301250652685; Sun, 27 Mar 2011 11:30:52 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id o11sm4738097wfa.12.2011.03.27.11.30.50 (version=SSLv3 cipher=OTHER); Sun, 27 Mar 2011 11:30:51 -0700 (PDT) Message-ID: <4D8F8257.4060806@gmail.com> Date: Sun, 27 Mar 2011 20:30:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Questions on draft-ietf-mif-dhcpv6-route-option-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 18:29:16 -0000 I am interested in this draft-ietf-mif-dhcpv6-route-option-01 because of its otherwise unstated DHCP ability to deliver a Default Route address to a Client. Can this Client be a Router? What is new about draft-droms-dhc-dhcpv6-default-router-00.txt? This draft also looked at default route delivered by DHCP. Alex From denghui02@gmail.com Sun Mar 27 13:01:38 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07B13A6938; Sun, 27 Mar 2011 13:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8d3iCAq0voot; Sun, 27 Mar 2011 13:01:38 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 00E333A6934; Sun, 27 Mar 2011 13:01:37 -0700 (PDT) Received: by iwn39 with SMTP id 39so2744826iwn.31 for ; Sun, 27 Mar 2011 13:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=awijncKixQ4spNZfVGXPqA5WBl1w9v4u0zfz2d4O8fw=; b=J3YmHXoodgGD5ScT9bXZy1anGglM4qqPfghsFRupD3YCs2CMHnRke4YS2GhUgnUnqC mFpjaAXNGDYVX0EOItME7W75x/BHNzVNmEb1sXuF2PgYk5wcW0ox6ifuRkcn49W2YXAQ udDbqgd+LDFQbnIlcHY95SJ+klScEmMO+EMmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AML7GJY4kpLJO1fVYzWlWr7XxAXgWz1msY2QAB+Ny1dx76aL6NRDXu3eKtGK2hZetQ 92mLjFFTMz7HTWPyL8VJcjkj1kQ8U8JpvwVuPmxlAs5iAWo9Q5DEkGReg8sflId0s88B ie9UuO4ZWpvzK3ZPLPgm1oehkyBcQdwSl0BA4= MIME-Version: 1.0 Received: by 10.42.66.147 with SMTP id p19mr5572443ici.7.1301256194470; Sun, 27 Mar 2011 13:03:14 -0700 (PDT) Received: by 10.42.224.71 with HTTP; Sun, 27 Mar 2011 13:03:14 -0700 (PDT) Date: Mon, 28 Mar 2011 04:03:14 +0800 Message-ID: From: Hui Deng To: 80attendees@ietf.org, MIF Mailing List , Internet Area , Margaret Wasserman , Jari Arkko , Ralph Droms Content-Type: multipart/alternative; boundary=90e6ba614eec3bb388049f7c51ea Subject: [mif] MIF session time (Monday Afternoon) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 20:01:39 -0000 --90e6ba614eec3bb388049f7c51ea Content-Type: text/plain; charset=ISO-8859-1 Dear all You may be misguided by the small brochure that MIF is scheduled on Friday morning, It is exactly scheduled on Monday afternoon 1-3pm, Congress Hall III http://tools.ietf.org/agenda/80/ -Hui --90e6ba614eec3bb388049f7c51ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all
=A0
You may be misguided by the small brochure that MIF is scheduled on Fr= iday morning,
It is exactly scheduled on Monday afternoon 1-3pm, Congress Hall III
=A0
-Hui
--90e6ba614eec3bb388049f7c51ea-- From Internet-Drafts@ietf.org Mon Mar 28 00:45:02 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88523A68C1; Mon, 28 Mar 2011 00:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUFwVA3yMzPl; Mon, 28 Mar 2011 00:45:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72393A68AD; Mon, 28 Mar 2011 00:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.13 Message-ID: <20110328074501.25040.65611.idtracker@localhost> Date: Mon, 28 Mar 2011 00:45:01 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-problem-statement-11.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 07:45:02 -0000 --NextPart 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 : Multiple Interfaces and Provisioning Domains Problem Statement Author(s) : M. Blanchet, P. Seite Filename : draft-ietf-mif-problem-statement-11.txt Pages : 19 Date : 2011-03-28 This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains where some configuration objects are global to the node, others are local to the interface. Issues such as selecting the wrong interface to send trafic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simulatenous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses single interface nodes situation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mif-problem-statement-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-28003922.I-D@ietf.org> --NextPart-- From scott.brim@gmail.com Mon Mar 28 02:29:33 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF92A3A691E for ; Mon, 28 Mar 2011 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQn+DoPcNqJD for ; Mon, 28 Mar 2011 02:29:31 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id AE3243A6920 for ; Mon, 28 Mar 2011 02:29:30 -0700 (PDT) Received: by iye19 with SMTP id 19so3305622iye.31 for ; Mon, 28 Mar 2011 02:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=QfnLBcZzUePyV0sZwapJIuGo7oC/I+p/eSBc7W4e1JY=; b=dvFEAV48D7d1ycerfixoQEAZzJb9fbECvzaUMvDo0GfzIe7a2b1ZoHGHJxgUA63H6Y 0219mP1yuEpeWRCoYZ2vW8mE6HnYH55lvbVopNc9FwbpyBXdZGD6PttmgfJAZhsITMLW 5Ug3C9MPppaX4vhxZs4MbkduTpt/94oSvLf1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=dffnEizWCxjSVQF5Cbd3U7Sig8bclR624FSOjEtXNFP+5gaVDnn1HXqsjrTsGjzT02 O1uaJaI/jf2eq/CIBF5A4sd9qv3wNKyKeG7uJjz9uwgxUFRDXQiSzBZg7LQUkU8ydrWq huBJuFgZjqjttUlYvo9aDtu8bLWJc/LdBlumE= MIME-Version: 1.0 Received: by 10.42.141.196 with SMTP id p4mr6308905icu.180.1301304668090; Mon, 28 Mar 2011 02:31:08 -0700 (PDT) Received: by 10.42.133.65 with HTTP; Mon, 28 Mar 2011 02:31:08 -0700 (PDT) Received: by 10.42.133.65 with HTTP; Mon, 28 Mar 2011 02:31:08 -0700 (PDT) Date: Mon, 28 Mar 2011 11:31:08 +0200 Message-ID: From: Scott Brim To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=90e6ba6e869e7c70cb049f879aaa Cc: mif@ietf.org Subject: Re: [mif] Happy Eyeballs Extension for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 09:29:34 -0000 --90e6ba6e869e7c70cb049f879aaa Content-Type: text/plain; charset=ISO-8859-1 First, there are a lot of issues that go into making a choice between interfaces. The ones I can think of immediately are interface cost, policy rules, higher layer services sought, and real goodput measurement over time. A simple integer preference for using a particular interface to reach a particular prefix, based only on how fast a SYNACK comes back, cannot reflect those. I suspect that it would be better do this in two stages: first choose a set of interfaces based on other criteria (like those listed above), and then run this draft's mechanism on that set. Second, I can't resist pointing out that goodput over time is more significant than initial connectivity so in the long run we're better off with MPTCP or SCTP and using real data packets on those interfaces. Thanks... Scott - use multipathing (SCTP CMT, MPTCP) to determine I have concerns about the usefulness. I like Happy Eyeballs very much in its original context. However, in the original context of Happy Eyeballs (IPv4 vs IPv6, TCP vs SCTP), the goals are clear, the choices are clear, and the metrics for the decision are clear. It's purely a problem of devising a good mechanism to enable making a technical choice. However, in this case, t --90e6ba6e869e7c70cb049f879aaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

First, there are a lot of issues that go into making a choice between in= terfaces. The ones I can think of immediately are interface cost, policy ru= les, higher layer services sought, and real goodput measurement over time. = A simple integer preference for using a particular interface to reach a par= ticular prefix, based only on how fast a SYNACK comes back, cannot reflect = those.

I suspect that it would be better do this in two stages: first choose a = set of interfaces based on other criteria (like those listed above), and th= en run this draft's mechanism on that set.

Second, I can't resist pointing out that goodput over time is more s= ignificant than initial connectivity so in the long run we're better of= f with MPTCP or SCTP and using real data packets on those interfaces.

Thanks...=A0 Scott

- use multipathing (SCTP CMT, MPTCP) to determine

I have concerns about the usefulness. I like Happy Eyeballs very much in= its original context. However, in the original context of Happy Eyeballs (= IPv4 vs IPv6, TCP vs SCTP), the goals are clear, the choices are clear, and= the metrics for the decision are clear. It's purely a problem of devis= ing a good mechanism to enable making a technical choice. However, in this = case, t

--90e6ba6e869e7c70cb049f879aaa-- From ajs@shinkuro.com Mon Mar 28 04:43:21 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0935A3A6822 for ; Mon, 28 Mar 2011 04:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3RW0dwGmkiO for ; Mon, 28 Mar 2011 04:43:20 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 2B9D53A67A8 for ; Mon, 28 Mar 2011 04:43:20 -0700 (PDT) Received: from shinkuro.com (dhcp-250f.meeting.ietf.org [130.129.37.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C12961ECB41D for ; Mon, 28 Mar 2011 11:44:56 +0000 (UTC) Date: Mon, 28 Mar 2011 07:44:54 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110328114453.GD85777@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [mif] Comments on draft-ietf-mif-dns-server-selection-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 11:43:21 -0000 Dear colleagues, I have read draft-ietf-mif-dns-server-selection-01. I have some comments. Apologies for having failed to comment sooner. The fundamental issue here is split horizon DNS. This has two different cases: 1. There are subsets of the name space that are resolvable from inside one network, but are not really globally resolvable. On the "inside network" of a corporate LAN, for instance, printer1.example.com might be a useful hostname, but not one that could be resolved from the public authoritative servers for example.com. On the public Internet, a query for printer1.example.com gets a Name Error response. 2. There are subsets of the name space that are globally resolvable, but that resolve differently depending one's network-topologic location. The obvious example is www.example.com, which is the public web server for everyone in the world but which provides a different experience inside the corporate network (and indeed, which may be a completely different host). The reason I want to distinguish these is that, if one contacts the wrong name server in case (1), it is only a denial of service; whereas if one contacts the wrong name server in case (2), one goes to the wrong place. (1) can be easily detected by even the most naïve user, whereas (2) might not be obvious. While I think the VPN case is important, whether one happens to be using a VPN or happens instead to be attached to more than one network is sort of irrelevant to the matter: the VPN is a compelling use-case, but the basic issue is just a split horizon. I find some appeal in its use of a dhcp option to say, "I know about [name spaces]." As the draft stands, it is not exactly clear how to extablish trust in this announcement, however. This seems like a new way for wireless hotpots to hijack my corporate lookups, so it bugs me. The draft on several occasions talks about a connection being "considered secure", and I am gravely worried that unpacking that meaning of "secure" is still to be done. I think what could help is a clearer account of exactly what assurance one can get from DNSSEC and how it may help, what assurance one can get from configuration that is somehow externally assured (or even just a remark that "how to determine trust in these cases is..." [undefined|beyond scope|defined in {ref}]). Here are some ways that you can do useful validation with DNSSEC. To me, this isn't clear in the draft as it is. I'm not sure where to put any of the following. Because DNSSEC provides cryptographic assurance of the integrity of DNS data, data that can be validated under DNSSEC is necessarily to be preferred over data that cannot be. It follows that, if validation is not performed by the host making the decision about whether to trust the DNS data from a given interface, it cannot make a decision to prefer data from any interface with any great assurance: any response could be forged, and there is no way to detect it without DNSSEC. In validatiing DNS answers with DNSSEC, a validator might order the list of trust anchors it uses to start validation chains, in terms of the host's preferences for those trust anchors. A host could use this ability in order to select among alternative DNS results from different interfaces. Suppose that a host has a trust anchor for the public DNS root, and also has a special-purpose trust anchor for example.com. An answer is received on interface i1 for www.example.com, and the validation for that succeeds by using the public trust anchor. Also, an answer is received on interface i2 for www.example.com, and the validation for that succeeds by using the trust anchor for example.com. In this case, the host has evidence for relying on i2 for answers in the example.com zone. I hope this is helpful Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Mon Mar 28 05:06:46 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA263A6811 for ; Mon, 28 Mar 2011 05:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDYNOXu4u8BX for ; Mon, 28 Mar 2011 05:06:45 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B62C73A67EA for ; Mon, 28 Mar 2011 05:06:45 -0700 (PDT) Received: from shinkuro.com (dhcp-250f.meeting.ietf.org [130.129.37.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C938A1ECB41D for ; Mon, 28 Mar 2011 12:08:22 +0000 (UTC) Date: Mon, 28 Mar 2011 08:08:20 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110328120819.GE85777@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [mif] DNSSEC trust anchors as a side channel for preferring an interface X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:06:46 -0000 Hi, Something that came up in the discussion today in the meeting was the way that using trust anchors as a way of establishing trust in an interface for answers for part of the name space might work. I think it was Ted who was suggesting that there might be a problem with having the same key signing the public-Internet-horizon answer and the intranet-horizon answer. The answer is, "Don't do that." If we want to tell people that using special-purpose trust anchors as the foundation link in a validation chain, and that such a chain is the message that tells you, "I'm the special-purpose 'internal' DNS server," then the chain for such a message has to be distinct from the chain you'd get from the public Internet root. This does potentially mean more DNSKEYs in the DNSKEY RRset. That's the cost of using this trick. If the answer is, "Ooh, people won't do this. They want one and only one key," then I say DNSSEC is the wrong hammer for that nut and bolt. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dthaler@microsoft.com Mon Mar 28 05:20:50 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392483A6907 for ; Mon, 28 Mar 2011 05:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.56 X-Spam-Level: X-Spam-Status: No, score=-110.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9qeKTZimtDw for ; Mon, 28 Mar 2011 05:20:49 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 574033A6903 for ; Mon, 28 Mar 2011 05:20:49 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Mar 2011 05:22:26 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 28 Mar 2011 05:22:26 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.127]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 05:22:26 -0700 From: Dave Thaler To: "mif@ietf.org" Thread-Topic: Comments on Improved DNS server selection Thread-Index: AcvtQqqraEjgKvmcT6myn2F3VLZV3A== Date: Mon, 28 Mar 2011 12:22:26 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B0054B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mif] Comments on Improved DNS server selection X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:20:50 -0000 My thoughts after the end of today's WG discussion... I don't yet buy that there's any real world scenario we care about where there's one interface that wants to configure different=20 DNS servers for different namespaces. If you want to do that, you have to deal with hosts that don't=20 yet do whatever the new option would do, and to handle them you'd hand out the IPs of a DNS server inside that ISP that then=20 uses the more detailed information when it does recursive queries for example.=20 And once you have that, you don't need DNS IPs in the DNS suffix list. -Dave From alexandru.petrescu@gmail.com Mon Mar 28 05:33:46 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DADF3A687D for ; Mon, 28 Mar 2011 05:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBGM2lp0yrWG for ; Mon, 28 Mar 2011 05:33:45 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 503823A680A for ; Mon, 28 Mar 2011 05:33:45 -0700 (PDT) Received: by pve39 with SMTP id 39so687868pve.31 for ; Mon, 28 Mar 2011 05:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=h1NDiXIJ/Dcc9PqmUNHqQZJ+s5DatanLM0rRGLcj8+c=; b=bgM5OMK7Kf2uy3PWZHWl3cLlGyDepgAILBcc9i3vCEqlahRBqY9n9zfmOsinZJEXqI iekhbRkHOjbCPrvLk9wO3KASa8T4if3bfZAE3JT9qTRD/IXNV7vDq26PUpmtcNhx+3oa sJEBnD/IFTzSq3yfhxqAvcXCLI6u7me0LhwkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=a9Gy51S2cG2KTAURxJNO03LUYYKUYl6nNPvel2HDi4/yN6ga0C1KpNU1wcWgSfwyB4 7cmBj2dKMPs7JJkc6wsQAPk7BAHNRu4nox5RLPOnaUEbLBjfC/g5UBSirgw14d6f3j2y RS5EkvWzpv+gh5ACYoEx0JaK1JWdILh7kX3EM= Received: by 10.142.121.41 with SMTP id t41mr3810346wfc.358.1301315722778; Mon, 28 Mar 2011 05:35:22 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id x11sm5839257wfd.1.2011.03.28.05.35.20 (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 05:35:21 -0700 (PDT) Message-ID: <4D908086.6020400@gmail.com> Date: Mon, 28 Mar 2011 14:35:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] comments on the dns selection discusion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:33:46 -0000 When the usecase is wifi-3g multiply ifaced host there is a need to consider the non-DHCP protocol used to deliver the address of DNS to the host, on 3g. I use hso, which I dont know what is, but is not dhcp yet it provises the dns address. It is not sufficient to consider that only dhcp provides the dns address. I would like that /etc/resolv.conf doesn't get overwritten, and that its entries are something like: 192.168.1.1, example.com, eth0 (note the additional eth0 parameter) In this way maybe smarter resolver libraries direct the dns request to appropriate server, without resorting to enhancing routing table or src address selection. Alex From teemu.savolainen@nokia.com Mon Mar 28 05:43:09 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE473A691A for ; Mon, 28 Mar 2011 05:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dnhzy1oQIlJQ for ; Mon, 28 Mar 2011 05:43:07 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id CEEA43A69C0 for ; Mon, 28 Mar 2011 05:43:07 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2SCiNTt006717; Mon, 28 Mar 2011 15:44:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 15:43:59 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 28 Mar 2011 14:43:58 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 14:43:58 +0200 From: To: , Thread-Topic: Comments on Improved DNS server selection Thread-Index: AcvtQqqraEjgKvmcT6myn2F3VLZV3AAAWSGg Date: Mon, 28 Mar 2011 12:43:57 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962015607@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B0054B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B0054B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.76.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2011 12:43:59.0362 (UTC) FILETIME=[CF1ECE20:01CBED45] X-Nokia-AV: Clean Subject: Re: [mif] Comments on Improved DNS server selection X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:43:09 -0000 This part of the discussions reminded me of the very first version of this = draft (October 2008) http://tools.ietf.org/id/draft-savolainen-6man-fqdn-based-if-selection-00.t= xt that simply used: - DHCPv4 Domain Search Option number 119=20 - DHCPv6 Domain Search List Option number 24=20 to choose between interfaces...=20 But then things started growing, as those were not ok to use and as feature= s crept in:) So is this proposal essentially to go backwards a bit and have option forma= t very similar to Search List Options? Having only name in the option actually requires having DNS Proxy in figure= 2 scenario of draft-ietf-v6ops-multihoming-without-nat66), while having DN= S server address in the option makes it possible for hosts to bypass the DN= S proxy and talk directly to correct DNS server. E.g. OPTION_DNS_SERVER_SELECT could have address of this proxy, while new o= ptions would point directly to DNS servers with knowledge of private namesp= aces. Best regards, Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext Dave Thaler > Sent: 28. maaliskuuta 2011 14:22 > To: mif@ietf.org > Subject: [mif] Comments on Improved DNS server selection >=20 > My thoughts after the end of today's WG discussion... >=20 > I don't yet buy that there's any real world scenario we care about > where there's one interface that wants to configure different > DNS servers for different namespaces. >=20 > If you want to do that, you have to deal with hosts that don't > yet do whatever the new option would do, and to handle them > you'd hand out the IPs of a DNS server inside that ISP that then > uses the more detailed information when it does recursive queries > for example. >=20 > And once you have that, you don't need DNS IPs in the DNS suffix list. >=20 > -Dave > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From tomasz.mrugalski@gmail.com Mon Mar 28 05:44:19 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099CC3A6A25 for ; Mon, 28 Mar 2011 05:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJf7BHm2d87W for ; Mon, 28 Mar 2011 05:44:18 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 226443A691A for ; Mon, 28 Mar 2011 05:44:18 -0700 (PDT) Received: by pve39 with SMTP id 39so689746pve.31 for ; Mon, 28 Mar 2011 05:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=GbO0yZFjhP5ZrbXNN4+Krw25TL0rIdzda+FiJ2i+se0=; b=ZoDJm1LvW2DO8e4gp0ZOZqGfxf0BvvBEd82gnUNHxeIIEYOMUTlFgkvFS3L1M63GkY a8rCpU3IQXkEqz0//+wOvdgU/QgMX7H59HLJ0Wk/VuMm77C9dSCAl5YLNq1XVFbuOzBW faP3mOSy3vEe/ECVo0Ju+ygwytxFAIU/4SeQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=raF8zhceuaz1krss5r+tURrgCkIFP4eKnLMTbOzrOEtD5frFDWATSm3iON8TBwEnb/ miszKUoofBv1vzwwzBEkrV80oA5mGD814bTTyRj3omA1Vgq9oO8E/d6WSJdQuf5y+QU5 WhUxQsffuIn0JTVj3E1Q41fqBOT7DBV/AFaag= Received: by 10.142.150.22 with SMTP id x22mr3721323wfd.150.1301316355677; Mon, 28 Mar 2011 05:45:55 -0700 (PDT) Received: from dhcp-11aa.meeting.ietf.org (dhcp-11aa.meeting.ietf.org [130.129.17.170]) by mx.google.com with ESMTPS id w29sm295184wfd.4.2011.03.28.05.45.53 (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 05:45:55 -0700 (PDT) Message-ID: <4D908300.3000509@gmail.com> Date: Mon, 28 Mar 2011 14:45:52 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, Ted.Lemon@nominum.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: [mif] Ted's comment about DHCPv6 Route Option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:44:19 -0000 Hi, For people not currently in MIF WG meeting, Ted Lemon commented on dhcpv6-route-option (thanks!). I'm not sure if I got Ted's comment right. My impression was that the suggestion was that routing options may be put inside IA_NA options (a container for addresses, standard feature of DHCPv6) to specify that connections originating from leased address should indeed use specific route. No such thing is currently defined in the route-option-01 draft. There was no intention to add it either, according to my knowledge. My understanding is that IA_NA, IA_TA and IA_PD options were mentioned in a different context. Each of those options has an identifier field (IAID) to differentiate between multiple instances of a given option (e.g. IA_NA with IAID=1 is different than IA_D with IAID=2). Wojciech's comment about IA_NA was whether we should include similar IAID field in IA_RT, not that we want to convey NEXT_HOP(with RT_PREFIX subotions) in IA_NA. If we incorporate Ted's comments, it will extend this proposal with kind of source address selection configuration. I'm not necessarily opposing that idea, I just wanted to mention that this is a significant extension to the draft as it is currenty specified. Tomek From Ted.Lemon@nominum.com Mon Mar 28 05:49:50 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4A93A6817 for ; Mon, 28 Mar 2011 05:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeY9-spnEfg5 for ; Mon, 28 Mar 2011 05:49:49 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 3EF103A67DA for ; Mon, 28 Mar 2011 05:49:49 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTZCETiCXYFAEZ8N0K/tSNC/x3hqYYj/N@postini.com; Mon, 28 Mar 2011 05:51:27 PDT 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 1B82A1B87B3 for ; Mon, 28 Mar 2011 05:51:24 -0700 (PDT) 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 0F349190065 for ; Mon, 28 Mar 2011 05:51:24 -0700 (PDT) (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.01.0255.000; Mon, 28 Mar 2011 05:51:24 -0700 From: Ted Lemon To: "mif@ietf.org" Thread-Topic: Scope of DNS router selection draft Thread-Index: AcvtRtfL10aBz96PT1ugbSqLgByEZw== Date: Mon, 28 Mar 2011 12:51:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <731CE53DB854F64BB410744381908DCF@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mif] Scope of DNS router selection draft X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:49:50 -0000 I think the maximal scenario this draft needs to solve is the case where a = MI host is connected to a 3G network with some private domains, and a corpo= rate network with some private domains. In this scenario, it is possible = for each provisioning domain to specify a minimal list of domains for which= queries should be sent to that provisioning domain's DNS servers, and not = the others. And I think it's exceedingly unlikely that that list of domai= ns will ever overlap. I would go so far as to say that there is no legiti= mate scenario where such a thing could occur. Hence we do not need to sol= ve that problem. Further, in any legitimate scenario, all the domains that do not appear on = the DNS server selection list must resolve to the same information, unless = the information is location-dependent. This document doesn't claim to sol= ve the location-dependency problem, so we don't need to think about that he= re, although it's actually an important problem that we might *want* to thi= nk about in a separate context. I don't think the solution for this probl= em overlaps with the solution that this document offers, so we can address = them separately. Margaret proposed a scenario where a multi-homed network might receive diff= erent router selection options from different service providers. In this = scenario, the question arises: how do we combine this information and provi= de it to the client. This presupposes a solution: that we do information = aggregation in the router, and provide that aggregate information to the cl= ient, which then uses it to resolve these domains. I would like to point out two things about this. First, this isn't a MIF = problem. This is a multihoming problem. I don't mean that it shouldn't = be solve, or even that we shouldn't solve it, but I think it's important to= keep the problem in perspective. From my perspective, this is an ops pro= blem, not a standards problem. The problem is that you have information f= rom two different services providers, and you need to combine that informat= ion.=20 There are two ways I can think of to combine the information. The first i= s the one Margaret proposed: to take the two DHCP options and produce the u= nion of the two options, including IP addresses. This would work, but it = has the potential not to scale--we were already worried that this option mi= ght get a bit too big; this potentially doubles or triples the potential si= ze of the option. So as a DHCP wonk, I don't like that. The second solution, which is the one I prefer, is to use the DHCP options = received on both interfaces to configure a caching name server, and to prov= ide the IP address of that caching name server to internal DHCP clients. = I think this solution is administratively easier, easier to debug, and gene= rally operationally simpler. Better still, it lets us consider the proble= m this draft attempts to solve *strictly* as a MIF problem, and *not* as a = multihoming problem. The point I'm getting to is that I think we can solve all reasonable scenar= ios with a DHCP option that isn't version-specific--it'll work whether you = get it via DHCPv4 or DHCPv6, and will contain no IP addresses of either typ= e. I think this is a lot easier and gets us to the finish line a lot fast= er than trying to address the edge cases we talked about in the meeting by = sending IP addresses in the option.= From dthaler@microsoft.com Mon Mar 28 05:50:33 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07793A6817 for ; Mon, 28 Mar 2011 05:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.566 X-Spam-Level: X-Spam-Status: No, score=-108.566 tagged_above=-999 required=5 tests=[AWL=-1.955, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 249BtQ3TBCKg for ; Mon, 28 Mar 2011 05:50:27 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id C14783A6881 for ; Mon, 28 Mar 2011 05:50:27 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Mar 2011 05:52:05 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 28 Mar 2011 05:52:04 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.127]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 05:52:04 -0700 From: Dave Thaler To: "mif@ietf.org" Thread-Topic: Comments on draft-liu-mif-api-extension-04 Thread-Index: AcvtRazzLZNYuNfzQsC270FTmsKu6w== Date: Mon, 28 Mar 2011 12:52:04 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B0055C6@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mif] Comments on draft-liu-mif-api-extension-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:50:34 -0000 First two comments from last IETF that have not been=20 addressed yet: 1) Although the draft does now include some text saying it intends to define an abstract API, it actually defines a=20 concrete one. For example, saying that an API is a socket option used with setsockopt makes it a concrete API. And saying that a parameter is a "char *" rather than a=20 "string" makes it a concrete API. 2) My understanding is that the POSIX socket APIs are defined by the Austin Group, and standardized by the IEEE and the Open Group. When we did RFC 3678, we learned that the Austin Group now considers new socket options and ioctls harmful, since they're not typesafe. As a result, the API was fixed to use new methods instead. Unfortunately by then, some implementations already started using socket options/ ioctls, and so those were moved into an Appendix. New comments: 3) "struct parameter" is underspecified. In an abstract API document, one would need to list the parameters and their meanings and abstract types (string, integer, whatever). 4) gethostbyname was obsoleted by getaddrinfo. And it's not defined as a DNS API. For more info, see http://pubs.opengroup.org/onlinepubs/009695399/functions/gethostbyname.html and RFC 6055. 5) For interface selection, there are existing (non-standard) APIs on Windows and perhaps other OS's too. I'd recommend looking at what is already in use today and making sure the abstract API is defined with that information in mind. -Dave From teemu.savolainen@nokia.com Mon Mar 28 05:52:30 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DC53A68D5 for ; Mon, 28 Mar 2011 05:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br3kil8mAvmw for ; Mon, 28 Mar 2011 05:52:29 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 42C3A3A6817 for ; Mon, 28 Mar 2011 05:52:29 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2SCs2vc009074; Mon, 28 Mar 2011 15:54:05 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 15:53:06 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 28 Mar 2011 14:53:05 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 14:53:05 +0200 From: To: , Thread-Topic: [mif] comments on the dns selection discusion Thread-Index: AQHL7USf/DurzC6MlUuTuWO/MD+A2JRCsWMg Date: Mon, 28 Mar 2011 12:53:04 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696201568E@008-AM1MPN1-036.mgdnok.nokia.com> References: <4D908086.6020400@gmail.com> In-Reply-To: <4D908086.6020400@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.76.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2011 12:53:06.0487 (UTC) FILETIME=[153B7470:01CBED47] X-Nokia-AV: Clean Subject: Re: [mif] comments on the dns selection discusion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:52:30 -0000 3GPP specifications also allow use of Stateless DHCPv6 (e.g. for DNS, P-CSC= F, etc discovery). A setup could be such that a legacy host is happy with t= he DNS server IPv6 address received the usual style via layer 2 signaling (= PCO IE element), but multi-intefaced host would actually use Stateless DHCP= v6 to get more information (DNS selection, DHCPv6 more specific routes, RFC= 3484 updates..) Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext Alexandru Petrescu > Sent: 28. maaliskuuta 2011 14:35 > To: mif@ietf.org > Subject: [mif] comments on the dns selection discusion >=20 > When the usecase is wifi-3g multiply ifaced host there is a need to > consider the non-DHCP protocol used to deliver the address of DNS to > the > host, on 3g. I use hso, which I dont know what is, but is not dhcp yet > it provises the dns address. It is not sufficient to consider that > only > dhcp provides the dns address. >=20 > I would like that /etc/resolv.conf doesn't get overwritten, and that > its > entries are something like: >=20 > 192.168.1.1, example.com, eth0 >=20 > (note the additional eth0 parameter) > In this way maybe smarter resolver libraries direct the dns request > to > appropriate server, without resorting to enhancing routing table or > src > address selection. >=20 > Alex >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From prvs=706895dc5f=alan.ford@roke.co.uk Mon Mar 28 05:56:56 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1C53A67E4 for ; Mon, 28 Mar 2011 05:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYRRn9CahjgM for ; Mon, 28 Mar 2011 05:56:55 -0700 (PDT) Received: from ixe-mta-29.emailfiltering.com (ixe-mta-29-tx.emailfiltering.com [194.116.199.160]) by core3.amsl.com (Postfix) with ESMTP id 5830E3A67DA for ; Mon, 28 Mar 2011 05:56:55 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by ixe-mta-29.emailfiltering.com with emfmta (version 4.8.0.437) vanilla id 326170954 for mif@ietf.org;da419d1a41870893; Mon, 28 Mar 2011 13:58:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: A0rv BCXM Bn1r CGiH Cid7 DvqD Ebx+ Ev4x FQp/ FSuq Fc8g HPGN JDQa Jt5B KArM KWk9; 1; bQBpAGYAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {18DA80DD-34CB-491A-BE74-C210E3366336}; YQBsAGEAbgAuAGYAbwByAGQAQAByAG8AawBlAC4AYwBvAC4AdQBrAA==; Mon, 28 Mar 2011 12:47:32 GMT; TQBQAFQAQwBQACAAQQBQAEkA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {18DA80DD-34CB-491A-BE74-C210E3366336} Content-class: urn:content-classes:message Date: Mon, 28 Mar 2011 13:47:32 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680C8333EC@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPTCP API Thread-Index: AcvtRk4Btet0UFFoTT6fo7BpEyCkCA== From: "Ford, Alan" To: Subject: [mif] MPTCP API X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:56:57 -0000 Hi folks, As I just flagged up at the mic during the API discussion, we have been considering a number of similar API issues (from a very abstract perspective) for Multipath TCP. Our current draft is at: http://tools.ietf.org/html/draft-ietf-mptcp-api-01 And it would be great if we could ensure this and any MIF API work are appropriately aligned. Regards, Alan From Ted.Lemon@nominum.com Mon Mar 28 06:06:16 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2551D3A67E6 for ; Mon, 28 Mar 2011 06:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUhZzP-8yyCs for ; Mon, 28 Mar 2011 06:06:15 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id E038A3A67DA for ; Mon, 28 Mar 2011 06:06:14 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTZCIKGpc42/sRH3TAse/rt+snmFMLYkR@postini.com; Mon, 28 Mar 2011 06:07:52 PDT 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 EEEA01B8746 for ; Mon, 28 Mar 2011 06:07:51 -0700 (PDT) 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 CED9A190065; Mon, 28 Mar 2011 06:07:51 -0700 (PDT) (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.01.0255.000; Mon, 28 Mar 2011 06:07:52 -0700 From: Ted Lemon To: Tomasz Mrugalski Thread-Topic: Ted's comment about DHCPv6 Route Option Thread-Index: AQHL7UYV0DHI5pTWdkKzp7pLQNwNBpRCt71u Date: Mon, 28 Mar 2011 13:07:51 +0000 Message-ID: References: <4D908300.3000509@gmail.com> In-Reply-To: <4D908300.3000509@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C3D1C236891F4343B9CAE386F1F22212nominumcom_" MIME-Version: 1.0 Cc: "mif@ietf.org" , "draft-ietf-mif-dhcpv6-route-option@tools.ietf.org" Subject: Re: [mif] Ted's comment about DHCPv6 Route Option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:06:16 -0000 --_000_C3D1C236891F4343B9CAE386F1F22212nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 28, 2011, at 2:45 PM, "Tomasz Mrugalski" > wrote: No such thing is currently defined in the route-option-01 draft. There was no intention to add it either, according to my knowledge. My understanding is that IA_NA, IA_TA and IA_PD options were mentioned in a different context. Each of those options has an identifier field (IAID) to differentiate between multiple instances of a given option (e.g. IA_NA with IAID=3D1 is different than IA_D with IAID=3D2). Wojciech's comment about IA_NA was whether we should include similar IAID field in IA_RT, not that we want to convey NEXT_HOP(with RT_PREFIX subotions) in IA_NA. The only reason to include the IAID would be if you want to have lifetimes = specific to routes, and if you wanted to do DHCPv6-style address deprecatio= n on routes. I'm assuming that you just update the routing table every ti= me you get this option in a DHCPv6 packet, at least based on my most recent= skim of the draft. I will read it a little more carefully and see if my = opinion changes... :) --_000_C3D1C236891F4343B9CAE386F1F22212nominumcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Mar 28, 2011, at 2:45 PM, "Tomasz Mrugalski" <tomasz.mrugalski@gmail.com> w= rote:
No such thing is currently defined in the route-option-01 draft.= There
was no intention to add it either, according to my knowledge. My
understanding is that IA_NA, IA_TA and IA_PD options were mentioned i= n a
different context. Each of those options has an identifier field (IAI= D)
to differentiate between multiple instances of a given option (e.g.
IA_NA with IAID=3D1 is different than IA_D with IAID=3D2). Wojciech's=
comment about IA_NA was whether we should include similar IAID field = in
IA_RT, not that we want to convey NEXT_HOP(with RT_PREFIX subotions) = in
IA_NA.

The only reason to include the IAID would be if you want to have lifet= imes specific to routes, and if you wanted to do DHCPv6-style address depre= cation on routes.   I'm assuming that you just update the routing tabl= e every time you get this option in a DHCPv6 packet, at least based on my most recent skim of the draft.   = I will read it a little more carefully and see if my opinion changes... :)<= /div>

--_000_C3D1C236891F4343B9CAE386F1F22212nominumcom_-- From jari.arkko@piuha.net Mon Mar 28 06:50:11 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D557B3A687D for ; Mon, 28 Mar 2011 06:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTWt4SA0oCSO for ; Mon, 28 Mar 2011 06:50:07 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7C7473A67E3 for ; Mon, 28 Mar 2011 06:50:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7CA232CC39; Mon, 28 Mar 2011 16:51:42 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bhsWp7L2O8H; Mon, 28 Mar 2011 16:51:41 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 84B502CC2F; Mon, 28 Mar 2011 16:51:41 +0300 (EEST) Message-ID: <4D90926D.3030700@piuha.net> Date: Mon, 28 Mar 2011 15:51:41 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-mif-current-practices@tools.ietf.org, mif , Ted Lemon Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] AD review of draft-ietf-mif-current-practices X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:50:11 -0000 I have re-reviewed this draft after changes per my earlier review. I think the draft is ready to move forward with one change: please add a reference to RFC 5113 in Section 3.3 and explain that it contains further discussion about the access network selection problem. I don't have a strong opinion on whether we should add something to highlight Ted's scenario from today's meeting. I'll let the working group and the chairs decide that. I have set the status of the draft to Revised ID Needed, and we are ready to start IETF Last Call as soon as the above issue is fixed; if you don't add anything about the other scenario then a quick update this week would move the draft forward. Let me know when you have a new version that can be advanced. Jari From Ted.Lemon@nominum.com Mon Mar 28 08:23:10 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59CDB28C0CF for ; Mon, 28 Mar 2011 08:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGyGX91GPZfk for ; Mon, 28 Mar 2011 08:23:09 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 390C93A6819 for ; Mon, 28 Mar 2011 08:23:09 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTZCoPlQRMn8pZcUxvYWarlGKt1WaprO8@postini.com; Mon, 28 Mar 2011 08:24:47 PDT 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 10A37F80A3 for ; Mon, 28 Mar 2011 08:24:46 -0700 (PDT) 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 EBE74190069; Mon, 28 Mar 2011 08:24:45 -0700 (PDT) (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.01.0255.000; Mon, 28 Mar 2011 08:24:45 -0700 From: Ted Lemon To: Jari Arkko Thread-Topic: AD review of draft-ietf-mif-current-practices Thread-Index: AQHL7U9IuT4hgyWp1kuj9x/QaruM85RC3eqb Date: Mon, 28 Mar 2011 15:24:45 +0000 Message-ID: <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com> References: <4D90926D.3030700@piuha.net> In-Reply-To: <4D90926D.3030700@piuha.net> 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: "draft-ietf-mif-current-practices@tools.ietf.org" , mif Subject: Re: [mif] AD review of draft-ietf-mif-current-practices X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:23:10 -0000 FYI, this is a rough approximation of the text I would want to add: 4.1a. DNS resolution issues with captive portals A MIF node (M1) has an active interface(I1) connected to a network (N1) which has its DNS server (S1) and another active interface (I2) connected to a network (N2) which has its DNS server (S2). S1 is configured to respond to any A or AAAA record query with the IP address of a captive portal, so as to redirect web browsers to an access control portal web page. Any of the following situations may occur: 1. M1 stack, based on its routing table, uses I2 to reach S1 to resolve "a.example.com". M1 never reaches S1. The name is not resolved. 2. M1 keeps only one set of DNS server addresses from the received configuration objects and kept S2 address. M1 sends the forward DNS query for a.example.com to S2. S2 responds with the correct answer, R1. M1 attempts to contact R1 by way of I1. The connection fails. Or, the connection succeeds, bypassing the security policy on N1, possibly exposing the owner of M1 to prosecution. 3. M1 keeps only one set of DNS server addresses from the received configuration objects and kept S1 address. M1 sends the DNS query for a.example.com to S1. S1 provides the address of its captive portal. S1 attempts to contact this IP address using I1. The application tries to connect to the wrong destination node, resulting in lack of service and possible security issues. 4. M1 has resolved an FQDN to the IP address of the captive portal connected to N1. If the node loses connection to N1, the node may try to connect, via N2, to the same IP address as earlier, but as the address was only locally valid, connection setup fails. From teemu.savolainen@nokia.com Mon Mar 28 08:46:21 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF543A67CF for ; Mon, 28 Mar 2011 08:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYDc60UaE8jC for ; Mon, 28 Mar 2011 08:46:20 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 70FE53A691E for ; Mon, 28 Mar 2011 08:46:20 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2SFlKxK003109; Mon, 28 Mar 2011 18:47:53 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 18:47:19 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 28 Mar 2011 17:47:19 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 17:47:18 +0200 From: To: , Thread-Topic: AD review of draft-ietf-mif-current-practices Thread-Index: AQHL7U9IuT4hgyWp1kuj9x/QaruM85RC3eqbgAADDKA= Date: Mon, 28 Mar 2011 15:47:18 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962015946@008-AM1MPN1-036.mgdnok.nokia.com> References: <4D90926D.3030700@piuha.net> <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com> In-Reply-To: <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2011 15:47:19.0846 (UTC) FILETIME=[6BEB7460:01CBED5F] X-Nokia-AV: Clean Cc: draft-ietf-mif-current-practices@tools.ietf.org, mif@ietf.org Subject: Re: [mif] AD review of draft-ietf-mif-current-practices X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:46:21 -0000 Ted, Good text. I agree the problem exist. The DNS server selection points to th= is issue as well: -- (DISCUSS: What about those DNS servers that instead of negative answer always return positive reply with an IP address of some captive portal?) -- IMHO the problem section should say that this problem (usually/always) disa= ppears right after M1 has authenticated to the captive portal and interface= becomes truly "up". I.e. human intervention is required to clear the situa= tion, but once cleared, things work as they should - until captive portal p= ossibly wants to renew authentication.. This problem btw means the M1 cannot start validating responses until authe= ntication with captive portal shas been completed.=20 Best regards, Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext Ted Lemon > Sent: 28. maaliskuuta 2011 17:25 > To: Jari Arkko > Cc: draft-ietf-mif-current-practices@tools.ietf.org; mif > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices >=20 > FYI, this is a rough approximation of the text I would want to add: >=20 > 4.1a. DNS resolution issues with captive portals >=20 > A MIF node (M1) has an active interface(I1) connected to a network > (N1) which has its DNS server (S1) and another active interface > (I2) connected to a network (N2) which has its DNS server (S2). S1 > is configured to respond to any A or AAAA record query with the > IP address of a captive portal, so as to redirect web browsers to an > access control portal web page. Any of the following situations > may occur: >=20 > 1. M1 stack, based on its routing table, uses I2 to reach S1 to > resolve "a.example.com". M1 never reaches S1. The name > is not resolved. > 2. M1 keeps only one set of DNS server addresses from the received > configuration objects and kept S2 address. M1 sends the > forward DNS query for a.example.com to S2. S2 responds with the > correct answer, R1. M1 attempts to contact R1 by way of I1. > The connection fails. Or, the connection succeeds, > bypassing the security policy on N1, possibly exposing the > owner of M1 to prosecution. > 3. M1 keeps only one set of DNS server addresses from the received > configuration objects and kept S1 address. M1 sends the DNS > query for a.example.com to S1. S1 provides the address of its > captive portal. S1 attempts to contact this IP address using > I1. The application tries to connect to the wrong destination > node, resulting in lack of service and possible security issues. > 4. M1 has resolved an FQDN to the IP address of the captive portal > connected to N1. If the node loses connection to N1, the node > may try to connect, via N2, to the same IP address as earlier, > but as the address was only locally valid, connection setup > fails. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Mon Mar 28 08:52:02 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F923A68BF for ; Mon, 28 Mar 2011 08:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWLinWmMQQjj for ; Mon, 28 Mar 2011 08:52:01 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id CC2663A67CF for ; Mon, 28 Mar 2011 08:52:00 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTZCvAjTfNh4QwA0VX6fKyJgjlkQPpA0q@postini.com; Mon, 28 Mar 2011 08:53:38 PDT 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 D4A22F80A3 for ; Mon, 28 Mar 2011 08:53:37 -0700 (PDT) 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 C968A190069; Mon, 28 Mar 2011 08:53:37 -0700 (PDT) (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.01.0255.000; Mon, 28 Mar 2011 08:53:37 -0700 From: Ted Lemon To: Andrew Sullivan Thread-Topic: [mif] DNSSEC trust anchors as a side channel for preferring an interface Thread-Index: AQHL7UDZYDKD9oNOHk26+O5WImMz05RC5hgy Date: Mon, 28 Mar 2011 15:53:37 +0000 Message-ID: References: <20110328120819.GE85777@crankycanuck.ca> In-Reply-To: <20110328120819.GE85777@crankycanuck.ca> 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] DNSSEC trust anchors as a side channel for preferring an interface X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:52:02 -0000 What happened here, I think, is that I posited a problem--essentially the p= roblem you mentioned in your previous message, which is that the DNS server= selection option can be used to provide DNS server IP addresses for which = will then provide wrong answers for certain domains. I offered to write so= me text for Teemu explaining how to use DNSSEC to mitigate this problem. I= never wrote the text. Teemu wrote his own text, based on his understandin= g of what I'd asked for, which was slightly different than what I intended = (understanding that I had never clearly thought the problem through to its = conclusion--I offered to write the text intending to think it through when = I wrote it). The point of this exercise (hopefully Teemu will correct me if I am wrong o= n this) is to prevent the type of domain hijacking I described above. It'= s not to choose a different answer based on what trust anchor was used to s= ign the zone. I think you *can* sign an internal and external zone using = the same key, and generally have that work, as long as you don't cache answ= ers from both zones and attempt to validate some answer by combining answer= s from the two versions of the zone. If that's not the case, it's potenti= ally a problem for this draft. Be that as it may, the main point of this exercise was to provide a way for= securely detecting an attempt to spoof DNS responses for a signed zone--th= at is, a way to prevent this option from serving as a mechanism for bypassi= ng DNSSEC. In order for that to happen, both copies of the zone have to v= alidate to the root; it is the fact that the spoofed zone will fail to vali= date to the root that allows us to discard it. The idea of differentiatin= g between different zones on the basis of the trust anchor used to validate= them was not what I intended, and I don't think Teemu had it in mind as a = requirement either, although I may be mistaken about that--I think it's jus= t a mistranslation of a muddy explanation I'd given to him back around the = time of the Beijing meeting. From pierrick.seite@orange-ftgroup.com Mon Mar 28 09:09:29 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8F128B56A for ; Mon, 28 Mar 2011 09:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.007 X-Spam-Level: X-Spam-Status: No, score=-3.007 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyUera0wvZNn for ; Mon, 28 Mar 2011 09:09:29 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id D6EB43A6892 for ; Mon, 28 Mar 2011 09:09:28 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E98738B8015; Mon, 28 Mar 2011 18:11:36 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id DF5918B8010; Mon, 28 Mar 2011 18:11:36 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 18:11:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Mar 2011 18:11:04 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201990D2A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4D90926D.3030700@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AcvtT040A9F9ojmKSdSex14oRhjz5wAEyoLw References: <4D90926D.3030700@piuha.net> From: To: , , , X-OriginalArrivalTime: 28 Mar 2011 16:11:06.0236 (UTC) FILETIME=[BE1D4BC0:01CBED62] Subject: Re: [mif] AD review of draft-ietf-mif-current-practices X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:09:29 -0000 Current practices draft is updated with reference to RFC5113. New = version is: = http://datatracker.ietf.org/doc/draft-ietf-mif-current-practices=20 Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de Jari > Arkko > Envoy=E9=A0: lundi 28 mars 2011 15:52 > =C0=A0: draft-ietf-mif-current-practices@tools.ietf.org; mif; Ted = Lemon > Objet=A0: [mif] AD review of draft-ietf-mif-current-practices >=20 > I have re-reviewed this draft after changes per my earlier review. I > think the draft is ready to move forward with one change: please add a > reference to RFC 5113 in Section 3.3 and explain that it contains > further discussion about the access network selection problem. >=20 > I don't have a strong opinion on whether we should add something to > highlight Ted's scenario from today's meeting. I'll let the working > group and the chairs decide that. I have set the status of the draft = to > Revised ID Needed, and we are ready to start IETF Last Call as soon as > the above issue is fixed; if you don't add anything about the other > scenario then a quick update this week would move the draft forward. = Let > me know when you have a new version that can be advanced. >=20 > Jari >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Mon Mar 28 09:13:28 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3192E28C0F2 for ; Mon, 28 Mar 2011 09:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwNH6o7qXAlq for ; Mon, 28 Mar 2011 09:13:27 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 0DC5828B56A for ; Mon, 28 Mar 2011 09:13:26 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTZC0BWA2v7evLsne2+ifipgfgq0s0W6n@postini.com; Mon, 28 Mar 2011 09:15:05 PDT 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 AF4D91B86FF for ; Mon, 28 Mar 2011 09:15:01 -0700 (PDT) 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 A4FF619006B; Mon, 28 Mar 2011 09:15:01 -0700 (PDT) (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.01.0255.000; Mon, 28 Mar 2011 09:15:01 -0700 From: Ted Lemon To: Ted Lemon Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AQHL7WNJokM44ZfFxkSPRflCY/pshg== Date: Mon, 28 Mar 2011 16:15:00 +0000 Message-ID: <6651B176-D55A-4DF7-B7C9-E69A4B4BF10A@nominum.com> References: <4D90926D.3030700@piuha.net>, <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com> In-Reply-To: <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.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 , "draft-ietf-mif-current-practices@tools.ietf.org" Subject: Re: [mif] AD review of draft-ietf-mif-current-practices X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:13:28 -0000 On Mar 28, 2011, at 5:24 PM, "Ted Lemon" wrote: > FYI, this is a rough approximation of the text I would want to add: I don't know if it's old age, stupidity or jet lag, but in case it wasn't c= lear, the document I was talking about here was the problem statement docum= ent, not the current practices document. Sorry for replying on the wrong t= hread. From Internet-Drafts@ietf.org Mon Mar 28 09:15:03 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26AF828C0EE; Mon, 28 Mar 2011 09:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+KC4TxZ1mqN; Mon, 28 Mar 2011 09:15:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1A83A67E5; Mon, 28 Mar 2011 09:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.13 Message-ID: <20110328161501.28480.221.idtracker@localhost> Date: Mon, 28 Mar 2011 09:15:01 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-current-practices-09.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:15:03 -0000 --NextPart 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 : Current Practices for Multiple Interface Hosts Author(s) : M. Wasserman, P. Seite Filename : draft-ietf-mif-current-practices-09.txt Pages : 23 Date : 2011-03-28 An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document summarizes current practices in this area, and describes in detail how some common operating systems cope with these challenges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mif-current-practices-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-28090312.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Mon Mar 28 09:38:15 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17BA328C104; Mon, 28 Mar 2011 09:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mot058WN6RPx; Mon, 28 Mar 2011 09:38:14 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602633A6A5E; Mon, 28 Mar 2011 09:38:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.13 Message-ID: <20110328163814.1159.77824.idtracker@localhost> Date: Mon, 28 Mar 2011 09:38:14 -0700 Cc: mif@ietf.org Subject: [mif] Last Call: (Current Practices for Multiple Interface Hosts) to Informational RFC X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:38:15 -0000 The IESG has received a request from the Multiple Interfaces WG (mif) to consider the following document: - 'Current Practices for Multiple Interface Hosts' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mif-current-practices/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mif-current-practices/ No IPR declarations have been submitted directly on this I-D. From ajs@shinkuro.com Mon Mar 28 09:57:47 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA1A3A6A5E for ; Mon, 28 Mar 2011 09:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcGNL6c+WzWd for ; Mon, 28 Mar 2011 09:57:46 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 605BA3A6A35 for ; Mon, 28 Mar 2011 09:57:46 -0700 (PDT) Received: from shinkuro.com (dhcp-250f.meeting.ietf.org [130.129.37.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 118F71ECB41D; Mon, 28 Mar 2011 16:59:21 +0000 (UTC) Date: Mon, 28 Mar 2011 12:59:05 -0400 From: Andrew Sullivan To: Ted Lemon Message-ID: <20110328165904.GA86314@crankycanuck.ca> References: <20110328120819.GE85777@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mif@ietf.org" Subject: Re: [mif] DNSSEC trust anchors as a side channel for preferring an interface X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:57:47 -0000 On Mon, Mar 28, 2011 at 03:53:37PM +0000, Ted Lemon wrote: > > Be that as it may, the main point of this exercise was to provide a > way for securely detecting an attempt to spoof DNS responses for a > signed zone--that is, a way to prevent this option from serving as a > mechanism for bypassing DNSSEC. In order for that to happen, both > copies of the zone have to validate to the root; it is the fact that > the spoofed zone will fail to validate to the root that allows us to > discard it. The idea of differentiating between different zones on No. You can discard it because it fails validation to some trust anchor you have. You could have lots of them. What I was suggesting is that we could use that trick to tell us which interface to prefer for a zone, in case more than one interface told us it was supported. What wasn't clear to me after today is whether we think that's something we ever need to care about. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ted.Lemon@nominum.com Mon Mar 28 10:55:15 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7968E3A6A2A for ; Mon, 28 Mar 2011 10:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f921nZKxUG7Q for ; Mon, 28 Mar 2011 10:55:14 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 05DBE3A67D1 for ; Mon, 28 Mar 2011 10:55:13 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTZDL46fp9fOLEsSlBF5hONOXt5n6YUtO@postini.com; Mon, 28 Mar 2011 10:56:52 PDT 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 E63BF1B86FC for ; Mon, 28 Mar 2011 10:56:50 -0700 (PDT) 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 B68EC190069; Mon, 28 Mar 2011 10:56:50 -0700 (PDT) (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.01.0255.000; Mon, 28 Mar 2011 10:56:50 -0700 From: Ted Lemon To: Andrew Sullivan Thread-Topic: [mif] DNSSEC trust anchors as a side channel for preferring an interface Thread-Index: AQHL7Wl+bHGQFrzPhES3PN1VBrD8eJRDCDMt Date: Mon, 28 Mar 2011 17:56:50 +0000 Message-ID: <05995AB2-0364-4C3C-8C07-EA45386E3B69@nominum.com> References: <20110328120819.GE85777@crankycanuck.ca> , <20110328165904.GA86314@crankycanuck.ca> In-Reply-To: <20110328165904.GA86314@crankycanuck.ca> 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] DNSSEC trust anchors as a side channel for preferring an interface X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:55:15 -0000 On Mar 28, 2011, at 6:59 PM, "Andrew Sullivan" wrote: > No. You can discard it because it fails validation to some trust > anchor you have. You could have lots of them. What I was suggesting > is that we could use that trick to tell us which interface to prefer > for a zone, in case more than one interface told us it was supported. Sorry to be dense, but to which trick are you referring? In general I don't think we really want to require people to configure trus= t anchors, although in principle I suppose that's a valid way to do things,= presuming that the support were there in the DNSSEC implementation, which = I think you said is not the case. From teemu.savolainen@nokia.com Mon Mar 28 14:36:59 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367443A6967 for ; Mon, 28 Mar 2011 14:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTWL9w+ZUi6V for ; Mon, 28 Mar 2011 14:36:58 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id BA6733A6873 for ; Mon, 28 Mar 2011 14:36:57 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2SLc3sR002892; Tue, 29 Mar 2011 00:38:32 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 00:38:16 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 28 Mar 2011 23:38:16 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 23:38:15 +0200 From: To: , Thread-Topic: [mif] DNSSEC trust anchors as a side channel for preferring an interface Thread-Index: AQHL7WmAN8aynL0Xekm8veAFRrZX6ZRDRO7g Date: Mon, 28 Mar 2011 21:38:14 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962015C00@008-AM1MPN1-036.mgdnok.nokia.com> References: <20110328120819.GE85777@crankycanuck.ca> <20110328165904.GA86314@crankycanuck.ca> In-Reply-To: <20110328165904.GA86314@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2011 21:38:16.0742 (UTC) FILETIME=[72CECC60:01CBED90] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] DNSSEC trust anchors as a side channel for preferring an interface X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 21:36:59 -0000 In the text I actually tried to cover both of these cases:=20 - protect against domain hijacking - in case of different but validated answers choose the more preferred one If we want to scope down the solution a bit, we might want to focus only on= protecting against hijacking and not cover selection between multiple vali= dated responses? Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext Andrew Sullivan > Sent: 28. maaliskuuta 2011 18:59 > To: Ted Lemon > Cc: mif@ietf.org > Subject: Re: [mif] DNSSEC trust anchors as a side channel for > preferring an interface >=20 > On Mon, Mar 28, 2011 at 03:53:37PM +0000, Ted Lemon wrote: > > > > Be that as it may, the main point of this exercise was to provide a > > way for securely detecting an attempt to spoof DNS responses for a > > signed zone--that is, a way to prevent this option from serving as a > > mechanism for bypassing DNSSEC. In order for that to happen, both > > copies of the zone have to validate to the root; it is the fact that > > the spoofed zone will fail to validate to the root that allows us to > > discard it. The idea of differentiating between different zones on >=20 > No. You can discard it because it fails validation to some trust > anchor you have. You could have lots of them. What I was suggesting > is that we could use that trick to tell us which interface to prefer > for a zone, in case more than one interface told us it was supported. >=20 > What wasn't clear to me after today is whether we think that's > something we ever need to care about. >=20 > A >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From teemu.savolainen@nokia.com Mon Mar 28 15:28:11 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41F63A679F for ; Mon, 28 Mar 2011 15:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANP80LcS3h4y for ; Mon, 28 Mar 2011 15:28:10 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 2CA693A65A5 for ; Mon, 28 Mar 2011 15:28:09 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2SMTkiK006661; Tue, 29 Mar 2011 01:29:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 01:29:46 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 29 Mar 2011 00:29:46 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Tue, 29 Mar 2011 00:29:45 +0200 From: To: , Thread-Topic: [mif] Comments on draft-ietf-mif-dns-server-selection-01 Thread-Index: AQHL7T2VVgIU2Jh5UkG+cybp2+5g35RDR9gw Date: Mon, 28 Mar 2011 22:29:45 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696201647D@008-AM1MPN1-036.mgdnok.nokia.com> References: <20110328114453.GD85777@crankycanuck.ca> In-Reply-To: <20110328114453.GD85777@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.64.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2011 22:29:46.0523 (UTC) FILETIME=[A475F6B0:01CBED97] X-Nokia-AV: Clean Subject: Re: [mif] Comments on draft-ietf-mif-dns-server-selection-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:28:11 -0000 SGkgQW5kcmV3LA0KDQpPZiB0aG9zZSB0d28gdGhlIGNhc2UgMSBpcyBzb21ldGhpbmcgd2UgaGF2 ZSB0YXJnZXRlZCB3aXRoIHRoaXMgZG9jdW1lbnQgYW5kIHRoZSBjYXNlIDIgaXMgc29tZXRoaW5n IEkgdGhpbmsgaXMgdmVyeSBoYXJkIHRvIHRhY2tsZSB3aXRoIGEgcHJvdG9jb2wuIEFzIHdlJ3Zl IHNlZW4sIHRoZSBjYXNlIDIgbWlnaHQgZXZlbiBsZWFkIHVzZXIgdG8gdGhlIHNhbWUgc2Vydmlj ZSwgYnV0IG9uZSB0aGF0IHByb3ZpZGVzIG1vcmUgb3IgbGVzcyBkaWZmZXJlbnQgc2VydmljZSBk ZXBlbmRpbmcgb24gcGVyY2VpdmVkIGxvY2F0aW9uIG9mIHRoZSB1c2VyLi4uDQoNCkhlbmNlIEkg d291bGQgc2NvcGUgc29sdXRpb24gb25seSB0byB0aGUgY2FzZSAxLg0KDQpJIGxvb2tlZCBhdCBS RkM0MDM1IHRoYXQgc2F5czoNCi0tDQogICBBIHJlc29sdmVyIE1VU1QgZGlzcmVnYXJkIHRoZSBt ZWFuaW5nIG9mIHRoZSBDRCBhbmQgQUQgYml0cyBpbiBhDQogICByZXNwb25zZSB1bmxlc3MgdGhl IHJlc3BvbnNlIHdhcyBvYnRhaW5lZCBieSB1c2luZyBhIHNlY3VyZSBjaGFubmVsDQogICBvciB0 aGUgcmVzb2x2ZXIgd2FzIHNwZWNpZmljYWxseSBjb25maWd1cmVkIHRvIHJlZ2FyZCB0aGUgbWVz c2FnZQ0KICAgaGVhZGVyIGJpdHMgd2l0aG91dCB1c2luZyBhIHNlY3VyZSBjaGFubmVsLg0KLS0N Cg0KU28gbWF5YmUgc29tZXRoaW5nIGxpa2UgdGhpcyB3b3VsZCBjb3ZlciB0aGUgdHJ1c3QgaXNz dWU6DQotLQ0KICAgQSBub2RlIE1VU1Qgbm90IHJlcXVlc3Qgb3IgYWNjZXB0IE9QVElPTl9ETlNf U0VSVkVSX1NFTEVDVCANCiAgIHVubGVzcyB0aGUgb3B0aW9uIHdhcyByZWNlaXZlZCBieSB1c2lu ZyBhIHNlY3VyZSBjaGFubmVsDQogICBvciB0aGUgbm9kZSB3YXMgc3BlY2lmaWNhbGx5IGNvbmZp Z3VyZWQgdG8gcmVnYXJkIHRoZSBvcHRpb24NCiAgIHdpdGhvdXQgdXNpbmcgYSBzZWN1cmUgY2hh bm5lbC4NCi0tDQpVbmxlc3MgaXQgbGltaXRzIHRoZSBhcHBsaWNhYmlsaXR5IHRvbyBtdWNoPyBB bnlob3csIGZvciB0aGUgdXNlIGNhc2VzIHdlIHRhcmdldCB0aGF0IHByb2JhYmx5IHdvdWxkIHN1 aXQsIGFzIHdlIGNvdWxkIGNvbnNpZGVyIGNlbGx1bGFyIGludGVyZmFjZXMgYXMgc2VjdXJlIGNo YW5uZWwuDQoNClRoZSBETlNTRUMgdGV4dHMgYXJlIGdvb2QsIHRoYW5rIHlvdS4gVGhlIGZpcnN0 IHBhcnQgd2lsbCBmaW5kIHBsYWNlIGluIHRoZSBkb2N1bWVudCwgZm9yIHRoZSBzZWNvbmQgbGV0 J3MgZGVjaWRlIGlmIHdlIHdhbnQgdHJ1c3QgYW5jaG9yIGRlcGVuZGVudCByZXNwb25zZSBzZWxl Y3Rpb24gaW5jbHVkZWQgb3Igbm90Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCglUZWVtdQ0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1pZi1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBleHQgQW5kcmV3IFN1 bGxpdmFuDQo+IFNlbnQ6IDI4LiBtYWFsaXNrdXV0YSAyMDExIDEzOjQ1DQo+IFRvOiBtaWZAaWV0 Zi5vcmcNCj4gU3ViamVjdDogW21pZl0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1taWYtZG5zLXNl cnZlci1zZWxlY3Rpb24tMDENCj4gDQo+IERlYXIgY29sbGVhZ3VlcywNCj4gDQo+IEkgaGF2ZSBy ZWFkIGRyYWZ0LWlldGYtbWlmLWRucy1zZXJ2ZXItc2VsZWN0aW9uLTAxLiAgSSBoYXZlIHNvbWUN Cj4gY29tbWVudHMuICBBcG9sb2dpZXMgZm9yIGhhdmluZyBmYWlsZWQgdG8gY29tbWVudCBzb29u ZXIuDQo+IA0KPiBUaGUgZnVuZGFtZW50YWwgaXNzdWUgaGVyZSBpcyBzcGxpdCBob3Jpem9uIERO Uy4gIFRoaXMgaGFzIHR3bw0KPiBkaWZmZXJlbnQgY2FzZXM6DQo+IA0KPiAgICAgMS4gIFRoZXJl IGFyZSBzdWJzZXRzIG9mIHRoZSBuYW1lIHNwYWNlIHRoYXQgYXJlIHJlc29sdmFibGUgZnJvbQ0K PiAgICAgaW5zaWRlIG9uZSBuZXR3b3JrLCBidXQgYXJlIG5vdCByZWFsbHkgZ2xvYmFsbHkgcmVz b2x2YWJsZS4gIE9uDQo+ICAgICB0aGUgImluc2lkZSBuZXR3b3JrIiBvZiBhIGNvcnBvcmF0ZSBM QU4sIGZvciBpbnN0YW5jZSwNCj4gICAgIHByaW50ZXIxLmV4YW1wbGUuY29tIG1pZ2h0IGJlIGEg dXNlZnVsIGhvc3RuYW1lLCBidXQgbm90IG9uZSB0aGF0DQo+ICAgICBjb3VsZCBiZSByZXNvbHZl ZCBmcm9tIHRoZSBwdWJsaWMgYXV0aG9yaXRhdGl2ZSBzZXJ2ZXJzIGZvcg0KPiAgICAgZXhhbXBs ZS5jb20uICBPbiB0aGUgcHVibGljIEludGVybmV0LCBhIHF1ZXJ5IGZvcg0KPiAgICAgcHJpbnRl cjEuZXhhbXBsZS5jb20gZ2V0cyBhIE5hbWUgRXJyb3IgcmVzcG9uc2UuDQo+IA0KPiAgICAgMi4g IFRoZXJlIGFyZSBzdWJzZXRzIG9mIHRoZSBuYW1lIHNwYWNlIHRoYXQgYXJlIGdsb2JhbGx5DQo+ ICAgICByZXNvbHZhYmxlLCBidXQgdGhhdCByZXNvbHZlIGRpZmZlcmVudGx5IGRlcGVuZGluZyBv bmUncw0KPiAgICAgbmV0d29yay10b3BvbG9naWMgbG9jYXRpb24uICBUaGUgb2J2aW91cyBleGFt cGxlIGlzDQo+ICAgICB3d3cuZXhhbXBsZS5jb20sIHdoaWNoIGlzIHRoZSBwdWJsaWMgd2ViIHNl cnZlciBmb3IgZXZlcnlvbmUgaW4NCj4gICAgIHRoZSB3b3JsZCBidXQgd2hpY2ggcHJvdmlkZXMg YSBkaWZmZXJlbnQgZXhwZXJpZW5jZSBpbnNpZGUgdGhlDQo+ICAgICBjb3Jwb3JhdGUgbmV0d29y ayAoYW5kIGluZGVlZCwgd2hpY2ggbWF5IGJlIGEgY29tcGxldGVseSBkaWZmZXJlbnQNCj4gICAg IGhvc3QpLg0KPiANCj4gVGhlIHJlYXNvbiBJIHdhbnQgdG8gZGlzdGluZ3Vpc2ggdGhlc2UgaXMg dGhhdCwgaWYgb25lIGNvbnRhY3RzIHRoZQ0KPiB3cm9uZyBuYW1lIHNlcnZlciBpbiBjYXNlICgx KSwgaXQgaXMgb25seSBhIGRlbmlhbCBvZiBzZXJ2aWNlOyB3aGVyZWFzDQo+IGlmIG9uZSBjb250 YWN0cyB0aGUgd3JvbmcgbmFtZSBzZXJ2ZXIgaW4gY2FzZSAoMiksIG9uZSBnb2VzIHRvIHRoZQ0K PiB3cm9uZyBwbGFjZS4gICgxKSBjYW4gYmUgZWFzaWx5IGRldGVjdGVkIGJ5IGV2ZW4gdGhlIG1v c3QgbmHDr3ZlIHVzZXIsDQo+IHdoZXJlYXMgKDIpIG1pZ2h0IG5vdCBiZSBvYnZpb3VzLg0KPiAN Cj4gV2hpbGUgSSB0aGluayB0aGUgVlBOIGNhc2UgaXMgaW1wb3J0YW50LCB3aGV0aGVyIG9uZSBo YXBwZW5zIHRvIGJlDQo+IHVzaW5nIGEgVlBOIG9yIGhhcHBlbnMgaW5zdGVhZCB0byBiZSBhdHRh Y2hlZCB0byBtb3JlIHRoYW4gb25lIG5ldHdvcmsNCj4gaXMgc29ydCBvZiBpcnJlbGV2YW50IHRv IHRoZSBtYXR0ZXI6IHRoZSBWUE4gaXMgYSBjb21wZWxsaW5nIHVzZS1jYXNlLA0KPiBidXQgdGhl IGJhc2ljIGlzc3VlIGlzIGp1c3QgYSBzcGxpdCBob3Jpem9uLg0KPiANCj4gSSBmaW5kIHNvbWUg YXBwZWFsIGluIGl0cyB1c2Ugb2YgYSBkaGNwIG9wdGlvbiB0byBzYXksICJJIGtub3cgYWJvdXQN Cj4gW25hbWUgc3BhY2VzXS4iICBBcyB0aGUgZHJhZnQgc3RhbmRzLCBpdCBpcyBub3QgZXhhY3Rs eSBjbGVhciBob3cgdG8NCj4gZXh0YWJsaXNoIHRydXN0IGluIHRoaXMgYW5ub3VuY2VtZW50LCBo b3dldmVyLiAgVGhpcyBzZWVtcyBsaWtlIGEgbmV3DQo+IHdheSBmb3Igd2lyZWxlc3MgaG90cG90 cyB0byBoaWphY2sgbXkgY29ycG9yYXRlIGxvb2t1cHMsIHNvIGl0IGJ1Z3MNCj4gbWUuICBUaGUg ZHJhZnQgb24gc2V2ZXJhbCBvY2Nhc2lvbnMgdGFsa3MgYWJvdXQgYSBjb25uZWN0aW9uIGJlaW5n DQo+ICJjb25zaWRlcmVkIHNlY3VyZSIsIGFuZCBJIGFtIGdyYXZlbHkgd29ycmllZCB0aGF0IHVu cGFja2luZyB0aGF0DQo+IG1lYW5pbmcgb2YgInNlY3VyZSIgaXMgc3RpbGwgdG8gYmUgZG9uZS4N Cj4gDQo+IEkgdGhpbmsgd2hhdCBjb3VsZCBoZWxwIGlzIGEgY2xlYXJlciBhY2NvdW50IG9mIGV4 YWN0bHkgd2hhdCBhc3N1cmFuY2UNCj4gb25lIGNhbiBnZXQgZnJvbSBETlNTRUMgYW5kIGhvdyBp dCBtYXkgaGVscCwgd2hhdCBhc3N1cmFuY2Ugb25lIGNhbg0KPiBnZXQgZnJvbSBjb25maWd1cmF0 aW9uIHRoYXQgaXMgc29tZWhvdyBleHRlcm5hbGx5IGFzc3VyZWQgKG9yIGV2ZW4NCj4ganVzdCBh IHJlbWFyayB0aGF0ICJob3cgdG8gZGV0ZXJtaW5lIHRydXN0IGluIHRoZXNlIGNhc2VzIGlzLi4u Ig0KPiBbdW5kZWZpbmVkfGJleW9uZCBzY29wZXxkZWZpbmVkIGluIHtyZWZ9XSkuDQo+IA0KPiBI ZXJlIGFyZSBzb21lIHdheXMgdGhhdCB5b3UgY2FuIGRvIHVzZWZ1bCB2YWxpZGF0aW9uIHdpdGgg RE5TU0VDLiAgVG8NCj4gbWUsIHRoaXMgaXNuJ3QgY2xlYXIgaW4gdGhlIGRyYWZ0IGFzIGl0IGlz LiAgSSdtIG5vdCBzdXJlIHdoZXJlIHRvIHB1dA0KPiBhbnkgb2YgdGhlIGZvbGxvd2luZy4NCj4g DQo+ICAgICBCZWNhdXNlIEROU1NFQyBwcm92aWRlcyBjcnlwdG9ncmFwaGljIGFzc3VyYW5jZSBv ZiB0aGUgaW50ZWdyaXR5DQo+ICAgICBvZiBETlMgZGF0YSwgZGF0YSB0aGF0IGNhbiBiZSB2YWxp ZGF0ZWQgdW5kZXIgRE5TU0VDIGlzDQo+ICAgICBuZWNlc3NhcmlseSB0byBiZSBwcmVmZXJyZWQg b3ZlciBkYXRhIHRoYXQgY2Fubm90IGJlLiAgSXQgZm9sbG93cw0KPiAgICAgdGhhdCwgaWYgdmFs aWRhdGlvbiBpcyBub3QgcGVyZm9ybWVkIGJ5IHRoZSBob3N0IG1ha2luZyB0aGUNCj4gICAgIGRl Y2lzaW9uIGFib3V0IHdoZXRoZXIgdG8gdHJ1c3QgdGhlIEROUyBkYXRhIGZyb20gYSBnaXZlbg0K PiAgICAgaW50ZXJmYWNlLCBpdCBjYW5ub3QgbWFrZSBhIGRlY2lzaW9uIHRvIHByZWZlciBkYXRh IGZyb20gYW55DQo+ICAgICBpbnRlcmZhY2Ugd2l0aCBhbnkgZ3JlYXQgYXNzdXJhbmNlOiBhbnkg cmVzcG9uc2UgY291bGQgYmUgZm9yZ2VkLA0KPiAgICAgYW5kIHRoZXJlIGlzIG5vIHdheSB0byBk ZXRlY3QgaXQgd2l0aG91dCBETlNTRUMuDQo+IA0KPiANCj4gDQo+ICAgICBJbiB2YWxpZGF0aWlu ZyBETlMgYW5zd2VycyB3aXRoIEROU1NFQywgYSB2YWxpZGF0b3IgbWlnaHQgb3JkZXINCj4gICAg IHRoZSBsaXN0IG9mIHRydXN0IGFuY2hvcnMgaXQgdXNlcyB0byBzdGFydCB2YWxpZGF0aW9uIGNo YWlucywgaW4NCj4gICAgIHRlcm1zIG9mIHRoZSBob3N0J3MgcHJlZmVyZW5jZXMgZm9yIHRob3Nl IHRydXN0IGFuY2hvcnMuICBBIGhvc3QNCj4gICAgIGNvdWxkIHVzZSB0aGlzIGFiaWxpdHkgaW4g b3JkZXIgdG8gc2VsZWN0IGFtb25nIGFsdGVybmF0aXZlDQo+ICAgICBETlMgcmVzdWx0cyBmcm9t IGRpZmZlcmVudCBpbnRlcmZhY2VzLiAgU3VwcG9zZSB0aGF0IGEgaG9zdCBoYXMNCj4gICAgIGEg dHJ1c3QgYW5jaG9yIGZvciB0aGUgcHVibGljIEROUyByb290LCBhbmQgYWxzbyBoYXMgYQ0KPiAg ICAgc3BlY2lhbC1wdXJwb3NlIHRydXN0IGFuY2hvciBmb3IgZXhhbXBsZS5jb20uICBBbiBhbnN3 ZXIgaXMNCj4gICAgIHJlY2VpdmVkIG9uIGludGVyZmFjZSBpMSBmb3Igd3d3LmV4YW1wbGUuY29t LCBhbmQgdGhlIHZhbGlkYXRpb24NCj4gICAgIGZvciB0aGF0IHN1Y2NlZWRzIGJ5IHVzaW5nIHRo ZSBwdWJsaWMgdHJ1c3QgYW5jaG9yLiAgQWxzbywgYW4NCj4gICAgIGFuc3dlciBpcyByZWNlaXZl ZCBvbiBpbnRlcmZhY2UgaTIgZm9yIHd3dy5leGFtcGxlLmNvbSwgYW5kIHRoZQ0KPiAgICAgdmFs aWRhdGlvbiBmb3IgdGhhdCBzdWNjZWVkcyBieSB1c2luZyB0aGUgdHJ1c3QgYW5jaG9yIGZvcg0K PiAgICAgZXhhbXBsZS5jb20uICBJbiB0aGlzIGNhc2UsIHRoZSBob3N0IGhhcyBldmlkZW5jZSBm b3IgcmVseWluZyBvbg0KPiAgICAgaTIgZm9yIGFuc3dlcnMgaW4gdGhlIGV4YW1wbGUuY29tIHpv bmUuDQo+IA0KPiBJIGhvcGUgdGhpcyBpcyBoZWxwZnVsDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+ IA0KPiBBDQo+IA0KPiAtLQ0KPiBBbmRyZXcgU3VsbGl2YW4NCj4gYWpzQHNoaW5rdXJvLmNvbQ0K PiBTaGlua3VybywgSW5jLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBtaWYgbWFpbGluZyBsaXN0DQo+IG1pZkBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZg0K From Ted.Lemon@nominum.com Mon Mar 28 23:31:16 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0F93A6802 for ; Mon, 28 Mar 2011 23:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1kr5qOINQq2 for ; Mon, 28 Mar 2011 23:31:15 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 89E293A67EF for ; Mon, 28 Mar 2011 23:31:14 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTZF9FE7YWbEpc4kJR9YcwftfmjpC6hda@postini.com; Mon, 28 Mar 2011 23:32:53 PDT 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 503231B8798 for ; Mon, 28 Mar 2011 23:32:52 -0700 (PDT) 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 42CF519006C; Mon, 28 Mar 2011 23:32:52 -0700 (PDT) (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.01.0255.000; Mon, 28 Mar 2011 23:32:52 -0700 From: Ted Lemon To: "teemu.savolainen@nokia.com" Thread-Topic: [mif] DNSSEC trust anchors as a side channel for preferring an interface Thread-Index: AQHL7Wl+bHGQFrzPhES3PN1VBrD8eJRDu2gAgACT44A= Date: Tue, 29 Mar 2011 06:32:51 +0000 Message-ID: <6F6B254A-B001-4626-82B1-D8D7A6941B9D@nominum.com> References: <20110328120819.GE85777@crankycanuck.ca> <20110328165904.GA86314@crankycanuck.ca> <916CE6CF87173740BC8A2CE443096962015C00@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962015C00@008-AM1MPN1-036.mgdnok.nokia.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-ID: <2DC60F930C8EDE44B99FB6EF726502C7@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] DNSSEC trust anchors as a side channel for preferring an interface X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 06:31:16 -0000 On Mar 28, 2011, at 11:38 PM, "teemu.savolainen@nokia.com" wrote: > If we want to scope down the solution a bit, we might want to focus only = on protecting against hijacking and not cover selection between multiple va= lidated responses? That seems okay to me. It should be possible to choose between two differen= t validated responses on the basis of the server preference option without = resorting to checking for differences in keys. Although I must admit that = this still requires an extended API.=20 From Ted.Lemon@nominum.com Mon Mar 28 23:46:03 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F63B3A683B for ; Mon, 28 Mar 2011 23:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlB+idvBRswh for ; Mon, 28 Mar 2011 23:46:02 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 1DC053A67D0 for ; Mon, 28 Mar 2011 23:46:01 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTZGAixZmFVSmr1x0Yjm5B98aLZ02Cy5r@postini.com; Mon, 28 Mar 2011 23:47:40 PDT 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 9DD231B80C6 for ; Mon, 28 Mar 2011 23:47:35 -0700 (PDT) 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 89BA819006C; Mon, 28 Mar 2011 23:47:35 -0700 (PDT) (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.01.0255.000; Mon, 28 Mar 2011 23:47:35 -0700 From: Ted Lemon To: "teemu.savolainen@nokia.com" Thread-Topic: [mif] Comments on draft-ietf-mif-dns-server-selection-01 Thread-Index: AQHL7T2TZudS6uSp00WtSjuDIkpv2ZRDyiSAgAAVv0w= Date: Tue, 29 Mar 2011 06:47:34 +0000 Message-ID: References: <20110328114453.GD85777@crankycanuck.ca>, <916CE6CF87173740BC8A2CE44309696201647D@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696201647D@008-AM1MPN1-036.mgdnok.nokia.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] Comments on draft-ietf-mif-dns-server-selection-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 06:46:03 -0000 On Mar 29, 2011, at 12:29 AM, "teemu.savolainen@nokia.com" wrote: I think there are four cases to consider here: 1. The server selection option is delivered across a secure, trusted channe= l. 2. The server selection option is not secure, but the client does DNSSEC va= lidation. 3. The server selection option is not secure, the resolver does DNSSEC vali= dation, and the client communicates with the resolver over a secure, truste= d channel. 4. The DNS server IP address that is being recommended in the server select= ion option is known and trusted by the client; that is, the server selectio= n option serves not to introduce the client to a new server, but rather to = inform it that a server it has already been configured to trust is availabl= e to it for resolving certain domains. I think any use of the server selection option that falls outside of these = four cases should be excluded. By excluding such cases, we eliminate the = possibility that the server selection option can be used to initiate an att= ack that could not be initiated without it. I think that trusting the cell provider connection is something that needs = to be thought through carefully. It may in fact be okay to do so. But i= t depends on that channel being both secure and trusted, not just trusted. = In DHCP it's somewhat traditional to trust provider channels even though t= hey aren't cryptographically secure, and we get away with this because they= are in fact in secure locations, and the information we're trusting isn't = that sensitive. But those two rationalizations don't apply here--cell ser= vice is done by radio, and hence not in a secure location, and the informat= ion we propose to trust is in fact quite sensitive.= From teemu.savolainen@nokia.com Tue Mar 29 00:45:53 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FAA63A68BA for ; Tue, 29 Mar 2011 00:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVYfenGFgjAk for ; Tue, 29 Mar 2011 00:45:52 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id D83EF3A6A83 for ; Tue, 29 Mar 2011 00:45:51 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2T7lSfN001050; Tue, 29 Mar 2011 10:47:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 10:47:20 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 29 Mar 2011 09:47:20 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Tue, 29 Mar 2011 09:47:19 +0200 From: To: Thread-Topic: [mif] Comments on draft-ietf-mif-dns-server-selection-01 Thread-Index: AQHL7T2VVgIU2Jh5UkG+cybp2+5g35RDR9gwgAB2gwCAACvaoA== Date: Tue, 29 Mar 2011 07:47:18 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962016624@008-AM1MPN1-036.mgdnok.nokia.com> References: <20110328114453.GD85777@crankycanuck.ca>, <916CE6CF87173740BC8A2CE44309696201647D@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.70.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2011 07:47:20.0434 (UTC) FILETIME=[888BAD20:01CBEDE5] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-ietf-mif-dns-server-selection-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:45:53 -0000 Then maybe something like (slight modification): -- A node MAY request and accept OPTION_DNS_SERVER_SELECT in any of the follow= ing four cases. In other cases the node MUST NOT request or accept OPTION_D= NS_SERVER_SELECT unless the node is specifically configured to do so. 1. The server selection option is delivered across a secure, trusted channe= l. 2. The server selection option is not secured, but the client on a node doe= s DNSSEC validation. 3. The server selection option is not secured, the resolver does DNSSEC val= idation, and the client communicates with the resolver configured with serv= er selection option over a secure, trusted channel. 4. The DNS server IP address that is being recommended in the server select= ion option is known and trusted by the client; that is, the server selectio= n option serves not to introduce the client to a new server, but rather to = inform it that a server it has already been configured to trust is availabl= e to it for resolving certain domains. -- Where the case 4 could happen? When the trusted DNS server address is confi= gured via some secure channel (e.g. administratively)? The cellular interface (handset to first hop router) is AFAIK considered cr= yptographically secure. But anyhow, decision whether a channel is secure en= ough or not needs to be done case by case (e.g. by 3GPP(2), WiMAX Forum, BB= F...). Best regards, Teemu > -----Original Message----- > From: ext Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: 29. maaliskuuta 2011 08:48 > To: Savolainen Teemu (Nokia-MS/Tampere) > Cc: ajs@shinkuro.com; mif@ietf.org > Subject: Re: [mif] Comments on draft-ietf-mif-dns-server-selection-01 >=20 > On Mar 29, 2011, at 12:29 AM, "teemu.savolainen@nokia.com" > wrote: >=20 > I think there are four cases to consider here: >=20 > 1. The server selection option is delivered across a secure, trusted > channel. > 2. The server selection option is not secure, but the client does > DNSSEC validation. > 3. The server selection option is not secure, the resolver does DNSSEC > validation, and the client communicates with the resolver over a > secure, trusted channel. > 4. The DNS server IP address that is being recommended in the server > selection option is known and trusted by the client; that is, the > server selection option serves not to introduce the client to a new > server, but rather to inform it that a server it has already been > configured to trust is available to it for resolving certain domains. >=20 > I think any use of the server selection option that falls outside of > these four cases should be excluded. By excluding such cases, we > eliminate the possibility that the server selection option can be used > to initiate an attack that could not be initiated without it. >=20 > I think that trusting the cell provider connection is something that > needs to be thought through carefully. It may in fact be okay to do > so. But it depends on that channel being both secure and trusted, not > just trusted. In DHCP it's somewhat traditional to trust provider > channels even though they aren't cryptographically secure, and we get > away with this because they are in fact in secure locations, and the > information we're trusting isn't that sensitive. But those two > rationalizations don't apply here--cell service is done by radio, and > hence not in a secure location, and the information we propose to trust > is in fact quite sensitive. From Ted.Lemon@nominum.com Tue Mar 29 00:57:06 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F9A3A6A83 for ; Tue, 29 Mar 2011 00:57:06 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8AHiQ-o-Ttw for ; Tue, 29 Mar 2011 00:57:05 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 6DA523A69FC for ; Tue, 29 Mar 2011 00:57:05 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTZGRMhjTyLisOoPPX8zvXE6EuLwvPNJO@postini.com; Tue, 29 Mar 2011 00:58:43 PDT 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 46593F80A5 for ; Tue, 29 Mar 2011 00:58:42 -0700 (PDT) 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 3A62719006C; Tue, 29 Mar 2011 00:58:42 -0700 (PDT) (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.01.0255.000; Tue, 29 Mar 2011 00:58:42 -0700 From: Ted Lemon To: "teemu.savolainen@nokia.com" Thread-Topic: [mif] Comments on draft-ietf-mif-dns-server-selection-01 Thread-Index: AQHL7T2TZudS6uSp00WtSjuDIkpv2ZRDyiSAgAAVv0yAAIYIAP//jdfK Date: Tue, 29 Mar 2011 07:58:42 +0000 Message-ID: References: <20110328114453.GD85777@crankycanuck.ca>, <916CE6CF87173740BC8A2CE44309696201647D@008-AM1MPN1-036.mgdnok.nokia.com> , <916CE6CF87173740BC8A2CE443096962016624@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962016624@008-AM1MPN1-036.mgdnok.nokia.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] Comments on draft-ietf-mif-dns-server-selection-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:57:06 -0000 On Mar 29, 2011, at 9:47 AM, "teemu.savolainen@nokia.com" wrote: > Where the case 4 could happen? When the trusted DNS server address is con= figured via some secure channel (e.g. administratively)? Yes, that's the case I had in mind. It's probably worth defining the term= s more clearly if there is agreement on the set of four requirements that I= suggested, but I'm curious to know if Andrew and Peter think they make sen= se. From ajs@shinkuro.com Tue Mar 29 05:48:59 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172AC3A681B for ; Tue, 29 Mar 2011 05:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obF4wa8NcM1f for ; Tue, 29 Mar 2011 05:48:56 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 36FCF3A67F0 for ; Tue, 29 Mar 2011 05:48:56 -0700 (PDT) Received: from shinkuro.com (unknown [130.129.99.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 21F3A1ECB41D; Tue, 29 Mar 2011 12:50:32 +0000 (UTC) Date: Tue, 29 Mar 2011 08:50:26 -0400 From: Andrew Sullivan To: Ted Lemon Message-ID: <20110329125026.GH88058@crankycanuck.ca> References: <20110328114453.GD85777@crankycanuck.ca> <916CE6CF87173740BC8A2CE44309696201647D@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962016624@008-AM1MPN1-036.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mif@ietf.org" Subject: Re: [mif] Comments on draft-ietf-mif-dns-server-selection-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:48:59 -0000 On Tue, Mar 29, 2011 at 07:58:42AM +0000, Ted Lemon wrote: > On Mar 29, 2011, at 9:47 AM, "teemu.savolainen@nokia.com" wrote: > > Where the case 4 could happen? When the trusted DNS server address is configured via some secure channel (e.g. administratively)? > > Yes, that's the case I had in mind. It's probably worth defining the terms more clearly if there is agreement on the set of four requirements that I suggested, but I'm curious to know if Andrew and Peter think they make sense. This was more or less what I had in mind with the many trust anchor thing as well. Essentially, the idea is that you use the DNSSEC trust anchor as something similar to a VPN config: you need some prior configuration. By having this extra Trust Anchor, you can have something that proves your claims cryptographically. But I'm still not sure whether that's a use case we care about (it sounds like "no", to me). A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From margaretw42@gmail.com Tue Mar 29 06:18:10 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856153A690F for ; Tue, 29 Mar 2011 06:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh+SD+hrUgUI for ; Tue, 29 Mar 2011 06:17:55 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 6E7BD3A68F0 for ; Tue, 29 Mar 2011 06:17:53 -0700 (PDT) Received: by bwz13 with SMTP id 13so185346bwz.31 for ; Tue, 29 Mar 2011 06:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:content-type :content-transfer-encoding:mime-version:subject:date:cc:x-mailer; bh=w+YPc4mvXGQ+H9CcUmVJBub7y67cpKxQVprAHGa9UmY=; b=WbedftiKBK8loIrlQmDYb0WeJr4bDJxxZ+DI7mcoy2m/IWN2uvCVMwLrQOmLELiX4V YHTQFTEzwEoNgVVZoo4n9Z5Az2xwBPEBm7Q5H4mXER7jsn1d70UUgRy/QcOjA/86UgMN Xwwi5fpCGZqRwRcKjEjccmw+WXew4XC3eFZU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=P161zTU85gWbKFN72lmkPaQqhl1o5pVATYDDbBNBrrWJkcxDWOjje9IdX3Rvb3kXDk paY/FcGvYzH2z4eCIf6H+4okre7TJCXroygIOcxl4Yl/UlHLAbDLqW58JjWfp3B4UQ3A 3vfWLms9FjUMMQuTnW175hFo/u4m28ZO8lAgM= Received: by 10.204.84.142 with SMTP id j14mr4624045bkl.20.1301404770489; Tue, 29 Mar 2011 06:19:30 -0700 (PDT) Received: from dhcp-1138.meeting.ietf.org ([130.129.17.56]) by mx.google.com with ESMTPS id v21sm3425667bkt.23.2011.03.29.06.19.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 06:19:25 -0700 (PDT) Message-Id: From: Margaret Wasserman To: mif@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 29 Mar 2011 15:19:19 +0200 X-Mailer: Apple Mail (2.936) Cc: Shoaib Rao , Hui Deng , Dave Thaler , Gabriel Montenegro Subject: [mif] Connection/Session Manager Info Discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:18:10 -0000 Hi All, As I mentioned in the WG, I would like to have an off-line discussion with people who are interested in the "Connection Manager" (or "Session Manager") approach that has been discussed in the MIF WG. The IETF can't really standardize the concept of a connection manager, and we don't standardize how modules in a particular implementation talk to each other. However, there may be a possibility that different types of Connection/Session Managers need a common set of information from their attached networks (network attributes?, policy information?), and that there might be a need for a standard to define how that information is passed. During this informal meeting, we will discuss what information is needed by different Connection/Session managers, and whether there is a common set of information that would be useful across multiple implementations/node types, etc. If so, we will discuss how that information should be provided by the network (DHCP, NETCONF, SNMP, other?) and what form we should use to standardize it (DHCP option, YANG Module, MIB, other?). I have created a doodle poll to determine when people can meet about this subject. Please respond using the URL below: http://doodle.com/p34rxze96ds7mvdh At the end of the day today, I will make a determination about when we will meet and send information about where. Thanks, Margaret From swmike@swm.pp.se Tue Mar 29 22:32:42 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692043A67F8 for ; Tue, 29 Mar 2011 22:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B86PnAJs+ufa for ; Tue, 29 Mar 2011 22:32:40 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 4CCE93A6AA0 for ; Tue, 29 Mar 2011 22:32:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C21509C; Wed, 30 Mar 2011 07:34:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BEC5F9A for ; Wed, 30 Mar 2011 07:34:17 +0200 (CEST) Date: Wed, 30 Mar 2011 07:34:17 +0200 (CEST) From: Mikael Abrahamsson To: mif@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [mif] MIF and SCTP X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 05:32:42 -0000 Hello. We've been having quite a lot of operational problems when using SCTP and vendors implementing destination based routing, meaning that for a dual NIC SCTP speaker each SCTP far end IP needs to have a separate static route out to the gw of each nic to get path redundancy (two default routes doesn't work as both SCTP legs will choose the same default route). It'd be much more preferable to have two virtual routing tables with two default routes, and packets with each NIC source IP address was sent out using that NIC virtual routing table (policy routing). >From reading the MIF documents this scenario is one that is part of the problem statement, but does MIF feel like it's going to give this specific SCTP case guidance in MIF, or is this needed to be taken up via the SCTP WG? Perhaps I have missed that it already has been done, in that case I would greatly appreciate a pointer to a document I can hit our vendors over the head with. Thanks. -- Mikael Abrahamsson email: swmike@swm.pp.se From margaretw42@gmail.com Tue Mar 29 23:48:29 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42173A6B17 for ; Tue, 29 Mar 2011 23:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqEg1LCG9Lw7 for ; Tue, 29 Mar 2011 23:48:28 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id DC7CE3A6859 for ; Tue, 29 Mar 2011 23:48:27 -0700 (PDT) Received: by bwz13 with SMTP id 13so795698bwz.31 for ; Tue, 29 Mar 2011 23:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:content-type :content-transfer-encoding:mime-version:subject:date:cc:x-mailer; bh=sEgQMzNZOALVxLLDtaBFDJTY0hMeayl1ujx3406Lv2o=; b=nTb3b6N4uIHNzFLJRitlkZywhqrB2eMHeSvpbCvKGyPyNKMqOFyf0Z4G7Dt7ARh1yE bnU2hOMSPnlfX7GZV4cBmp6VbZa4kqAsKA30Dc6+soGWlCmA2UNJRIXLQyNI2QG3XJVV uTCl+XRzGw5QMG9qA48L+pM+O1OgjhX8VAKew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=o/GJqw78XBBLBJyjXWv9tRP+MnCEcWHqE4H9hPi/3Xjq3e419CWDlN8niS3zQpydET JnNtsO0+pr0JB0C730EtdbT1DPhVNDsiu11MPm0PRCQvuPMTGS4rv+ijU1/AkC25tGZo HAS+yWhmHEnU+5b7PIBgA/PXh6Fz2zZYxKzfA= Received: by 10.204.18.193 with SMTP id x1mr687906bka.79.1301467805945; Tue, 29 Mar 2011 23:50:05 -0700 (PDT) Received: from dhcp-4168.meeting.ietf.org (dhcp-4168.meeting.ietf.org [130.129.65.104]) by mx.google.com with ESMTPS id z18sm3859155bkf.20.2011.03.29.23.50.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 23:50:05 -0700 (PDT) Message-Id: <54150F18-5262-448A-8AEC-3A3DBFB66073@lilacglade.org> From: Margaret Wasserman To: Ted Lemon , Hui Deng , juancarlos.zuniga@interdigital.com, "pierrick.seite@orange-ftgroup.com Seite" , Scott Brim , Gabriel Montenegro , Stefano Faccin Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 30 Mar 2011 08:49:57 +0200 X-Mailer: Apple Mail (2.936) Cc: mif@ietf.org Subject: [mif] Connection/Session Manager Discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 06:48:29 -0000 Based on the results of the doodle poll, the connection/session manager discussion will be held from 8:00am - 9:00am tomorrow (Thursday) morning. Let's meet in the IETF registration area, and we will grab and unused room. Margaret From pierrick.seite@orange-ftgroup.com Wed Mar 30 14:49:43 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D9F3A693D for ; Wed, 30 Mar 2011 14:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.029 X-Spam-Level: X-Spam-Status: No, score=-3.029 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I96lFfgJqc26 for ; Wed, 30 Mar 2011 14:49:42 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 02A423A6ABD for ; Wed, 30 Mar 2011 14:49:42 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 536BE778002; Wed, 30 Mar 2011 23:57:23 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 49F12778001; Wed, 30 Mar 2011 23:57:23 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 23:51:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 23:51:19 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462019B5E9B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <916CE6CF87173740BC8A2CE443096962015946@008-AM1MPN1-036.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices) Thread-Index: AQHL7U9IuT4hgyWp1kuj9x/QaruM85RC3eqbgAADDKCAA4tsUA== References: <4D90926D.3030700@piuha.net> <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com> <916CE6CF87173740BC8A2CE443096962015946@008-AM1MPN1-036.mgdnok.nokia.com> From: To: , , X-OriginalArrivalTime: 30 Mar 2011 21:51:20.0792 (UTC) FILETIME=[9AF6D580:01CBEF24] Cc: mif@ietf.org Subject: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:49:43 -0000 Any other comments with regards to this text? Is there an agreement to = include it into the PS? > -----Message d'origine----- > De=A0: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Envoy=E9=A0: lundi 28 mars 2011 17:47 > =C0=A0: Ted.Lemon@nominum.com; jari.arkko@piuha.net > Cc=A0: draft-ietf-mif-current-practices@tools.ietf.org; mif@ietf.org > Objet=A0: RE: AD review of draft-ietf-mif-current-practices >=20 > Ted, >=20 > Good text. I agree the problem exist. The DNS server selection points = to > this issue as well: > -- > (DISCUSS: > What about those DNS servers that instead of negative answer always > return positive reply with an IP address of some captive portal?) > -- >=20 > IMHO the problem section should say that this problem (usually/always) > disappears right after M1 has authenticated to the captive portal and > interface becomes truly "up". I.e. human intervention is required to = clear > the situation, but once cleared, things work as they should - until > captive portal possibly wants to renew authentication.. >=20 > This problem btw means the M1 cannot start validating responses until > authentication with captive portal shas been completed. >=20 > Best regards, >=20 > Teemu >=20 >=20 > > -----Original Message----- > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf = Of > > ext Ted Lemon > > Sent: 28. maaliskuuta 2011 17:25 > > To: Jari Arkko > > Cc: draft-ietf-mif-current-practices@tools.ietf.org; mif > > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices > > > > FYI, this is a rough approximation of the text I would want to add: > > > > 4.1a. DNS resolution issues with captive portals > > > > A MIF node (M1) has an active interface(I1) connected to a = network > > (N1) which has its DNS server (S1) and another active interface > > (I2) connected to a network (N2) which has its DNS server (S2). = S1 > > is configured to respond to any A or AAAA record query with the > > IP address of a captive portal, so as to redirect web browsers to = an > > access control portal web page. Any of the following situations > > may occur: > > > > 1. M1 stack, based on its routing table, uses I2 to reach S1 to > > resolve "a.example.com". M1 never reaches S1. The name > > is not resolved. > > 2. M1 keeps only one set of DNS server addresses from the = received > > configuration objects and kept S2 address. M1 sends the > > forward DNS query for a.example.com to S2. S2 responds with = the > > correct answer, R1. M1 attempts to contact R1 by way of I1. > > The connection fails. Or, the connection succeeds, > > bypassing the security policy on N1, possibly exposing the > > owner of M1 to prosecution. > > 3. M1 keeps only one set of DNS server addresses from the = received > > configuration objects and kept S1 address. M1 sends the DNS > > query for a.example.com to S1. S1 provides the address of = its > > captive portal. S1 attempts to contact this IP address = using > > I1. The application tries to connect to the wrong = destination > > node, resulting in lack of service and possible security = issues. > > 4. M1 has resolved an FQDN to the IP address of the captive = portal > > connected to N1. If the node loses connection to N1, the = node > > may try to connect, via N2, to the same IP address as = earlier, > > but as the address was only locally valid, connection setup > > fails. > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif From scott.brim@gmail.com Thu Mar 31 00:29:51 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6371528C1E4 for ; Thu, 31 Mar 2011 00:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izWAe3rNekrQ for ; Thu, 31 Mar 2011 00:29:50 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7039C28C0D9 for ; Thu, 31 Mar 2011 00:29:50 -0700 (PDT) Received: by iye19 with SMTP id 19so2404625iye.31 for ; Thu, 31 Mar 2011 00:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=uLCURH7TxGO0VzUtbmE5VuLNoPPioB8MAE/XeInjuwM=; b=fSGPr3bx7lCKUXrJGW8hfg+6l3LSi79p3PkkTV8hWv3S7ipzdkb+Y0mCDG8eWCUg1R 0f1yin4l3QBMpOETo688YDC1L2Y3jbx78gZL5Y1QDBAFTCna+Vi4Y56QcQYKjBCLOqUW P86RklFLlIz3oJxAnZx8QS3FwRa8rUzS6iq00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=idYNM7GIIMwbW9MKBw4YowIHt6/a/DpioMm6a6VM4Ft+2sjj64uiXdApfuhjqybHh1 p3VJArdDPgOLMFlqOgSSGEwAdEDnElxXDlZb9Ez0CC3QKu4em3RBIsCUozLNPHF8EdJk cnBeNr0W80TxqxtG3Y2ag9H6nOdMxWyLSoebk= Received: by 10.42.134.132 with SMTP id l4mr2516808ict.13.1301556689904; Thu, 31 Mar 2011 00:31:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.225.133 with HTTP; Thu, 31 Mar 2011 00:28:27 -0700 (PDT) In-Reply-To: References: From: Scott Brim Date: Thu, 31 Mar 2011 09:28:27 +0200 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] MIF and SCTP X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 07:29:51 -0000 Mikael (Mike?), If I understand correctly, you are looking for a way that your transport function can control which interface a packet goes out on. How to do that would be OS-specific. When you suggest two routing tables, I guess you want that because otherwise your OS won't know that it's okay to send the packet out a particular interface at all. It's not an SCTP problem -- it's a problem with SCTP's environment. I think you should send specific text for the MIF drafts, but about the problem, not your proposed solution (since it is neither a problem nor a current practice). Scott On Wed, Mar 30, 2011 at 07:34, Mikael Abrahamsson wrote: > We've been having quite a lot of operational problems when using SCTP and > vendors implementing destination based routing, meaning that for a dual N= IC > SCTP speaker each SCTP far end IP needs to have a separate static route o= ut > to the gw of each nic to get path redundancy (two default routes doesn't > work as both SCTP legs will choose the same default route). > > It'd be much more preferable to have two virtual routing tables with two > default routes, and packets with each NIC source IP address was sent out > using that NIC virtual routing table (policy routing). > > From reading the MIF documents this scenario is one that is part of the > problem statement, but does MIF feel like it's going to give this specifi= c > SCTP case guidance in MIF, or is this needed to be taken up via the SCTP = WG? > > Perhaps I have missed that it already has been done, in that case I would > greatly appreciate a pointer to a document I can hit our vendors over the > head with. > > Thanks. > > -- > Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se From swmike@swm.pp.se Thu Mar 31 01:46:08 2011 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DDB3A6B2B for ; Thu, 31 Mar 2011 01:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9auQMrDYcsh6 for ; Thu, 31 Mar 2011 01:46:08 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id BDB433A6AFA for ; Thu, 31 Mar 2011 01:46:07 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 78D639C; Thu, 31 Mar 2011 10:47:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 758429A; Thu, 31 Mar 2011 10:47:45 +0200 (CEST) Date: Thu, 31 Mar 2011 10:47:45 +0200 (CEST) From: Mikael Abrahamsson To: Scott Brim In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mif@ietf.org Subject: Re: [mif] MIF and SCTP X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:46:08 -0000 On Thu, 31 Mar 2011, Scott Brim wrote: > Mikael (Mike?), > > If I understand correctly, you are looking for a way that your > transport function can control which interface a packet goes out on. > How to do that would be OS-specific. When you suggest two routing > tables, I guess you want that because otherwise your OS won't know > that it's okay to send the packet out a particular interface at all. I want the multi-NIC host to use the strong host model. > It's not an SCTP problem -- it's a problem with SCTP's environment. I > think you should send specific text for the MIF drafts, but about the > problem, not your proposed solution (since it is neither a problem nor > a current practice). I can write text if someone can give guidance as to where my text might fit in. It can be argued that my case is covered in 4.2, but it doesn't include the traffic separation case, only ingress filtering case. Is this a good place to add text to? -- Mikael Abrahamsson email: swmike@swm.pp.se