From julienl@qualcomm.com Mon Jan 3 12:16: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 576103A6B62 for ; Mon, 3 Jan 2011 12:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.341 X-Spam-Level: X-Spam-Status: No, score=-106.341 tagged_above=-999 required=5 tests=[AWL=0.257, 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 NNgjfD4lvT0v for ; Mon, 3 Jan 2011 12:16:15 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 1BF653A6B59 for ; Mon, 3 Jan 2011 12:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1294085902; x=1325621902; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Hui=20Deng=20,=20MIF=20Mailin g=20List=20,=20Margaret=0D=0A=20Wasserman =20|CC:=20Ted=20Lemon=20|Date:=20Mon,=203=20Jan=202011=2012:17:50=20 -0800|Subject:=20RE:=20[mif]=20Confirm=20call=20for=0D=0A =09adoption:draft-savolainen-mif-dns-server-selection |Thread-Topic:=20[mif]=20Confirm=20call=20for=0D=0A=09ado ption:draft-savolainen-mif-dns-server-selection |Thread-Index:=20AcuhhM/ZTvYdSVi0RIKwywNYPhSnVwJ/UqSQ |Message-ID:=20|References:=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_BF345F63074F8040B58C00A186FCA57F7E273BBF62NALAS EXMB04na_"|MIME-Version:=201.0; bh=H/Z6ea1WyL/uJqMd3O1sO/p6eWC6Yt+Njs0jVQT7ct4=; b=wUcHCNiZtw3GADRLvHelGpd4QYPBaHdJrv4d6l1sILGnsyqRMSXMJx4s pwMp0F82Z+gxPDeC5X/+xCJYlz7aLBNTSVPbpFUNPtFbXKIwPtNwtKm8o BiMfn+IEUnbL6uJIf+w5yzzIUjjDUX/cOwG0mFwURs6E339elo8MA12BA M=; X-IronPort-AV: E=McAfee;i="5400,1158,6215"; a="68878107" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 03 Jan 2011 12:17:52 -0800 X-IronPort-AV: E=Sophos;i="4.60,266,1291622400"; d="scan'208,217";a="104777016" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 03 Jan 2011 12:17:52 -0800 Received: from nasanexhc09.na.qualcomm.com (172.30.39.8) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 3 Jan 2011 12:17:52 -0800 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 3 Jan 2011 12:17:51 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Mon, 3 Jan 2011 12:17:51 -0800 From: "Laganier, Julien" To: Hui Deng , MIF Mailing List , Margaret Wasserman Date: Mon, 3 Jan 2011 12:17:50 -0800 Thread-Topic: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection Thread-Index: AcuhhM/ZTvYdSVi0RIKwywNYPhSnVwJ/UqSQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BF345F63074F8040B58C00A186FCA57F7E273BBF62NALASEXMB04na_" MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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, 03 Jan 2011 20:16:16 -0000 --_000_BF345F63074F8040B58C00A186FCA57F7E273BBF62NALASEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Hui, I have reviewed the mailing list discussion about this draft and I think th= at Ted Lemon makes a valid point that in its current form it is not a good = solution because it introduces security vulnerabilities that can cause harm= . As a result I do not think we should adopt this draft prior to reaching an = agreement on the mailing list as to how the security vulnerabilities introd= uced by the draft in its current form are to be addressed. I believe that Ted has made one such proposal (implementation of this speci= fication MUST use DNSSEC) but so far there was no agreement reached. This h= as to be worked out now, not when the document is held back by a bad SECDIR= review. Thanks, --julien From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui D= eng Sent: Tuesday, December 21, 2010 7:03 PM To: MIF Mailing List; Margaret Wasserman Subject: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-se= lection Hello, Based on the last Beijing meeting, we have received one major concern for t= he dns draft. After the meeting discussion, it seems it has made the progress with the ma= jor people involved. And historically, this drat has received support as well, based on that we are now asking the mailing list about adoption of this draft. If we don't hear any objection by next wednesday, then we are going to adopt this darft as the working group document, Thanks -Hui --_000_BF345F63074F8040B58C00A186FCA57F7E273BBF62NALASEXMB04na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Hui,

 

I have reviewed the mailing list discussion about this draft= and I think that Ted Lemon makes a valid point that in its current form it is n= ot a good solution because it introduces security vulnerabilities that can cause harm.

 

As a result I do not think we should adopt this draft prior = to reaching an agreement on the mailing list as to how the security vulnerabil= ities introduced by the draft in its current form are to be addressed.

 

I believe that Ted has made one such proposal (implementatio= n of this specification MUST use DNSSEC) but so far there was no agreement reach= ed. This has to be worked out now, not when the document is held back by a bad SECDI= R review.

 

Thanks,

 

--julien

 

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui = Deng
Sent: Tuesday, December 21, 2010 7:03 PM
To: MIF Mailing List; Margaret Wasserman
Subject: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection

 

Hello,

 

Based on the last Beijing meeting, we have received on= e major concern for the dns draft.

After the meeting discussion, it seems it has made the progress with the major people involved.

 

And historically, this drat has received support as we= ll, based on that

we are now asking the mailing list about adoption= of this draft.

 

If we don't hear any objection by next wednesday,= then we are going to

adopt this darft as the working group document,

 

Thanks

 

-Hui

 

--_000_BF345F63074F8040B58C00A186FCA57F7E273BBF62NALASEXMB04na_-- From teemu.savolainen@nokia.com Mon Jan 3 14:52: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 348E93A6CCC for ; Mon, 3 Jan 2011 14:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.254 X-Spam-Level: X-Spam-Status: No, score=-4.254 tagged_above=-999 required=5 tests=[AWL=-1.656, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 mGDCyk4rYqv0 for ; Mon, 3 Jan 2011 14:52:27 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id DB0273A6CCB for ; Mon, 3 Jan 2011 14:52:26 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p03MsSnO011956; Tue, 4 Jan 2011 00:54:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jan 2011 00:54:23 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 3 Jan 2011 23:54:23 +0100 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.106]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi; Mon, 3 Jan 2011 23:54:23 +0100 From: To: , , , Thread-Topic: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection Thread-Index: AcuhhM/ZTvYdSVi0RIKwywNYPhSnVwJ/UqSQAAVYeyY= Date: Mon, 3 Jan 2011 22:54:21 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_056B511A55F8AA42A3E492B7DD19A31910B583008AM1MPN1017mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jan 2011 22:54:23.0948 (UTC) FILETIME=[2A6020C0:01CBAB99] X-Nokia-AV: Clean Cc: Ted.Lemon@nominum.com Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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, 03 Jan 2011 22:52:28 -0000 --_000_056B511A55F8AA42A3E492B7DD19A31910B583008AM1MPN1017mgdn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Julien, We would also like to actually progress with this document, not wait foreve= r for comments or proposals that may never arrive. I more than welcome sugg= estions that improve the document. My personal opinion is that DNSSEC should not be MUST, as it does not appea= r to be MUST in the Internet for the time being (or it would be as strong M= UST as the IPsec was MUST in IPv6 requirements RFC). Also, there are tighly= controlled deployment scenarios, where it is hard to imagine DNSSEC brings= much additional security. E.g. the CPE case with two uplink VLAN interface= s and receiving server selection rules from trusted gateways, alongiside wi= th routing rules and other information. My understanding at this point is that the DNSSEC SHOULD (or MUST, if WG so= chooses) to be used in the general Internet access case, but in tightly co= ntrolled environments deviation from DNSSEC use should continue to be possi= ble. But I am happy to leave this for the working group to decide, I'm just= pointing that MUST is not black and white here. After all, security level = is often implementation decision. Furthermore, wouldn't the discussion of whether DNSSEC is MUST or SHOULD be= part of the working group process after the document has been adopted - to= be decided before WG sends the doc to IESG. After all, we do have charter = that specifies that DHCPv6 based solution shall be defined. Best regards, Teemu ________________________________ From: mif-bounces@ietf.org [mif-bounces@ietf.org] on behalf of ext Laganier= , Julien [julienl@qualcomm.com] Sent: Monday, January 03, 2011 10:17 PM To: Hui Deng; MIF Mailing List; Margaret Wasserman Cc: Ted Lemon Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-dns-serve= r-selection Hello Hui, I have reviewed the mailing list discussion about this draft and I think th= at Ted Lemon makes a valid point that in its current form it is not a good = solution because it introduces security vulnerabilities that can cause harm= . As a result I do not think we should adopt this draft prior to reaching an = agreement on the mailing list as to how the security vulnerabilities introd= uced by the draft in its current form are to be addressed. I believe that Ted has made one such proposal (implementation of this speci= fication MUST use DNSSEC) but so far there was no agreement reached. This h= as to be worked out now, not when the document is held back by a bad SECDIR= review. Thanks, --julien From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui D= eng Sent: Tuesday, December 21, 2010 7:03 PM To: MIF Mailing List; Margaret Wasserman Subject: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-se= lection Hello, Based on the last Beijing meeting, we have received one major concern for t= he dns draft. After the meeting discussion, it seems it has made the progress with the ma= jor people involved. And historically, this drat has received support as well, based on that we are now asking the mailing list about adoption of this draft. If we don't hear any objection by next wednesday, then we are going to adopt this darft as the working group document, Thanks -Hui --_000_056B511A55F8AA42A3E492B7DD19A31910B583008AM1MPN1017mgdn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Julien,

We would also like to actually progress with this document, not wait foreve= r for comments or proposals that may never arrive. I more than welcome sugg= estions that improve the document.

My personal opinion is that DNSSEC should not be MUST, as it does not appea= r to be MUST in the Internet for the time being (or it would be as strong M= UST as the IPsec was MUST in IPv6 requirements RFC). Also, there are tighly= controlled deployment scenarios, where it is hard to imagine DNSSEC brings much additional security. E.g. t= he CPE case with two uplink VLAN interfaces and receiving server selection = rules from trusted gateways, alongiside with routing rules and other inform= ation.

My understanding at this point is that the DNSSEC SHOULD (or MUST, if WG so= chooses) to be used in the general Internet access case, but in tightly co= ntrolled environments deviation from DNSSEC use should continue to be possi= ble. But I am happy to leave this for the working group to decide, I'm just pointing that MUST is not black = and white here. After all, security level is often implementation decision.=

Furthermore, wouldn't the discussion of whether DNSSEC is MUST or SHOULD be= part of the working group process after the document has been adopted - to= be decided before WG sends the doc to IESG. After all, we do have charter = that specifies that DHCPv6 based solution shall be defined.

Best regards,

Teemu


 
From: mif-bounces@ietf.org [mif-bounces@i= etf.org] on behalf of ext Laganier, Julien [julienl@qualcomm.com]
Sent: Monday, January 03, 2011 10:17 PM
To: Hui Deng; MIF Mailing List; Margaret Wasserman
Cc: Ted Lemon
Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-dn= s-server-selection

Hello Hui,

 

I have revie= wed the mailing list discussion about this draft and I think that Ted Lemon= makes a valid point that in its current form it is not a good solution because it introduces security vulnerabilities that can ca= use harm.

 

As a result = I do not think we should adopt this draft prior to reaching an agreement on= the mailing list as to how the security vulnerabilities introduced by the draft in its current form are to be addressed.

 

I believe th= at Ted has made one such proposal (implementation of this specification MUS= T use DNSSEC) but so far there was no agreement reached. This has to be worked out now, not when the document is held back by a bad= SECDIR review.

 

Thanks,

 

--julien

 

From: mif-= bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui Deng
Sent: Tuesday, December 21, 2010 7:03 PM
To: MIF Mailing List; Margaret Wasserman
Subject: [mif] Confirm call for adoption:draft-savolainen-mif-dns-se= rver-selection

 

Hello,

 

Based on the last Beijing meeting, we have received = one major concern for the dns draft.

After the meeting discussion, it seems it has made t= he progress with the major people involved.

 

And historically, this drat has received support as = well, based on that

we are now asking the mailing list about adopti= on of this draft.

 

If we don't hear any objection by next wednesda= y, then we are going to

adopt this darft as the working group document,

 

Thanks

 

-Hui

 

--_000_056B511A55F8AA42A3E492B7DD19A31910B583008AM1MPN1017mgdn_-- From julienl@qualcomm.com Mon Jan 3 15:37:26 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 E367C3A6D89 for ; Mon, 3 Jan 2011 15:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.415 X-Spam-Level: X-Spam-Status: No, score=-106.415 tagged_above=-999 required=5 tests=[AWL=0.183, 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 3KomjNwDj7Aa for ; Mon, 3 Jan 2011 15:37:18 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5F0553A6D47 for ; Mon, 3 Jan 2011 15:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1294097965; x=1325633965; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"teemu.savolainen@nokia.com"=20,=0D=0A=09"denghui02@gmail.com"=20,=20"mif@ietf.org"=20,=0D=0A=09"marg aretw42@gmail.com"=20|CC:=20"Ted.L emon@nominum.com"=20|Date:=20Mon, =203=20Jan=202011=2015:39:22=20-0800|Subject:=20RE:=20[mi f]=20Confirm=20call=09for=0D=0A=09adoption:draft-savolain en-mif-dns-server-selection|Thread-Topic:=20[mif]=20Confi rm=20call=09for=0D=0A=09adoption:draft-savolainen-mif-dns -server-selection|Thread-Index:=20AcuhhM/ZTvYdSVi0RIKwywN YPhSnVwJ/UqSQAAVYeyYAAamd4A=3D=3D|Message-ID:=20|References:=20,=0D=0A=20<056 B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdno k.nokia.com>|In-Reply-To:=20<056B511A55F8AA42A3E492B7DD19 A31910B583@008-AM1MPN1-017.mgdnok.nokia.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_BF345F63074F8040B58C00A186FCA57F7E273 BBFBENALASEXMB04na_"|MIME-Version:=201.0; bh=8EoNXaouCUWGz3wRN/vngdh9aCuoB23lV0ls22dxyy0=; b=wMin2RidZ6lN4GxIOcWxRDum7a424a+Q7QX2wHmSYxdAVbR13QSZgOj7 sJ4R0K+vbklwZbmkHC8q4E7vd3XbrAwypXuOfIhcLo7uWQotbwX+bBoZu qyUq467UTB68Jar/lk50ELST/+TnQhvAB0FTyNP/6sSNP5qITS51yhH80 E=; X-IronPort-AV: E=McAfee;i="5400,1158,6215"; a="68899038" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 03 Jan 2011 15:39:25 -0800 X-IronPort-AV: E=Sophos;i="4.60,266,1291622400"; d="scan'208,217";a="104838659" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 03 Jan 2011 15:39:25 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 3 Jan 2011 15:39:24 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Mon, 3 Jan 2011 15:39:24 -0800 From: "Laganier, Julien" To: "teemu.savolainen@nokia.com" , "denghui02@gmail.com" , "mif@ietf.org" , "margaretw42@gmail.com" Date: Mon, 3 Jan 2011 15:39:22 -0800 Thread-Topic: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection Thread-Index: AcuhhM/ZTvYdSVi0RIKwywNYPhSnVwJ/UqSQAAVYeyYAAamd4A== Message-ID: References: , <056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BF345F63074F8040B58C00A186FCA57F7E273BBFBENALASEXMB04na_" MIME-Version: 1.0 Cc: "Ted.Lemon@nominum.com" Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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, 03 Jan 2011 23:37:27 -0000 --_000_BF345F63074F8040B58C00A186FCA57F7E273BBFBENALASEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Teemu, I do not see why the discussion on how the proposed mechanism can be secure= d would have to be deferred to the WG until after the document has been ado= pted. On the contrary, and as explained at length by Ted earlier, the mecha= nism in its current form is not acceptable unless provided with adequate se= curity. Thus the question of whether the mechanism you propose is fit for this WG t= o standardize is contingent to this WG finding an agreement on how it can b= e secured. Thus this is what we should do first: discuss how to do what you want to do= securely, because if we can't find an agreement on that, maybe we shouldn'= t be doing what you want to do in the first place. As to DNSSEC being a MUST or not in the tightly controlled environment you = evocate, I feel it might be OK to not require DNSSEC in those insofar an im= plementation (S/W stack) can securely determine if it is in such an environ= ment. Although "security level is often implementation decision", from my = perspective security is not optional :) Best, --julien From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] Sent: Monday, January 03, 2011 2:54 PM To: Laganier, Julien; denghui02@gmail.com; mif@ietf.org; margaretw42@gmail.= com Cc: Ted.Lemon@nominum.com Subject: RE: [mif] Confirm call for adoption:draft-savolainen-mif-dns-serve= r-selection Hi Julien, We would also like to actually progress with this document, not wait foreve= r for comments or proposals that may never arrive. I more than welcome sugg= estions that improve the document. My personal opinion is that DNSSEC should not be MUST, as it does not appea= r to be MUST in the Internet for the time being (or it would be as strong M= UST as the IPsec was MUST in IPv6 requirements RFC). Also, there are tighly= controlled deployment scenarios, where it is hard to imagine DNSSEC brings= much additional security. E.g. the CPE case with two uplink VLAN interface= s and receiving server selection rules from trusted gateways, alongiside wi= th routing rules and other information. My understanding at this point is that the DNSSEC SHOULD (or MUST, if WG so= chooses) to be used in the general Internet access case, but in tightly co= ntrolled environments deviation from DNSSEC use should continue to be possi= ble. But I am happy to leave this for the working group to decide, I'm just= pointing that MUST is not black and white here. After all, security level = is often implementation decision. Furthermore, wouldn't the discussion of whether DNSSEC is MUST or SHOULD be= part of the working group process after the document has been adopted - to= be decided before WG sends the doc to IESG. After all, we do have charter = that specifies that DHCPv6 based solution shall be defined. Best regards, Teemu ________________________________ From: mif-bounces@ietf.org [mif-bounces@ietf.org] on behalf of ext Laganier= , Julien [julienl@qualcomm.com] Sent: Monday, January 03, 2011 10:17 PM To: Hui Deng; MIF Mailing List; Margaret Wasserman Cc: Ted Lemon Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-dns-serve= r-selection Hello Hui, I have reviewed the mailing list discussion about this draft and I think th= at Ted Lemon makes a valid point that in its current form it is not a good = solution because it introduces security vulnerabilities that can cause harm= . As a result I do not think we should adopt this draft prior to reaching an = agreement on the mailing list as to how the security vulnerabilities introd= uced by the draft in its current form are to be addressed. I believe that Ted has made one such proposal (implementation of this speci= fication MUST use DNSSEC) but so far there was no agreement reached. This h= as to be worked out now, not when the document is held back by a bad SECDIR= review. Thanks, --julien From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui D= eng Sent: Tuesday, December 21, 2010 7:03 PM To: MIF Mailing List; Margaret Wasserman Subject: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-se= lection Hello, Based on the last Beijing meeting, we have received one major concern for t= he dns draft. After the meeting discussion, it seems it has made the progress with the ma= jor people involved. And historically, this drat has received support as well, based on that we are now asking the mailing list about adoption of this draft. If we don't hear any objection by next wednesday, then we are going to adopt this darft as the working group document, Thanks -Hui --_000_BF345F63074F8040B58C00A186FCA57F7E273BBFBENALASEXMB04na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Teemu,

 

I do not see why the discussion on how the proposed mechanis= m can be secured would have to be deferred to the WG until after the document= has been adopted. On the contrary, and as explained at length by Ted earlier, t= he mechanism in its current form is not acceptable unless provided with adequa= te security.

 

Thus the question of whether the mechanism you propose is fi= t for this WG to standardize is contingent to this WG finding an agreement on= how it can be secured.

 

Thus this is what we should do first: discuss how to do what= you want to do securely, because if we can’t find an agreement on that, m= aybe we shouldn’t be doing what you want to do in the first place.

 

As to DNSSEC being a MUST or not in the tightly controlled environment you evocate, I feel it might be OK to not require DNSSEC in tho= se insofar an implementation (S/W stack) can securely determine if it is in su= ch an environment.  Although “security level is often implementatio= n decision”, from my perspective security is not optional J

 

Best,

 

--julien

 

From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]
Sent: Monday, January 03, 2011 2:54 PM
To: Laganier, Julien; denghui02@gmail.com; mif@ietf.org; margaretw42@gmail.com
Cc: Ted.Lemon@nominum.com
Subject: RE: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection

 

Hi Julien,

We would also like to actually progress with this document, not wait foreve= r for comments or proposals that may never arrive. I more than welcome suggestions that improve the document.

My personal opinion is that DNSSEC should not be MUST, as it does not appea= r to be MUST in the Internet for the time being (or it would be as strong MUST a= s the IPsec was MUST in IPv6 requirements RFC). Also, there are tighly contro= lled deployment scenarios, where it is hard to imagine DNSSEC brings much additi= onal security. E.g. the CPE case with two uplink VLAN interfaces and receiving server selection rules from trusted gateways, alongiside with routing rules= and other information.

My understanding at this point is that the DNSSEC SHOULD (or MUST, if WG so chooses) to be used in the general Internet access case, but in tightly controlled environments deviation from DNSSEC use should continue to be possible. But I am happy to leave this for the working group to decide, I'm just pointing that MUST is not black and white here. After all, security le= vel is often implementation decision.

Furthermore, wouldn't the discussion of whether DNSSEC is MUST or SHOULD be part of the working group process after the document has been adopted - to = be decided before WG sends the doc to IESG. After all, we do have charter that specifies that DHCPv6 based solution shall be defined.

Best regards,

Teemu


 

From: mif-bounces@ietf.org [mif-bounces@ietf.org] on behalf of ext Laganier, Juli= en [julienl@qualcomm.com]
Sent: Monday, January 03, 2011 10:17 PM
To: Hui Deng; MIF Mailing List; Margaret Wasserman
Cc: Ted Lemon
Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection

Hello Hui,

 <= /p>

I have reviewed the mailing list discussion about this draft= and I think that Ted Lemon makes a valid point that in its current form it is n= ot a good solution because it introduces security vulnerabilities that can cause harm.

 <= /p>

As a result I do not think we should adopt this draft prior = to reaching an agreement on the mailing list as to how the security vulnerabilities introduced by the draft in its current form are to be addressed.

 <= /p>

I believe that Ted has made one such proposal (implementatio= n of this specification MUST use DNSSEC) but so far there was no agreement reach= ed. This has to be worked out now, not when the document is held back by a bad SECDI= R review.

 <= /p>

Thanks,=

 <= /p>

--julien

 <= /p>

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Beha= lf Of Hui Deng
Sent: Tuesday, December 21, 2010 7:03 PM
To: MIF Mailing List; Margaret Wasserman
Subject: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection

 

Hello, <= /p>

 

Based on the last Beijing = meeting, we have received one major concern for the dns draft.

After the meeting discussi= on, it seems it has made the progress with the major people involved.

 

And historically, this dra= t has received support as well, based on that

we are now asking the mail= ing list about adoption of this draft.

 

If we don't hear any objection by next wednesday, then we are going to

adopt this darft as the wo= rking group document,

 

Thanks

 

-Hui

 

--_000_BF345F63074F8040B58C00A186FCA57F7E273BBFBENALASEXMB04na_-- From teemu.savolainen@nokia.com Mon Jan 3 23:05:26 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 8C4D23A6B44 for ; Mon, 3 Jan 2011 23:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=-4.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272] 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 IztcqmQo99CH for ; Mon, 3 Jan 2011 23:05:20 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id BC7E53A6B47 for ; Mon, 3 Jan 2011 23:05:19 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0477Nrf017732; Tue, 4 Jan 2011 09:07:24 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jan 2011 09:07:19 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 4 Jan 2011 08:07:18 +0100 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.106]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi; Tue, 4 Jan 2011 08:07:16 +0100 From: To: , , , Thread-Topic: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection Thread-Index: AcuhhM/ZTvYdSVi0RIKwywNYPhSnVwJ/UqSQAAVYeyYAAamd4AAOvFE7 Date: Tue, 4 Jan 2011 07:07:18 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A31910B688@008-AM1MPN1-017.mgdnok.nokia.com> References: , <056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_056B511A55F8AA42A3E492B7DD19A31910B688008AM1MPN1017mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2011 07:07:19.0316 (UTC) FILETIME=[06AB2540:01CBABDE] X-Nokia-AV: Clean Cc: Ted.Lemon@nominum.com Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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: Tue, 04 Jan 2011 07:05:26 -0000 --_000_056B511A55F8AA42A3E492B7DD19A31910B688008AM1MPN1017mgdn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Julien, I'm not proposing we should defer the discussion of how to secure things, I= 'm saying we should not continue postpone progress of this work indefinitel= y waiting for discussion not taking place. E.g. during the past two months = since Beijing I haven't seen any discussion on this list about this. We can discuss now for sure. I would like to discuss the real severity of the attack vector in more dept= h. As far as I understood the concern was that the attacker selects a small= subset of names (e.g. a single name) that it wants to give malicious DNS r= eply. As the subset of names being attacked would be small, it would be non= trivial to see attack is ongoing (or pending - most of the private names wo= uld resolve just fine). Now what if instead of this technology the node's implementation would be s= uch that it always sends DNS queries to all DNS servers (at least one serve= r per interface). In the usual case it could happen that it gets positive r= eplies for questions (for *.corporate.com) sent over VPN, and NXDOMAIN when= sent to DNS server of the visited WLAN (for example). Now couldn't the att= acker on WLAN currently do it so that when the question to this specific se= rver name comes, the visited network's DNS server would not reply NXDOMAIN,= but positive answer instead? And as the visited networks DNS server is lik= ely faster to reply than the server behind the VPN, similar redirection att= ack could be accomplished? Or what if the attacker provides malicious RFC3646 search list option havin= g "attacker.com" and reply NXDOMAIN until host asks for "targeted.server.co= rporate.com.attacker.com" and reply that with positive answer and hence tak= e the traffic? (This is explained in section 6 of RFC3646). In that case ev= en DNSSEC does not help. If the DNSSEC is the only concern you have, can't we just make a call to WG= on who thinks it should be MUST and who thinks it should be SHOULD? But in= presence of other DNS attacks, couldn't you separate DNSSEC requirement fr= om individual tools, and just mandate DNSSEC implementation to cover all ki= nds of threats? Best regards, Teemu ________________________________ From: ext Laganier, Julien [julienl@qualcomm.com] Sent: Tuesday, January 04, 2011 1:39 AM To: Savolainen Teemu (Nokia-MS/Tampere); denghui02@gmail.com; mif@ietf.org;= margaretw42@gmail.com Cc: Ted.Lemon@nominum.com Subject: RE: [mif] Confirm call for adoption:draft-savolainen-mif-dns-serve= r-selection Hi Teemu, I do not see why the discussion on how the proposed mechanism can be secure= d would have to be deferred to the WG until after the document has been ado= pted. On the contrary, and as explained at length by Ted earlier, the mecha= nism in its current form is not acceptable unless provided with adequate se= curity. Thus the question of whether the mechanism you propose is fit for this WG t= o standardize is contingent to this WG finding an agreement on how it can b= e secured. Thus this is what we should do first: discuss how to do what you want to do= securely, because if we can=92t find an agreement on that, maybe we should= n=92t be doing what you want to do in the first place. As to DNSSEC being a MUST or not in the tightly controlled environment you = evocate, I feel it might be OK to not require DNSSEC in those insofar an im= plementation (S/W stack) can securely determine if it is in such an environ= ment. Although =93security level is often implementation decision=94, from= my perspective security is not optional :) Best, --julien From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] Sent: Monday, January 03, 2011 2:54 PM To: Laganier, Julien; denghui02@gmail.com; mif@ietf.org; margaretw42@gmail.= com Cc: Ted.Lemon@nominum.com Subject: RE: [mif] Confirm call for adoption:draft-savolainen-mif-dns-serve= r-selection Hi Julien, We would also like to actually progress with this document, not wait foreve= r for comments or proposals that may never arrive. I more than welcome sugg= estions that improve the document. My personal opinion is that DNSSEC should not be MUST, as it does not appea= r to be MUST in the Internet for the time being (or it would be as strong M= UST as the IPsec was MUST in IPv6 requirements RFC). Also, there are tighly= controlled deployment scenarios, where it is hard to imagine DNSSEC brings= much additional security. E.g. the CPE case with two uplink VLAN interface= s and receiving server selection rules from trusted gateways, alongiside wi= th routing rules and other information. My understanding at this point is that the DNSSEC SHOULD (or MUST, if WG so= chooses) to be used in the general Internet access case, but in tightly co= ntrolled environments deviation from DNSSEC use should continue to be possi= ble. But I am happy to leave this for the working group to decide, I'm just= pointing that MUST is not black and white here. After all, security level = is often implementation decision. Furthermore, wouldn't the discussion of whether DNSSEC is MUST or SHOULD be= part of the working group process after the document has been adopted - to= be decided before WG sends the doc to IESG. After all, we do have charter = that specifies that DHCPv6 based solution shall be defined. Best regards, Teemu ________________________________ From: mif-bounces@ietf.org [mif-bounces@ietf.org] on behalf of ext Laganier= , Julien [julienl@qualcomm.com] Sent: Monday, January 03, 2011 10:17 PM To: Hui Deng; MIF Mailing List; Margaret Wasserman Cc: Ted Lemon Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-dns-serve= r-selection Hello Hui, I have reviewed the mailing list discussion about this draft and I think th= at Ted Lemon makes a valid point that in its current form it is not a good = solution because it introduces security vulnerabilities that can cause harm= . As a result I do not think we should adopt this draft prior to reaching an = agreement on the mailing list as to how the security vulnerabilities introd= uced by the draft in its current form are to be addressed. I believe that Ted has made one such proposal (implementation of this speci= fication MUST use DNSSEC) but so far there was no agreement reached. This h= as to be worked out now, not when the document is held back by a bad SECDIR= review. Thanks, --julien From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui D= eng Sent: Tuesday, December 21, 2010 7:03 PM To: MIF Mailing List; Margaret Wasserman Subject: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-se= lection Hello, Based on the last Beijing meeting, we have received one major concern for t= he dns draft. After the meeting discussion, it seems it has made the progress with the ma= jor people involved. And historically, this drat has received support as well, based on that we are now asking the mailing list about adoption of this draft. If we don't hear any objection by next wednesday, then we are going to adopt this darft as the working group document, Thanks -Hui --_000_056B511A55F8AA42A3E492B7DD19A31910B688008AM1MPN1017mgdn_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Julien,

