From nobody Tue Dec 2 04:43:02 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD82C1A1B3D; Tue, 2 Dec 2014 04:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTXC-z6LNMpi; Tue, 2 Dec 2014 04:42:52 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9488D1A1B12; Tue, 2 Dec 2014 04:42:52 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so16743247wgh.23 for ; Tue, 02 Dec 2014 04:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dxR6jsChQi6T/tWB1dEV71z6F88XXbKMrKeOC4lz8F8=; b=Bb71zhlV0t4dLiy+HpNhUSW80VMiSl3FqEgpzQo1ToDPyGP4upH2TVOa7Qzy0M0fqT 9Qz6gigoVDhLQYZvql9RQGEGzChcaP0jtSb/bR9XdY6jI3zgsk4EOBaMZ2Ua3XNDh34q i6E43SJ7bBncoO+SAETG7briQPe+UM4fAHGpSgqoAMyC85fddne0s5B/pcY9CjO6xadf zB71MsfWvLX2mg/Dzp19vNStZsZvQbC7e1xdeJAbS662+LHUI3qzyOH6YmW8HrHC6NRu WHDPt4c2+rW8rbF9X6cSA76BKGNlR80BvUaAjegcysYeBW4alX0kHRNO7wHrOAbdSj4q ba2A== MIME-Version: 1.0 X-Received: by 10.180.98.100 with SMTP id eh4mr5016915wib.54.1417524171178; Tue, 02 Dec 2014 04:42:51 -0800 (PST) Received: by 10.194.76.237 with HTTP; Tue, 2 Dec 2014 04:42:51 -0800 (PST) Date: Tue, 2 Dec 2014 13:42:51 +0100 Message-ID: From: Daniel Migault To: "mif@ietf.org" , "multipathtcp@ietf.org Mailing List" Content-Type: multipart/alternative; boundary=f46d04428cd2af0a0105093b1098 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/aeUJgJSlb6FWpGv4Pb9c65bjUWg Cc: Yaron Sheffer , Valery Smyslov , Paul Hoffman Subject: [mif] Securing Multiple Interfaces with IPsec X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 12:42:58 -0000 --f46d04428cd2af0a0105093b1098 Content-Type: text/plain; charset=UTF-8 Hi, We would like to inform you that the ipsecme WG has started an survey of interest [1] for the draft-mglt-ipsecme-clone-ike-sa [2]. This draft details how to set IPsec Security Associations with multiple Interfaces. If you think this topic should or should not be addressed please respond to this mail by December 8. If you have any question regarding the document, feel free to let us know. BR Daniel and Valery (authors of the draft) *I. Area that may benefit from this optimization:* The main scenarios we envisioned IPsec with multiple interfaces were: - Offload from RAN to WLAN network - Resilience - Multiple Path TCP: I believe this is the optimal way to have IPsec with multiple Path TCP for example. *II. Scenarios that motivated the document* Initial motivation for the document was to optimize setting IPsec associations with devices that have more than one interface. Briefly speaking, currently, setting an IPsec association with multiple interfaces requires one authentication per interface. This introduces multiple delays, especially when authentication requires multiple round trip. With the optimization, we make it possible to configure it with a single authentication. Authentication is performed on a single interface, and for the other interfaces, IPsec authentication and settings is "replicated". Another scenario that motivated us was load sharing between different security gateways (each of them has its own IP addresses). In this case client creates IKE SA with any of these security gateways and then could be moved to another without re-authentication. Of course this assumes that security gateways can communicate between each other and exchange IKE & IPsec SA states. [1] http://www.ietf.org/mail-archive/web/ipsec/current/msg09442.html [2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/ -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d04428cd2af0a0105093b1098 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We would like to inform = you that the ipsecme WG has started an survey of interest [1] for the= draft-mglt-ipsecme-clone-ike-sa [2].= This draft details how to set IPsec Security Associations with multiple In= terfaces. If you think this topic should or should not be addressed please = respond to this mail by December 8.

If you have any question regard= ing the document, feel free to let us know.

BR

Daniel and Val= ery (authors of the draft)

I. Area that may benefit from this= optimization:

The main scenarios we envisioned IPsec with m= ultiple interfaces were:
=C2=A0=C2=A0=C2=A0 - Offload from RA= N to WLAN network
=C2=A0=C2=A0=C2=A0 - Resilience
=C2=A0=C2=A0=C2=A0 - Multiple Path TCP: I believe this is the opt= imal way to have IPsec with multiple Path TCP for example.


II. Sce= narios that motivated the document
=C2=A0=C2=A0=C2=A0
=
Initial motivation for the document was to optimize setting IPsec=20 associations with devices that have more than one interface. Briefly=20 speaking, currently, setting an IPsec association with multiple=20 interfaces requires one authentication per interface. This introduces=20 multiple delays, especially when authentication requires multiple round=20 trip. With the optimization, we make it possible to configure it with a=20 single authentication. Authentication is performed on a single=20 interface, and for the other interfaces, IPsec authentication and=20 settings is "replicated".

Another scenario that= =20 motivated us was load sharing between different security gateways (each=20 of them has its own IP addresses). In this=20 case client creates IKE SA with any of these security gateways= and then could be moved to another without re-authentication. Of course this assumes that=20 security gateways can communicate between each other and exchange IKE & IPsec SA states.


[1] http:= //www.ietf.org/mail-archive/web/ipsec/current/msg09442.html
[2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-= ike-sa/

--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
--f46d04428cd2af0a0105093b1098-- From nobody Fri Dec 5 06:54:57 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976B61ACEA2 for ; Fri, 5 Dec 2014 06:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.041 X-Spam-Level: * X-Spam-Status: No, score=1.041 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw6KMrVpprBK for ; Fri, 5 Dec 2014 06:54:53 -0800 (PST) Received: from COL004-OMC2S7.hotmail.com (col004-omc2s7.hotmail.com [65.55.34.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DBD1ACE2A for ; Fri, 5 Dec 2014 06:54:53 -0800 (PST) Received: from COL125-W22 ([65.55.34.72]) by COL004-OMC2S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 5 Dec 2014 06:54:52 -0800 X-TMN: [DFqWK6GhyqibtHrX+IGmsNHtA6I3BaKc] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_bf03a250-17a7-4395-8e0d-aa9c87258cd3_" From: Hui Deng To: "mif@ietf.org" Date: Fri, 5 Dec 2014 22:54:52 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 05 Dec 2014 14:54:52.0953 (UTC) FILETIME=[6D10B090:01D0109B] Archived-At: http://mailarchive.ietf.org/arch/msg/mif/TZor2tWF_Y7Hq0Bbn7-yuelwnc4 Subject: [mif] MIF 91th minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 14:54:54 -0000 --_bf03a250-17a7-4395-8e0d-aa9c87258cd3_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLg0KIA0KV2Ugd291bGQgbGlrZSB0byB0aGFuayBCYXJiYXJhJ3Mga2luZCBoZWxw IHRvIHRha2UgdGhlIG1pbnV0ZXMuDQphbmQgYWxzbyBEYXZlJ3MgamFiYmVyIHNjcmliZS4NCiAN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvbWludXRlcy9taW51dGVzLTkxLW1p Zg0KIA0KUGxlYXNlIGZlZWwgZnJlZSB0byBsZXQgY29jaGFpciBrbm93IGlmIHlvdSB3b3VsZCBs aWtlIHRvIGhhdmUgYSByZXZpc2lvbi4NCiANCkJlc3QgcmVnYXJkcywNCiANCi1IdWkNCiAJCSAJ ICAgCQkgIA== --_bf03a250-17a7-4395-8e0d-aa9c87258cd3_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsLjxCUj4mbmJzcDs8QlI+V2Ugd291bGQg bGlrZSB0byB0aGFuayBCYXJiYXJhJ3Mga2luZCBoZWxwIHRvIHRha2UgdGhlIG1pbnV0ZXMuPEJS PmFuZCBhbHNvIERhdmUncyBqYWJiZXIgc2NyaWJlLjxCUj4mbmJzcDs8QlI+PGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MS9taW51dGVzL21pbnV0ZXMtOTEtbWlmIj5o dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkxL21pbnV0ZXMvbWludXRlcy05MS1taWY8 L2E+PEJSPiZuYnNwOzxCUj5QbGVhc2UgZmVlbCBmcmVlIHRvIGxldCZuYnNwO2NvY2hhaXIga25v dyBpZiB5b3Ugd291bGQgbGlrZSB0byBoYXZlIGEgcmV2aXNpb24uPEJSPiZuYnNwOzxCUj5CZXN0 IHJlZ2FyZHMsPEJSPiZuYnNwOzxCUj4tSHVpPEJSPiAJCSAJICAgCQkgIDwvZGl2PjwvYm9keT4N CjwvaHRtbD4= --_bf03a250-17a7-4395-8e0d-aa9c87258cd3_-- From nobody Wed Dec 17 07:49:10 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0C21A1B76 for ; Wed, 17 Dec 2014 07:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4mbYpNpCQkn for ; Wed, 17 Dec 2014 07:49:00 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0AA1A1B89 for ; Wed, 17 Dec 2014 07:48:55 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 05C1FDA00BA for ; Wed, 17 Dec 2014 15:48:58 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2ED1553E084 for ; Wed, 17 Dec 2014 07:48:25 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Dec 2014 07:48:25 -0800 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <9071C858-BBCA-483C-94CD-E7C2584980F0@nominum.com> Date: Wed, 17 Dec 2014 10:48:10 -0500 To: "mif@ietf.org List" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/mif/I7DGByRJqm0N9mRo51vZWMcI4Ok Subject: [mif] AD review of MPVD Architecture X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:49:07 -0000 I'm sorry this has taken so long. It got lost in the tracker, only to = surface just as an unrelated cluster of documents was soaking up a lot = of my time. I am very excited to get this document to the IESG, so = please don't take this delay as being indicative of a lack of interest. = On to the comments: This is a bit hard to parse, and I suggest the following change: OLD: 3. Usage of a particular network that is not consistent with the intent of the scenario or involved parties leading to connectivity failure and / or other undesired consequences. NEW: 3. Use of a particular network that is not consistent with the intended use of the network, or the intent of the communicating parties, leading to connectivity failure and / or other undesired consequences. What's the rationale for the third sentence in the paragraph below? In some network topologies, network infrastructure elements may need to advertise multiple PvDs. Generally, the details of how this is performed will be defined in companion design documents. However, where different design choices are possible, the choice that requires a smaller number of packets shall be preferred for efficiency. I ask because I think this is DISCUSS fodder: someone is going to want = details. If it's important, let's keep it and defend it. If it's = more of an aside, let's get rid of it. Difficult to parse: OLD: For some time it is likely that there will be networks which do not advertise explicit PvD information as the deployment of new features in networking protocols is a relatively slow process. NEW: For the foreseeable future, there will be networks which do not advertise explicit PvD information, because deployment of new features in networking protocols is a relatively slow process. I think the last sentence in this paragraph serves two purposes, and = would be better separated: OLD: Through the use of implicit PvDs, PvD-aware nodes may still provide benefits to their users (when compared to non-PvD aware nodes) by following the best practices described in Section 5, using the network information from different interfaces separately to consistently serve network connection request. NEW: Through the use of implicit PvDs, PvD-aware nodes may still provide benefits to their users (when compared to non-PvD aware nodes) by following the best practices described in Section 5. PvD-aware nodes shall treat betwork information from different interfaces, which is not identified as belonging explicitly to some PvD, as belonging to separate PvDs, one per interface. The reason I propose this is that the last paragraph in the section = imposes an explicit requirement on PvD-aware nodes that they separate = out PvD-labeled and non-PvD-labeled information into explicit and = implicit PvDs, but the section as a whole never explicitly states a = requirement that information from different interfaces that is not = labeled is treated as belonging to separate PvDs. Whether this change = as taken as I have made it, or done some other way, I think you need to = state a requirement for both cases. The last paragraph in the section also doesn't parse very well: OLD: In mixed mode, i.e., where of multiple networks are available on an attached link only some of which advertise PvD information, the PvD- aware node shall create explicit PvDs from explicitly learned PvD information and associate other learned configuration (without an explicit PvD) with implicit PvD(s) created for that interface. NEW: Implicit PvDs can also occur in a mixed mode, i.e., where of multiple networks that are available on an attached link, only some advertise PvD information. In this case, the PvD- aware node shall create explicit PvDs from information explicitly=20 labeled as beloinging to PvDs. It shall associate=20 configuration information not labeled with an explicit PvD with an implicit PvD created for that interface. (Is there a case where two implicit PvDs would be created on the same = interface?) This seems a bit too definite to me: OLD: Explicit PvDs, in practice will often also be scoped only for configuration related to a particular interface. However, there are no such requirements or limitations defined in this architecture. NEW: In the simplest case, explicit PvDs will be scoped for configuration related only to a specific interface. However,=20 there is no requirement in this architecture for such a limitation. I don't know what "generally" means here, suggest you delete it: generally, authentication of a PvD ID may be also required in scenarios involving only one connected interface and / or PvD You could take out some equivocating here: OLD: This architecture intends to support such scenarios, among others. Hence, it shall be noted that no hierarchical relationship exists between interfaces and PvDs: it is possible for multiple PvDs to be simultaneously accessible over one interface, as well as a single PvD to be simultaneously accessible over multiple interfaces. NEW: This architecture supports such scenarios. Hence, no hierarchical relationship exists between interfaces and PvDs: it is possible for multiple PvDs to be simultaneously accessible over one interface, as well as a single PvD to be simultaneously accessible over multiple interfaces. I think you need a signature, not an authorization token, here: To resolve this, there must be a mechanism for the PvD owner to attach some form of authorization token to the configuration information that is delivered. I don't remember the details of the discussion we had anymore, but the = issue with a token is that it doesn't actually solve the problem of = proving that the PvD information supplied is actually associated with = the named PvD. Having said this, I know the working group thought = about this, and I'm not proposing to change the consensus. If the term = "token" was preferred over "signature", it's fine to leave it that way = and duke it out during IESG review. :) This doesn't make sense: One way to restrict the propagation of information which is of no use to a specific host is for the host to indicate the PvD information they require within their configuration request. One way this could be accomplished is by using a DHCPv6 ORO containing the PvDs that are of interest. The configuration source can then respond with only the requested information. The ORO just lists options. There's no way to name a PvD. I vaguely = recall that the idea here was to provide a per-PvD ORO, not list PvDs in = the ORO. Do you really want to advocate the use of shared-secret authentication = of PvD identities? This would mean that any node that can authenticate = the assertion of the PvD identity can also spoof it: One way to validate the trust relationship between a node and the source of a PvD is through the combination of cryptographic authentication and an identifier configured on the node. In some cases, the two could be the same; for example, if authentication is by a shared secret, the secret would have to be associated with the PvD identifier. Without a PvD Identifier / shared key tuple, authentication would be impossible, and hence authentication and authorization are combined. Slight clarification called for here: Rogue configuration source: A compromised configuration source, such as a router or a DHCPv6 server, may advertise information about PvDs that it is not authorized to advertise. e.g. A coffee shop WLAN may advertise configuration information purporting to be from an enterprise and may try to attract enterprise related traffic. The only real way to prevent this is is for the PvD related configuration container to contain embedded authentication and authorization information from the owner of the PvD. This provides the client with a way of detecting the attack by verifying the authentication and authorization information provided inside the PvD container option, after verifying its trust of the PvD owner (e.g. a certificate with a well-known / common trust anchor). What prevents this attack is not the provision of authentication = information, but an explicit configuration on the client to reject this = PvD if it is _not_ authenticated. The way you've stated it, it's = fairly obvious that that's the case, but you don't actually say so. From nobody Wed Dec 17 07:50:31 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC8A1A1B76 for ; Wed, 17 Dec 2014 07:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zmNc2pCpw5J for ; Wed, 17 Dec 2014 07:50:15 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E6D1A88CF for ; Wed, 17 Dec 2014 07:50:05 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id BEA50DA00BA for ; Wed, 17 Dec 2014 15:50:07 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id F332353E084 for ; Wed, 17 Dec 2014 07:49:34 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Dec 2014 07:49:34 -0800 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Date: Wed, 17 Dec 2014 10:49:20 -0500 To: "mif@ietf.org List" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/mif/czkbz0NZG8O70TCVqrfLtwlouDo Subject: [mif] Process for MPvD Architecture document. X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:50:22 -0000 I am an acknowledged contributor to the MPvD architecture document, I = think correctly so. As such, I can't actually be the AD sponsor for = the document. So I am going to work on getting another AD to sponsor = the document. This may introduce some additional delay, but hopefully = not too much. I will keep you posted. From nobody Wed Dec 17 07:53:42 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA7A1A8A51 for ; Wed, 17 Dec 2014 07:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmvCyTLo1coj; Wed, 17 Dec 2014 07:53:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E8A1A8AAC; Wed, 17 Dec 2014 07:53:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: denghui02@hotmail.com, mif@ietf.org, mif-chairs@tools.ietf.org, draft-ietf-mif-mpvd-arch.all@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141217155330.16192.26948.idtracker@ietfa.amsl.com> Date: Wed, 17 Dec 2014 07:53:30 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mif/dbrsTfpaAA1QR8iprJcCDgUoEeo Subject: [mif] ID Tracker State Update Notice: X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:53:40 -0000 IESG state changed to AD Evaluation::AD Followup from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ From nobody Wed Dec 17 14:04:39 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9881A8781 for ; Wed, 17 Dec 2014 14:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj0Hjq4grzUV for ; Wed, 17 Dec 2014 14:04:35 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9606B1A0164 for ; Wed, 17 Dec 2014 14:04:35 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id bj1so17338505pad.9 for ; Wed, 17 Dec 2014 14:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LPCFpLDQJsXDCwTzi6MugI57U6rYzqUHkyIOEvUpks4=; b=uG/pRLQb0nDoez0SU/CAV1FwvFTEVCdVJLUffnFOubQ8iKKLlmtWuPjEiNExyrwBJj o1N7mbJPx5qg3ubVHp9TIcro2SzGqMS8WtNXMcXXuoNGjCjkHQfVa6V7kvROd0UWOEDr WmtuFFLtcX3+3hMC/kAqH+nwTNqepufVNI4L7V8C3zd4/LaQmWHiWeENrYdY8+9CHUo+ 4EIplF6HLTJ+KoE7sFWlrIayAVLcK2U3XUBjg2c9hcZMR0uDc9BNpDv+6RVi4AEk+g4n LI4hkg2wjTcMGVpZwRg4/f2kBF6KRcTZ5T0bpTQnyx+RxkYno3ZOJbUFVIu5gNW4f/2L 8eag== X-Received: by 10.70.23.99 with SMTP id l3mr73573740pdf.86.1418853874896; Wed, 17 Dec 2014 14:04:34 -0800 (PST) Received: from ?IPv6:2406:e007:6d06:1:28cc:dc4c:9703:6781? ([2406:e007:6d06:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id e2sm4888029pdo.11.2014.12.17.14.04.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 14:04:33 -0800 (PST) Message-ID: <5491FDF7.5050101@gmail.com> Date: Thu, 18 Dec 2014 11:04:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ted Lemon References: <9071C858-BBCA-483C-94CD-E7C2584980F0@nominum.com> In-Reply-To: <9071C858-BBCA-483C-94CD-E7C2584980F0@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mif/QuXSZ6dQaDibQBDHOxxMR1SUN_8 Cc: "mif@ietf.org List" Subject: Re: [mif] AD review of MPVD Architecture X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:04:37 -0000 On 18/12/2014 04:48, Ted Lemon wrote: ... > What's the rationale for the third sentence in the paragraph below? > > In some network topologies, network infrastructure elements may need > to advertise multiple PvDs. Generally, the details of how this is > performed will be defined in companion design documents. However, > where different design choices are possible, the choice that requires > a smaller number of packets shall be preferred for efficiency. > > I ask because I think this is DISCUSS fodder: someone is going to want details. If it's important, let's keep it and defend it. If it's more of an aside, let's get rid of it. Good catch, IMHO. I could easily imagine an argument that a smaller number of packets that for some reason need more complex processing would actually be less efficient. Let's not invite that argument - delete the sentence. Brian