I'm not proposing we should defer the discussion of how to secure things, I= 'm saying we should not continue postpone progress of this work indefinitel= y waiting for discussion not taking place. E.g. during the past two months = since Beijing I haven't seen any discussion on this list about this.

We can discuss now for sure.

I would like to discuss the real severity of the attack vector in more dept= h. As far as I understood the concern was that the attacker selects a small= subset of names (e.g. a single name) that it wants to give malicious DNS r= eply. As the subset of names being attacked would be small, it would be nontrivial to see attack is ongoing (= or pending - most of the private names would resolve just fine).

Now what if instead of this technology the node's implementation would be s= uch that it always sends DNS queries to all DNS servers (at least one serve= r per interface). In the usual case it could happen that it gets positive r= eplies for questions (for *.corporate.com) sent over VPN, and NXDOMAIN when sent to DNS server of the visited WLAN (f= or example). Now couldn't the attacker on WLAN currently do it so that when= the question to this specific server name comes, the visited network's DNS= server would not reply NXDOMAIN, but positive answer instead? And as the visited networks DNS server is lik= ely faster to reply than the server behind the VPN, similar redirection att= ack could be accomplished?

Or what if the attacker provides malicious RFC3646 search list option havin= g "attacker.com" and reply NXDOMAIN until host asks for "tar= geted.server.corporate.com.attacker.com" and reply that with positive = answer and hence take the traffic? (This is explained in section 6 of RFC3646). In that case even DNSSEC does not help.

If the DNSSEC is the only concern you have, can't we just make a call to WG= on who thinks it should be MUST and who thinks it should be SHOULD? But in= presence of other DNS attacks, couldn't you separate DNSSEC requirement fr= om individual tools, and just mandate DNSSEC implementation to cover all kinds of threats?

Best regards,

Teemu
 
From: ext Laganier, Julien [julienl@qualc= omm.com]
Sent: Tuesday, January 04, 2011 1:39 AM
To: Savolainen Teemu (Nokia-MS/Tampere); denghui02@gmail.com; mif@ie= tf.org; margaretw42@gmail.com
Cc: Ted.Lemon@nominum.com
Subject: RE: [mif] Confirm call for adoption:draft-savolainen-mif-dn= s-server-selection

Hi Teemu,

 

I do not see= why the discussion on how the proposed mechanism can be secured would have= to be deferred to the WG until after the document has been adopted. On the contrary, and as explained at length by Ted earlier, the m= echanism in its current form is not acceptable unless provided with adequat= e security.

 

Thus the que= stion of whether the mechanism you propose is fit for this WG to standardiz= e is contingent to this WG finding an agreement on how it can be secured.

 

Thus this is= what we should do first: discuss how to do what you want to do securely, b= ecause if we can=92t find an agreement on that, maybe we shouldn=92t be doing what you want to do in the first place.

 

As to DNSSEC= being a MUST or not in the tightly controlled environment you evocate, I f= eel it might be OK to not require DNSSEC in those insofar an implementation (S/W stack) can securely determine if it is in such an e= nvironment.  Although =93security level is often implementation decisi= on=94, from my perspective security is not optional J

 

Best,=

 

--julien

 

From: teem= u.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]
Sent: Monday, January 03, 2011 2:54 PM
To: Laganier, Julien; denghui02@gmail.com; mif@ietf.org; margaretw42= @gmail.com
Cc: Ted.Lemon@nominum.com
Subject: RE: [mif] Confirm call for adoption:draft-savolainen-mif-dn= s-server-selection

 

Hi Julien,

We would also like to actually progress with this document, not wait foreve= r for comments or proposals that may never arrive. I more than welcome sugg= estions that improve the document.

My personal opinion is that DNSSEC should not be MUST, as it does not appea= r to be MUST in the Internet for the time being (or it would be as strong M= UST as the IPsec was MUST in IPv6 requirements RFC). Also, there are tighly= controlled deployment scenarios, where it is hard to imagine DNSSEC brings much additional security. E.g. t= he CPE case with two uplink VLAN interfaces and receiving server selection = rules from trusted gateways, alongiside with routing rules and other inform= ation.

My understanding at this point is that the DNSSEC SHOULD (or MUST, if WG so= chooses) to be used in the general Internet access case, but in tightly co= ntrolled environments deviation from DNSSEC use should continue to be possi= ble. But I am happy to leave this for the working group to decide, I'm just pointing that MUST is not black = and white here. After all, security level is often implementation decision.=

Furthermore, wouldn't the discussion of whether DNSSEC is MUST or SHOULD be= part of the working group process after the document has been adopted - to= be decided before WG sends the doc to IESG. After all, we do have charter = that specifies that DHCPv6 based solution shall be defined.

Best regards,

Teemu


 

From: mif-bounces@ietf.org= [mif-bounces@ietf.org] on behalf of ext Laganier, Julien [julienl@qualcomm.com]
Sent: Monday, January 03, 2011 10:17 PM
To: Hui Deng; MIF Mailing List; Margaret Wasserman
Cc: Ted Lemon
Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-dn= s-server-selection

Hello Hui,

 

I have revie= wed the mailing list discussion about this draft and I think that Ted Lemon= makes a valid point that in its current form it is not a good solution because it introduces security vulnerabilities that can ca= use harm.

 

As a result = I do not think we should adopt this draft prior to reaching an agreement on= the mailing list as to how the security vulnerabilities introduced by the draft in its current form are to be addressed.

 

I believe th= at Ted has made one such proposal (implementation of this specification MUS= T use DNSSEC) but so far there was no agreement reached. This has to be worked out now, not when the document is held back by a bad= SECDIR review.

 

Thanks,

 

--julien

 

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui Deng
Sent: Tuesday, December 21, 2010 7:03 PM
To: MIF Mailing List; Margaret Wasserman
Subject: [mif] Confirm call for adoption:draft-savolainen-mif-dns-se= rver-selection

 

Hello,

 

Based on the last Beij= ing meeting, we have received one major concern for the dns draft.

After the meeting disc= ussion, it seems it has made the progress with the major people involv= ed.

 

And historically, this= drat has received support as well, based on that

we are now asking the = mailing list about adoption of this draft.

 

If we don't hear any o= bjection by next wednesday, then we are going to

adopt this darft as th= e working group document,

 

Thanks

 

-Hui

 

--_000_056B511A55F8AA42A3E492B7DD19A31910B688008AM1MPN1017mgdn_-- From satoru.matsushima@gmail.com Wed Jan 5 05:47: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 00DC53A6E1E for ; Wed, 5 Jan 2011 05:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 q8pdeek4rjWb for ; Wed, 5 Jan 2011 05:47:14 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D24463A6D3C for ; Wed, 5 Jan 2011 05:47:13 -0800 (PST) Received: by iwn40 with SMTP id 40so16292912iwn.31 for ; Wed, 05 Jan 2011 05:49:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=r6r+sF4afSah80HuZ/0uj2tD6DkcZ0YZtwDavZAwCiI=; b=msHAUlE8JCKq5T4IgwNBIZAyZMhFbwryc+gUf5L1z8SszbtBa5tWcLIx2ZzSBxShjT 8CV0iLiLrmRqkmILRJ+Yuph2ptGAyl5a8Ofk6Dn92kAX8rKXVaViAcqLnvxNUeQ5vRob JyOYcvg9UgCw4dYfx+gnK/11nxzVJKDK7WWLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=bvexXSEhWjMKeBAJ4ZFl8iqhJtFksYhiJfkc13iiMjEQt2D4NdSxaG6Apa76NGm/v3 alpOo2ZHhQ26WpNzrxA+pC2JARQb5BmQj0ucl1y0tuVTs9FVUWSQlo2Wo/YTdDYxp/ke LWOuG5FmDej7CY3cewG1twTUvVanQcssJrVso= Received: by 10.231.10.76 with SMTP id o12mr7159483ibo.144.1294235360701; Wed, 05 Jan 2011 05:49:20 -0800 (PST) Received: from [192.168.3.10] (softbank221038134212.bbtec.net [221.38.134.212]) by mx.google.com with ESMTPS id d21sm20953064ibg.21.2011.01.05.05.49.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 05:49:19 -0800 (PST) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Apple Message framework v1082) From: Satoru Matsushima In-Reply-To: Date: Wed, 5 Jan 2011 22:49:15 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <043E3479-22C4-44A4-994D-80CC33D6A505@gmail.com> References: , <056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.com> To: mif@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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: Wed, 05 Jan 2011 13:47:15 -0000 Hi, On 2011/01/04, at 8:39, Laganier, Julien wrote: > Hi Teemu, > =20 > I do not see why the discussion on how the proposed mechanism can be = secured would have to be deferred to the WG until after the document has = been adopted. On the contrary, and as explained at length by Ted = earlier, the mechanism in its current form is not acceptable unless = provided with adequate security. > =20 > Thus the question of whether the mechanism you propose is fit for this = WG to standardize is contingent to this WG finding an agreement on how = it can be secured. =46rom wg progress aspect, as of mif wg charter, we expect that the wg = doc will be appeared in this January, along with milestone in the = charter. So, > =20 > Thus this is what we should do first: discuss how to do what you want = to do securely, because if we can=1B$B!G=1B(Bt find an agreement on = that, maybe we shouldn=1B$B!G=1B(Bt be doing what you want to do in the = first place. I thinks that the first thing we should do is that adopting wg doc if = any other solution doesn't come up with attractive technology. The PS document of mif already stated about this. This is well known = issue. > =20 > As to DNSSEC being a MUST or not in the tightly controlled environment = you evocate, I feel it might be OK to not require DNSSEC in those = insofar an implementation (S/W stack) can securely determine if it is in = such an environment. Although =1B$B!H=1B(Bsecurity level is often = implementation decision=1B$B!I=1B(B, from my perspective security is not = optional J > =20 =46rom technical aspect, this is proposal for DNS "Server" selection. = Anybody who want to use DNSSEC can use it because using DNSSEC depends = on DNS server and client. It means that any dhcpv6 option cannot force = or avoid to use DNSSEC. Of course this is not obstacle to use DNSSEC. I think that there is no show stopper of the adoption. Best regards, -- Satoru Matsushima From zehn.cao@gmail.com Wed Jan 5 19:54:12 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 832D53A6896 for ; Wed, 5 Jan 2011 19:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 I4vqIEMnYIDB for ; Wed, 5 Jan 2011 19:54:11 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 45B753A67E2 for ; Wed, 5 Jan 2011 19:54:11 -0800 (PST) Received: by wyf23 with SMTP id 23so16737139wyf.31 for ; Wed, 05 Jan 2011 19:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nwc2G5gyDCFVnbAtre49NmTBUqiYMVSY4YLQcc38Pi0=; b=JpuloDGNSVRKqmxlxe1rAZdn+R+wdNrQPXHkm2LAzNPau66aW1XHDeneZV/5l+2BJp WQBM9Ah4s8zwZDTTA2zC0iyBQh9JV15Zv5YSsIqpfZZOPuIUPTv4P0n4RN31z4znrY8d q6BWsZlK73miVluudSq4RSdwKZzYaMDfAiwu0= 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:content-transfer-encoding; b=IZSuBRiMVXDZvTQsDk9THH8eHQevxnxg0eEOS5DydLRI/iJHkTf6irVpDRKaQMgVFe mF1RV1OxFKxyQrbm/F9XYT/kcEXExjVRJp6oHFmqifRXkgD8xed/9pwNhT1j8ZkyX87E /1u3SiCwOADgni51CCmHH2MOQRRZZgpUsZm98= MIME-Version: 1.0 Received: by 10.216.173.7 with SMTP id u7mr201881wel.50.1294286176306; Wed, 05 Jan 2011 19:56:16 -0800 (PST) Received: by 10.216.85.149 with HTTP; Wed, 5 Jan 2011 19:56:16 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Jan 2011 11:56:16 +0800 Message-ID: From: Zhen Cao To: "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Margaret Wasserman , MIF Mailing List , Ted Lemon Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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: Thu, 06 Jan 2011 03:54:12 -0000 Hi Julien, I do not agree with you and would like to support the adoption of this draft in current form. The solution in the draft is straightforward and tackles the problem of the current environment where DNSSEC is not de-facto. DNSSEC considerations can be put into the security analysis section which is informational enough. Regards, Zhen On Tue, Jan 4, 2011 at 4:17 AM, Laganier, Julien wro= te: > Hello Hui, > > > > I have reviewed the mailing list discussion about this draft and I think > that Ted Lemon makes a valid point that in its current form it is not a g= ood > solution because it introduces security vulnerabilities that can cause ha= rm. > > > > As a result I do not think we should adopt this draft prior to reaching a= n > agreement on the mailing list as to how the security vulnerabilities > introduced by the draft in its current form are to be addressed. > > > > I believe that Ted has made one such proposal (implementation of this > specification MUST use DNSSEC) but so far there was no agreement reached. > This has to be worked out now, not when the document is held back by a ba= d > SECDIR review. > > > > Thanks, > > > > --julien > > > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui > Deng > Sent: Tuesday, December 21, 2010 7:03 PM > To: MIF Mailing List; Margaret Wasserman > Subject: [mif] Confirm call for > adoption:draft-savolainen-mif-dns-server-selection > > > > Hello, > > > > Based on the last Beijing meeting, we have received one major concern for > the dns draft. > > After the meeting discussion, it seems it has made the progress=A0with th= e > major people involved. > > > > And historically, this drat has received support as well, based on that > > we are now asking the mailing list about=A0adoption of this draft. > > > > If we don't hear any objection=A0by next wednesday, then we are going to > > adopt this darft as the working group document, > > > > Thanks > > > > -Hui > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --=20 Best regards, Zhen From wdec.ietf@gmail.com Thu Jan 6 10:00: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 E944E3A6E28 for ; Thu, 6 Jan 2011 10:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cl7033rhfsKK for ; Thu, 6 Jan 2011 10:00:06 -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 D24BA3A68D5 for ; Thu, 6 Jan 2011 10:00:05 -0800 (PST) Received: by bwz12 with SMTP id 12so16514704bwz.31 for ; Thu, 06 Jan 2011 10:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=DbkOy59S0NS3ihk/yV+/Wfz06Qp/VOhqWFBOxce2k8o=; b=wSY4W7v4t/RTZXwFZCNbBLr39RlzKQLFlNdzJoEDqQFgYf+RjdVBAEmAlecANPZUd+ 2e6us9yYWxE5DeJZgo4IuJMOboZ27tc36X6LfuEwQnOci2oEdRvHgv0bsD2zwgJ1HvWN G4lB6Z3mtg55d0YNpwFphnHQWQ11QQeIPmc0k= 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=FFYmVICI646iW5d/+RIx5HWXjrT9BNcG7FurAZaLgnTblLYzA3tIXltvIybBSPjfbl DvGy5J16g+RcRBKFu304CUpoHc3bijNTgi0KUFDzzOvhU/ghVDYesFR4zGAyKr1knFKI dkk6OLME1FO9Lvs0pKc6dky/VS3u9xlHTfGZA= MIME-Version: 1.0 Received: by 10.204.78.67 with SMTP id j3mr11455215bkk.144.1294336931647; Thu, 06 Jan 2011 10:02:11 -0800 (PST) Received: by 10.204.55.71 with HTTP; Thu, 6 Jan 2011 10:02:10 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Jan 2011 19:02:10 +0100 Message-ID: From: Wojciech Dec To: Zhen Cao Content-Type: multipart/alternative; boundary=001485f8753607d19d0499314dff Cc: MIF Mailing List , "Laganier, Julien" , Margaret Wasserman , Ted Lemon Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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: Thu, 06 Jan 2011 18:00:09 -0000 --001485f8753607d19d0499314dff Content-Type: text/plain; charset=ISO-8859-1 I support the WG adoption of this draft. Regards, Woj. On 6 January 2011 04:56, Zhen Cao wrote: > Hi Julien, > > I do not agree with you and would like to support the adoption of this > draft in current form. The solution in the draft is straightforward > and tackles the problem of the current environment where DNSSEC is not > de-facto. DNSSEC considerations can be put into the security analysis > section which is informational enough. > > Regards, > Zhen > On Tue, Jan 4, 2011 at 4:17 AM, Laganier, Julien > wrote: > > Hello Hui, > > > > > > > > I have reviewed the mailing list discussion about this draft and I think > > that Ted Lemon makes a valid point that in its current form it is not a > good > > solution because it introduces security vulnerabilities that can cause > harm. > > > > > > > > As a result I do not think we should adopt this draft prior to reaching > an > > agreement on the mailing list as to how the security vulnerabilities > > introduced by the draft in its current form are to be addressed. > > > > > > > > I believe that Ted has made one such proposal (implementation of this > > specification MUST use DNSSEC) but so far there was no agreement reached. > > This has to be worked out now, not when the document is held back by a > bad > > SECDIR review. > > > > > > > > Thanks, > > > > > > > > --julien > > > > > > > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Hui > > Deng > > Sent: Tuesday, December 21, 2010 7:03 PM > > To: MIF Mailing List; Margaret Wasserman > > Subject: [mif] Confirm call for > > adoption:draft-savolainen-mif-dns-server-selection > > > > > > > > Hello, > > > > > > > > Based on the last Beijing meeting, we have received one major concern for > > the dns draft. > > > > After the meeting discussion, it seems it has made the progress with the > > major people involved. > > > > > > > > And historically, this drat has received support as well, based on that > > > > we are now asking the mailing list about adoption of this draft. > > > > > > > > If we don't hear any objection by next wednesday, then we are going to > > > > adopt this darft as the working group document, > > > > > > > > Thanks > > > > > > > > -Hui > > > > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > > > > > > -- > Best regards, > Zhen > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --001485f8753607d19d0499314dff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support the WG adoption of this draft.

Regards,
Woj.

On 6 January 2011 04:56, Zhen Cao <zehn.cao@gmail.com> wrote:
Hi Julien,

I do not agree with you and would like to support the adoption of this
draft in current form. The solution in the draft is straightforward
and tackles the problem of the current environment where DNSSEC is not
de-facto. =A0DNSSEC considerations can be put into the security analysis section which is informational enough.

Regards,
Zhen
On Tue, Jan 4, 2011 at 4:17 AM, Laganier,= Julien <julienl@qualcomm.com> wrote:
> Hello Hui,
>
>
>
> I have reviewed the mailing list discussion about this draft and I thi= nk
> that Ted Lemon makes a valid point that in its current form it is not = a good
> solution because it introduces security vulnerabilities that can cause= harm.
>
>
>
> As a result I do not think we should adopt this draft prior to reachin= g an
> agreement on the mailing list as to how the security vulnerabilities > introduced by the draft in its current form are to be addressed.
>
>
>
> I believe that Ted has made one such proposal (implementation of this<= br> > specification MUST use DNSSEC) but so far there was no agreement reach= ed.
> This has to be worked out now, not when the document is held back by a= bad
> SECDIR review.
>
>
>
> Thanks,
>
>
>
> --julien
>
>
>
> From: mif-bounces@ietf.org= [mailto:mif-bounces@ietf.org] = On Behalf Of Hui
> Deng
> Sent: Tuesday, December 21, 2010 7:03 PM
> To: MIF Mailing List; Margaret Wasserman
> Subject: [mif] Confirm call for
> adoption:draft-savolainen-mif-dns-server-selection
>
>
>
> Hello,
>
>
>
> Based on the last Beijing meeting, we have received one major concern = for
> the dns draft.
>
> After the meeting discussion, it seems it has made the progress=A0with= the
> major people involved.
>
>
>
> And historically, this drat has received support as well, based on tha= t
>
> we are now asking the mailing list about=A0adoption of this draft.
>
>
>
> If we don't hear any objection=A0by next wednesday, then we are go= ing to
>
> adopt this darft as the working group document,
>
>
>
> Thanks
>
>
>
> -Hui
>
>
>
> ________________________________________= _______
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>
>



--
Best regards,
Zhen
__________________________________= _____________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

--001485f8753607d19d0499314dff-- From julienl@qualcomm.com Thu Jan 6 15:12: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 4BDE83A6F75 for ; Thu, 6 Jan 2011 15:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.023 X-Spam-Level: X-Spam-Status: No, score=-104.023 tagged_above=-999 required=5 tests=[AWL=-2.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272, 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 DkrwKbVVEQci for ; Thu, 6 Jan 2011 15:12:09 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CD0043A6DF6 for ; Thu, 6 Jan 2011 15:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1294355655; x=1325891655; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"teemu.savolainen@nokia.com"=20,=0D=0A=09"denghui02@gmail.com"=20,=20"mif@ietf.org"=20,=0D=0A=09"marg aretw42@gmail.com"=20|CC:=20"Ted.L emon@nominum.com"=20|Date:=20Thu, =206=20Jan=202011=2015:14:12=20-0800|Subject:=20RE:=20[mi f]=20Confirm=20call=09for=0D=0A=09adoption:draft-savolain en-mif-dns-server-selection|Thread-Topic:=20[mif]=20Confi rm=20call=09for=0D=0A=09adoption:draft-savolainen-mif-dns -server-selection|Thread-Index:=20AcuhhM/ZTvYdSVi0RIKwywN YPhSnVwJ/UqSQAAVYeyYAAamd4AAOvFE7AId45VA=3D|Message-ID: =20|References:=20, =0D=0A=20<056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1M PN1-017.mgdnok.nokia.com>,=0D=0A=20<056B51 1A55F8AA42A3E492B7DD19A31910B688@008-AM1MPN1-017.mgdnok.n okia.com>|In-Reply-To:=20<056B511A55F8AA42A3E492B7DD19A31 910B688@008-AM1MPN1-017.mgdnok.nokia.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=3uJvya6qH8ei/hcdQSLQFf09swEzuiqigv34r36z+vY=; b=sFItTkPKclNc/YZ2dT+OIOfaCJDtVSZELMKcAnUIZvwby/Y1KWjglGHL wrYqjewTAVeiWmRd1/ST5oNGawOMdPM/jYvwZjAAsRNTVXZEN4WhpDdA4 ZMxvqX3rv1JG01A7r6s9a2tDjDLDVD0iVIp9jLMCBaTX6x9ojoYYHc9eo E=; X-IronPort-AV: E=McAfee;i="5400,1158,6218"; a="69323776" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 06 Jan 2011 15:14:15 -0800 X-IronPort-AV: E=Sophos;i="4.60,283,1291622400"; d="scan'208";a="106160340" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Jan 2011 15:14:15 -0800 Received: from nasanexhc08.na.qualcomm.com (172.30.39.7) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 6 Jan 2011 15:14:15 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 6 Jan 2011 15:14:14 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Thu, 6 Jan 2011 15:14:14 -0800 From: "Laganier, Julien" To: "teemu.savolainen@nokia.com" , "denghui02@gmail.com" , "mif@ietf.org" , "margaretw42@gmail.com" Date: Thu, 6 Jan 2011 15:14:12 -0800 Thread-Topic: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection Thread-Index: AcuhhM/ZTvYdSVi0RIKwywNYPhSnVwJ/UqSQAAVYeyYAAamd4AAOvFE7AId45VA= Message-ID: References: , <056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.com>, <056B511A55F8AA42A3E492B7DD19A31910B688@008-AM1MPN1-017.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A31910B688@008-AM1MPN1-017.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ted.Lemon@nominum.com" Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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: Thu, 06 Jan 2011 23:12:10 -0000 Hi Teemu, > I'm not proposing we should defer the discussion of how to secure things,= I'm > saying we should not continue postpone progress of this work indefinitely > waiting for discussion not taking place. E.g. during the past two months > since Beijing I haven't seen any discussion on this list about this. I don't think we're stalled: The period straight after an IETF meeting is usually pretty quiet because everyone has to catch up with the other busine= ss that wasn't taken care of during the meeting, and then there was the holida= y season.=20 I also do not equate adoption as WG draft to progress. This work can progre= ss (a lot) without this specific draft being a WG draft by having the WG comin= g to consensus on how to do this DHCP-based DNS server selection securely. This = will be a pre-requisite for publication anyway. > We can discuss now for sure.=20 Right, almost everybody should be back from holidays by now so let's do jus= t that... > I would like to discuss the real severity of the attack vector in more de= pth. > As far as I understood the concern was that the attacker selects a small > subset of names (e.g. a single name) that it wants to give malicious DNS > reply. As the subset of names being attacked would be small, it would be > nontrivial to see attack is ongoing (or pending - most of the private nam= es > would resolve just fine).=20 I am not sure the subset of names necessarily needs to be small. An attacke= r could inject on the WLAN a DHCPv6 DNS selection option with .com or '.' (i.= e. global) as a prefix and declare itself as high preference and be able to divert all of that traffic if the other interface has no DHCP server sending such a DN= S selection option. > Now what if instead of this technology the node's implementation would be > such that it always sends DNS queries to all DNS servers (at least one se= rver > per interface). In the usual case it could happen that it gets positive > replies for questions (for *.corporate.com) sent over VPN, and NXDOMAIN w= hen > sent to DNS server of the visited WLAN (for example). Now couldn't the > attacker on WLAN currently do it so that when the question to this specif= ic > server name comes, the visited network's DNS server would not reply NXDOM= AIN, > but positive answer instead? And as the visited networks DNS server is li= kely > faster to reply than the server behind the VPN, similar redirection attac= k > could be accomplished? Right. Which is why if you have DNSSEC you'd wait for all answers from all= =20 interfaces first before returning to the application. Alternatively, if the stack knew that one of the interface (WWAN) is more trusted than the other (unauthenticated WLAN) it would wait for the answer from the more trusted interface to return to the application. > Or what if the attacker provides malicious RFC3646 search list option hav= ing > "attacker.com" and reply NXDOMAIN until host asks for > "targeted.server.corporate.com.attacker.com" and reply that with positive > answer and hence take the traffic? (This is explained in section 6 of > RFC3646). In that case even DNSSEC does not help. RFC3646 specically says:=20 2. Resolve a name that contains any dots by first trying it as an FQDN and if that fails, with the names in the searchlist appended. If there are indeed multiple alternative DNS servers on different network interfaces providing multiple search lists, I would interpret the above "resolve a name that contains any dots by first trying it as an FQDN on all interfaces, and if that fails, with the names in the search list for the respective interface appended." That seems to be to be the sensible way to extend the 3646 provision to a multi-interfaced host. > If the DNSSEC is the only concern you have, can't we just make a call to = WG > on who thinks it should be MUST and who thinks it should be SHOULD? But i= n > presence of other DNS attacks, couldn't you separate DNSSEC requirement f= rom > individual tools, and just mandate DNSSEC implementation to cover all kin= ds > of threats? No offense but in the end, whatever the WG rough consensus is, if it does introduce security vulnerabilities the draft is going to held on by the SEC= AD.=20 DNSSEC is not the only concern I have, I have actually outline another way = to use that option in a less problematic manner than currently proposed:=20 > > As to DNSSEC being a MUST or not in the tightly controlled environment = you > > evocate, I feel it might be OK to not require DNSSEC in those insofar a= n > > implementation (S/W stack) can securely determine if it is in such an > > environment. =20 So maybe we ought to say that when receiving a DNS server selection option from an untrusted network interface (e.g., unauthenticated WLAN, as opposed to corporate WLAN or WWAN), the node MUST tries to resolve FQDN through DNS servers on each of the interface to try to obtain DNSSEC protected DNS repl= ies.=20 This way DNSSEC isn't a MUST, but if it is deployed, the node is in a posit= ion to avoid the DNS redirection attack that Ted originally outlined. What do you think? --julien From julienl@qualcomm.com Thu Jan 6 15:31:37 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 441783A6F75 for ; Thu, 6 Jan 2011 15:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.288 X-Spam-Level: X-Spam-Status: No, score=-106.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 JAvJ1Cw644vy for ; Thu, 6 Jan 2011 15:31:35 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3ACD93A6D23 for ; Thu, 6 Jan 2011 15:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1294356821; x=1325892821; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Satoru=20Matsushima=20,=20"mif@ietf.org"=0D=0A=09|Date:=20Thu, =206=20Jan=202011=2015:33:38=20-0800|Subject:=20RE:=20[mi f]=20Confirm=20call=09for=0D=0A=09adoption:draft-savolain en-mif-dns-server-selection|Thread-Topic:=20[mif]=20Confi rm=20call=09for=0D=0A=09adoption:draft-savolainen-mif-dns -server-selection|Thread-Index:=20Acus3128ACXcPmbXSPylhw7 U/Bi6pgBGrPAQ|Message-ID:=20|References: =20,=0D=0A=09=0D=0A=09<056B511A55F8 AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.c om>=0D=0A=09=0D=0A=20<043E3479-22C4-44A4-9 94D-80CC33D6A505@gmail.com>|In-Reply-To:=20<043E3479-22C4 -44A4-994D-80CC33D6A505@gmail.com>|Accept-Language:=20en- US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=VhM0lvgL7ZaiXPf1JttwTnYNEGflwIEeNbWh200tIqc=; b=Tx3pGBabtoSnVF6jUKWq0GfgxjTSYzbCqeZMtzwB6Txzhp8Sx/AwZ7lw xcHZ+QwzM6F56mPdX6yZALGWo59aEdnCNbKtSlS9ihZloG6OBeLVORIix V14eiHZG+2a+++qiINEo5PWfCURxKumAPQ6ctXwk2dUgm2AHU1cfoVmkF 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6218"; a="69543605" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 06 Jan 2011 15:33:41 -0800 X-IronPort-AV: E=Sophos;i="4.60,283,1291622400"; d="scan'208";a="106166117" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Jan 2011 15:33:40 -0800 Received: from nasanexhc08.na.qualcomm.com (172.30.39.7) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 6 Jan 2011 15:33:41 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 6 Jan 2011 15:33:40 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 6 Jan 2011 15:33:40 -0800 From: "Laganier, Julien" To: Satoru Matsushima , "mif@ietf.org" Date: Thu, 6 Jan 2011 15:33:38 -0800 Thread-Topic: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection Thread-Index: Acus3128ACXcPmbXSPylhw7U/Bi6pgBGrPAQ Message-ID: References: , <056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.com> <043E3479-22C4-44A4-994D-80CC33D6A505@gmail.com> In-Reply-To: <043E3479-22C4-44A4-994D-80CC33D6A505@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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: Thu, 06 Jan 2011 23:31:37 -0000 Hi, On 2011/01/04, at 8:39, Laganier, Julien wrote: > =20 > > I do not see why the discussion on how the proposed mechanism can be > > secured would have to be deferred to the WG until after the document ha= s > > been adopted. On the contrary, and as explained at length by Ted earlie= r, > > the mechanism in its current form is not acceptable unless provided wit= h > > adequate security. > >=20 > > Thus the question of whether the mechanism you propose is fit for this = WG > > to standardize is contingent to this WG finding an agreement on how it = can > > be secured. > > From wg progress aspect, as of mif wg charter, we expect that the wg doc = will > be appeared in this January, along with milestone in the charter. > So, >From my perspective the fact that a work item is late and about to miss one= of=20 its milestones is not a reason to rush WG adoption of a document that has=20 security issues pointed out by WG participants. =20 > > Thus this is what we should do first: discuss how to do what you want t= o do > > securely, because if we can't find an agreement on that, maybe we shoul= dn't > > be doing what you want to do in the first place. >=20 > I thinks that the first thing we should do is that adopting wg doc if any= =20 > other solution doesn't come up with attractive technology. > The PS document of mif already stated about this. This is well known issu= e. The first thing you should do is propose a solution that seems to be adequa= te and does not introduce security vulnerabilities. Let's not allow the cure t= o be worse than the disease. > > As to DNSSEC being a MUST or not in the tightly controlled environment = you > > evocate, I feel it might be OK to not require DNSSEC in those insofar a= n > > implementation (S/W stack) can securely determine if it is in such an > > environment. Although "security level is often implementation decision= ", > > from my perspective security is not optional J > > From technical aspect, this is proposal for DNS "Server" selection. Anybo= dy > who want to use DNSSEC can use it because using DNSSEC depends on DNS ser= ver > and client. It means that any dhcpv6 option cannot force or avoid to use > DNSSEC. Of course this is not obstacle to use DNSSEC. > > I think that there is no show stopper of the adoption. As I have outlined in my other note to Teemu, it seems to me that this opti= on would defeat DNSSEC in case an attacker is able to inject such a DNS server selection option with high priority. I have also outlined some strawman on = how the DNS server selection option could be made acceptable by treating it differently depending on whether it comes from a trusted (authenticated) or untrusted (unauthenticated) network. At this point my position is that thi= s can and should be captured in the document before I feel comfortable endors= ing it. --julien From julienl@qualcomm.com Thu Jan 6 15:36: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 936FC3A6E3F for ; Thu, 6 Jan 2011 15:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.365 X-Spam-Level: X-Spam-Status: No, score=-106.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 XNkvFNAbLigS for ; Thu, 6 Jan 2011 15:36:29 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id CFBAA3A6D23 for ; Thu, 6 Jan 2011 15:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1294357115; x=1325893115; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Wojciech=20Dec=20,=20Zhen=20C ao=20|CC:=20Margaret=20Wasserman=20,=20MIF=20Mailing=20List=0D=0A=09,=20Ted=20Lemon=20 |Date:=20Thu,=206=20Jan=202011=2015:38:34=20-0800 |Subject:=20RE:=20[mif]=20Confirm=20call=20for=0D=0A=20ad option:draft-savolainen-mif-dns-server-selection |Thread-Topic:=20[mif]=20Confirm=20call=20for=0D=0A=20ado ption:draft-savolainen-mif-dns-server-selection |Thread-Index:=20Acuty9sgIZu0l8gCTs6PABu3+nKw7gALpivQ |Message-ID:=20|References:=20=0D =0A=09=0D=0A=09=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ub6Iyt7zW4ycoEOxTS8526uZF/yZjlB/QEOyChB7GIU=; b=faqVBxmfxUFEK82zpqE/WOCCU+Zd5+Ps3KhBHXjtxdzE4YZ/GbfW8+6Q 3HPHEJQEekA3EUHC+LE0EgrLKgZ9Rj0oKCVZHj7Jl4854+jV5iZk0tHZo XyAQ5i/NACS4Gq8dvxO01TfsTyIhWBbnk4Wq3oPPiZJuOB4wOTZcZpZvQ A=; X-IronPort-AV: E=McAfee;i="5400,1158,6218"; a="69544026" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 06 Jan 2011 15:38:35 -0800 X-IronPort-AV: E=Sophos;i="4.60,283,1291622400"; d="scan'208";a="40571626" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Jan 2011 15:38:35 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 6 Jan 2011 15:38:35 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Thu, 6 Jan 2011 15:38:35 -0800 From: "Laganier, Julien" To: Wojciech Dec , Zhen Cao Date: Thu, 6 Jan 2011 15:38:34 -0800 Thread-Topic: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection Thread-Index: Acuty9sgIZu0l8gCTs6PABu3+nKw7gALpivQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MIF Mailing List , Margaret Wasserman , Ted Lemon Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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: Thu, 06 Jan 2011 23:36:30 -0000 Woj, Wojciech Dec wrote: > > I support the WG adoption of this draft. Would you care to explain on the mailing list the reasons you support adopt= ion of a solution in spite of that solution defeating DNSSEC in some situat= ions? --julien From teemu.savolainen@nokia.com Thu Jan 6 16:20: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 6C2493A6F41 for ; Thu, 6 Jan 2011 16:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=-3.916, BAYES_00=-2.599, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272] 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 LfbnbgIXNeyw for ; Thu, 6 Jan 2011 16:20:08 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id B517E3A6E3F for ; Thu, 6 Jan 2011 16:20:07 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p070MB1i019377; Fri, 7 Jan 2011 02:22:11 +0200 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); Fri, 7 Jan 2011 02:22:06 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 7 Jan 2011 01:22:06 +0100 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.212]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi; Fri, 7 Jan 2011 01:21:53 +0100 From: To: , , , Thread-Topic: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection Thread-Index: AcuhhM/ZTvYdSVi0RIKwywNYPhSnVwJ/UqSQAAVYeyYAAamd4AAOvFE7AId45VAAALAFwA== Date: Fri, 7 Jan 2011 00:21:52 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3191390CC@008-AM1MPN1-017.mgdnok.nokia.com> References: , <056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.com>, <056B511A55F8AA42A3E492B7DD19A31910B688@008-AM1MPN1-017.mgdnok.nokia.com> In-Reply-To: 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 X-OriginalArrivalTime: 07 Jan 2011 00:22:06.0431 (UTC) FILETIME=[EA4C8EF0:01CBAE00] X-Nokia-AV: Clean Cc: Ted.Lemon@nominum.com Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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: Fri, 07 Jan 2011 00:20:09 -0000 Hi Julien, > I am not sure the subset of names necessarily needs to be small. An > attacker > could inject on the WLAN a DHCPv6 DNS selection option with .com or '.' > (i.e. global) > as a prefix and declare itself as high preference and be able to divert > all > of that traffic if the other interface has no DHCP server sending such > a DNS selection > option. If you would not have the new option, then you would have an implementation= randomly picking DNS server from one interface or form another, hence bein= g vulnerable for this attack (but less systematically, I admit). If the implementation is not randomly picking DNS servers, but prefers DNS = servers of interfaces it considers more trustworthy (e.g. VPN or cellular),= then maybe such implementation should choose to listen for this new option= only on the interfaces it trusts (and in fact, not use the hotspot WLAN's = honey pot DNS server at all if possible (ah so fast but results are .. some= thing)). > > Now what if instead of this technology the node's implementation > would be > > such that it always sends DNS queries to all DNS servers (at least > one server > > per interface). In the usual case it could happen that it gets > positive > > replies for questions (for *.corporate.com) sent over VPN, and > NXDOMAIN when > > sent to DNS server of the visited WLAN (for example). Now couldn't > the > > attacker on WLAN currently do it so that when the question to this > specific > > server name comes, the visited network's DNS server would not reply > NXDOMAIN, > > but positive answer instead? And as the visited networks DNS server > is likely > > faster to reply than the server behind the VPN, similar redirection > attack > > could be accomplished? >=20 > Right. Which is why if you have DNSSEC you'd wait for all answers from > all > interfaces first before returning to the application.=20 I'm not sure I see how this relates to point I was making... The DNSSEC ind= eed helps with the new option as well - if you get DNSSEC validation failur= e you can fallback to use another DNS server. >Alternatively, if > the > stack knew that one of the interface (WWAN) is more trusted than the > other > (unauthenticated WLAN) it would wait for the answer from the more > trusted > interface to return to the application. I think I had something in revision -03 of my draft, but I got then some ne= gative feedback for that approach: -- 1. Managed tunnel interfaces (such as VPN) considered most trustworthy 2. Managed networks being on the middle 3. Unmanaged networks having lowest priority Now, for example, if all of the three abovementioned networks would advertise 'corporation.com' DNS suffix, the host would prefer the VPN network interface for related DNS resolution requests. -- I admit that version did not take into account the case you made: no confli= ct to resolve but interface with attacker is luring DNS traffic that should= 've been sent out of another interface (but the another interface did not a= dvertise anything).=20 > > Or what if the attacker provides malicious RFC3646 search list option > having > > "attacker.com" and reply NXDOMAIN until host asks for > > "targeted.server.corporate.com.attacker.com" and reply that with > positive > > answer and hence take the traffic? (This is explained in section 6 of > > RFC3646). In that case even DNSSEC does not help. >=20 > RFC3646 specically says: >=20 > 2. Resolve a name that contains any dots by first trying it as an > FQDN and if that fails, with the names in the searchlist > appended. Right, but couldn't an attacker who can compromise DHCPv6 server on the acc= ess network also change the DNS server address host gets to his own, and th= en from that DNS server reply with NXDOMAIN or whatever to the basic FQDN r= esolution request, and thus forcing host to go to searchlist procedures, an= d then answer positively to FQDN containing the appended suffix that valida= tes ok with DNSSEC? > If there are indeed multiple alternative DNS servers on different > network > interfaces providing multiple search lists, I would interpret the above > "resolve a name that contains any dots by first trying it as an FQDN on > all > interfaces, and if that fails, with the names in the search list for > the > respective interface appended." That seems to be to be the sensible way > to > extend the 3646 provision to a multi-interfaced host. But see, we don't want to sent queries always to all interfaces. Only once = to right interface. > No offense but in the end, whatever the WG rough consensus is, if it > does > introduce security vulnerabilities the draft is going to held on by the > SEC AD. I definitely do prefer sorting out issues sooner or later:)=20 Maybe pointing out vulnerabilities in other possible approaches doesn't hel= p so much to progress..=20 =20 > DNSSEC is not the only concern I have, I have actually outline another > way to use that option in a less problematic manner than currently > proposed: Let's see.. > > > As to DNSSEC being a MUST or not in the tightly controlled > environment you > > > evocate, I feel it might be OK to not require DNSSEC in those > insofar an > > > implementation (S/W stack) can securely determine if it is in such > an > > > environment. >=20 > So maybe we ought to say that when receiving a DNS server selection > option > from an untrusted network interface (e.g., unauthenticated WLAN, as > opposed > to corporate WLAN or WWAN), the node MUST tries to resolve FQDN through > DNS > servers on each of the interface to try to obtain DNSSEC protected DNS > replies. > > This way DNSSEC isn't a MUST, but if it is deployed, the node is in a > position > to avoid the DNS redirection attack that Ted originally outlined. Let me think, do you mean that in the case of DNS server of the untrusted n= etwork interface would have the highest priority (when node thinks about wh= ere to send a query), node should additionally send queries also to trusted= interfaces and then collect replies? But for the queries where the DNS ser= ver of a trusted interface would have highest priority, node could send DNS= query just over the trusted interface? Could you implement that also so that whatever untrusted network tells you,= you prioritize it lowest. I.e. if DNS queries would be sent out in series = rather than parallel, first query would go to the default DNS server of tru= sted interface, and only if that fails query would go to specific server of= untrusted interface? What do you think about the case when untrusted but preferred interface (sa= y WLAN) has no new options (just the old DNS configuration option), and the= trusted but otherwise less preferred interface (say 3G) has also default D= NS server option, but additionally some high priority rules with new option= . The queries matching high priority rules would go to trusted interface fo= r usre, but what about the "default" queries? Where those should be sent? In more general terms, should the default queries always be sent over the m= ost trusted interface first (if you don't want to use all interfaces)? This= is actually the case already today if you would have device with WLAN and = cellular IPv4/IPv6 interfaces. Which do you use for DNS (I guess currently = it oftentimes happens that the interface last opened would be used - but wo= uldn't that be a security risk)?=20 Should existing multihomed device send DNS queries always over the most tru= sted interfaces, even if that results in latency penalty? Best regards, Teemu From teemu.savolainen@nokia.com Thu Jan 6 16:26:37 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 D0F763A6F41 for ; Thu, 6 Jan 2011 16:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.016 X-Spam-Level: X-Spam-Status: No, score=-4.016 tagged_above=-999 required=5 tests=[AWL=-1.417, 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 SAUUYnl8sF9n for ; Thu, 6 Jan 2011 16:26:35 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 6AD5B3A6E3F for ; Thu, 6 Jan 2011 16:26:35 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p070SdGK005036; Fri, 7 Jan 2011 02:28:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 02:28:34 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 7 Jan 2011 01:28:33 +0100 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.212]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi; Fri, 7 Jan 2011 01:28:33 +0100 From: To: , , Thread-Topic: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection Thread-Index: Acus3128ACXcPmbXSPylhw7U/Bi6pgBGrPAQAAG/JtA= Date: Fri, 7 Jan 2011 00:28:32 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3191390E6@008-AM1MPN1-017.mgdnok.nokia.com> References: , <056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.com> <043E3479-22C4-44A4-994D-80CC33D6A505@gmail.com> In-Reply-To: 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 X-OriginalArrivalTime: 07 Jan 2011 00:28:34.0656 (UTC) FILETIME=[D1B2FE00:01CBAE01] X-Nokia-AV: Clean Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-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: Fri, 07 Jan 2011 00:26:38 -0000 > selection option with high priority. I have also outlined some strawman > on how > the DNS server selection option could be made acceptable by treating it > differently depending on whether it comes from a trusted > (authenticated) or > untrusted (unauthenticated) network. At this point my position is that > this > can and should be captured in the document before I feel comfortable > endorsing > it. I will work tomorrow to see if I can grab enough input from your last email= (and your possible reply to my reply) to do improvements, and we can then = see how the result would look like (i.e. on Monday, if things go well).=20 We also have "just" two authors on the document currently. I do welcome dir= ect textual contributions as well:-) Best regards, Teemu From teemu.savolainen@nokia.com Fri Jan 7 04:32: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 C44403A6836 for ; Fri, 7 Jan 2011 04:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=-3.787, BAYES_00=-2.599, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272] 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 GnYjb5Zw8Neb for ; Fri, 7 Jan 2011 04:32:03 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id F333C3A6835 for ; Fri, 7 Jan 2011 04:32:02 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p07CY6Mc019700; Fri, 7 Jan 2011 14:34:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 14:34:01 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 7 Jan 2011 13:33:57 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.148]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi; Fri, 7 Jan 2011 13:33:56 +0100 From: To: , , , Thread-Topic: New revision of DNS server select, (Was: RE: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection) Thread-Index: AQHLrmcn3j1k+N1ijEmjeD/Ibgn51Q== Date: Fri, 7 Jan 2011 12:33:55 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A319149C32@008-AM1MPN1-015.mgdnok.nokia.com> References: , <056B511A55F8AA42A3E492B7DD19A31910B583@008-AM1MPN1-017.mgdnok.nokia.com>, <056B511A55F8AA42A3E492B7DD19A31910B688@008-AM1MPN1-017.mgdnok.nokia.com> <056B511A55F8AA42A3E492B7DD19A3191390CC@008-AM1MPN1-017.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3191390CC@008-AM1MPN1-017.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 X-OriginalArrivalTime: 07 Jan 2011 12:34:01.0885 (UTC) FILETIME=[29F30CD0:01CBAE67] X-Nokia-AV: Clean Cc: Ted.Lemon@nominum.com Subject: [mif] New revision of DNS server select, (Was: RE: Confirm call for adoption:draft-savolainen-mif-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: Fri, 07 Jan 2011 12:32:04 -0000 Hi all, I worked out today -06 version of the draft, please see how it looks on sec= urity aspects. http://www.ietf.org/id/draft-savolainen-mif-dns-server-selection-06.txt Changes focused on section 3 as the normative text is there. But there were= some changes here and there in order to be more consistent and also to do = some other fixes (e.g. reference to OPTION_ORO). Security Considerations se= ction was rewritten and I collected some of the discussions and considerati= ons there Please also comment if you think some of the changes caused by increased se= curity considerations here and there takes work to wrong direction. Best regards, Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Savolainen Teemu (Nokia-MS/Tampere) > Sent: 07. tammikuuta 2011 02:22 > To: julienl@qualcomm.com; denghui02@gmail.com; mif@ietf.org; > margaretw42@gmail.com > Cc: Ted.Lemon@nominum.com > Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-dns- > server-selection >=20 > Hi Julien, >=20 > > I am not sure the subset of names necessarily needs to be small. An > > attacker > > could inject on the WLAN a DHCPv6 DNS selection option with .com or > '.' > > (i.e. global) > > as a prefix and declare itself as high preference and be able to > divert > > all > > of that traffic if the other interface has no DHCP server sending > such > > a DNS selection > > option. >=20 > If you would not have the new option, then you would have an > implementation randomly picking DNS server from one interface or form > another, hence being vulnerable for this attack (but less > systematically, I admit). >=20 > If the implementation is not randomly picking DNS servers, but prefers > DNS servers of interfaces it considers more trustworthy (e.g. VPN or > cellular), then maybe such implementation should choose to listen for > this new option only on the interfaces it trusts (and in fact, not use > the hotspot WLAN's honey pot DNS server at all if possible (ah so fast > but results are .. something)). >=20 > > > Now what if instead of this technology the node's implementation > > would be > > > such that it always sends DNS queries to all DNS servers (at least > > one server > > > per interface). In the usual case it could happen that it gets > > positive > > > replies for questions (for *.corporate.com) sent over VPN, and > > NXDOMAIN when > > > sent to DNS server of the visited WLAN (for example). Now couldn't > > the > > > attacker on WLAN currently do it so that when the question to this > > specific > > > server name comes, the visited network's DNS server would not reply > > NXDOMAIN, > > > but positive answer instead? And as the visited networks DNS server > > is likely > > > faster to reply than the server behind the VPN, similar redirection > > attack > > > could be accomplished? > > > > Right. Which is why if you have DNSSEC you'd wait for all answers > from > > all > > interfaces first before returning to the application. >=20 > I'm not sure I see how this relates to point I was making... The DNSSEC > indeed helps with the new option as well - if you get DNSSEC validation > failure you can fallback to use another DNS server. >=20 > >Alternatively, if > > the > > stack knew that one of the interface (WWAN) is more trusted than the > > other > > (unauthenticated WLAN) it would wait for the answer from the more > > trusted > > interface to return to the application. >=20 > I think I had something in revision -03 of my draft, but I got then > some negative feedback for that approach: > -- > 1. Managed tunnel interfaces (such as VPN) considered most > trustworthy >=20 > 2. Managed networks being on the middle >=20 > 3. Unmanaged networks having lowest priority >=20 > Now, for example, if all of the three abovementioned networks would > advertise 'corporation.com' DNS suffix, the host would prefer the > VPN > network interface for related DNS resolution requests. > -- >=20 > I admit that version did not take into account the case you made: no > conflict to resolve but interface with attacker is luring DNS traffic > that should've been sent out of another interface (but the another > interface did not advertise anything). >=20 > > > Or what if the attacker provides malicious RFC3646 search list > option > > having > > > "attacker.com" and reply NXDOMAIN until host asks for > > > "targeted.server.corporate.com.attacker.com" and reply that with > > positive > > > answer and hence take the traffic? (This is explained in section 6 > of > > > RFC3646). In that case even DNSSEC does not help. > > > > RFC3646 specically says: > > > > 2. Resolve a name that contains any dots by first trying it as an > > FQDN and if that fails, with the names in the searchlist > > appended. >=20 > Right, but couldn't an attacker who can compromise DHCPv6 server on the > access network also change the DNS server address host gets to his own, > and then from that DNS server reply with NXDOMAIN or whatever to the > basic FQDN resolution request, and thus forcing host to go to > searchlist procedures, and then answer positively to FQDN containing > the appended suffix that validates ok with DNSSEC? >=20 > > If there are indeed multiple alternative DNS servers on different > > network > > interfaces providing multiple search lists, I would interpret the > above > > "resolve a name that contains any dots by first trying it as an FQDN > on > > all > > interfaces, and if that fails, with the names in the search list for > > the > > respective interface appended." That seems to be to be the sensible > way > > to > > extend the 3646 provision to a multi-interfaced host. >=20 > But see, we don't want to sent queries always to all interfaces. Only > once to right interface. >=20 > > No offense but in the end, whatever the WG rough consensus is, if it > > does > > introduce security vulnerabilities the draft is going to held on by > the > > SEC AD. >=20 > I definitely do prefer sorting out issues sooner or later:) >=20 > Maybe pointing out vulnerabilities in other possible approaches doesn't > help so much to progress.. >=20 > > DNSSEC is not the only concern I have, I have actually outline > another > > way to use that option in a less problematic manner than currently > > proposed: >=20 > Let's see.. >=20 > > > > As to DNSSEC being a MUST or not in the tightly controlled > > environment you > > > > evocate, I feel it might be OK to not require DNSSEC in those > > insofar an > > > > implementation (S/W stack) can securely determine if it is in > such > > an > > > > environment. > > > > So maybe we ought to say that when receiving a DNS server selection > > option > > from an untrusted network interface (e.g., unauthenticated WLAN, as > > opposed > > to corporate WLAN or WWAN), the node MUST tries to resolve FQDN > through > > DNS > > servers on each of the interface to try to obtain DNSSEC protected > DNS > > replies. > > > > This way DNSSEC isn't a MUST, but if it is deployed, the node is in a > > position > > to avoid the DNS redirection attack that Ted originally outlined. >=20 > Let me think, do you mean that in the case of DNS server of the > untrusted network interface would have the highest priority (when node > thinks about where to send a query), node should additionally send > queries also to trusted interfaces and then collect replies? But for > the queries where the DNS server of a trusted interface would have > highest priority, node could send DNS query just over the trusted > interface? >=20 > Could you implement that also so that whatever untrusted network tells > you, you prioritize it lowest. I.e. if DNS queries would be sent out in > series rather than parallel, first query would go to the default DNS > server of trusted interface, and only if that fails query would go to > specific server of untrusted interface? >=20 > What do you think about the case when untrusted but preferred interface > (say WLAN) has no new options (just the old DNS configuration option), > and the trusted but otherwise less preferred interface (say 3G) has > also default DNS server option, but additionally some high priority > rules with new option. The queries matching high priority rules would > go to trusted interface for usre, but what about the "default" queries? > Where those should be sent? >=20 > In more general terms, should the default queries always be sent over > the most trusted interface first (if you don't want to use all > interfaces)? This is actually the case already today if you would have > device with WLAN and cellular IPv4/IPv6 interfaces. Which do you use > for DNS (I guess currently it oftentimes happens that the interface > last opened would be used - but wouldn't that be a security risk)? >=20 > Should existing multihomed device send DNS queries always over the most > trusted interfaces, even if that results in latency penalty? >=20 > Best regards, >=20 > Teemu > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From denghui02@gmail.com Wed Jan 12 07:27:12 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 37C7828C128 for ; Wed, 12 Jan 2011 07:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.698, 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 6Quw2NLvszur for ; Wed, 12 Jan 2011 07:27:09 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 817C528C107 for ; Wed, 12 Jan 2011 07:27:08 -0800 (PST) Received: by fxm9 with SMTP id 9so729932fxm.31 for ; Wed, 12 Jan 2011 07:29:27 -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=Ys0CoV6YWv25DT9XCIVbtWqxAg0gBQLfYVvABAI3u8g=; b=WnUPa8GosmRY5DIdKf3egT6uyy7LPvwnWjMxRHt8ziWmTrwjpYI6Ky0wd9pJbIn/vi HtGOjPSSgMYTkmIhAeQwdzf3aqO29w6D9EF9Oi89V2cuSs3Qph/zFxg3A7hrhAwuwmPu /xMUxrBB7CmuXgsdbDIpQw5OMkV05D+BhAoBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=knI+Iu7TJ14k0+RBS2Y+3bv8FSmsF7+0aMVE1dLy47sI30xiyiu23bz92BdG5F7tYh keT4egUzNvnaIO+cmjf/Dk6LlwWOOh8dy0FlPwD6U3blbAW3nfMhpUFOjrBHR8j2ZwO4 x9awIJwhjvd3HIqj9TKSPUTTv5Wo18awOQqLo= MIME-Version: 1.0 Received: by 10.223.74.5 with SMTP id s5mr1142156faj.72.1294846167796; Wed, 12 Jan 2011 07:29:27 -0800 (PST) Received: by 10.223.83.7 with HTTP; Wed, 12 Jan 2011 07:29:27 -0800 (PST) Date: Wed, 12 Jan 2011 23:29:27 +0800 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=20cf3054a38fdecd210499a7dd09 Subject: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG 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: Wed, 12 Jan 2011 15:27:12 -0000 --20cf3054a38fdecd210499a7dd09 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello all With the chair hat, Based on the last call discussion in the mailing list, chairs observed that one issue regarding to security has been raised, but this won't be the critical one to prevent it from becoming the WG draft. MIF working group could continue to discuss how to improve it after it become a WG draft based on the constructive contribution. Chair could also issue the call for whether we need put the =93Must" or "Should" support DNSSEC to resolve the issue if needed. Thank you all for the comment, please continue to help the editor to improv= e the qulity of the document after WG draft submitted. Best regards, -Hui --20cf3054a38fdecd210499a7dd09 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
With the chair hat,
=A0
Based on the last call discussion in the mailing list, chairs observed= that one issue regarding to security
has been raised, but this won't be the critical=A0one to prevent i= t from becoming the WG draft.
=A0
MIF working group could continue to discuss how to improve it after it= become a WG draft=A0based on=A0the constructive contribution.
=A0
Chair could also issue the call for whether we need put the =93Must&qu= ot; or "Should" support DNSSEC to resolve=A0the issue=A0if needed= .
=A0
Thank you all for the comment, please continue to help the editor to i= mprove the qulity of the document after WG draft submitted.
=A0
Best regards,
=A0
-Hui
--20cf3054a38fdecd210499a7dd09-- From Internet-Drafts@ietf.org Wed Jan 12 17: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 745E73A67DB; Wed, 12 Jan 2011 17:30:03 -0800 (PST) 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 34d3LSp9OcEA; Wed, 12 Jan 2011 17:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857AC3A67B1; Wed, 12 Jan 2011 17: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.10 Message-ID: <20110113013001.1649.22770.idtracker@localhost> Date: Wed, 12 Jan 2011 17:30:01 -0800 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-dhcpv6-route-option-00.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: Thu, 13 Jan 2011 01: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 : DHCPv6 Route Option Author(s) : W. Dec, et al. Filename : draft-ietf-mif-dhcpv6-route-option-00.txt Pages : 11 Date : 2011-01-12 This document describes DHCPv6 Route Options for provisioning IPv6 routes on nodes with DHCPv6 clients. This is expected to improve the ability of an operator to configure and influence a node's 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-00.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-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-12172811.I-D@ietf.org> --NextPart-- From julienl@qualcomm.com Thu Jan 13 14:00:25 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 8A4DC3A6BE8 for ; Thu, 13 Jan 2011 14:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.385 X-Spam-Level: X-Spam-Status: No, score=-106.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 YBMA4kb5RM5D for ; Thu, 13 Jan 2011 14:00:24 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 684863A6BE2 for ; Thu, 13 Jan 2011 14:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1294956168; x=1326492168; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Hui=20Deng=20,=20MIF=20Mailin g=20List=20|Date:=20Thu,=2013=20Jan=202011 =2014:02:44=20-0800|Subject:=20RE:=20[mif]=20Adoption=20o f=20draft-savolainen-mif-dns-server-selection=20as=0D=0A =20WG=09draft|Thread-Topic:=20[mif]=20Adoption=20of=20dra ft-savolainen-mif-dns-server-selection=20as=0D=0A=20WG=09 draft|Thread-Index:=20AcuybYX4X9I3gKUNTW6/DBPaEu7KZwA/y73 w|Message-ID:=20|References:=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=Pe/fNx2XFn9R0enAiDmBExykPvAUIuLXNkqhia/5i4Q=; b=gv6x6aiyGuiVjQlAY+G4l5bojxylssJJsS1dImrnHyZ1Ovv8qMcuTzGg uxJC1MV+C0UwTkHhFseEB7yCA8HmmRJocpSb8mSDf3CgbmcNmrSbZCtC2 BcXavJAdWtqeumTDowXvhgMMR7TdH6vXzo57WUPcR5DyaZa3sE3PVmzvu M=; X-IronPort-AV: E=McAfee;i="5400,1158,6225"; a="70157160" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 13 Jan 2011 14:02:47 -0800 X-IronPort-AV: E=Sophos;i="4.60,317,1291622400"; d="scan'208";a="42052016" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 13 Jan 2011 14:02:47 -0800 Received: from nasanexhc08.na.qualcomm.com (172.30.39.7) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 13 Jan 2011 14:02:47 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 13 Jan 2011 14:02:47 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 13 Jan 2011 14:02:47 -0800 From: "Laganier, Julien" To: Hui Deng , MIF Mailing List Date: Thu, 13 Jan 2011 14:02:44 -0800 Thread-Topic: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG draft Thread-Index: AcuybYX4X9I3gKUNTW6/DBPaEu7KZwA/y73w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG 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: Thu, 13 Jan 2011 22:00:25 -0000 Hello Hui, Just a clarification from my side: Hui Deng wroteL > Hello all > =A0 > With the chair hat, >=20 > Based on the last call discussion in the mailing list, chairs > observed that one issue regarding to security has been raised,=20 > but this won't be the critical=A0one to prevent it from becoming > the WG draft. > =A0 > MIF working group could continue to discuss how to improve it > after it become a WG draft=A0based on=A0the constructive contribution. > =A0 > Chair could also issue the call for whether we need put the "Must" > or "Should" support DNSSEC to resolve=A0the issue=A0if needed. I don't think the issue is MUST or SHOULD support DNSSEC. I think the issue is when you do not trust the interface or DHCP server from which=20 your received the DHCP option, you MUST query all the DNS servers you have and wait for answers before you're able to possibly validate DNSSEC. Then you might want to prioritize the answers you have as per the DHCP option. =A0 > Thank you all for the comment, please continue to help the editor > to improve the qulity of the document after WG draft submitted. I will review the last update from Teemu and provide feedback. --julien From ajs@shinkuro.com Thu Jan 13 14:14:44 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 18D1A3A6BF0 for ; Thu, 13 Jan 2011 14:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 kRVuaUU3fS+V for ; Thu, 13 Jan 2011 14:14:43 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 321203A6BEC for ; Thu, 13 Jan 2011 14:14:43 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 078DB1ECB41F for ; Thu, 13 Jan 2011 22:17:05 +0000 (UTC) Date: Thu, 13 Jan 2011 17:17:04 -0500 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110113221704.GM26731@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG 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: Thu, 13 Jan 2011 22:14:44 -0000 On Thu, Jan 13, 2011 at 02:02:44PM -0800, Laganier, Julien wrote: > I don't think the issue is MUST or SHOULD support DNSSEC. I think the > issue is when you do not trust the interface or DHCP server from which > your received the DHCP option, you MUST query all the DNS servers you have > and wait for answers before you're able to possibly validate DNSSEC. Then > you might want to prioritize the answers you have as per the DHCP option. Apologies for having failed completely to follow up on any of this stuff since Beijing; I plead dayjob interference. Nevertheless, I wanted to clarify something here. If you are validating on the end point where you are doing the above, then you can query any DNS server you like and you will be able to detect if there is a DNS server lying to you. That is, if you are doing DNSSEC validation, then you will be able to detect which DNS server is able to answer your query with a validatable reply. In that sense, I think Julien is right in case you get a failure. But if you get a validatable response, I'm not so sure. Now what about the case where you have a locally-scoped trust anchor for a domain, example.com, and a root covering trust anchor as well? On one interface for LAN-only-host.example.com you get a validatable answer of NAME ERROR (3) and on the other interface you get a validatable postive answer for that name, covered by the locally-scoped trust anchor. In this case, you have the ability to know that you have a special trust anchor configured, and the good people at ISC will tell you (well, one of them) that you ought to prefer it or at least that you ought to be able to prefer it. So that seems like the right answer for this case (and it would be right to look for an answer covered by that trust anchor and use it. What about the case where LAN-only-host.example.com is actually signed using the same chain of trust as any random "public Internet" name in example.com? I suspect the answer is going to have to be, "Don't do that." For if you get two responses, both of which validate, but they have different answers in them, there is no reason whatever for you to prefer one over the other. This is rather unfortunate, as there actually isn't any mechanism in DNS to be able to prefer one trust anchor over another. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From teemu.savolainen@nokia.com Thu Jan 13 23:13: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 3233F28C0E5 for ; Thu, 13 Jan 2011 23:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.858 X-Spam-Level: X-Spam-Status: No, score=-3.858 tagged_above=-999 required=5 tests=[AWL=-1.259, 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 lYoj1C7YHWtf for ; Thu, 13 Jan 2011 23:13:46 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id B62E728C0E2 for ; Thu, 13 Jan 2011 23:13:45 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0E7G85F020012; Fri, 14 Jan 2011 09:16:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 09:15:59 +0200 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; Fri, 14 Jan 2011 08:15:58 +0100 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.12]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi; Fri, 14 Jan 2011 08:15:57 +0100 From: To: , Thread-Topic: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG draft Thread-Index: AQHLs2+lzUEd4bAgOk+uoBZ6J/NA5ZPQDJbQ Date: Fri, 14 Jan 2011 07:15:56 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3191A52C0@008-AM1MPN1-017.mgdnok.nokia.com> References: <20110113221704.GM26731@shinkuro.com> In-Reply-To: <20110113221704.GM26731@shinkuro.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 X-OriginalArrivalTime: 14 Jan 2011 07:15:59.0366 (UTC) FILETIME=[E4C5FA60:01CBB3BA] X-Nokia-AV: Clean Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG 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: Fri, 14 Jan 2011 07:13:47 -0000 Hi, The host implementing this technology (in not-being-attacked case) would se= nd the DNS query first over the interface where "LAN-only-host.example.com"= would be positively validated with local trust anchor, as from that interf= ace "example.com" suffix was learned on? It would be happy with that answer= , and not even become aware of the negative validatable responses that woul= d be received via other interfaces if asked.=20 While being attacked (the other interface also advertising "example.com") t= he host might get negative but validatable reply, in which case it probably= should try out other interfaces (especially if two interfaces are advertis= ing "example.com")? Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext Andrew Sullivan > Sent: 14. tammikuuta 2011 00:17 > To: mif@ietf.org > Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server- > selection as WG draft >=20 > On Thu, Jan 13, 2011 at 02:02:44PM -0800, Laganier, Julien wrote: > > I don't think the issue is MUST or SHOULD support DNSSEC. I think the > > issue is when you do not trust the interface or DHCP server from > which > > your received the DHCP option, you MUST query all the DNS servers you > have > > and wait for answers before you're able to possibly validate DNSSEC. > Then > > you might want to prioritize the answers you have as per the DHCP > option. >=20 > Apologies for having failed completely to follow up on any of this > stuff since Beijing; I plead dayjob interference. Nevertheless, I > wanted to clarify something here. >=20 > If you are validating on the end point where you are doing the above, > then you can query any DNS server you like and you will be able to > detect if there is a DNS server lying to you. That is, if you are > doing DNSSEC validation, then you will be able to detect which DNS > server is able to answer your query with a validatable reply. >=20 > In that sense, I think Julien is right in case you get a failure. But > if you get a validatable response, I'm not so sure. >=20 > Now what about the case where you have a locally-scoped trust anchor > for a domain, example.com, and a root covering trust anchor as well? > On one interface for LAN-only-host.example.com you get a validatable > answer of NAME ERROR (3) and on the other interface you get a > validatable postive answer for that name, covered by the > locally-scoped trust anchor. In this case, you have the ability to > know that you have a special trust anchor configured, and the good > people at ISC will tell you (well, one of them) that you ought to > prefer it or at least that you ought to be able to prefer it. So that > seems like the right answer for this case (and it would be right to > look for an answer covered by that trust anchor and use it. >=20 > What about the case where LAN-only-host.example.com is actually signed > using the same chain of trust as any random "public Internet" name in > example.com? I suspect the answer is going to have to be, "Don't do > that." For if you get two responses, both of which validate, but they > have different answers in them, there is no reason whatever for you to > prefer one over the other. >=20 > This is rather unfortunate, as there actually isn't any mechanism in > DNS to be able to prefer one trust anchor over another. >=20 > A >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From ajs@shinkuro.com Fri Jan 14 04:52:54 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 D661B3A6AFB for ; Fri, 14 Jan 2011 04:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 eRaW7hQ+9Jd4 for ; Fri, 14 Jan 2011 04:52:54 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E91053A6ABC for ; Fri, 14 Jan 2011 04:52:53 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 771981ECB41F; Fri, 14 Jan 2011 12:55:18 +0000 (UTC) Date: Fri, 14 Jan 2011 07:55:16 -0500 From: Andrew Sullivan To: teemu.savolainen@nokia.com Message-ID: <20110114125516.GB58308@shinkuro.com> References: <20110113221704.GM26731@shinkuro.com> <056B511A55F8AA42A3E492B7DD19A3191A52C0@008-AM1MPN1-017.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3191A52C0@008-AM1MPN1-017.mgdnok.nokia.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: mif@ietf.org Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG 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: Fri, 14 Jan 2011 12:52:55 -0000 On Fri, Jan 14, 2011 at 07:15:56AM +0000, teemu.savolainen@nokia.com wrote: > > The host implementing this technology (in not-being-attacked case) > would send the DNS query first over the interface where > "LAN-only-host.example.com" would be positively validated with local > trust anchor, as from that interface "example.com" suffix was > learned on? How would it know? I thought _ex hypothesi_ the problem was that a host doesn't know which interface to use for which query, because you can't rely on the DHCP hint because you have no way of trusting it. So you just have to try blindly. The host, however, could have a rule to prefer "closer" trust anchors (i.e. to prefer to use the TA for example.com for validating it when such a TA is configured). So, having a TA for the root and a TA for example.com, the host sends the query for LAN-only-host.example.com on any interface, and as soon as the answer can be validated using the TA for example.com, it knows that that interface is the one to use for example.com. But this won't work if the local view and the Internet-wide view use the same trust anchor, because then the example.com TA is not tied to the local view. In that case, any interface could be validated with the example.com TA and you would lose the ability to make the inference. (There remains open the question of how example.com will validate when the host is not attached to the locally-scoped network. I think this is something that DNS weenies still need to work out, because under some implementations the suggestion I'm making is totally broken.) > While being attacked (the other interface also advertising > "example.com") the host might get negative but validatable reply, in > which case it probably should try out other interfaces (especially > if two interfaces are advertising "example.com")? If the other interface advertises example.com, and the answer is validatable, then all bets are off, I think. But how is an attacker going to produce a validatable response? Is this just a DOS, in that the attacker prevents you from using the local view of the DNS? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Internet-Drafts@ietf.org Fri Jan 14 05: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 A64CD28C0FB; Fri, 14 Jan 2011 05:30:04 -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 M2VYIWOwe0yM; Fri, 14 Jan 2011 05:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41BD928C0FC; Fri, 14 Jan 2011 05: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.10 Message-ID: <20110114133002.522.46217.idtracker@localhost> Date: Fri, 14 Jan 2011 05:30:02 -0800 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-dns-server-selection-00.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, 14 Jan 2011 13: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-00.txt Pages : 19 Date : 2011-01-13 A multi-homed node can be connected to multiple networks that may utilize different DNS namespaces. The node often 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-00.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-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-14051507.I-D@ietf.org> --NextPart-- From teemu.savolainen@nokia.com Fri Jan 14 06:24:23 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 74B033A6C60 for ; Fri, 14 Jan 2011 06:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.771 X-Spam-Level: X-Spam-Status: No, score=-3.771 tagged_above=-999 required=5 tests=[AWL=-1.172, 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 4zdvmQdS8XKz for ; Fri, 14 Jan 2011 06:24:22 -0800 (PST) Received: from mgw-da02.nokia.com (mgw-da02.ext.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 9C7373A6B26 for ; Fri, 14 Jan 2011 06:24:18 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0EEQ27L003673; Fri, 14 Jan 2011 16:26:43 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 16:25:59 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 14 Jan 2011 15:25:58 +0100 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.12]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi; Fri, 14 Jan 2011 15:25:57 +0100 From: To: Thread-Topic: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG draft Thread-Index: AQHLs/b1sqD/x71bi06ecWbZKdGhvg== Date: Fri, 14 Jan 2011 14:25:56 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3191A7CCC@008-AM1MPN1-017.mgdnok.nokia.com> References: <20110113221704.GM26731@shinkuro.com> <056B511A55F8AA42A3E492B7DD19A3191A52C0@008-AM1MPN1-017.mgdnok.nokia.com> <20110114125516.GB58308@shinkuro.com> In-Reply-To: <20110114125516.GB58308@shinkuro.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 X-OriginalArrivalTime: 14 Jan 2011 14:25:59.0076 (UTC) FILETIME=[F6994E40:01CBB3F6] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG 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: Fri, 14 Jan 2011 14:24:23 -0000 > -----Original Message----- > From: ext Andrew Sullivan [mailto:ajs@shinkuro.com] > Sent: 14. tammikuuta 2011 14:55 > To: Savolainen Teemu (Nokia-MS/Tampere) > Cc: mif@ietf.org > Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server- > selection as WG draft >=20 > On Fri, Jan 14, 2011 at 07:15:56AM +0000, teemu.savolainen@nokia.com > wrote: > > > > The host implementing this technology (in not-being-attacked case) > > would send the DNS query first over the interface where > > "LAN-only-host.example.com" would be positively validated with local > > trust anchor, as from that interface "example.com" suffix was > > learned on? >=20 > How would it know? I thought _ex hypothesi_ the problem was that a > host doesn't know which interface to use for which query, because you > can't rely on the DHCP hint because you have no way of trusting it. > So you just have to try blindly. No, the problem is that currently a node has no idea where to send the quer= y so it has to send it out blindly (choose one interface randomly, like oft= entimes currently, or stick on some preferred interface). With the new option host can make more informed decision where to send the = first query.=20 > The host, however, could have a rule to prefer "closer" trust anchors > (i.e. to prefer to use the TA for example.com for validating it when > such a TA is configured). So, having a TA for the root and a TA for > example.com, the host sends the query for LAN-only-host.example.com on > any interface, and as soon as the answer can be validated using the TA "Any interface" is no go, as we do not want to send all DNS queries out of = all interfaces or randomly pick interfaces. Fallbacks in failures is ok.=20 I'm not a DNSSEC expert, so I really need assistance here. Do you suggest t= hat if a host is configured with knowledge that example.com should be valid= ated with TA (?) for example.com, and the response host receives is actuall= y validated with TA for the root, the host would see that it should actuall= y continue asking in hopes some other DNS server replies with something tha= t validates with the desired trust anchor? (unless last DNS server was reac= hed, in which case the reply should be passed to app for connection attempt= ?) > for example.com, it knows that that interface is the one to use for > example.com. But this won't work if the local view and the > Internet-wide view use the same trust anchor, because then the > example.com TA is not tied to the local view. In that case, any > interface could be validated with the example.com TA and you would > lose the ability to make the inference. (There remains open the > question of how example.com will validate when the host is not > attached to the locally-scoped network. I think this is something > that DNS weenies still need to work out, because under some > implementations the suggestion I'm making is totally broken.) Then you would use this option to make a pick. Of course it might happen th= at attacker lures host to go to extranet web site of your corporation rathe= r than intranet web site, but the damage would not be too huge? =20 > > While being attacked (the other interface also advertising > > "example.com") the host might get negative but validatable reply, in > > which case it probably should try out other interfaces (especially > > if two interfaces are advertising "example.com")? >=20 > If the other interface advertises example.com, and the answer is > validatable, then all bets are off, I think. But how is an attacker > going to produce a validatable response? Is this just a DOS, in that > the attacker prevents you from using the local view of the DNS? I mean the server.example.com could have perfectly valid negative reply if = example.com's authoritative name server is contacted from Internet, but wou= ld also have valid positive reply if authoritative name server is contacted= from intranet. Hence if a host gets negative reply it does not mean DNS se= rver of some other interface could not provide positive replies. Best regards, Teemu From ajs@shinkuro.com Fri Jan 14 06:48:12 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 65D3728C0EB for ; Fri, 14 Jan 2011 06:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 18483mcq9Ozj for ; Fri, 14 Jan 2011 06:48:09 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3913728C0EA for ; Fri, 14 Jan 2011 06:48:09 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6BF261ECB41F for ; Fri, 14 Jan 2011 14:50:33 +0000 (UTC) Date: Fri, 14 Jan 2011 09:50:31 -0500 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110114145031.GF58308@shinkuro.com> Mail-Followup-To: mif@ietf.org References: <20110113221704.GM26731@shinkuro.com> <056B511A55F8AA42A3E492B7DD19A3191A52C0@008-AM1MPN1-017.mgdnok.nokia.com> <20110114125516.GB58308@shinkuro.com> <056B511A55F8AA42A3E492B7DD19A3191A7CCC@008-AM1MPN1-017.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3191A7CCC@008-AM1MPN1-017.mgdnok.nokia.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG 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: Fri, 14 Jan 2011 14:48:12 -0000 On Fri, Jan 14, 2011 at 02:25:56PM +0000, teemu.savolainen@nokia.com wrote: > > No, the problem is that currently a node has no idea where to send > the query so it has to send it out blindly (choose one interface > randomly, like oftentimes currently, or stick on some preferred > interface). Right, but my recollection of the objections both in the meetings and on list is that this is just a walking invitation to attacks, because there's no way to secure the connection. (I'm not sure I completely agree: this is already a problem with DHCP anyway. But I guess this makes possible a more focussed attack, which might be a problem.) Therefore, if you're going to rely on DNSSEC to make this secure, you're going to have to make some inferences from DNSSEC. > With the new option host can make more informed decision where to > send the first query. Only if you have some reason to trust the information, and we don't currently have a way to do that on my reading. (I have read the draft, but only very quickly, so feel free to tell me to read more closely.) > "Any interface" is no go, as we do not want to send all DNS queries > out of all interfaces or randomly pick interfaces. Fallbacks in > failures is ok. Right, I get that. My point is that you don't actually have trustworthy information yet, so you might have to do some probing anyway. > I'm not a DNSSEC expert, so I really need assistance here. Do you > suggest that if a host is configured with knowledge that example.com > should be validated with TA (?) for example.com, and the response > host receives is actually validated with TA for the root, the host > would see that it should actually continue asking in hopes some > other DNS server replies with something that validates with the > desired trust anchor? (unless last DNS server was reached, in which > case the reply should be passed to app for connection attempt?) Sorry for the jargon. "TA" == "Trust Anchor". That's the key you have locally configured as something you can use to begin a validation chain. (I'm going to give this a gloss, and get several details wrong, but it's close enough for our purposes.) Normally, we'd expect people to have a TA for the root, and do all validation from that point. But you can have some other TA as well. For instance, you could have a key just for example.com configured. (Is that clear enough? If not, let me know and I'll expand more.) There are different interpretations of what to do in this case. Suppose that you have a TA for example.com and a TA for the root. You get a response for host.example.com, and it validates by starting with the root TA and proceeding down the chain to validate host.example.com. However, it does _not_ validate with the TA for example.com. What do you do? Some people think you reject this as invalid, because you have a "closer" TA (the one for example.com), and you should "trust that more". Others (I am among them) think you should trust every path equivalently. Still others think that this is local policy, and the user needs to choose what kind of policy is in place. I think that the approach I am suggesting falls into this third category, where the policy is, "If I have another network, then try it until I get the one that validates with my example.com TA. Otherwise, trust the validation chain that works." Or something like that. The idea here is a kind of trust-but-verify. If I got the clue from DHCP that I ought to prefer interface-A for example.com, but my locally-configured TA for example.com doesn't produce the results I expect there, I am entitled to try other configured interfaces to see whether my example.com TA works in those contexts. If it does, then I have (validatable) reason to discard the advice from DHCP and to cleave instead to the interface that gave me validatable results using my "closer" TA for example.com. I should say that I am very uneasy with this, in that it's implicit policy about "more trustworthy" keys, and I think that it grafts something onto DNSSEC that isn't really in the design. In this case, however, I can see a practical value, so I think it might make some sense. > Then you would use this option to make a pick. Of course it might > happen that attacker lures host to go to extranet web site of your > corporation rather than intranet web site, but the damage would not > be too huge? It's likely at most a DOS, I agree, assuming that your DNSSEC operations are working. > I mean the server.example.com could have perfectly valid negative > reply if example.com's authoritative name server is contacted from > Internet, but would also have valid positive reply if authoritative > name server is contacted from intranet. Hence if a host gets > negative reply it does not mean DNS server of some other interface > could not provide positive replies. Right, so this is at most a denial of service. I think the issue that (Ted Lemon, I think?) was raising at the mic in Beijing was that, without DNSSEC, this option makes it easier for someone to draw you off to a fake DNS server and capture your traffic in a targetted way. That does seem like a problem, though DHCP already sort of makes that possible anyway. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From teemu.savolainen@nokia.com Fri Jan 14 07:15: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 32C483A6BA0 for ; Fri, 14 Jan 2011 07:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.679 X-Spam-Level: X-Spam-Status: No, score=-4.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 gKjfPv1OSbEL for ; Fri, 14 Jan 2011 07:15:37 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id E36ED3A6B9C for ; Fri, 14 Jan 2011 07:15:36 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0EFHt1X026971; Fri, 14 Jan 2011 17:18:01 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 17:17:40 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 14 Jan 2011 16:17:40 +0100 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.12]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi; Fri, 14 Jan 2011 16:17:40 +0100 From: To: , Thread-Topic: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG draft Thread-Index: AQHLs/pvzUEd4bAgOk+uoBZ6J/NA5ZPQkjSA Date: Fri, 14 Jan 2011 15:17:39 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3191A7D8D@008-AM1MPN1-017.mgdnok.nokia.com> References: <20110113221704.GM26731@shinkuro.com> <056B511A55F8AA42A3E492B7DD19A3191A52C0@008-AM1MPN1-017.mgdnok.nokia.com> <20110114125516.GB58308@shinkuro.com> <056B511A55F8AA42A3E492B7DD19A3191A7CCC@008-AM1MPN1-017.mgdnok.nokia.com> <20110114145031.GF58308@shinkuro.com> In-Reply-To: <20110114145031.GF58308@shinkuro.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 X-OriginalArrivalTime: 14 Jan 2011 15:17:40.0953 (UTC) FILETIME=[2F762C90:01CBB3FE] X-Nokia-AV: Clean Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG 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: Fri, 14 Jan 2011 15:15:38 -0000 > Right, but my recollection of the objections both in the meetings and > on list is that this is just a walking invitation to attacks, because > there's no way to secure the connection. (I'm not sure I completely > agree: this is already a problem with DHCP anyway. But I guess this > makes possible a more focussed attack, which might be a problem.) > Therefore, if you're going to rely on DNSSEC to make this secure, > you're going to have to make some inferences from DNSSEC. I included DNSSEC as people wanted it in:) Originally I thought we could do= by using this option where feasible, e.g. with somehow trusted networks, a= nd securing stuff e.g. with SSL/TLS. For example, nowadays people use cellular, and then go to WLAN (one at a ti= me). Happily doing so, but losing access to information possibly provided o= nly via cellular network. I can use this option there e.g. so that host is = simultaneously connected to cellular and WLAN and would send default querie= s to WLAN (faster - and as it would do if it were the only interface), but = host would not lose visibility to information only available I cellular. Th= e host would listen this option only from cellular interface, which it trus= ts. In CPE case the CPE may listen for this only on its WAN VLANs, not from loc= al WLAN. Hence it would have only trusted uplink interfaces. > > With the new option host can make more informed decision where to > > send the first query. >=20 > Only if you have some reason to trust the information, and we don't > currently have a way to do that on my reading. (I have read the > draft, but only very quickly, so feel free to tell me to read more > closely.) By deployment scenario. On the dnsop list I spelled out this implementation alternative: -- Anyway, we could have it also so that if the most preferred DNS server does= not give positive validatable reply in half a second the node resends the = query out on all interfaces to all DNS servers like a lightning storm. That= would ensure the common case does not require DNS storming, but in case of= trouble the user experience would remain good. -- I will return to rest of your email later, have to go now:-) Teemu From teemu.savolainen@nokia.com Mon Jan 17 03:00: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 DBAC428C0E6 for ; Mon, 17 Jan 2011 03:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 5cjTBz3vLOqm for ; Mon, 17 Jan 2011 03:00:27 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 887D73A6F2D for ; Mon, 17 Jan 2011 03:00:27 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0HAU18w021686; Mon, 17 Jan 2011 12:30:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 12:29:47 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 17 Jan 2011 11:29:47 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.137]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Mon, 17 Jan 2011 11:29:47 +0100 From: To: , Thread-Topic: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG draft Thread-Index: AQHLtjF2+V3doP3NU0aYs55jsfHrNQ== Date: Mon, 17 Jan 2011 10:29:46 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3191D1BC6@008-AM1MPN1-015.mgdnok.nokia.com> References: <20110113221704.GM26731@shinkuro.com> <056B511A55F8AA42A3E492B7DD19A3191A52C0@008-AM1MPN1-017.mgdnok.nokia.com> <20110114125516.GB58308@shinkuro.com> <056B511A55F8AA42A3E492B7DD19A3191A7CCC@008-AM1MPN1-017.mgdnok.nokia.com> <20110114145031.GF58308@shinkuro.com> <056B511A55F8AA42A3E492B7DD19A3191A7D8D@008-AM1MPN1-017.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3191A7D8D@008-AM1MPN1-017.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 X-OriginalArrivalTime: 17 Jan 2011 10:29:47.0701 (UTC) FILETIME=[770A5650:01CBB631] X-Nokia-AV: Clean Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG 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, 17 Jan 2011 11:00:29 -0000 Andrew, I read the rest of your email now and I think I got the idea. I als= o think there's plenty of suggestions already to produce -01:) Will work on= that. Thank you, Teemu=20 > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext teemu.savolainen@nokia.com > Sent: 14. tammikuuta 2011 17:18 > To: ajs@shinkuro.com; mif@ietf.org > Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server- > selection as WG draft >=20 > > Right, but my recollection of the objections both in the meetings and > > on list is that this is just a walking invitation to attacks, because > > there's no way to secure the connection. (I'm not sure I completely > > agree: this is already a problem with DHCP anyway. But I guess this > > makes possible a more focussed attack, which might be a problem.) > > Therefore, if you're going to rely on DNSSEC to make this secure, > > you're going to have to make some inferences from DNSSEC. >=20 > I included DNSSEC as people wanted it in:) Originally I thought we > could do by using this option where feasible, e.g. with somehow trusted > networks, and securing stuff e.g. with SSL/TLS. >=20 > For example, nowadays people use cellular, and then go to WLAN (one at > a time). Happily doing so, but losing access to information possibly > provided only via cellular network. I can use this option there e.g. so > that host is simultaneously connected to cellular and WLAN and would > send default queries to WLAN (faster - and as it would do if it were > the only interface), but host would not lose visibility to information > only available I cellular. The host would listen this option only from > cellular interface, which it trusts. >=20 > In CPE case the CPE may listen for this only on its WAN VLANs, not from > local WLAN. Hence it would have only trusted uplink interfaces. >=20 > > > With the new option host can make more informed decision where to > > > send the first query. > > > > Only if you have some reason to trust the information, and we don't > > currently have a way to do that on my reading. (I have read the > > draft, but only very quickly, so feel free to tell me to read more > > closely.) >=20 > By deployment scenario. >=20 > On the dnsop list I spelled out this implementation alternative: > -- > Anyway, we could have it also so that if the most preferred DNS server > does not give positive validatable reply in half a second the node > resends the query out on all interfaces to all DNS servers like a > lightning storm. That would ensure the common case does not require DNS > storming, but in case of trouble the user experience would remain good. > -- >=20 > I will return to rest of your email later, have to go now:-) >=20 > Teemu > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From pierrick.seite@orange-ftgroup.com Fri Jan 21 15:41: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 07FCD3A683C for ; Fri, 21 Jan 2011 15:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] 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 ECk56slNYTKS for ; Fri, 21 Jan 2011 15:41:07 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id E531B3A6846 for ; Fri, 21 Jan 2011 15:41:06 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 380FD6C0003 for ; Sat, 22 Jan 2011 00:44:21 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2A70E6C0001 for ; Sat, 22 Jan 2011 00:44:21 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 22 Jan 2011 00:43:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB9C5.0E622381" Date: Sat, 22 Jan 2011 00:43:50 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201723868@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option Thread-Index: AcuTvFv34kysIr1PTOqyNyoPEhehsAmAfPYQ References: From: To: X-OriginalArrivalTime: 21 Jan 2011 23:43:52.0020 (UTC) FILETIME=[0EEB7940:01CBB9C5] Subject: [mif] draft-ietf-mif-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: Fri, 21 Jan 2011 23:41:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB9C5.0E622381 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I've one concern regarding draft-ietf-mif-dhcpv6-route-option. I think the use-cases should be clarified. Actually, this draft only illustrates the use-case of multi-homed residential access networks. The problem is that it is not clear if other use-cases are covered (e.g. multihomed 3GPP/WIFI handset). But I guess they are, as described in http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-03 which is supposed to be taken into account in draft-ietf-mif-dhcpv6-route-option. Right? =20 Pierrick =20 =20 =20 ------_=_NextPart_001_01CBB9C5.0E622381 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I’ve one concern regarding =
draft-ietf-mif-dhcpv6-route-option. I think the use-cases should be =
clarified. Actually, this draft only illustrates the use-case of =
multi-homed residential access networks. The problem is that it is not =
clear if other use-cases are covered (e.g. multihomed 3GPP/WIFI =
handset). But I guess they are,  as described in h=
ttp://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-03 which =
is supposed to be taken into account in =
draft-ietf-mif-dhcpv6-route-option. =
Right?
 
Pierrick

 =

 =

 =

------_=_NextPart_001_01CBB9C5.0E622381-- From behcetsarikaya@yahoo.com Mon Jan 24 11:02: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 38F0C3A6B2A for ; Mon, 24 Jan 2011 11:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 WYSIAM+W-NWH for ; Mon, 24 Jan 2011 11:02:08 -0800 (PST) Received: from nm1-vm0.bullet.mail.ne1.yahoo.com (nm1-vm0.bullet.mail.ne1.yahoo.com [98.138.91.74]) by core3.amsl.com (Postfix) with SMTP id 5612A3A6B30 for ; Mon, 24 Jan 2011 11:02:08 -0800 (PST) Received: from [98.138.90.52] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 24 Jan 2011 19:05:03 -0000 Received: from [98.138.89.194] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 24 Jan 2011 19:05:03 -0000 Received: from [127.0.0.1] by omp1052.mail.ne1.yahoo.com with NNFMP; 24 Jan 2011 19:05:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 588511.73588.bm@omp1052.mail.ne1.yahoo.com Received: (qmail 4934 invoked by uid 60001); 24 Jan 2011 19:05:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295895902; bh=mYzw4cAIHofTPa70EzMzHf2FmsDEVn+USQ9IpO5I+f8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xYsYXejXpwUOjF5Z80f/BTeyevsKMfIND/adhgJgu8ZDMEwtWtZujClMHHcHd+93KGxQgtNqQEN8RUz4V3GN4ua8JM8jdK53Re5+c7u98JbYzLllfQ/8FbKb5go2qUUAdzBqb5K1vZy/EQbHIy2O8dEzyCe4BfL1Gui7EmbgC5k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Jg8FfH9yvoDS6st4C/hqN6GMpQ+jWqDMBxzrvhkUv8oWqr6b9hGGJGHXN1OR0hukCYrDpuG8YeWIgnf5vB54/+lMZBL6gU9Ut1z6pCuGTWget4mrX3SoAnlyte8pXtwIsW29EDJ71S4Z/dwdVyhBRvnLhc8teKVbLLL0q/vAkqQ=; Message-ID: <631938.4416.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: CcC1R5sVM1n0QubItrZS34gvSRJXFa7U8a1V9jez1vjp7OC 2i3ra9sdkhHeYpzRmxRYQyKFZhujQyRh.QKjWz6lfLDFKAJfI9hYvj5VOXf7 8IAAd51hywtWOj_K.s7WSD83GyJVxAa5HiC7.HrtbBIma6nSgKRnufCasXCu WKYIQQWWC_Xi8HlFHSwMQ17OmMPhL8l4oiR8k0eg7p4PoBENobm.NBA9LCMu HYKy00NjYYd9FSlwEIK9Lpjgr9V3vHu5gva7RLYTT64eBEEAv2u9.0cskmLn 2MkstTbgiZNNsKW77mUAPKQU1VWK1LElGQYxMmIEM4Ech3mlHa5TMy2_Ll8f f32t273irNNIQFi39Cp7y4f.6yW1Edl87s3oz4QWfGBarfZa616FVaqWXnz8 FY.4aEJj9gPAM Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Mon, 24 Jan 2011 11:05:02 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <843DA8228A1BA74CA31FB4E111A5C46201723868@ftrdmel0.rd.francetelecom.fr> Date: Mon, 24 Jan 2011 11:05:02 -0800 (PST) From: Behcet Sarikaya To: pierrick.seite@orange-ftgroup.com, mif@ietf.org In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201723868@ftrdmel0.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 19:02:09 -0000 Hi Pierrick,=0A> =0A>Hello,=0A> =0A>I=E2=80=99ve one concern regarding draf= t-ietf-mif-dhcpv6-route-option. I think the =0A>use-cases should be clarifi= ed. Actually, this draft only illustrates the =0A>use-case of multi-homed r= esidential access networks. The problem is that it is =0A>not clear if othe= r use-cases are covered (e.g. multihomed 3GPP/WIFI handset). =0A>But I gues= s they are, as described in =0A>http://tools.ietf.org/html/draft-sun-mif-r= oute-config-dhcp6-03=0A=0Aand also draft-sarikaya-mif-dhcpv6solution-04.txt= =0A=0A=0A>which is supposed =0A>to be taken into account in draft-ietf-mif-= dhcpv6-route-option. Right?=0A=0A=0AI am not sure. We need to discuss the n= eed for Interface-Info attribute and =0Asimilar issues, I think.=0A=0ARegar= ds,=0A=0ABehcet=0A=0A=0A=0A From pierrick.seite@orange-ftgroup.com Tue Jan 25 00:29:26 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 0AC023A6B7B for ; Tue, 25 Jan 2011 00:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GhlbO2su9n7o for ; Tue, 25 Jan 2011 00:29:25 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 2C76D3A6964 for ; Tue, 25 Jan 2011 00:29:25 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4BFF36C000A; Tue, 25 Jan 2011 09:32:43 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id C96986C001B; Tue, 25 Jan 2011 09:32:43 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 09:32:10 +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: Tue, 25 Jan 2011 09:32:09 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201723D21@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <631938.4416.qm@web111413.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option Thread-Index: Acu7+Z3AQHPV69CQTdyQJHgC+41oDAAb/MdA References: <843DA8228A1BA74CA31FB4E111A5C46201723868@ftrdmel0.rd.francetelecom.fr> <631938.4416.qm@web111413.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 25 Jan 2011 08:32:10.0683 (UTC) FILETIME=[5C08D8B0:01CBBC6A] Subject: Re: [mif] draft-ietf-mif-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: Tue, 25 Jan 2011 08:29:26 -0000 Hi Behcet, At the moment my point is only on the use case: should DHCP route option = be restricted to residential network use-case or is the scope broader, = e.g. including multihomed 3GPP/WIFI? BR, Pierrick > -----Message d'origine----- > De=A0: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > Envoy=E9=A0: lundi 24 janvier 2011 20:05 > =C0=A0: SEITE Pierrick RD-RESA-REN; mif@ietf.org > Objet=A0: Re: [mif] draft-ietf-mif-dhcpv6-route-option >=20 > Hi Pierrick, > > > >Hello, > > > >I've one concern regarding draft-ietf-mif-dhcpv6-route-option. I = think > the > >use-cases should be clarified. Actually, this draft only illustrates = the > >use-case of multi-homed residential access networks. The problem is = that > it is > >not clear if other use-cases are covered (e.g. multihomed 3GPP/WIFI > handset). > >But I guess they are, as described in > >http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-03 >=20 > and also draft-sarikaya-mif-dhcpv6solution-04.txt >=20 >=20 > >which is supposed > >to be taken into account in draft-ietf-mif-dhcpv6-route-option. = Right? >=20 >=20 > I am not sure. We need to discuss the need for Interface-Info = attribute > and > similar issues, I think. >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 >=20 From teemu.savolainen@nokia.com Tue Jan 25 07:57: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 0EC7E3A67F3 for ; Tue, 25 Jan 2011 07:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=-0.929, 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 ayuUKNmmdi6S for ; Tue, 25 Jan 2011 07:57:30 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 04F123A67EC for ; Tue, 25 Jan 2011 07:57:29 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0PG0P00016079; Tue, 25 Jan 2011 18:00:26 +0200 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, 25 Jan 2011 18:00:20 +0200 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, 25 Jan 2011 17:00:14 +0100 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.219]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Tue, 25 Jan 2011 17:00:14 +0100 From: To: , , Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option Thread-Index: Acu7+Z3AQHPV69CQTdyQJHgC+41oDAAb/MdAAA/ONPA= Date: Tue, 25 Jan 2011 16:00:11 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A319315263@008-AM1MPN1-017.mgdnok.nokia.com> References: <843DA8228A1BA74CA31FB4E111A5C46201723868@ftrdmel0.rd.francetelecom.fr> <631938.4416.qm@web111413.mail.gq1.yahoo.com> <843DA8228A1BA74CA31FB4E111A5C46201723D21@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201723D21@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jan 2011 16:00:20.0566 (UTC) FILETIME=[F7A75F60:01CBBCA8] X-Nokia-AV: Clean Subject: Re: [mif] draft-ietf-mif-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: Tue, 25 Jan 2011 15:57:31 -0000 Broader, including (but not limited to) the multihomed 3GPP/WiFi. Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext pierrick.seite@orange-ftgroup.com > Sent: 25. tammikuuta 2011 10:32 > To: sarikaya@ieee.org; mif@ietf.org > Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option >=20 >=20 > Hi Behcet, >=20 > At the moment my point is only on the use case: should DHCP route > option be restricted to residential network use-case or is the scope > broader, e.g. including multihomed 3GPP/WIFI? >=20 > BR, > Pierrick >=20 > > -----Message d'origine----- > > De=A0: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > Envoy=E9=A0: lundi 24 janvier 2011 20:05 > > =C0=A0: SEITE Pierrick RD-RESA-REN; mif@ietf.org > > Objet=A0: Re: [mif] draft-ietf-mif-dhcpv6-route-option > > > > Hi Pierrick, > > > > > >Hello, > > > > > >I've one concern regarding draft-ietf-mif-dhcpv6-route-option. I > think > > the > > >use-cases should be clarified. Actually, this draft only illustrates > the > > >use-case of multi-homed residential access networks. The problem is > that > > it is > > >not clear if other use-cases are covered (e.g. multihomed 3GPP/WIFI > > handset). > > >But I guess they are, as described in > > >http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-03 > > > > and also draft-sarikaya-mif-dhcpv6solution-04.txt > > > > > > >which is supposed > > >to be taken into account in draft-ietf-mif-dhcpv6-route-option. > Right? > > > > > > I am not sure. We need to discuss the need for Interface-Info > attribute > > and > > similar issues, I think. > > > > Regards, > > > > Behcet > > > > > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From hisuntao@gmail.com Tue Jan 25 09:39: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 8B8663A685B for ; Tue, 25 Jan 2011 09:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IqngWkDzCqoR for ; Tue, 25 Jan 2011 09:39:52 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 730163A6876 for ; Tue, 25 Jan 2011 09:39:52 -0800 (PST) Received: by iwn40 with SMTP id 40so25366iwn.31 for ; Tue, 25 Jan 2011 09:42:50 -0800 (PST) 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=JfBfykgYJ8pNwjmkx6oBqdFkRZGj/QqU463mp9OxGiE=; b=eYCu+Rys+APMbGW4Ouk/tSBQMt1kC7VwtGrrCZsx1KZ7BYBd14qYHnuS3KKR1GgOvi 6OABQiyCNH3eDiEDaiBH3xRYNjvWhl4htvqX27K7rMNE4oas8lLlx1gclgaPuSEuuKix TiZzt7aNP3JLYzzlPEig+As4ZZM8I0DS6VBdI= 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=U0BlJDcMsiIKBXiwmXSnZUjMbasd4RR09ik+Um/E/bLi9Sb/LvUDoMXzlvzoHLyM3y 58jpfmiIWO4f2nCgkKBR+SHgy6fqoLIdfMLx6wT8C14yau+YQBpw9cw/M6RK1a5ajQRt z+NOBGWVIeWmwqdJqsNYHudltELeMHtWsoCYU= MIME-Version: 1.0 Received: by 10.231.174.71 with SMTP id s7mr6935532ibz.56.1295977369945; Tue, 25 Jan 2011 09:42:49 -0800 (PST) Received: by 10.231.15.74 with HTTP; Tue, 25 Jan 2011 09:42:49 -0800 (PST) In-Reply-To: <056B511A55F8AA42A3E492B7DD19A319315263@008-AM1MPN1-017.mgdnok.nokia.com> References: <843DA8228A1BA74CA31FB4E111A5C46201723868@ftrdmel0.rd.francetelecom.fr> <631938.4416.qm@web111413.mail.gq1.yahoo.com> <843DA8228A1BA74CA31FB4E111A5C46201723D21@ftrdmel0.rd.francetelecom.fr> <056B511A55F8AA42A3E492B7DD19A319315263@008-AM1MPN1-017.mgdnok.nokia.com> Date: Wed, 26 Jan 2011 01:42:49 +0800 Message-ID: From: Tao Sun To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=0016363b903ec5f0a4049aaf3efa Cc: mif@ietf.org Subject: Re: [mif] draft-ietf-mif-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: Tue, 25 Jan 2011 17:39:53 -0000 --0016363b903ec5f0a4049aaf3efa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Maybe we can add a sentence at the begining of the Section 2 to clarify this. . For exmple: "The solution described in this document applies to multihomed scenarios such as simultaneously connected to multiple access network (e.g.= , WiFi and 3G.). The following scenario ..." Regards, Tao On Wed, Jan 26, 2011 at 12:00 AM, wrote: > Broader, including (but not limited to) the multihomed 3GPP/WiFi. > > Teemu > > > -----Original Message----- > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > > ext pierrick.seite@orange-ftgroup.com > > Sent: 25. tammikuuta 2011 10:32 > > To: sarikaya@ieee.org; mif@ietf.org > > Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option > > > > > > Hi Behcet, > > > > At the moment my point is only on the use case: should DHCP route > > option be restricted to residential network use-case or is the scope > > broader, e.g. including multihomed 3GPP/WIFI? > > > > BR, > > Pierrick > > > > > -----Message d'origine----- > > > De : Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > > Envoy=E9 : lundi 24 janvier 2011 20:05 > > > =C0 : SEITE Pierrick RD-RESA-REN; mif@ietf.org > > > Objet : Re: [mif] draft-ietf-mif-dhcpv6-route-option > > > > > > Hi Pierrick, > > > > > > > >Hello, > > > > > > > >I've one concern regarding draft-ietf-mif-dhcpv6-route-option. I > > think > > > the > > > >use-cases should be clarified. Actually, this draft only illustrates > > the > > > >use-case of multi-homed residential access networks. The problem is > > that > > > it is > > > >not clear if other use-cases are covered (e.g. multihomed 3GPP/WIFI > > > handset). > > > >But I guess they are, as described in > > > >http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-03 > > > > > > and also draft-sarikaya-mif-dhcpv6solution-04.txt > > > > > > > > > >which is supposed > > > >to be taken into account in draft-ietf-mif-dhcpv6-route-option. > > Right? > > > > > > > > > I am not sure. We need to discuss the need for Interface-Info > > attribute > > > and > > > similar issues, I think. > > > > > > Regards, > > > > > > Behcet > > > > > > > > > > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --0016363b903ec5f0a4049aaf3efa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Maybe we can add a sentence at the begining of the Section 2 to clarif= y this.=A0.
For exmple: "The solution described in this document applies to m= ultihomed scenarios such as simultaneously connected to multiple access net= work (e.g., WiFi and 3G.). The following scenario ..."
=A0
Regards,
=A0
Tao

On Wed, Jan 26, 2011 at 12:00 AM, <teemu.savolainen@noki= a.com> wrote:
Broader, including (but not limi= ted to) the multihomed 3GPP/WiFi.

Teemu

> -----Original Message-----
> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of
= > ext pierrick.seit= e@orange-ftgroup.com
> Sent: 25. tammikuuta 2011 10:32
> To: sarikaya@ieee.org; mif@ietf.= org
> Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option
&g= t;
>
> Hi Behcet,
>
> At the moment my point is only on t= he use case: should DHCP route
> option be restricted to residential = network use-case or is the scope
> broader, e.g. including multihomed= 3GPP/WIFI?
>
> BR,
> Pierrick
>
> > -----Message d'o= rigine-----
> > De=A0: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
> > Envoy= =E9=A0: lundi 24 janvier 2011 20:05
> > =C0=A0: SEITE Pierrick RD-RESA-REN; mif@ietf.org
> > Objet=A0: Re: [mif] draft-ietf-mif-dhcpv6-= route-option
> >
> > Hi Pierrick,
> > >
&g= t; > >Hello,
> > >
> > >I've one concern regarding draft-ietf-m= if-dhcpv6-route-option. I
> think
> > the
> > >u= se-cases should be clarified. Actually, this draft only illustrates
> the
> > >use-case of multi-homed residential access networ= ks. The problem is
> that
> > it is
> > >not cle= ar if other use-cases are covered (e.g. multihomed 3GPP/WIFI
> > h= andset).
> > >But I guess they are, =A0as described in
> > >http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-= 03
> >
> > and also draft-sarikaya-mif-dhcpv6solution-04.txt> >
> >
> > >which is supposed
> > >= ;to be taken into account in draft-ietf-mif-dhcpv6-route-option.
> Ri= ght?
> >
> >
> > I am not sure. We need to discuss the n= eed for Interface-Info
> attribute
> > and
> > simi= lar issues, I think.
> >
> > Regards,
> >
> > Behcet
> >
> >
> >
> >
>= ; _______________________________________________
> mif mailing list<= br>> mif@ietf.org
> https://www.i= etf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/l= istinfo/mif

--0016363b903ec5f0a4049aaf3efa-- From pierrick.seite@orange-ftgroup.com Thu Jan 27 08:11: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 1459D3A6908 for ; Thu, 27 Jan 2011 08:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 wKufqFzw57sS for ; Thu, 27 Jan 2011 08:11:36 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 4C5863A67D3 for ; Thu, 27 Jan 2011 08:11:32 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 34545858001; Thu, 27 Jan 2011 17:19:28 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 28D22760001; Thu, 27 Jan 2011 17:19:28 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jan 2011 17:14:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBE3D.490D4010" Date: Thu, 27 Jan 2011 17:14:33 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620175A80E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option Thread-Index: Acu8t0szfDr3D7h5Sk+f2SP5Yfu1zQBhcswg References: <843DA8228A1BA74CA31FB4E111A5C46201723868@ftrdmel0.rd.francetelecom.fr><631938.4416.qm@web111413.mail.gq1.yahoo.com><843DA8228A1BA74CA31FB4E111A5C46201723D21@ftrdmel0.rd.francetelecom.fr><056B511A55F8AA42A3E492B7DD19A319315263@008-AM1MPN1-017.mgdnok.nokia.com> From: To: , X-OriginalArrivalTime: 27 Jan 2011 16:14:34.0662 (UTC) FILETIME=[498F9460:01CBBE3D] Cc: mif@ietf.org Subject: Re: [mif] draft-ietf-mif-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: Thu, 27 Jan 2011 16:11:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBE3D.490D4010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sounds good. I think, it should be added to the draft. Can the editor = confirm? =20 Pierrick =20 ________________________________ De : Tao Sun [mailto:hisuntao@gmail.com]=20 Envoy=E9 : mardi 25 janvier 2011 18:43 =C0 : teemu.savolainen@nokia.com Cc : SEITE Pierrick RD-RESA-REN; sarikaya@ieee.org; mif@ietf.org Objet : Re: [mif] draft-ietf-mif-dhcpv6-route-option =20 Maybe we can add a sentence at the begining of the Section 2 to clarify = this. .=20 For exmple: "The solution described in this document applies to = multihomed scenarios such as simultaneously connected to multiple access = network (e.g., WiFi and 3G.). The following scenario ..." =20 Regards, =20 Tao On Wed, Jan 26, 2011 at 12:00 AM, wrote: Broader, including (but not limited to) the multihomed 3GPP/WiFi. Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext pierrick.seite@orange-ftgroup.com > Sent: 25. tammikuuta 2011 10:32 > To: sarikaya@ieee.org; mif@ietf.org > Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option > > > Hi Behcet, > > At the moment my point is only on the use case: should DHCP route > option be restricted to residential network use-case or is the scope > broader, e.g. including multihomed 3GPP/WIFI? > > BR, > Pierrick > > > -----Message d'origine----- > > De : Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > Envoy=E9 : lundi 24 janvier 2011 20:05 > > =C0 : SEITE Pierrick RD-RESA-REN; mif@ietf.org > > Objet : Re: [mif] draft-ietf-mif-dhcpv6-route-option > > > > Hi Pierrick, > > > > > >Hello, > > > > > >I've one concern regarding draft-ietf-mif-dhcpv6-route-option. I > think > > the > > >use-cases should be clarified. Actually, this draft only = illustrates > the > > >use-case of multi-homed residential access networks. The problem is > that > > it is > > >not clear if other use-cases are covered (e.g. multihomed 3GPP/WIFI > > handset). > > >But I guess they are, as described in > > >http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-03 > > > > and also draft-sarikaya-mif-dhcpv6solution-04.txt > > > > > > >which is supposed > > >to be taken into account in draft-ietf-mif-dhcpv6-route-option. > Right? > > > > > > I am not sure. We need to discuss the need for Interface-Info > attribute > > and > > similar issues, I think. > > > > Regards, > > > > Behcet > > > > > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif =20 ------_=_NextPart_001_01CBBE3D.490D4010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sounds good. I = think, it should be added to the draft. Can the editor = confirm?

 =

Pierrick

 =

De : Tao = Sun [mailto:hisuntao@gmail.com]
Envoy=E9 : mardi 25 = janvier 2011 18:43
=C0 : teemu.savolainen@nokia.com
Cc : SEITE Pierrick RD-RESA-REN; sarikaya@ieee.org; mif@ietf.org
Objet : Re: [mif] draft-ietf-mif-dhcpv6-route-option

 

Maybe we can add a sentence at the begining of the Section 2 to = clarify this. .

For exmple: "The solution described in this document = applies to multihomed scenarios such as simultaneously connected to multiple access network (e.g., WiFi and 3G.). The following scenario = ..."

 

Regards,

 

Tao

On Wed, Jan 26, 2011 at 12:00 AM, <teemu.savolainen@nokia.com= > wrote:

Broader, including (but not limited to) the multihomed = 3GPP/WiFi.

Teemu


> -----Original Message-----
> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of
> ext pierrick.seite@orange-f= tgroup.com
> Sent: 25. tammikuuta 2011 10:32
> To: sarikaya@ieee.org; mif@ietf.org
> Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option
>
>
> Hi Behcet,
>
> At the moment my point is only on the use case: should DHCP = route
> option be restricted to residential network use-case or is the = scope
> broader, e.g. including multihomed 3GPP/WIFI?
>
> BR,
> Pierrick
>
> > -----Message d'origine-----
> > De : Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > Envoy=E9 : lundi 24 janvier 2011 20:05
> > =C0 : SEITE Pierrick RD-RESA-REN; mif@ietf.org
> > Objet : Re: [mif] draft-ietf-mif-dhcpv6-route-option
> >
> > Hi Pierrick,
> > >
> > >Hello,
> > >
> > >I've one concern regarding = draft-ietf-mif-dhcpv6-route-option. I
> think
> > the
> > >use-cases should be clarified. Actually, this draft only illustrates
> the
> > >use-case of multi-homed residential access networks. The = problem is
> that
> > it is
> > >not clear if other use-cases are covered (e.g. multihomed 3GPP/WIFI
> > handset).
> > >But I guess they are,  as described in
> > >http://tools.ietf.org/html/draft-sun-mif-route-config-d= hcp6-03
> >
> > and also draft-sarikaya-mif-dhcpv6solution-04.txt
> >
> >
> > >which is supposed
> > >to be taken into account in = draft-ietf-mif-dhcpv6-route-option.
> Right?
> >
> >
> > I am not sure. We need to discuss the need for = Interface-Info
> attribute
> > and
> > similar issues, I think.
> >
> > Regards,
> >
> > Behcet
> >
> >
> >
> >
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

 

------_=_NextPart_001_01CBBE3D.490D4010--