From nobody Sun May 3 20:19:36 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DD11A0032; Sun, 3 May 2015 20:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 Yf5ABCu-N4aL; Sun, 3 May 2015 20:19:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7611A1A002F; Sun, 3 May 2015 20:19:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSC14071; Mon, 04 May 2015 03:19:26 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 May 2015 04:19:24 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 4 May 2015 11:19:19 +0800 From: Xuxiaohu To: Joe Touch , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAYoLZIFwke90qEGncpXxc1v51nAPgAgAQl8XA= Date: Mon, 4 May 2015 03:19:19 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> In-Reply-To: <5543D870.6080108@isi.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 03:19:31 -0000 Hi Joe, I'm wondering whether your proposal as below is also applicable to other UD= P-based encapsulation approaches which have not yet considered doing fragme= ntation on the tunnel layer, such as GENEVE, VXLAN-GPE, GRE-in-UDP and NSH-= UDP. Best regards, Xiaohu > -----Original Message----- > From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Saturday, May 02, 2015 3:48 AM > To: Donald Eastlake; trill@ietf.org > Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 > Hi, all, >=20 > Have you considered GUE as an encapsulation layer? >=20 > Encapsulating anything in UDP directly has a number of hazards, including > support for at-rate fragmentation, IPv4 ID generation, etc., that GUE is = intended > to address. >=20 > Joe >=20 > On 5/1/2015 9:58 AM, Donald Eastlake wrote: > > Forwarded with permission. > > > > Thanks, > > Donald > > ---------- Forwarded message ---------- > > From: *Donald Eastlake* > > > Date: Tue, Apr 28, 2015 at 9:26 AM > > Subject: Re: Mail regarding draft-ietf-trill-over-ip > > To: Mingui Zhang > > > > > > Hi Mingui, > > > > Thanks for these comments! See below. > > > > On Tue, Apr 28, 2015 at 4:27 AM, Mingui Zhang > > wrote: > >> Hi, > >> > >> I read the document. It's comprehensive and well written. Below, sever= al > comments for your information. > >> > >> 1. It's not clear how the ports IPs are associated with the ports= ? Maybe, > we can add some words to explain that they can be got from DHCP or manual > configuration? Or we just say it is out the scope of this document. > > > > Yes, they need to be configured. Could be DHCP or manual or maybe some > > sort of orchestration thing... Seems reasonable to mention this in the > > draft. > > > >> 2. Is it helpful to add a reference topology? Terminologies, such= as IP > tunnel, port IPs, RBridges can be put onto this figure. A walk-through ex= ample > based on this reference topology can be used to explain how the IP tunnel= is set > up, how does a TRILL Data packet get encapsulated/decapsulated and > transported in the IP tunnel. I think this would be educational. > > > > A few more network diagrams would probably be helpful. If you look at > > the minutes from the Dallas TRILL WG meeting, the suggestion of having > > a couple of example packets was supported... > > > >> 3. Both IP and TRILL have specified BFD. Since TRILL is dependent= on IP > in TRILL-over-IP, it's unnecessary to have both TRILL and IP interact wit= h BFD. It's > best to assert TRILL-over-IP will have the IP interact with BFD. Please r= efer to > https://tools.ietf.org/html/rfc5882#section-4.4 > > > > Well, if you are only going to use one then I agree with the section > > you reference in RFC 5882 and you should do BFD over IP. But that > > doesn't check the TRILL stack, just the IP and lower stacks. So we > > could recommend just using IP BFD but I don't think we should try to > > prohibit people from also using BFD over TRILL on the link. > > > >> 4. Is the IP link in this document "a single link (physical, or a= secure > tunnel such as IPsec)"? Then, we can require the TTL "MUST be set to the > maximum on transmit, and checked to be equal to the maximum value on > reception (and the packet dropped if this is not the case)." See also RFC= 5880 > Section 9. > > > > I don't think so. There is nothing wrong with the communication > > between two TRILL IP ports being multiple IP hops. Even if IPsec is in > > use, it could be integrated with the TRILL over IP port at one end but > > at the other end, the IPsec implementation could be integrated with a > > firewall a couple of hops from the RBridge... > > > >> 5. There are six tiny typos marked in the attached doc. > > > > OK. We'll fix this up in the next version. > > > > Maybe you should post these comments, or some of them, to the TRILL WG > > mailing list. It would be good if there was more discussion of drafts > > there. Or if it OK with you, I could just forward your comments and my > > responses to the list... > > > > Thanks, > > Donald > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > Donald E. Eastlake 3rd +1-508-333-2270 (cell= ) > > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > > > > > >> Thanks, > >> Mingui > > > > > > > > _______________________________________________ > > trill mailing list > > trill@ietf.org > > https://www.ietf.org/mailman/listinfo/trill > > >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From nobody Sun May 3 23:29:27 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FBB1A9123 for ; Sun, 3 May 2015 23:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 0Sd8rQeGkbTT for ; Sun, 3 May 2015 23:29:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C35A1A9121 for ; Sun, 3 May 2015 23:29:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVP57228; Mon, 04 May 2015 06:29:20 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 May 2015 07:29:20 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Mon, 4 May 2015 14:29:14 +0800 From: "Xialiang (Frank)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-xia-sfc-yang-oam-03.txt Thread-Index: AQHQhjIdUEHEalMrGUeQiqokotf2z51rWKpg Date: Mon, 4 May 2015 06:29:13 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [sfc] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-xia-sfc-yang-oam-03=2Etxt?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 06:29:25 -0000 SGkgYWxsLA0KQmFzZWQgb24gdGhlIGxhdGVzdCB1cGRhdGVzIG9mIFtJLUQudGlzc2EtbGltZS15 YW5nLW9hbS1tb2RlbF0gYW5kIFtJLUQucGVubm8tc2ZjLXlhbmddLCB3ZSBhbHNvIHVwZGF0ZSB0 aGUgU0ZDIHlhbmcgb2FtIGRyYWZ0Lg0KUGxlYXNlIHJldmlldyBpdCwgYW55IGNvbW1lbnRzIGFy ZSB3YXJtbHkgd2VsY29tZSENCg0KQi5SLg0KRnJhbmsNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0t LQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0NeaciDTml6UgMTQ6MTgNCuaU tuS7tuS6ujogRGVlcGFrIEt1bWFyOyB3YW5neml0YW87IFhpYWxpYW5nIChGcmFuayk7IERlZXBh ayBLdW1hcjsgTW9oYW1lZCBCb3VjYWRhaXI7IHdhbmd6aXRhbzsgUWluIFd1OyBNb2hhbWVkIEJv dWNhZGFpcjsgUWluIFd1OyBYaWFsaWFuZyAoRnJhbmspDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQteGlhLXNmYy15YW5nLW9hbS0wMy50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQteGlhLXNmYy15YW5nLW9hbS0wMy50eHQgaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMaWFuZyBYaWEgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQteGlhLXNmYy15YW5nLW9hbQ0KUmV2aXNpb246CTAz DQpUaXRsZToJCVlBTkcgRGF0YSBNb2RlbCBmb3IgU0ZDIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0 aW9uLCBhbmQgTWFpbnRlbmFuY2UgKE9BTSkNCkRvY3VtZW50IGRhdGU6CTIwMTUtMDUtMDMNCkdy b3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTE5DQpVUkw6ICAgICAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXhpYS1zZmMteWFuZy1v YW0tMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQteGlhLXNmYy15YW5nLW9hbS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQteGlhLXNmYy15YW5nLW9hbS0wMw0KRGlmZjogICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC14aWEtc2ZjLXlhbmctb2Ft LTAzDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIFlBTkcgZGF0YSBtb2Rl bCBmb3IgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZw0KICAgKFNGQyBPcGVyYXRpb25zLCBBZG1p bmlzdHJhdGlvbiwgYW5kIE1haW50ZW5hbmNlIChPQU0pLiAgSXQgZXh0ZW5kcw0KICAgZnJvbSB0 aGUgYmFzaWMgWUFORyBkYXRhIG1vZGVsIGZvciBMYXllciBpbmRlcGVuZGVudCBPQU0gTWFuYWdl bWVudA0KICAgZGVmaW5lZCBpbiBbSS1ELnRpc3NhLWxpbWUteWFuZy1vYW0tbW9kZWxdIHdpdGgg U0ZDIHRlY2hub2xvZ3kNCiAgIHNwZWNpZmljcy4gIEl0IGluY2x1ZGVzIFNGQyBPQU0gcmVsYXRl ZCBjb25maWd1cmF0aW9uLCBzdGF0ZSwgYW5kIFJQQw0KICAgaW5mb3JtYXRpb24gZGF0YS4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon May 4 09:24:47 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96171A6F11; Mon, 4 May 2015 09:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Wxv_mRuLQUKV; Mon, 4 May 2015 09:13:13 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730E11A1AB8; Mon, 4 May 2015 09:13:13 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t44GCUg9011597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 May 2015 09:12:39 -0700 (PDT) Message-ID: <55479A6D.2040403@isi.edu> Date: Mon, 04 May 2015 09:12:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-Mailman-Approved-At: Mon, 04 May 2015 09:24:46 -0700 Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 16:13:19 -0000 On 5/3/2015 8:19 PM, Xuxiaohu wrote: > Hi Joe, > > I'm wondering whether your proposal as below is also applicable to > other UDP-based encapsulation approaches which have not yet considered > doing fragmentation on the tunnel layer, such as GENEVE, VXLAN-GPE, > GRE-in-UDP and NSH-UDP. Again: We know of at least four things that tunnels need that IP-in-UDP ignores: - stronger checksums - fragmentation support - signalling support (e.g., to test whether a tunnel is up or to measure MTUs) - support for robust ID fields (related to fragmentation, e.g., to overcome the limits of IPv4 ID as per RFC 6864) I haven't scrubbed GUE to ensure that all four are addressed, but it may be more than the above, and certainly it's important not to start from scratch needlessly. Joe > > Best regards, > Xiaohu > >> -----Original Message----- >> From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Saturday, May 02, 2015 3:48 AM >> To: Donald Eastlake; trill@ietf.org >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >> >> Hi, all, >> >> Have you considered GUE as an encapsulation layer? >> >> Encapsulating anything in UDP directly has a number of hazards, including >> support for at-rate fragmentation, IPv4 ID generation, etc., that GUE is intended >> to address. >> >> Joe >> >> On 5/1/2015 9:58 AM, Donald Eastlake wrote: >>> Forwarded with permission. >>> >>> Thanks, >>> Donald >>> ---------- Forwarded message ---------- >>> From: *Donald Eastlake* > >>> Date: Tue, Apr 28, 2015 at 9:26 AM >>> Subject: Re: Mail regarding draft-ietf-trill-over-ip >>> To: Mingui Zhang >> > >>> >>> Hi Mingui, >>> >>> Thanks for these comments! See below. >>> >>> On Tue, Apr 28, 2015 at 4:27 AM, Mingui Zhang >> > wrote: >>>> Hi, >>>> >>>> I read the document. It's comprehensive and well written. Below, several >> comments for your information. >>>> >>>> 1. It's not clear how the ports IPs are associated with the ports? Maybe, >> we can add some words to explain that they can be got from DHCP or manual >> configuration? Or we just say it is out the scope of this document. >>> >>> Yes, they need to be configured. Could be DHCP or manual or maybe some >>> sort of orchestration thing... Seems reasonable to mention this in the >>> draft. >>> >>>> 2. Is it helpful to add a reference topology? Terminologies, such as IP >> tunnel, port IPs, RBridges can be put onto this figure. A walk-through example >> based on this reference topology can be used to explain how the IP tunnel is set >> up, how does a TRILL Data packet get encapsulated/decapsulated and >> transported in the IP tunnel. I think this would be educational. >>> >>> A few more network diagrams would probably be helpful. If you look at >>> the minutes from the Dallas TRILL WG meeting, the suggestion of having >>> a couple of example packets was supported... >>> >>>> 3. Both IP and TRILL have specified BFD. Since TRILL is dependent on IP >> in TRILL-over-IP, it's unnecessary to have both TRILL and IP interact with BFD. It's >> best to assert TRILL-over-IP will have the IP interact with BFD. Please refer to >> https://tools.ietf.org/html/rfc5882#section-4.4 >>> >>> Well, if you are only going to use one then I agree with the section >>> you reference in RFC 5882 and you should do BFD over IP. But that >>> doesn't check the TRILL stack, just the IP and lower stacks. So we >>> could recommend just using IP BFD but I don't think we should try to >>> prohibit people from also using BFD over TRILL on the link. >>> >>>> 4. Is the IP link in this document "a single link (physical, or a secure >> tunnel such as IPsec)"? Then, we can require the TTL "MUST be set to the >> maximum on transmit, and checked to be equal to the maximum value on >> reception (and the packet dropped if this is not the case)." See also RFC 5880 >> Section 9. >>> >>> I don't think so. There is nothing wrong with the communication >>> between two TRILL IP ports being multiple IP hops. Even if IPsec is in >>> use, it could be integrated with the TRILL over IP port at one end but >>> at the other end, the IPsec implementation could be integrated with a >>> firewall a couple of hops from the RBridge... >>> >>>> 5. There are six tiny typos marked in the attached doc. >>> >>> OK. We'll fix this up in the next version. >>> >>> Maybe you should post these comments, or some of them, to the TRILL WG >>> mailing list. It would be good if there was more discussion of drafts >>> there. Or if it OK with you, I could just forward your comments and my >>> responses to the list... >>> >>> Thanks, >>> Donald >>> ============================= >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >>> >>> >>>> Thanks, >>>> Mingui >>> >>> >>> >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>> >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill From nobody Mon May 4 13:39:28 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D4C1B2AF5; Mon, 4 May 2015 13:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBdfUSrjrEO7; Mon, 4 May 2015 13:39:23 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9461B2AE5; Mon, 4 May 2015 13:39:23 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so113660867lbb.3; Mon, 04 May 2015 13:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=add0lHRgFGZGKXL8srK/vgHwML8IuV5sL31ehqespPk=; b=cfoCnfnAHnGbfrDNJ7/+9dp1kRSkKQeqcu0NuHC3PBP6ESZfT1cnTrxnyqL5yo4LNQ r1ZEK+HNMiUbPxV9P1v8/fZjmf4Gjjxawzt7wfYQZsUTcE0b7SMd4fhbVXVB0LhWrOwh 0mDGSBiuqKgBfxWiTHsckApSB1PbZWsFcIYoWLEtXZAGkrUhBPeq9/ZtZxsjVfRk1I6Y 6MtorCtekWvR6e4sq14pBlaOx+7SAgAurrfjx25B0p1gqAYNLmbOHzDruQyTxXd4UH0f +Y3fFjnVDL+3DB6+JHn3PzFfdSHJctGIx3P9nGa3aJDGtjrGuDStKzRZTIsiLXZnBO5Y 1dkg== MIME-Version: 1.0 X-Received: by 10.152.44.225 with SMTP id h1mr20923652lam.5.1430771961433; Mon, 04 May 2015 13:39:21 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Mon, 4 May 2015 13:39:21 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> Date: Mon, 4 May 2015 15:39:21 -0500 Message-ID: From: Behcet Sarikaya To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "int-area@ietf.org" , "sfc@ietf.org" , Joe Touch , "nvo3@ietf.org" , "trill@ietf.org" , Donald Eastlake Subject: Re: [sfc] [Int-area] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 20:39:25 -0000 Hi Xiaohu, Joe, On Sun, May 3, 2015 at 10:19 PM, Xuxiaohu wrote: > Hi Joe, > > I'm wondering whether your proposal as below is also applicable to other UDP-based encapsulation approaches which have not yet considered doing fragmentation on the tunnel layer, such as GENEVE, VXLAN-GPE, GRE-in-UDP and NSH-UDP. > This is a very good question. Let me give draft links below for Joe in case he can not find them: VXLAN-GPE: https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-00 GENEVE: https://www.ietf.org/archive/id/draft-gross-geneve-02.txt Regards, Behcet > Best regards, > Xiaohu > >> -----Original Message----- >> From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Saturday, May 02, 2015 3:48 AM >> To: Donald Eastlake; trill@ietf.org >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >> >> Hi, all, >> >> Have you considered GUE as an encapsulation layer? >> >> Encapsulating anything in UDP directly has a number of hazards, including >> support for at-rate fragmentation, IPv4 ID generation, etc., that GUE is intended >> to address. >> >> Joe >> >> On 5/1/2015 9:58 AM, Donald Eastlake wrote: >> > Forwarded with permission. >> > >> > Thanks, >> > Donald >> > ---------- Forwarded message ---------- >> > From: *Donald Eastlake* > >> > Date: Tue, Apr 28, 2015 at 9:26 AM >> > Subject: Re: Mail regarding draft-ietf-trill-over-ip >> > To: Mingui Zhang > > > >> > >> > Hi Mingui, >> > >> > Thanks for these comments! See below. >> > >> > On Tue, Apr 28, 2015 at 4:27 AM, Mingui Zhang > > > wrote: >> >> Hi, >> >> >> >> I read the document. It's comprehensive and well written. Below, several >> comments for your information. >> >> >> >> 1. It's not clear how the ports IPs are associated with the ports? Maybe, >> we can add some words to explain that they can be got from DHCP or manual >> configuration? Or we just say it is out the scope of this document. >> > >> > Yes, they need to be configured. Could be DHCP or manual or maybe some >> > sort of orchestration thing... Seems reasonable to mention this in the >> > draft. >> > >> >> 2. Is it helpful to add a reference topology? Terminologies, such as IP >> tunnel, port IPs, RBridges can be put onto this figure. A walk-through example >> based on this reference topology can be used to explain how the IP tunnel is set >> up, how does a TRILL Data packet get encapsulated/decapsulated and >> transported in the IP tunnel. I think this would be educational. >> > >> > A few more network diagrams would probably be helpful. If you look at >> > the minutes from the Dallas TRILL WG meeting, the suggestion of having >> > a couple of example packets was supported... >> > >> >> 3. Both IP and TRILL have specified BFD. Since TRILL is dependent on IP >> in TRILL-over-IP, it's unnecessary to have both TRILL and IP interact with BFD. It's >> best to assert TRILL-over-IP will have the IP interact with BFD. Please refer to >> https://tools.ietf.org/html/rfc5882#section-4.4 >> > >> > Well, if you are only going to use one then I agree with the section >> > you reference in RFC 5882 and you should do BFD over IP. But that >> > doesn't check the TRILL stack, just the IP and lower stacks. So we >> > could recommend just using IP BFD but I don't think we should try to >> > prohibit people from also using BFD over TRILL on the link. >> > >> >> 4. Is the IP link in this document "a single link (physical, or a secure >> tunnel such as IPsec)"? Then, we can require the TTL "MUST be set to the >> maximum on transmit, and checked to be equal to the maximum value on >> reception (and the packet dropped if this is not the case)." See also RFC 5880 >> Section 9. >> > >> > I don't think so. There is nothing wrong with the communication >> > between two TRILL IP ports being multiple IP hops. Even if IPsec is in >> > use, it could be integrated with the TRILL over IP port at one end but >> > at the other end, the IPsec implementation could be integrated with a >> > firewall a couple of hops from the RBridge... >> > >> >> 5. There are six tiny typos marked in the attached doc. >> > >> > OK. We'll fix this up in the next version. >> > >> > Maybe you should post these comments, or some of them, to the TRILL WG >> > mailing list. It would be good if there was more discussion of drafts >> > there. Or if it OK with you, I could just forward your comments and my >> > responses to the list... >> > >> > Thanks, >> > Donald >> > ============================= >> > Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >> > >> > >> >> Thanks, >> >> Mingui >> > >> > >> > >> > _______________________________________________ >> > trill mailing list >> > trill@ietf.org >> > https://www.ietf.org/mailman/listinfo/trill >> > >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Mon May 4 19:23:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C59B1B2DAE; Mon, 4 May 2015 19:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 FND4tVru777N; Mon, 4 May 2015 19:23:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4121B2CF6; Mon, 4 May 2015 19:23:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVQ87904; Tue, 05 May 2015 02:23:10 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 May 2015 03:23:08 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 5 May 2015 10:23:05 +0800 From: Xuxiaohu To: Joe Touch , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAYoLZIFwke90qEGncpXxc1v51nAPgAgAQl8XCAAFTXgIABIiUA Date: Tue, 5 May 2015 02:23:04 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> In-Reply-To: <55479A6D.2040403@isi.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 02:23:16 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, May 05, 2015 12:12 AM > To: Xuxiaohu; Donald Eastlake; trill@ietf.org > Cc: nvo3@ietf.org; sfc@ietf.org; int-area@ietf.org > Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/3/2015 8:19 PM, Xuxiaohu wrote: > > Hi Joe, > > > > I'm wondering whether your proposal as below is also applicable to > > other UDP-based encapsulation approaches which have not yet considered > > doing fragmentation on the tunnel layer, such as GENEVE, VXLAN-GPE, > > GRE-in-UDP and NSH-UDP. >=20 > Again: >=20 > We know of at least four things that tunnels need that IP-in-UDP ignores: >=20 > - stronger checksums >=20 > - fragmentation support >=20 > - signalling support (e.g., to test whether a tunnel is up or > to measure MTUs) >=20 > - support for robust ID fields (related to fragmentation, > e.g., to overcome the limits of IPv4 ID as per RFC 6864) I'm just wondering whether the above is only applicable to IP-in-UDP or app= licable to all the other UDP-based encapsulations as well. > I haven't scrubbed GUE to ensure that all four are addressed, but it may = be more > than the above, and certainly it's important not to start from scratch ne= edlessly. I don't intend addressing items 1), 2) and 3). As for item 3), I would add= the following text: =20 "Ingress AFBRs MUST NOT fragment I-IP [RFC5565] packets (i.e., UDP encapsul= ated IP packets), and when the outer IP header is IPv4, ingress AFBRs MUST = set the DF bit in the outer IPv4 header. It is strongly RECOMMENDED that I-= IP [RFC5565] transit core be configured to carry an MTU at least large enou= gh to accommodate the added encapsulation headers. Meanwhile, it is strongl= y RECOMMENDED that Path MTU Discovery [RFC1191][RFC1981] is used to prevent= or minimize fragmentation."=20 Ahead of the following existing text in Section 4: "If an ingress AFBR performs fragmentation on an E-IP packet before encapsulating, it MUST use the same source UDP port for all fragmented packets so as to ensures these fragmented packets are always forwarded on the same path." In a word, IP-in-UDP is just intended for those network environments where = fragmentation on the tunnel layer and strong checksums are not desired. For= those network environments where fragmentation on the tunnel layer and str= onger checksums are required, GUE should be considered instead. Best regards, Xiaohu > Joe >=20 >=20 > > > > Best regards, > > Xiaohu > > > >> -----Original Message----- > >> From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Joe Touch > >> Sent: Saturday, May 02, 2015 3:48 AM > >> To: Donald Eastlake; trill@ietf.org > >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > >> > >> Hi, all, > >> > >> Have you considered GUE as an encapsulation layer? > >> > >> Encapsulating anything in UDP directly has a number of hazards, > >> including support for at-rate fragmentation, IPv4 ID generation, > >> etc., that GUE is intended to address. > >> > >> Joe > >> > >> On 5/1/2015 9:58 AM, Donald Eastlake wrote: > >>> Forwarded with permission. > >>> > >>> Thanks, > >>> Donald > >>> ---------- Forwarded message ---------- > >>> From: *Donald Eastlake* > > >>> Date: Tue, Apr 28, 2015 at 9:26 AM > >>> Subject: Re: Mail regarding draft-ietf-trill-over-ip > >>> To: Mingui Zhang >>> > > >>> > >>> Hi Mingui, > >>> > >>> Thanks for these comments! See below. > >>> > >>> On Tue, Apr 28, 2015 at 4:27 AM, Mingui Zhang > >>> > wrote: > >>>> Hi, > >>>> > >>>> I read the document. It's comprehensive and well written. Below, > >>>> several > >> comments for your information. > >>>> > >>>> 1. It's not clear how the ports IPs are associated with the por= ts? > Maybe, > >> we can add some words to explain that they can be got from DHCP or > >> manual configuration? Or we just say it is out the scope of this docum= ent. > >>> > >>> Yes, they need to be configured. Could be DHCP or manual or maybe > >>> some sort of orchestration thing... Seems reasonable to mention this > >>> in the draft. > >>> > >>>> 2. Is it helpful to add a reference topology? Terminologies, su= ch as IP > >> tunnel, port IPs, RBridges can be put onto this figure. A > >> walk-through example based on this reference topology can be used to > >> explain how the IP tunnel is set up, how does a TRILL Data packet get > >> encapsulated/decapsulated and transported in the IP tunnel. I think th= is > would be educational. > >>> > >>> A few more network diagrams would probably be helpful. If you look > >>> at the minutes from the Dallas TRILL WG meeting, the suggestion of > >>> having a couple of example packets was supported... > >>> > >>>> 3. Both IP and TRILL have specified BFD. Since TRILL is depende= nt on > IP > >> in TRILL-over-IP, it's unnecessary to have both TRILL and IP interact > >> with BFD. It's best to assert TRILL-over-IP will have the IP interact > >> with BFD. Please refer to > >> https://tools.ietf.org/html/rfc5882#section-4.4 > >>> > >>> Well, if you are only going to use one then I agree with the section > >>> you reference in RFC 5882 and you should do BFD over IP. But that > >>> doesn't check the TRILL stack, just the IP and lower stacks. So we > >>> could recommend just using IP BFD but I don't think we should try to > >>> prohibit people from also using BFD over TRILL on the link. > >>> > >>>> 4. Is the IP link in this document "a single link (physical, or= a secure > >> tunnel such as IPsec)"? Then, we can require the TTL "MUST be set to > >> the maximum on transmit, and checked to be equal to the maximum value > >> on reception (and the packet dropped if this is not the case)." See > >> also RFC 5880 Section 9. > >>> > >>> I don't think so. There is nothing wrong with the communication > >>> between two TRILL IP ports being multiple IP hops. Even if IPsec is > >>> in use, it could be integrated with the TRILL over IP port at one > >>> end but at the other end, the IPsec implementation could be > >>> integrated with a firewall a couple of hops from the RBridge... > >>> > >>>> 5. There are six tiny typos marked in the attached doc. > >>> > >>> OK. We'll fix this up in the next version. > >>> > >>> Maybe you should post these comments, or some of them, to the TRILL > >>> WG mailing list. It would be good if there was more discussion of > >>> drafts there. Or if it OK with you, I could just forward your > >>> comments and my responses to the list... > >>> > >>> Thanks, > >>> Donald > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >>> Donald E. Eastlake 3rd +1-508-333-2270 > (cell) > >>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > >>> > >>> > >>>> Thanks, > >>>> Mingui > >>> > >>> > >>> > >>> _______________________________________________ > >>> trill mailing list > >>> trill@ietf.org > >>> https://www.ietf.org/mailman/listinfo/trill > >>> > >> > >> _______________________________________________ > >> trill mailing list > >> trill@ietf.org > >> https://www.ietf.org/mailman/listinfo/trill From nobody Tue May 5 09:43:47 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018E01A1B95; Tue, 5 May 2015 09:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 grrLgXxf4BUJ; Tue, 5 May 2015 09:43:40 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1535C1B2F2B; Tue, 5 May 2015 09:34:41 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t45GWqVl024884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 09:33:02 -0700 (PDT) Message-ID: <5548F0B3.80602@isi.edu> Date: Tue, 05 May 2015 09:32:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 16:43:42 -0000 On 5/4/2015 7:23 PM, Xuxiaohu wrote: > In a word, IP-in-UDP is just intended for those network environments > where fragmentation on the tunnel layer and strong checksums are not > desired. That's insufficient. They are only applicable where fragmentation and a strong checksum are not *needed*. Once you run IP in IP (IP in UDP in IP qualifies as this), you have only two choices: - support fragmentation - use in networks that are engineered so that fragmentation is never needed As to the strong checksum, similarly you have to either support one or deploy the result where that checksum isn't needed - either because you know that all apps will have strong enough checksums of their own or because you know enough about the kinds of errors that will occur that strong checksums aren't needed. But the key there is to define a use case where these properties are true AND to limit the document solution to uses in those case ONLY. > For those network environments where fragmentation on the > tunnel layer and stronger checksums are required, GUE should be > considered instead. Agreed. Joe From nobody Tue May 5 09:45:41 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6861B2F3A; Tue, 5 May 2015 09:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Gov2ywyLHAZM; Tue, 5 May 2015 09:45:36 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731EF1B2F3F; Tue, 5 May 2015 09:35:53 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t45GYwWF025313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 09:35:10 -0700 (PDT) Message-ID: <5548F132.7050704@isi.edu> Date: Tue, 05 May 2015 09:34:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 16:45:37 -0000 On 5/5/2015 7:54 AM, Templin, Fred L wrote: > I thought we determined the IP-in-UDP is just GUE with header compression? IP in UDP adds only port numbers and an Internet checksum. That doesn't address fragmentation; if outer fragmentation is assumed, IPv4 needs to be rate-limited to avoid ID collisions and the Internet checksum is insufficient to correct those collisions. Joe From nobody Tue May 5 10:18:11 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41681A8835; Tue, 5 May 2015 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 0U07sewgRdqr; Tue, 5 May 2015 10:18:07 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 29C291A882D; Tue, 5 May 2015 10:18:07 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Tue, 5 May 2015 13:18:06 -0400 From: Dave Dolson To: Joe Touch , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhtp6xe00UGkG+kO9Al9/qga7jZ1t15uA///H7FA= Date: Tue, 5 May 2015 17:18:05 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> In-Reply-To: <5548F0B3.80602@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:18:10 -0000 Joe, I think this discussion is about fragmenting the outer IP packet. There is a 3rd choice: to fragment the inner datagram, and/or use ICMP "dat= agram is too big" messages to facilitate PMTU discovery of the tunnel. This certainly seems to have been the intent, when one reads about the IPv4= DF flag. (And IPv6 always requires DF). -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joe Touch Sent: Tuesday, May 05, 2015 12:33 PM To: Xuxiaohu; Donald Eastlake; trill@ietf.org Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip On 5/4/2015 7:23 PM, Xuxiaohu wrote: > In a word, IP-in-UDP is just intended for those network environments > where fragmentation on the tunnel layer and strong checksums are not > desired. That's insufficient. They are only applicable where fragmentation and a strong checksum are not *needed*. Once you run IP in IP (IP in UDP in IP qualifies as this), you have only two choices: - support fragmentation - use in networks that are engineered so that fragmentation is never needed As to the strong checksum, similarly you have to either support one or deploy the result where that checksum isn't needed - either because you know that all apps will have strong enough checksums of their own or because you know enough about the kinds of errors that will occur that strong checksums aren't needed. But the key there is to define a use case where these properties are true AND to limit the document solution to uses in those case ONLY. > For those network environments where fragmentation on the > tunnel layer and stronger checksums are required, GUE should be > considered instead. Agreed. Joe _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue May 5 10:54:20 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296961A8547; Tue, 5 May 2015 10:54:18 -0700 (PDT) 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 1RhlwIQLH03p; Tue, 5 May 2015 10:54:16 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54161A1AA9; Tue, 5 May 2015 10:54:16 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t45HrYKS026241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 10:53:44 -0700 (PDT) Message-ID: <5549039C.2020709@isi.edu> Date: Tue, 05 May 2015 10:53:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:54:18 -0000 On 5/5/2015 9:39 AM, Templin, Fred L wrote: > Hi Joe, .. >> IP in UDP adds only port numbers and an Internet checksum. >> >> That doesn't address fragmentation; if outer fragmentation is assumed, >> IPv4 needs to be rate-limited to avoid ID collisions and the Internet >> checksum is insufficient to correct those collisions. > > Right - that is why we have GUE. But, when these functions are not > needed GUE can perform header compression and the result looks > exactly like IP in UDP. That seems impossible. The outer IP header indicates UDP as next-protocol, and GUE based on the port number. You can't then compress the GUE header to nothing. You still need at least one bit somewhere to indicate "compressed GUE header", and there's nothing left. And no, I don't think "compressed GUE" qualifies as an independently useful service that warrants a separate UDP port. Joe From nobody Tue May 5 10:59:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCCE1A8863; Tue, 5 May 2015 10:59:20 -0700 (PDT) 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 22zmT9u5iywB; Tue, 5 May 2015 10:59:16 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8648C1A6FF5; Tue, 5 May 2015 10:59:16 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t45HwIEG027840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 10:58:32 -0700 (PDT) Message-ID: <554904B8.9020504@isi.edu> Date: Tue, 05 May 2015 10:58:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:59:20 -0000 On 5/5/2015 10:18 AM, Dave Dolson wrote: > Joe, > I think this discussion is about fragmenting the outer IP packet. That's feasible for IPv6, but extremely limiting for IPv4 because of the limited ID field size (it would rate-limit the tunnel significantly). > There is a 3rd choice: to fragment the inner datagram, That is not valid for IPv6 or IPv6 DF=1, so unless you support only IPv4 DF=0 packets, it won't work. > and/or use ICMP "datagram is too big" messages to facilitate > PMTU discovery of the tunnel. That won't work for several reasons: - ICMPs are often blocked - ICMP might not return enough of the nested headers - ICMP cannot validly say "1280 is too big" for IPv6 (which it would need to do if the path supported only 1280, because there wouldn't be space for the additional IP header) > This certainly seems to have been the intent, when one reads about > the IPv4 DF flag. (And IPv6 always requires DF). See above; while the DF issue might be useful in some contexts, it doesn't magically get around the need to fragment in ways that are not supported by the inner header. Joe > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Tuesday, May 05, 2015 12:33 PM > To: Xuxiaohu; Donald Eastlake; trill@ietf.org > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > > > > On 5/4/2015 7:23 PM, Xuxiaohu wrote: >> In a word, IP-in-UDP is just intended for those network environments >> where fragmentation on the tunnel layer and strong checksums are not >> desired. > > That's insufficient. They are only applicable where fragmentation and a > strong checksum are not *needed*. > > Once you run IP in IP (IP in UDP in IP qualifies as this), you have only > two choices: > > - support fragmentation > > - use in networks that are engineered so that > fragmentation is never needed > > As to the strong checksum, similarly you have to either support one or > deploy the result where that checksum isn't needed - either because you > know that all apps will have strong enough checksums of their own or > because you know enough about the kinds of errors that will occur that > strong checksums aren't needed. > > But the key there is to define a use case where these properties are > true AND to limit the document solution to uses in those case ONLY. > >> For those network environments where fragmentation on the >> tunnel layer and stronger checksums are required, GUE should be >> considered instead. > > Agreed. > > Joe > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue May 5 11:02:00 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA041B2CDD; Tue, 5 May 2015 07:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 Jz7crjniVru9; Tue, 5 May 2015 07:54:21 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A1C1B2B1B; Tue, 5 May 2015 07:54:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t45EsJiU020726; Tue, 5 May 2015 09:54:19 -0500 Received: from XCH-BLV-304.nw.nos.boeing.com (xch-blv-304.nw.nos.boeing.com [130.247.25.216]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t45EsFed020439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 May 2015 09:54:16 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-304.nw.nos.boeing.com ([169.254.4.247]) with mapi id 14.03.0235.001; Tue, 5 May 2015 07:54:14 -0700 From: "Templin, Fred L" To: Xuxiaohu , Joe Touch , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAejJGxDIiBx0S2BZ0ZWLGtWJ1nAPgAgAQl8XCAAFTXgIABIiUAgADgFUA= Date: Tue, 5 May 2015 14:54:13 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-Mailman-Approved-At: Tue, 05 May 2015 11:01:55 -0700 Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 14:54:26 -0000 Hi, > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Monday, May 04, 2015 7:23 PM > To: Joe Touch; Donald Eastlake; trill@ietf.org > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [Int-area] [trill] Fwd: Mail regarding draft-ietf-trill-over= -ip >=20 > Hi Joe, >=20 > > -----Original Message----- > > From: Joe Touch [mailto:touch@isi.edu] > > Sent: Tuesday, May 05, 2015 12:12 AM > > To: Xuxiaohu; Donald Eastlake; trill@ietf.org > > Cc: nvo3@ietf.org; sfc@ietf.org; int-area@ietf.org > > Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > > > > > > > > On 5/3/2015 8:19 PM, Xuxiaohu wrote: > > > Hi Joe, > > > > > > I'm wondering whether your proposal as below is also applicable to > > > other UDP-based encapsulation approaches which have not yet considere= d > > > doing fragmentation on the tunnel layer, such as GENEVE, VXLAN-GPE, > > > GRE-in-UDP and NSH-UDP. > > > > Again: > > > > We know of at least four things that tunnels need that IP-in-UDP ignore= s: > > > > - stronger checksums > > > > - fragmentation support > > > > - signalling support (e.g., to test whether a tunnel is up or > > to measure MTUs) > > > > - support for robust ID fields (related to fragmentation, > > e.g., to overcome the limits of IPv4 ID as per RFC 6864) >=20 > I'm just wondering whether the above is only applicable to IP-in-UDP or a= pplicable to all the other UDP-based encapsulations as well. >=20 > > I haven't scrubbed GUE to ensure that all four are addressed, but it ma= y be more > > than the above, and certainly it's important not to start from scratch = needlessly. >=20 > I don't intend addressing items 1), 2) and 3). As for item 3), I would a= dd the following text: >=20 > "Ingress AFBRs MUST NOT fragment I-IP [RFC5565] packets (i.e., UDP encaps= ulated IP packets), and when the outer IP header is IPv4, > ingress AFBRs MUST set the DF bit in the outer IPv4 header. It is strongl= y RECOMMENDED that I-IP [RFC5565] transit core be > configured to carry an MTU at least large enough to accommodate the added= encapsulation headers. Meanwhile, it is strongly > RECOMMENDED that Path MTU Discovery [RFC1191][RFC1981] is used to prevent= or minimize fragmentation." >=20 > Ahead of the following existing text in Section 4: >=20 > "If an ingress AFBR performs fragmentation on > an E-IP packet before encapsulating, it MUST use the same source UDP > port for all fragmented packets so as to ensures these fragmented > packets are always forwarded on the same path." >=20 >=20 > In a word, IP-in-UDP is just intended for those network environments wher= e fragmentation on the tunnel layer and strong checksums > are not desired. For those network environments where fragmentation on th= e tunnel layer and stronger checksums are required, > GUE should be considered instead. I thought we determined the IP-in-UDP is just GUE with header compression? Thanks - Fred fred.l.templin@boeing.com > Best regards, > Xiaohu >=20 > > Joe > > > > > > > > > > Best regards, > > > Xiaohu > > > > > >> -----Original Message----- > > >> From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Joe Touch > > >> Sent: Saturday, May 02, 2015 3:48 AM > > >> To: Donald Eastlake; trill@ietf.org > > >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > > >> > > >> Hi, all, > > >> > > >> Have you considered GUE as an encapsulation layer? > > >> > > >> Encapsulating anything in UDP directly has a number of hazards, > > >> including support for at-rate fragmentation, IPv4 ID generation, > > >> etc., that GUE is intended to address. > > >> > > >> Joe > > >> > > >> On 5/1/2015 9:58 AM, Donald Eastlake wrote: > > >>> Forwarded with permission. > > >>> > > >>> Thanks, > > >>> Donald > > >>> ---------- Forwarded message ---------- > > >>> From: *Donald Eastlake* > > > > >>> Date: Tue, Apr 28, 2015 at 9:26 AM > > >>> Subject: Re: Mail regarding draft-ietf-trill-over-ip > > >>> To: Mingui Zhang > >>> > > > >>> > > >>> Hi Mingui, > > >>> > > >>> Thanks for these comments! See below. > > >>> > > >>> On Tue, Apr 28, 2015 at 4:27 AM, Mingui Zhang > > >>> > wrote: > > >>>> Hi, > > >>>> > > >>>> I read the document. It's comprehensive and well written. Below, > > >>>> several > > >> comments for your information. > > >>>> > > >>>> 1. It's not clear how the ports IPs are associated with the p= orts? > > Maybe, > > >> we can add some words to explain that they can be got from DHCP or > > >> manual configuration? Or we just say it is out the scope of this doc= ument. > > >>> > > >>> Yes, they need to be configured. Could be DHCP or manual or maybe > > >>> some sort of orchestration thing... Seems reasonable to mention thi= s > > >>> in the draft. > > >>> > > >>>> 2. Is it helpful to add a reference topology? Terminologies, = such as IP > > >> tunnel, port IPs, RBridges can be put onto this figure. A > > >> walk-through example based on this reference topology can be used to > > >> explain how the IP tunnel is set up, how does a TRILL Data packet ge= t > > >> encapsulated/decapsulated and transported in the IP tunnel. I think = this > > would be educational. > > >>> > > >>> A few more network diagrams would probably be helpful. If you look > > >>> at the minutes from the Dallas TRILL WG meeting, the suggestion of > > >>> having a couple of example packets was supported... > > >>> > > >>>> 3. Both IP and TRILL have specified BFD. Since TRILL is depen= dent on > > IP > > >> in TRILL-over-IP, it's unnecessary to have both TRILL and IP interac= t > > >> with BFD. It's best to assert TRILL-over-IP will have the IP interac= t > > >> with BFD. Please refer to > > >> https://tools.ietf.org/html/rfc5882#section-4.4 > > >>> > > >>> Well, if you are only going to use one then I agree with the sectio= n > > >>> you reference in RFC 5882 and you should do BFD over IP. But that > > >>> doesn't check the TRILL stack, just the IP and lower stacks. So we > > >>> could recommend just using IP BFD but I don't think we should try t= o > > >>> prohibit people from also using BFD over TRILL on the link. > > >>> > > >>>> 4. Is the IP link in this document "a single link (physical, = or a secure > > >> tunnel such as IPsec)"? Then, we can require the TTL "MUST be set to > > >> the maximum on transmit, and checked to be equal to the maximum valu= e > > >> on reception (and the packet dropped if this is not the case)." See > > >> also RFC 5880 Section 9. > > >>> > > >>> I don't think so. There is nothing wrong with the communication > > >>> between two TRILL IP ports being multiple IP hops. Even if IPsec is > > >>> in use, it could be integrated with the TRILL over IP port at one > > >>> end but at the other end, the IPsec implementation could be > > >>> integrated with a firewall a couple of hops from the RBridge... > > >>> > > >>>> 5. There are six tiny typos marked in the attached doc. > > >>> > > >>> OK. We'll fix this up in the next version. > > >>> > > >>> Maybe you should post these comments, or some of them, to the TRILL > > >>> WG mailing list. It would be good if there was more discussion of > > >>> drafts there. Or if it OK with you, I could just forward your > > >>> comments and my responses to the list... > > >>> > > >>> Thanks, > > >>> Donald > > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > >>> Donald E. Eastlake 3rd +1-508-333-2270 > > (cell) > > >>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > > >>> > > >>> > > >>>> Thanks, > > >>>> Mingui > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> trill mailing list > > >>> trill@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/trill > > >>> > > >> > > >> _______________________________________________ > > >> trill mailing list > > >> trill@ietf.org > > >> https://www.ietf.org/mailman/listinfo/trill >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue May 5 11:02:02 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22EB1A1A81; Tue, 5 May 2015 09:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RTWtM47JbDHw; Tue, 5 May 2015 09:47:22 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 5A1F71A6EED; Tue, 5 May 2015 09:39:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t45Gdmw1043383; Tue, 5 May 2015 09:39:48 -0700 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t45Gde7o043301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 May 2015 09:39:40 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-209.sw.nos.boeing.com ([169.254.9.156]) with mapi id 14.03.0235.001; Tue, 5 May 2015 09:39:39 -0700 From: "Templin, Fred L" To: Joe Touch , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAejJGxDIiBx0S2BZ0ZWLGtWJ1nAPgAgAQl8XCAAFTXgIABIiUAgADgFUCAAJHXAP//i4Bg Date: Tue, 5 May 2015 16:39:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> In-Reply-To: <5548F132.7050704@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-Mailman-Approved-At: Tue, 05 May 2015 11:01:56 -0700 Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 16:47:24 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, May 05, 2015 9:35 AM > To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/5/2015 7:54 AM, Templin, Fred L wrote: > > I thought we determined the IP-in-UDP is just GUE with header compressi= on? >=20 > IP in UDP adds only port numbers and an Internet checksum. >=20 > That doesn't address fragmentation; if outer fragmentation is assumed, > IPv4 needs to be rate-limited to avoid ID collisions and the Internet > checksum is insufficient to correct those collisions. Right - that is why we have GUE. But, when these functions are not needed GUE can perform header compression and the result looks exactly like IP in UDP. Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Tue May 5 11:05:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B191A90D4; Tue, 5 May 2015 11:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 JY9sULI8Etky; Tue, 5 May 2015 11:05:19 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E411A9140; Tue, 5 May 2015 11:05:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t45I50eg011897; Tue, 5 May 2015 11:05:00 -0700 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t45I4rhn011360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 May 2015 11:04:53 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.178]) with mapi id 14.03.0235.001; Tue, 5 May 2015 11:04:52 -0700 From: "Templin, Fred L" To: Joe Touch , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAejJGxDIiBx0S2BZ0ZWLGtWJ1nAPgAgAQl8XCAAFTXgIABIiUAgADgFUCAAJHXAP//i4BggACKdAD//4xEMA== Date: Tue, 5 May 2015 18:04:51 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> In-Reply-To: <5549039C.2020709@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:05:22 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, May 05, 2015 10:54 AM > To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/5/2015 9:39 AM, Templin, Fred L wrote: > > Hi Joe, > .. > >> IP in UDP adds only port numbers and an Internet checksum. > >> > >> That doesn't address fragmentation; if outer fragmentation is assumed, > >> IPv4 needs to be rate-limited to avoid ID collisions and the Internet > >> checksum is insufficient to correct those collisions. > > > > Right - that is why we have GUE. But, when these functions are not > > needed GUE can perform header compression and the result looks > > exactly like IP in UDP. >=20 > That seems impossible. Not impossible - Tom Herbert provided the solution: http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html =20 > The outer IP header indicates UDP as next-protocol, and GUE based on the > port number. Yes. > You can't then compress the GUE header to nothing. You still need at > least one bit somewhere to indicate "compressed GUE header", and there's > nothing left. False and True. False that you can't compress the GUE header to nothing (you can) and True that there is one bit to indicate "compressed". But, that bit coincides with the direct IP encapsulation header. > And no, I don't think "compressed GUE" qualifies as an independently > useful service that warrants a separate UDP port. Right - there is only one UDP port number (GUE). Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Tue May 5 11:16:19 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDCD1B2F1A for ; Tue, 5 May 2015 11:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 Zj9l6dU-cLNF for ; Tue, 5 May 2015 11:07:43 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942FB1B2F27 for ; Tue, 5 May 2015 11:06:13 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so83485470igb.0 for ; Tue, 05 May 2015 11:06:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DK7+ZueeMZT5tojJpdbDyrwmx78NK6nEvQLpLr1mNTM=; b=JG7Bvsgp9WNIbCDSHPWM6t/BEB3lCTBbGFROO+qjo7UIZO0kz7yvo6NQUbvEdfP4Vf 4gcEa2r1KOsP4L3oqRqfFJ9MTuouIdgjuac7lYhTYnbjYbTd4sXiPi5HaMx+TgNj/YWv rSwHmMzAvy/t/Q1M2U3PvcTEXnObqNUHuBMgGRfOq2o7C6wV5WqfzTucekOaVkFLtiaz muntpAENUxWhUAnmXK4v9rIuQSCsdsxWboFuvKClMDHfdI4PmXJk4dR722IjSr5QJepx /C2NU53S+61Fa9Z4yj0/gYo/SOON4i0iDB+DeggP7hJy8ukOpVtmww58tlygtnIZ5/VY 2zbA== X-Gm-Message-State: ALoCoQmLFQlXb0r1RoqNEfjB16MhfZEhJxKx6vDJzAC2mA4fmS4GtR3fK2+Nduz90xCUY2CvT0pp MIME-Version: 1.0 X-Received: by 10.50.90.179 with SMTP id bx19mr3382248igb.43.1430849173127; Tue, 05 May 2015 11:06:13 -0700 (PDT) Received: by 10.107.160.2 with HTTP; Tue, 5 May 2015 11:06:13 -0700 (PDT) In-Reply-To: <5549039C.2020709@isi.edu> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> Date: Tue, 5 May 2015 11:06:13 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Tue, 05 May 2015 11:16:16 -0700 Cc: "int-area@ietf.org" , "sfc@ietf.org" , "nvo3@ietf.org" , "Templin, Fred L" , "trill@ietf.org" , Donald Eastlake , Xuxiaohu Subject: Re: [sfc] [nvo3] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:07:45 -0000 On Tue, May 5, 2015 at 10:53 AM, Joe Touch wrote: > > > On 5/5/2015 9:39 AM, Templin, Fred L wrote: >> Hi Joe, > .. >>> IP in UDP adds only port numbers and an Internet checksum. >>> >>> That doesn't address fragmentation; if outer fragmentation is assumed, >>> IPv4 needs to be rate-limited to avoid ID collisions and the Internet >>> checksum is insufficient to correct those collisions. >> >> Right - that is why we have GUE. But, when these functions are not >> needed GUE can perform header compression and the result looks >> exactly like IP in UDP. > > That seems impossible. > > The outer IP header indicates UDP as next-protocol, and GUE based on the > port number. > > You can't then compress the GUE header to nothing. You still need at > least one bit somewhere to indicate "compressed GUE header", and there's > nothing left. > As I described previously, the first two bits of GUE header are version number. If we reserve version 0x1, then an IPv6 or IPv4 can be directly encapsulated on the same port with GUE (version 0)-- this is what Fred means by GUE header compression. No new port is needed for this and it is backwards compatible with GUE. > And no, I don't think "compressed GUE" qualifies as an independently > useful service that warrants a separate UDP port. > > Joe > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Tue May 5 11:26:54 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48D51A9095; Tue, 5 May 2015 11:26:50 -0700 (PDT) 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 fsuIyYls6Lnd; Tue, 5 May 2015 11:26:48 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94281A92E9; Tue, 5 May 2015 11:26:48 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t45IQBa6000332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 11:26:21 -0700 (PDT) Message-ID: <55490B41.2000207@isi.edu> Date: Tue, 05 May 2015 11:26:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t45IQBa6000332 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:26:50 -0000 On 5/5/2015 11:04 AM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 05, 2015 10:54 AM >> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org >> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >> >> >> >> On 5/5/2015 9:39 AM, Templin, Fred L wrote: >>> Hi Joe, >> .. >>>> IP in UDP adds only port numbers and an Internet checksum. >>>> >>>> That doesn't address fragmentation; if outer fragmentation is assumed, >>>> IPv4 needs to be rate-limited to avoid ID collisions and the Internet >>>> checksum is insufficient to correct those collisions. >>> >>> Right - that is why we have GUE. But, when these functions are not >>> needed GUE can perform header compression and the result looks >>> exactly like IP in UDP. >> >> That seems impossible. > > Not impossible - Tom Herbert provided the solution: > > http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html That is allocating bits (or bit patterns) from the IP header. The solution provided - to check for 0x01 - is incorrect. IP can have versions that include 0x10 and 0x11. The only solution would be to say that if the first three bits were 0, then it's not an IP packet - but that would require reassigning 0x0000 and 0x0001 for GUE purposes. Although that's possible, I don't see why we would allocate IP versions to GUE message types. Joe From nobody Tue May 5 11:45:55 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B59D1ACD50 for ; Tue, 5 May 2015 11:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 Swd87dNrw066 for ; Tue, 5 May 2015 11:45:51 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320081A9163 for ; Tue, 5 May 2015 11:45:51 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so152859639ieb.3 for ; Tue, 05 May 2015 11:45:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aU/+ZwFdJf4nDkBlrnZ1tkG00OanJ8hRCMk9b5RgQNQ=; b=C8SDaQ0lV6R1hZtamRAMolKEmYMlCrT0A8g6UkfHLoqPsvCuFEsIqitI5x3GcdUttu Y5KU5cQrNz9syKZpPawcQRrWFWJkyksfr2fRAPJsJDHGH5CB6QfRkLQupJGtMNnzTLli XDcqUMWMTvcAfFwuCisn0IYzLQSFr53/Gr1nymcis4/DI6v0N8s5FM9H8rkv34ncy0ck IOeYJSa+zcpr1EO8Ou31KJEZomCSZYPFVwxkDbrabptpa4vMF7G/UOS8jj/dXK38F1xv 6kMCSnb0MI4gXWyCVKenBq2zHYgykjfFGMNf4+y47NPttwu0JacaGDrGqD14YbPE3PGK 9nHw== X-Gm-Message-State: ALoCoQnluUCjzhTsb9w1NtQcOwmbuLFMUMq1RmHNew9V1hLWKitLUJqXzlq92MRlTJz9ncCwB9wa MIME-Version: 1.0 X-Received: by 10.107.128.149 with SMTP id k21mr35170100ioi.7.1430851550601; Tue, 05 May 2015 11:45:50 -0700 (PDT) Received: by 10.107.160.2 with HTTP; Tue, 5 May 2015 11:45:50 -0700 (PDT) In-Reply-To: <55490B41.2000207@isi.edu> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> Date: Tue, 5 May 2015 11:45:50 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "int-area@ietf.org" , "sfc@ietf.org" , "nvo3@ietf.org" , "Templin, Fred L" , "trill@ietf.org" , Donald Eastlake , Xuxiaohu Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:45:53 -0000 On Tue, May 5, 2015 at 11:26 AM, Joe Touch wrote: > > > On 5/5/2015 11:04 AM, Templin, Fred L wrote: >> Hi Joe, >> >>> -----Original Message----- >>> From: Joe Touch [mailto:touch@isi.edu] >>> Sent: Tuesday, May 05, 2015 10:54 AM >>> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org >>> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org >>> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >>> >>> >>> >>> On 5/5/2015 9:39 AM, Templin, Fred L wrote: >>>> Hi Joe, >>> .. >>>>> IP in UDP adds only port numbers and an Internet checksum. >>>>> >>>>> That doesn't address fragmentation; if outer fragmentation is assumed, >>>>> IPv4 needs to be rate-limited to avoid ID collisions and the Internet >>>>> checksum is insufficient to correct those collisions. >>>> >>>> Right - that is why we have GUE. But, when these functions are not >>>> needed GUE can perform header compression and the result looks >>>> exactly like IP in UDP. >>> >>> That seems impossible. >> >> Not impossible - Tom Herbert provided the solution: >> >> http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html > > That is allocating bits (or bit patterns) from the IP header. > > The solution provided - to check for 0x01 - is incorrect. IP can have > versions that include 0x10 and 0x11. > It is correct as we defined it-- this is a solution to support direct encapsulation of only IPv4 and IPv6. This optimizes encapsulation those two IP protocols, and does not effect encapsulation of other protocols (including new versions of IP) using the GUE and header and protocol field. Whether this optimization is worth it is a fair question, but if this obviates the need for a separate port number in UDP-IP maybe it would be. > The only solution would be to say that if the first three bits were 0, > then it's not an IP packet - but that would require reassigning 0x0000 > and 0x0001 for GUE purposes. > > Although that's possible, I don't see why we would allocate IP versions > to GUE message types. > We're not proposing that at all. > Joe > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From nobody Tue May 5 11:47:47 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5F41A87EC; Tue, 5 May 2015 11:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dBjcRvRkfLqx; Tue, 5 May 2015 11:47:39 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 D72B71A873E; Tue, 5 May 2015 11:47:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t45IlZag022360; Tue, 5 May 2015 11:47:35 -0700 Received: from XCH-BLV-108.nw.nos.boeing.com (xch-blv-108.nw.nos.boeing.com [130.247.25.137]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t45IlVU7022338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 May 2015 11:47:31 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-108.nw.nos.boeing.com ([169.254.13.118]) with mapi id 14.03.0235.001; Tue, 5 May 2015 11:47:31 -0700 From: "Templin, Fred L" To: Joe Touch , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAejJGxDIiBx0S2BZ0ZWLGtWJ1nAPgAgAQl8XCAAFTXgIABIiUAgADgFUCAAJHXAP//i4BggACKdAD//4xEMIAAfNmA//+PG6A= Date: Tue, 5 May 2015 18:47:30 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> In-Reply-To: <55490B41.2000207@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:47:41 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, May 05, 2015 11:26 AM > To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/5/2015 11:04 AM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Tuesday, May 05, 2015 10:54 AM > >> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org > >> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > >> > >> > >> > >> On 5/5/2015 9:39 AM, Templin, Fred L wrote: > >>> Hi Joe, > >> .. > >>>> IP in UDP adds only port numbers and an Internet checksum. > >>>> > >>>> That doesn't address fragmentation; if outer fragmentation is assume= d, > >>>> IPv4 needs to be rate-limited to avoid ID collisions and the Interne= t > >>>> checksum is insufficient to correct those collisions. > >>> > >>> Right - that is why we have GUE. But, when these functions are not > >>> needed GUE can perform header compression and the result looks > >>> exactly like IP in UDP. > >> > >> That seems impossible. > > > > Not impossible - Tom Herbert provided the solution: > > > > http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html >=20 > That is allocating bits (or bit patterns) from the IP header. >=20 > The solution provided - to check for 0x01 - is incorrect. IP can have > versions that include 0x10 and 0x11. The version field in both IPv4 and IPv6 have that bit set to 1. If GUE then deems that bit to indicate "direct IP encapsulation, then there is no need for a GUE header of length greater than 0. You may say that future IP protocol versions might not have that bit set in the version field. But, the version bits for IPv4 and IPv6 will never change (by definition) and we do not see a new IP protocol version replacing IPv4 or IPv6 on the near-term horizon. Even if a new IP protocol version emerged with the "direct IP encapsulation" bit set to 0, that version can still be accommodated by GUE. It's just that direct encapsulation cannot be used and a non-zero-length GUE header is needed. Thanks - Fred fred.l.templin@boeing.com > The only solution would be to say that if the first three bits were 0, > then it's not an IP packet - but that would require reassigning 0x0000 > and 0x0001 for GUE purposes. >=20 > Although that's possible, I don't see why we would allocate IP versions > to GUE message types. >=20 > Joe From nobody Tue May 5 11:53:27 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7EC1B2F6B for ; Tue, 5 May 2015 11:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 XdSoG7G8zkOK for ; Tue, 5 May 2015 11:53:22 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B551B2F7E for ; Tue, 5 May 2015 11:53:22 -0700 (PDT) Received: by iecrt8 with SMTP id rt8so152887833iec.0 for ; Tue, 05 May 2015 11:53:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ex0jXvkuZDnFD9AKBH7p9gnLudQ2dBhV23OV7K1+qIc=; b=fNW9GhRZzjf6u7b+rAq7m3G8s0WWYhfM+oqsvj4QFvNQNRzWEDMWhAmh1MvAHiCqsL LhGi0/rL4gMEfRieINIToNMnx4YNT+kJANIoiKY99sfBeTsXkTCTP8cKoQq56CRn3vsd O9rwUhE8Rmto+6+4yONt1DO2AEUM+/MRl0aYboZRO5LsWIJ+gjl/WbmRAdloe+QshqRv E1AFt79a/o2q7LVEhn/vBTc4vQwp1jgraMQyvl19/NuJ2PSmyQxVKvZtNUR+/xJO68fO AY/ZpM3ntmrIlQLEV0T0HCRf0MelGI95ESWrH0ZS6XIk+T/Jko/LuUbuPvYhy6bI2Y/h CC0Q== X-Gm-Message-State: ALoCoQn6wKm1EBPeyKNNpGQeFIcAklqscPOSZOgOzcl66ZXNyM3wP/ZN5ihKGNIrzeo9myZoBtLQ MIME-Version: 1.0 X-Received: by 10.50.142.67 with SMTP id ru3mr3668851igb.16.1430852001441; Tue, 05 May 2015 11:53:21 -0700 (PDT) Received: by 10.107.160.2 with HTTP; Tue, 5 May 2015 11:53:21 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 5 May 2015 11:53:21 -0700 Message-ID: From: Tom Herbert To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "int-area@ietf.org" , "sfc@ietf.org" , Joe Touch , "nvo3@ietf.org" , "trill@ietf.org" , Donald Eastlake , Xuxiaohu Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:53:24 -0000 On Tue, May 5, 2015 at 11:47 AM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 05, 2015 11:26 AM >> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org >> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >> >> >> >> On 5/5/2015 11:04 AM, Templin, Fred L wrote: >> > Hi Joe, >> > >> >> -----Original Message----- >> >> From: Joe Touch [mailto:touch@isi.edu] >> >> Sent: Tuesday, May 05, 2015 10:54 AM >> >> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org >> >> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org >> >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >> >> >> >> >> >> >> >> On 5/5/2015 9:39 AM, Templin, Fred L wrote: >> >>> Hi Joe, >> >> .. >> >>>> IP in UDP adds only port numbers and an Internet checksum. >> >>>> >> >>>> That doesn't address fragmentation; if outer fragmentation is assumed, >> >>>> IPv4 needs to be rate-limited to avoid ID collisions and the Internet >> >>>> checksum is insufficient to correct those collisions. >> >>> >> >>> Right - that is why we have GUE. But, when these functions are not >> >>> needed GUE can perform header compression and the result looks >> >>> exactly like IP in UDP. >> >> >> >> That seems impossible. >> > >> > Not impossible - Tom Herbert provided the solution: >> > >> > http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html >> >> That is allocating bits (or bit patterns) from the IP header. >> >> The solution provided - to check for 0x01 - is incorrect. IP can have >> versions that include 0x10 and 0x11. > > The version field in both IPv4 and IPv6 have that bit set to 1. If GUE > then deems that bit to indicate "direct IP encapsulation, then there > is no need for a GUE header of length greater than 0. > > You may say that future IP protocol versions might not have that bit > set in the version field. But, the version bits for IPv4 and IPv6 will > never change (by definition) and we do not see a new IP protocol > version replacing IPv4 or IPv6 on the near-term horizon. > > Even if a new IP protocol version emerged with the "direct IP > encapsulation" bit set to 0, that version can still be accommodated > by GUE. It's just that direct encapsulation cannot be used and a > non-zero-length GUE header is needed. > Or just define a simple version translation as part of encapsulation. So for IPv8: 0x1000->0x0101 on encapsulation 0x0101->0x1000 on decapsualtion > Thanks - Fred > fred.l.templin@boeing.com > >> The only solution would be to say that if the first three bits were 0, >> then it's not an IP packet - but that would require reassigning 0x0000 >> and 0x0001 for GUE purposes. >> >> Although that's possible, I don't see why we would allocate IP versions >> to GUE message types. >> >> Joe > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From nobody Tue May 5 12:09:50 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DFA1A87A2 for ; Tue, 5 May 2015 12:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7lThCGj-t6GW for ; Tue, 5 May 2015 12:09:46 -0700 (PDT) Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4656D1A874D for ; Tue, 5 May 2015 12:09:46 -0700 (PDT) Received: by qkx62 with SMTP id 62so113134567qkx.0 for ; Tue, 05 May 2015 12:09:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=cZVaf2w+ncXTxyoHD495ykfI9FudHIGKUG8dAh1lqUs=; b=l4apxmI+iLBnIi/gdGTRd5A14K82svojXFrYhstP5nTzB73YXs7OCRiUn5qPV6AAcw URL2hRZuDAT6WGCQIOh+Ns2BNApW2aIZG4IElAvBbUBQDcU0RhGC1Se/r+IICvR8WJBk SnFF2Yh2MUf4upGri1Xd1dIN3VnuRLetwgHzKEQxBPFNkXbsph/36nkakhltsIxhW58B i1/M7MULoioghw4hvcCpMgMwssIR8pazbKQLDnkGqeXJ4lOSq8oMYcxWTN7H76W143U6 nPPXtE1mf5h/gaCCN2nJY3/Xj+NTlYYf/SCGz3Fbd6aU9KJCmghogRivLJ0fuGN9wIDf sZuQ== X-Gm-Message-State: ALoCoQmpIiP8TH0n9SWMncRuHIwwjGDHLzQLFg9mxc7ubjPq59w1bvcd9Hlpj6MmWZbrJcMufJke X-Received: by 10.140.149.23 with SMTP id 23mr36501631qhv.48.1430852985556; Tue, 05 May 2015 12:09:45 -0700 (PDT) Received: from [10.125.131.223] (C8ECD95E.static.tesa.net.br. [200.236.217.94]) by mx.google.com with ESMTPSA id z69sm12656707qkz.27.2015.05.05.12.09.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 May 2015 12:09:44 -0700 (PDT) From: William Caban Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <7500140A-FD3E-4720-ABDD-F28A20D32459@savantadvisors.com> Date: Tue, 5 May 2015 15:09:41 -0400 To: sfc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [sfc] Next Protocol in draft-ietf-sfc-nsh-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:09:48 -0000 In section 3.2: This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet Please, consider a =E2=80=9CRAW/BLOB=E2=80=9D or =E2=80=9CTEST=E2=80=9D = Next Protocol identifier which could be used by network researchers and = academia to develop future protocols and benefit from the NSH without = having to modify the future NSH standard. With such an identification, = application vendors could use the same headers to inject SN of = experimental and/or proprietary protocols without modifying the = standard. _William From nobody Tue May 5 12:21:28 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBB01B2FFD for ; Tue, 5 May 2015 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 X-84ZF_FPgfX for ; Tue, 5 May 2015 12:21:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916421B2FEA for ; Tue, 5 May 2015 12:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1068; q=dns/txt; s=iport; t=1430853684; x=1432063284; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=x7wBM82abxQiYkbku7JapOLb1DN5AfXehwSedhqOX+0=; b=V1d0hY7+UHYU9gRrVaye4jVoFWxziNZBFLm9itCr5+PyNBPIJkzUQxNq QfmLfcIqcI9aokx2w7PJ3WM+t6LVZHrmcnhMyfInI2WcxQYjna36Y3zo/ w2lebrgMRDrRZnE38/MoRPw+TjjsfewRcMjQFtdMKOh1GEQSfY9c0nxMr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AWBQB8F0lV/49dJa1cgwxTXAXFGoI7CoYFAoE9TAEBAQEBAYELhCABAQEEAQEBaxcEAgEIEQMBAi8nCx0IAgQBEogsDcRoAQEBAQEBAQEBAQEBAQEBAQEBARUEizmEUjoGhCcBBJIdilaBJINWkTUjg3RvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,374,1427760000"; d="scan'208";a="417287483" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP; 05 May 2015 19:21:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t45JLMkT013334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 19:21:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.104]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 5 May 2015 14:21:22 -0500 From: "Carlos Pignataro (cpignata)" To: William Caban , "sfc@ietf.org" Thread-Topic: [sfc] Next Protocol in draft-ietf-sfc-nsh-00 Thread-Index: AQHQh2fjUmc6ysjIH0qbgFwJ4qh8pp1t01QA Date: Tue, 5 May 2015 19:21:21 +0000 Message-ID: References: <7500140A-FD3E-4720-ABDD-F28A20D32459@savantadvisors.com> In-Reply-To: <7500140A-FD3E-4720-ABDD-F28A20D32459@savantadvisors.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.150.55.143] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2F521864CED3ED4394E55BC04336BAAF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Next Protocol in draft-ietf-sfc-nsh-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:21:25 -0000 Assigning a couple of Experimental values sounds useful. [RFC3692] Maybe 253 and 254, =B3Use for experimentation and testing=B2. Thanks, =8B Carlos. -----Original Message----- From: William Caban Date: Tuesday, May 5, 2015 at 3:09 PM To: "sfc@ietf.org" Subject: [sfc] Next Protocol in draft-ietf-sfc-nsh-00 >In section 3.2: This draft defines the following Next Protocol values: > > 0x1 : IPv4 > 0x2 : IPv6 > 0x3 : Ethernet > > >Please, consider a =B3RAW/BLOB=B2 or =B3TEST=B2 Next Protocol identifier w= hich >could be used by network researchers and academia to develop future >protocols and benefit from the NSH without having to modify the future >NSH standard. With such an identification, application vendors could use >the same headers to inject SN of experimental and/or proprietary >protocols without modifying the standard. > >_William > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue May 5 12:31:00 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51981A87BD; Tue, 5 May 2015 12:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 x0ibCGa_o6J4; Tue, 5 May 2015 12:30:56 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7321A873D; Tue, 5 May 2015 12:30:38 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t45JTSHG004607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 12:29:37 -0700 (PDT) Message-ID: <55491A18.6080309@isi.edu> Date: Tue, 05 May 2015 12:29:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tom Herbert References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "int-area@ietf.org" , "sfc@ietf.org" , "nvo3@ietf.org" , "Templin, Fred L" , "trill@ietf.org" , Donald Eastlake , Xuxiaohu Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:30:57 -0000 On 5/5/2015 11:45 AM, Tom Herbert wrote: >> > The solution provided - to check for 0x01 - is incorrect. IP can have >> > versions that include 0x10 and 0x11. >> > > It is correct as we defined it-- this is a solution to support direct > encapsulation of only IPv4 and IPv6. This optimizes encapsulation > those two IP protocols, and does not effect encapsulation of other > protocols (including new versions of IP) using the GUE and header and > protocol field. Whether this optimization is worth it is a fair > question, but if this obviates the need for a separate port number in > UDP-IP maybe it would be. > >> > The only solution would be to say that if the first three bits were 0, >> > then it's not an IP packet - but that would require reassigning 0x0000 >> > and 0x0001 for GUE purposes. >> > >> > Although that's possible, I don't see why we would allocate IP versions >> > to GUE message types. >> > > We're not proposing that at all. Then the solution is incorrect. As noted above, if you don't know you "own" the patterns, you don't know you can use them to indicate "non-compressed GUE header" because they are valid uncompressed IP packets. A field you don't reserve isn't yours to assume. Joe From nobody Tue May 5 12:32:35 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22FF1ACDD6 for ; Tue, 5 May 2015 12:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 3IjpVA-X_Gci for ; Tue, 5 May 2015 12:32:28 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688941ACD63 for ; Tue, 5 May 2015 12:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2066; q=dns/txt; s=iport; t=1430854346; x=1432063946; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KjPP6kiDdFk8GgfM3K6W5B8Btx5PLSwD+VwuIVFE0e0=; b=Teqvh1WIMmgZKB8fl4e40FR0cyCRACDlxt0oHjIf9L8O0i6LIY3pVLWM I5+DPcTNt/8lVaBF288rLUP3Xw+w206gNw+7Re5uaDoGVfkmSwLHJv2Jn 24NzfhejTwIlUQRV5q0xqEZaWo6Zmijc4H95AB0h/2kekXCFU4WG5SroV 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BTBABPGklV/4cNJK1cgwxTXAWDGMJoCYFMCoYFAhyBITgUAQEBAQEBAYEKhCABAQEEAQEBIBE6FwQCAQgRAwECAwImAgICJQsVCAgCBAESiCwNsRCTYwEBAQEBAQEBAQEBAQEBAQEBARYEgSGKGIRSOgaCYoFFBZIdilaBJINWkTUjg3RvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,374,1427760000"; d="scan'208";a="147334801" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2015 19:32:25 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t45JWPeq003001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 19:32:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.187]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 5 May 2015 14:32:25 -0500 From: "Larry Kreeger (kreeger)" To: "Carlos Pignataro (cpignata)" , William Caban , "sfc@ietf.org" Thread-Topic: [sfc] Next Protocol in draft-ietf-sfc-nsh-00 Thread-Index: AQHQh2cwr5fkY0jPBUKo9FhHBJ3B7J1uFlmA//+N0oA= Date: Tue, 5 May 2015 19:32:24 +0000 Message-ID: References: <7500140A-FD3E-4720-ABDD-F28A20D32459@savantadvisors.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.166.41] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Next Protocol in draft-ietf-sfc-nsh-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:32:30 -0000 VXNpbmcgdmFsdWVzIDI1NCBhbmQgMjU1IHdvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCB3aGF0IHdh cyBkb25lIGZvciB0aGUgTUQNClR5cGUsIGFuZCBmaXQgd2l0aGluIHRhYmxlIDIgd2hpY2ggZG9l c24ndCBkZWZpbmUgdGhlc2UgdmFsdWVzIGFzIGVpdGhlcg0KYXNzaWduZWQsIHVuYXNzaWduZWQg b3IgcmVzZXJ2ZWQuDQoNCiAtIExhcnJ5DQoNCk9uIDUvNS8xNSAxMjoyMSBQTSwgIkNhcmxvcyBQ aWduYXRhcm8gKGNwaWduYXRhKSIgPGNwaWduYXRhQGNpc2NvLmNvbT4NCndyb3RlOg0KDQo+QXNz aWduaW5nIGEgY291cGxlIG9mIEV4cGVyaW1lbnRhbCB2YWx1ZXMgc291bmRzIHVzZWZ1bC4gW1JG QzM2OTJdDQo+DQo+TWF5YmUgMjUzIGFuZCAyNTQsIMKzVXNlIGZvciBleHBlcmltZW50YXRpb24g YW5kIHRlc3RpbmfCsi4NCj4NCj5UaGFua3MsDQo+DQo+4oC5IENhcmxvcy4NCj4NCj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFdpbGxpYW0gQ2FiYW4gPHdpbGxpYW0uY2FiYW5A c2F2YW50YWR2aXNvcnMuY29tPg0KPkRhdGU6IFR1ZXNkYXksIE1heSA1LCAyMDE1IGF0IDM6MDkg UE0NCj5UbzogInNmY0BpZXRmLm9yZyIgPHNmY0BpZXRmLm9yZz4NCj5TdWJqZWN0OiBbc2ZjXSBO ZXh0IFByb3RvY29sIGluIGRyYWZ0LWlldGYtc2ZjLW5zaC0wMA0KPg0KPj5JbiBzZWN0aW9uIDMu MjogVGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgTmV4dCBQcm90b2NvbCB2YWx1ZXM6 DQo+Pg0KPj4gICAweDEgOiBJUHY0DQo+PiAgIDB4MiA6IElQdjYNCj4+ICAgMHgzIDogRXRoZXJu ZXQNCj4+DQo+Pg0KPj5QbGVhc2UsIGNvbnNpZGVyIGEgwrNSQVcvQkxPQsKyIG9yIMKzVEVTVMKy IE5leHQgUHJvdG9jb2wgaWRlbnRpZmllciB3aGljaA0KPj5jb3VsZCBiZSB1c2VkIGJ5IG5ldHdv cmsgcmVzZWFyY2hlcnMgYW5kIGFjYWRlbWlhIHRvIGRldmVsb3AgZnV0dXJlDQo+PnByb3RvY29s cyBhbmQgYmVuZWZpdCBmcm9tIHRoZSBOU0ggd2l0aG91dCBoYXZpbmcgdG8gbW9kaWZ5IHRoZSBm dXR1cmUNCj4+TlNIIHN0YW5kYXJkLiBXaXRoIHN1Y2ggYW4gaWRlbnRpZmljYXRpb24sIGFwcGxp Y2F0aW9uIHZlbmRvcnMgY291bGQgdXNlDQo+PnRoZSBzYW1lIGhlYWRlcnMgdG8gaW5qZWN0IFNO IG9mIGV4cGVyaW1lbnRhbCBhbmQvb3IgcHJvcHJpZXRhcnkNCj4+cHJvdG9jb2xzIHdpdGhvdXQg bW9kaWZ5aW5nIHRoZSBzdGFuZGFyZC4NCj4+DQo+Pl9XaWxsaWFtDQo+Pg0KPj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5zZmMgbWFpbGluZyBsaXN0 DQo+PnNmY0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Tue May 5 12:34:13 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EE01ACDD3; Tue, 5 May 2015 12:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 fCTDgU9x3jYU; Tue, 5 May 2015 12:34:00 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DFA1A87BD; Tue, 5 May 2015 12:34:00 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t45JXHkJ005267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 12:33:26 -0700 (PDT) Message-ID: <55491AFD.8000306@isi.edu> Date: Tue, 05 May 2015 12:33:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:34:03 -0000 On 5/5/2015 11:47 AM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 05, 2015 11:26 AM >> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org >> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >> >> >> >> On 5/5/2015 11:04 AM, Templin, Fred L wrote: >>> Hi Joe, >>> >>>> -----Original Message----- >>>> From: Joe Touch [mailto:touch@isi.edu] >>>> Sent: Tuesday, May 05, 2015 10:54 AM >>>> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org >>>> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org >>>> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >>>> >>>> >>>> >>>> On 5/5/2015 9:39 AM, Templin, Fred L wrote: >>>>> Hi Joe, >>>> .. >>>>>> IP in UDP adds only port numbers and an Internet checksum. >>>>>> >>>>>> That doesn't address fragmentation; if outer fragmentation is assumed, >>>>>> IPv4 needs to be rate-limited to avoid ID collisions and the Internet >>>>>> checksum is insufficient to correct those collisions. >>>>> >>>>> Right - that is why we have GUE. But, when these functions are not >>>>> needed GUE can perform header compression and the result looks >>>>> exactly like IP in UDP. >>>> >>>> That seems impossible. >>> >>> Not impossible - Tom Herbert provided the solution: >>> >>> http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html >> >> That is allocating bits (or bit patterns) from the IP header. >> >> The solution provided - to check for 0x01 - is incorrect. IP can have >> versions that include 0x10 and 0x11. > > The version field in both IPv4 and IPv6 have that bit set to 1. If GUE > then deems that bit to indicate "direct IP encapsulation, then there > is no need for a GUE header of length greater than 0. > > You may say that future IP protocol versions might not have that bit > set in the version field. But, the version bits for IPv4 and IPv6 will > never change (by definition) and we do not see a new IP protocol > version replacing IPv4 or IPv6 on the near-term horizon. 0x01 is valid for four version numbers: 4 5 6 7 You cannot assume either that 0x01 always means IPv4 and IPv6 only OR that any other pattern is NOT an IP packet UNLESS GUE is assigned the values you are assuming (e.g., 0x00, 0x10, 0x11), and that's not going to happen. As I said on the other post: Codepoints you aren't assigned aren't yours to assume. > Even if a new IP protocol version emerged with the "direct IP > encapsulation" bit set to 0, that version can still be accommodated > by GUE. It's just that direct encapsulation cannot be used and a > non-zero-length GUE header is needed. It's more than that - you need to ensure that all other IP values are NOT interpreted as uncompressed. Joe From nobody Tue May 5 12:35:41 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6461B305E; Tue, 5 May 2015 12:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ESUJsJWP1_7E; Tue, 5 May 2015 12:35:36 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFD71B303A; Tue, 5 May 2015 12:35:12 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t45JYWwE005373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 12:34:41 -0700 (PDT) Message-ID: <55491B47.4060400@isi.edu> Date: Tue, 05 May 2015 12:34:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tom Herbert , "Templin, Fred L" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "int-area@ietf.org" , "sfc@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , Donald Eastlake , Xuxiaohu Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:35:38 -0000 On 5/5/2015 11:53 AM, Tom Herbert wrote: > On Tue, May 5, 2015 at 11:47 AM, Templin, Fred L > wrote: >> Hi Joe, >> >>> -----Original Message----- >>> From: Joe Touch [mailto:touch@isi.edu] >>> Sent: Tuesday, May 05, 2015 11:26 AM >>> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org >>> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org >>> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >>> >>> >>> >>> On 5/5/2015 11:04 AM, Templin, Fred L wrote: >>>> Hi Joe, >>>> >>>>> -----Original Message----- >>>>> From: Joe Touch [mailto:touch@isi.edu] >>>>> Sent: Tuesday, May 05, 2015 10:54 AM >>>>> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org >>>>> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org >>>>> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >>>>> >>>>> >>>>> >>>>> On 5/5/2015 9:39 AM, Templin, Fred L wrote: >>>>>> Hi Joe, >>>>> .. >>>>>>> IP in UDP adds only port numbers and an Internet checksum. >>>>>>> >>>>>>> That doesn't address fragmentation; if outer fragmentation is assumed, >>>>>>> IPv4 needs to be rate-limited to avoid ID collisions and the Internet >>>>>>> checksum is insufficient to correct those collisions. >>>>>> >>>>>> Right - that is why we have GUE. But, when these functions are not >>>>>> needed GUE can perform header compression and the result looks >>>>>> exactly like IP in UDP. >>>>> >>>>> That seems impossible. >>>> >>>> Not impossible - Tom Herbert provided the solution: >>>> >>>> http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html >>> >>> That is allocating bits (or bit patterns) from the IP header. >>> >>> The solution provided - to check for 0x01 - is incorrect. IP can have >>> versions that include 0x10 and 0x11. >> >> The version field in both IPv4 and IPv6 have that bit set to 1. If GUE >> then deems that bit to indicate "direct IP encapsulation, then there >> is no need for a GUE header of length greater than 0. >> >> You may say that future IP protocol versions might not have that bit >> set in the version field. But, the version bits for IPv4 and IPv6 will >> never change (by definition) and we do not see a new IP protocol >> version replacing IPv4 or IPv6 on the near-term horizon. >> >> Even if a new IP protocol version emerged with the "direct IP >> encapsulation" bit set to 0, that version can still be accommodated >> by GUE. It's just that direct encapsulation cannot be used and a >> non-zero-length GUE header is needed. >> > Or just define a simple version translation as part of encapsulation. > So for IPv8: > > 0x1000->0x0101 on encapsulation > 0x0101->0x1000 on decapsualtion And what happens to 0x0101 WHEN it shows up? You need more patterns than you have because IP is allowed to use any of them. That's why you need an extra bit, and that's why you can't assume these bits are "yours". Joe From nobody Tue May 5 12:42:26 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DBE1ACDDA; Tue, 5 May 2015 12:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 CVerbjc2yk7x; Tue, 5 May 2015 12:42:18 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CC81ACDBF; Tue, 5 May 2015 12:42:17 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t45JfYn7006781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 12:41:43 -0700 (PDT) Message-ID: <55491CED.5070505@isi.edu> Date: Tue, 05 May 2015 12:41:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tom Herbert , "Templin, Fred L" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> <55491B47.4060400@isi.edu> In-Reply-To: <55491B47.4060400@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "int-area@ietf.org" , "sfc@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , Donald Eastlake , Xuxiaohu Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:42:20 -0000 On 5/5/2015 12:34 PM, Joe Touch wrote: >> Or just define a simple version translation as part of encapsulation. >> > So for IPv8: >> > >> > 0x1000->0x0101 on encapsulation >> > 0x0101->0x1000 on decapsualtion > And what happens to 0x0101 WHEN it shows up? > > You need more patterns than you have because IP is allowed to use any of > them. FWIW, you're essentially arguing for bit-stuffing, i.e., if a pattern you think will be common shows up, don't stuff, and if something else shows up, then do. That works only if you do true stuffing, e.g.,: 0x01** = uncompressed (might as well add 0x11** and 0x10** to that) 0x00** = compressed But then if 0x0000, 0x0001, 0x0010 or 0x0011 show up, you need to decide how to represent them - they CANNOT be uncompressed without at least two more bits somewhere else that indicates they're uncompressed and their value. So now your GUE methods are very sensitive to IP version numbers, which IMO defeats the "G" in the name. Never mind how this complicates hardware when (not if) other IP versions are used (for whatever reason). Joe From nobody Tue May 5 12:43:07 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A4E1ACDF9; Tue, 5 May 2015 12:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 7oP9ERvgTIeB; Tue, 5 May 2015 12:42:53 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B031ACDBF; Tue, 5 May 2015 12:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t45Jgj6A015271; Tue, 5 May 2015 14:42:45 -0500 Received: from XCH-BLV-106.nw.nos.boeing.com (xch-blv-106.nw.nos.boeing.com [130.247.25.122]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t45JggI0015242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 May 2015 14:42:43 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-106.nw.nos.boeing.com ([169.254.6.188]) with mapi id 14.03.0235.001; Tue, 5 May 2015 12:42:41 -0700 From: "Templin, Fred L" To: Joe Touch , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAejJGxDIiBx0S2BZ0ZWLGtWJ1nAPgAgAQl8XCAAFTXgIABIiUAgADgFUCAAJHXAP//i4BggACKdAD//4xEMIAAfNmA//+PG6AAEHTlgAAOmVVQ Date: Tue, 5 May 2015 19:42:41 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5AD42@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> <55491AFD.8000306@isi.edu> In-Reply-To: <55491AFD.8000306@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:43:02 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, May 05, 2015 12:33 PM > To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/5/2015 11:47 AM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Tuesday, May 05, 2015 11:26 AM > >> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org > >> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > >> > >> > >> > >> On 5/5/2015 11:04 AM, Templin, Fred L wrote: > >>> Hi Joe, > >>> > >>>> -----Original Message----- > >>>> From: Joe Touch [mailto:touch@isi.edu] > >>>> Sent: Tuesday, May 05, 2015 10:54 AM > >>>> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org > >>>> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > >>>> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > >>>> > >>>> > >>>> > >>>> On 5/5/2015 9:39 AM, Templin, Fred L wrote: > >>>>> Hi Joe, > >>>> .. > >>>>>> IP in UDP adds only port numbers and an Internet checksum. > >>>>>> > >>>>>> That doesn't address fragmentation; if outer fragmentation is assu= med, > >>>>>> IPv4 needs to be rate-limited to avoid ID collisions and the Inter= net > >>>>>> checksum is insufficient to correct those collisions. > >>>>> > >>>>> Right - that is why we have GUE. But, when these functions are not > >>>>> needed GUE can perform header compression and the result looks > >>>>> exactly like IP in UDP. > >>>> > >>>> That seems impossible. > >>> > >>> Not impossible - Tom Herbert provided the solution: > >>> > >>> http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html > >> > >> That is allocating bits (or bit patterns) from the IP header. > >> > >> The solution provided - to check for 0x01 - is incorrect. IP can have > >> versions that include 0x10 and 0x11. > > > > The version field in both IPv4 and IPv6 have that bit set to 1. If GUE > > then deems that bit to indicate "direct IP encapsulation, then there > > is no need for a GUE header of length greater than 0. > > > > You may say that future IP protocol versions might not have that bit > > set in the version field. But, the version bits for IPv4 and IPv6 will > > never change (by definition) and we do not see a new IP protocol > > version replacing IPv4 or IPv6 on the near-term horizon. >=20 > 0x01 is valid for four version numbers: > 4 > 5 > 6 > 7 Sure. > You cannot assume either that 0x01 always means IPv4 and IPv6 only OR > that any other pattern is NOT an IP packet UNLESS GUE is assigned the > values you are assuming (e.g., 0x00, 0x10, 0x11), and that's not going > to happen. You are making this way more complicated than it really is. 0xX1XX means that this is an IP header - at this moment, either IPv4 or IPv6. But, havin= g checked the bit the next step is to test the entire nibble to ensure that i= t is indeed either 0x0100 or 0x0110. And, if it is neither, the packet is dropped due to a malformed header. But, 0xX0XX means that the GUE header is present. There is no ambiguity here, and it just works. > As I said on the other post: >=20 > Codepoints you aren't assigned aren't yours to assume. >=20 > > Even if a new IP protocol version emerged with the "direct IP > > encapsulation" bit set to 0, that version can still be accommodated > > by GUE. It's just that direct encapsulation cannot be used and a > > non-zero-length GUE header is needed. >=20 > It's more than that - you need to ensure that all other IP values are > NOT interpreted as uncompressed. Again, you are twisting something that is very simple to make it appear complicated when in fact it is not. Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Tue May 5 12:49:11 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810D31ACE11; Tue, 5 May 2015 12:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 n-VNu--LEh3g; Tue, 5 May 2015 12:49:05 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FAE1ACE02; Tue, 5 May 2015 12:49:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t45Jn5K9020956; Tue, 5 May 2015 12:49:05 -0700 Received: from XCH-BLV-402.nw.nos.boeing.com (xch-blv-402.nw.nos.boeing.com [130.247.25.31]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t45Jn1N4020831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 May 2015 12:49:01 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-402.nw.nos.boeing.com ([169.254.2.156]) with mapi id 14.03.0235.001; Tue, 5 May 2015 12:49:01 -0700 From: "Templin, Fred L" To: Joe Touch , Tom Herbert Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQh2t9jJGxDIiBx0S2BZ0ZWLGtWJ1tyMJw Date: Tue, 5 May 2015 19:49:00 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5AD6C@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> <55491B47.4060400@isi.edu> <55491CED.5070505@isi.edu> In-Reply-To: <55491CED.5070505@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "int-area@ietf.org" , "sfc@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , Donald Eastlake , Xuxiaohu Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:49:08 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAwNSwgMjAxNSAx Mjo0MiBQTQ0KPiBUbzogVG9tIEhlcmJlcnQ7IFRlbXBsaW4sIEZyZWQgTA0KPiBDYzogWHV4aWFv aHU7IERvbmFsZCBFYXN0bGFrZTsgdHJpbGxAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IGludC1h cmVhQGlldGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0cmlsbF0gRndkOiBN YWlsIHJlZ2FyZGluZyBkcmFmdC1pZXRmLXRyaWxsLW92ZXItaXANCj4gDQo+IA0KPiANCj4gT24g NS81LzIwMTUgMTI6MzQgUE0sIEpvZSBUb3VjaCB3cm90ZToNCj4gPj4gT3IganVzdCBkZWZpbmUg YSBzaW1wbGUgdmVyc2lvbiB0cmFuc2xhdGlvbiBhcyBwYXJ0IG9mIGVuY2Fwc3VsYXRpb24uDQo+ ID4+ID4gU28gZm9yIElQdjg6DQo+ID4+ID4NCj4gPj4gPiAweDEwMDAtPjB4MDEwMSBvbiBlbmNh cHN1bGF0aW9uDQo+ID4+ID4gMHgwMTAxLT4weDEwMDAgb24gZGVjYXBzdWFsdGlvbg0KPiA+IEFu ZCB3aGF0IGhhcHBlbnMgdG8gMHgwMTAxIFdIRU4gaXQgc2hvd3MgdXA/DQo+ID4NCj4gPiBZb3Ug bmVlZCBtb3JlIHBhdHRlcm5zIHRoYW4geW91IGhhdmUgYmVjYXVzZSBJUCBpcyBhbGxvd2VkIHRv IHVzZSBhbnkgb2YNCj4gPiB0aGVtLg0KPiANCj4gRldJVywgeW91J3JlIGVzc2VudGlhbGx5IGFy Z3VpbmcgZm9yIGJpdC1zdHVmZmluZywgaS5lLiwgaWYgYSBwYXR0ZXJuDQo+IHlvdSB0aGluayB3 aWxsIGJlIGNvbW1vbiBzaG93cyB1cCwgZG9uJ3Qgc3R1ZmYsIGFuZCBpZiBzb21ldGhpbmcgZWxz ZQ0KPiBzaG93cyB1cCwgdGhlbiBkby4NCj4gDQo+IFRoYXQgd29ya3Mgb25seSBpZiB5b3UgZG8g dHJ1ZSBzdHVmZmluZywgZS5nLiw6DQo+IA0KPiAJMHgwMSoqID0gdW5jb21wcmVzc2VkDQo+ICht aWdodCBhcyB3ZWxsIGFkZCAweDExKiogYW5kIDB4MTAqKiB0byB0aGF0KQ0KPiAJMHgwMCoqID0g Y29tcHJlc3NlZA0KPiANCj4gQnV0IHRoZW4gaWYgMHgwMDAwLCAweDAwMDEsIDB4MDAxMCBvciAw eDAwMTEgc2hvdyB1cCwgeW91IG5lZWQgdG8gZGVjaWRlDQo+IGhvdyB0byByZXByZXNlbnQgdGhl bSAtIHRoZXkgQ0FOTk9UIGJlIHVuY29tcHJlc3NlZCB3aXRob3V0IGF0IGxlYXN0IHR3bw0KPiBt b3JlIGJpdHMgc29tZXdoZXJlIGVsc2UgdGhhdCBpbmRpY2F0ZXMgdGhleSdyZSB1bmNvbXByZXNz ZWQgYW5kIHRoZWlyDQo+IHZhbHVlLg0KPiANCj4gU28gbm93IHlvdXIgR1VFIG1ldGhvZHMgYXJl IHZlcnkgc2Vuc2l0aXZlIHRvIElQIHZlcnNpb24gbnVtYmVycywgd2hpY2gNCj4gSU1PIGRlZmVh dHMgdGhlICJHIiBpbiB0aGUgbmFtZS4gTmV2ZXIgbWluZCBob3cgdGhpcyBjb21wbGljYXRlcw0K PiBoYXJkd2FyZSB3aGVuIChub3QgaWYpIG90aGVyIElQIHZlcnNpb25zIGFyZSB1c2VkIChmb3Ig d2hhdGV2ZXIgcmVhc29uKS4NCg0KTm87IGl0IGlzIHN0aWxsIEdlbmVyaWMuIElmIHRoZSBwYWNr ZXQgaXMgbm90IGEgZGlyZWN0LW1hcHBlZCBJUCBwYWNrZXQsIHRoZW4gdGhlcmUNCmlzIGEgR1VF IGhlYWRlciB0aGF0IGNhbiBlbmNhcHN1bGF0ZSBhbnkgKGZvbykgcHJvdG9jb2wuIFRydWUgdGhh dCBJUCBwcm90b2NvbA0KdmVyc2lvbnMgdGhhdCBjYW4gYmUgcmVwcmVzZW50ZWQgYXMgMHhYMVhY IGNhbiBiZSBkaXJlY3RseSBtYXBwZWQgd2hpbGUNCm90aGVyIChmb28pIHByb3RvY29scyBjYW5u b3QgZG9lcyBub3QgbWVhbiB0aGF0IHdlIHNob3VsZCBub3QgdGFrZQ0KYWR2YW50YWdlIG9mIHRo ZSBkaXJlY3QgbWFwcGluZyB3aGVuIHBvc3NpYmxlLg0KDQpBYm91dCBoL3cgY29tcGxpY2F0aW9u cywgdGhlIHRlc3QgaXMgaW5jb3Jwb3JhdGVkIGluIHRoZSBzYW1lIHRlc3QgdGhhdA0KaGFyZHdh cmUgYWxyZWFkeSB1c2VzIHRvIGNoZWNrIHRoZSBJUCB2ZXJzaW9uIG51bWJlciwgaS5lLiwgbm8g bmV3DQppbnN0cnVjdGlvbnMgbmVlZGVkLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxp bkBib2VpbmcuY29tDQoNCj4gSm9lDQo+IA0KPiANCg0K From nobody Tue May 5 12:56:08 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC3C1B2FB7 for ; Tue, 5 May 2015 12:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 WYEAN2alR1TX for ; Tue, 5 May 2015 12:56:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7EDE1AD366 for ; Tue, 5 May 2015 12:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2598; q=dns/txt; s=iport; t=1430855762; x=1432065362; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aRQK9M/fME/umg0VjbM0M4z056+O3WvpOMH0AGtMXSk=; b=VVdt6qakYVA8H9/FyiyuRmnsfQEtVbPw2h7imEpK5wSYHb4cPG8pg2mh nx2PmkJuVlCAmFYmBfqWVe7Fkp8D3egwpQ+JLU/BCc7nRqG437a/xFylY LCK6Jc/XezswEQi1i2rROTjUKBoQ+Ms8XDdfbM+hvmg2xsrPzzu9qnXZn A=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBQDyH0lV/4QNJK1cgwxTUAwFgxjCAoI7CoYFAoE9TAEBAQEBAYELhCABAQEDAQEBASBLCwUHBAIBCBEDAQIBKgICJwsdCAIEDgUOiBYIDbEmk14BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs5hHQRBwaCYi+BFgWSHYF9gTqHHwGBI4NWkTUjg3RvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,374,1427760000"; d="asc'?scan'208";a="417290467" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP; 05 May 2015 19:56:02 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t45Ju1eN020478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 19:56:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.104]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 5 May 2015 14:56:01 -0500 From: "Carlos Pignataro (cpignata)" To: "Larry Kreeger (kreeger)" Thread-Topic: [sfc] Next Protocol in draft-ietf-sfc-nsh-00 Thread-Index: AQHQh2fjUmc6ysjIH0qbgFwJ4qh8pp1t01QAgABGGgCAAAajgA== Date: Tue, 5 May 2015 19:56:00 +0000 Message-ID: References: <7500140A-FD3E-4720-ABDD-F28A20D32459@savantadvisors.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.55.143] Content-Type: multipart/signed; boundary="Apple-Mail=_DD2249E2-4D37-415F-BB34-E906A68C7DE9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: William Caban , "sfc@ietf.org" Subject: Re: [sfc] Next Protocol in draft-ietf-sfc-nsh-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:56:04 -0000 --Apple-Mail=_DD2249E2-4D37-415F-BB34-E906A68C7DE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That works as well =E2=80=94 for a second I thought 255 was Reserved = (like 0), but you are right it is not. Thanks, =E2=80=94 Carlos. > On May 5, 2015, at 3:32 PM, Larry Kreeger (kreeger) = wrote: >=20 > Using values 254 and 255 would be consistent with what was done for = the MD > Type, and fit within table 2 which doesn't define these values as = either > assigned, unassigned or reserved. >=20 > - Larry >=20 > On 5/5/15 12:21 PM, "Carlos Pignataro (cpignata)" > wrote: >=20 >> Assigning a couple of Experimental values sounds useful. [RFC3692] >>=20 >> Maybe 253 and 254, =C2=B3Use for experimentation and testing=C2=B2. >>=20 >> Thanks, >>=20 >> =E2=80=B9 Carlos. >>=20 >> -----Original Message----- >> From: William Caban >> Date: Tuesday, May 5, 2015 at 3:09 PM >> To: "sfc@ietf.org" >> Subject: [sfc] Next Protocol in draft-ietf-sfc-nsh-00 >>=20 >>> In section 3.2: This draft defines the following Next Protocol = values: >>>=20 >>> 0x1 : IPv4 >>> 0x2 : IPv6 >>> 0x3 : Ethernet >>>=20 >>>=20 >>> Please, consider a =C2=B3RAW/BLOB=C2=B2 or =C2=B3TEST=C2=B2 Next = Protocol identifier which >>> could be used by network researchers and academia to develop future >>> protocols and benefit from the NSH without having to modify the = future >>> NSH standard. With such an identification, application vendors could = use >>> the same headers to inject SN of experimental and/or proprietary >>> protocols without modifying the standard. >>>=20 >>> _William >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 --Apple-Mail=_DD2249E2-4D37-415F-BB34-E906A68C7DE9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVJIFkACgkQtfDPGTp3USzh9QCdHuekEbFhvxWhfD/IpPshjxJt EbUAn03p82haUfu3yCHSCCRsw6eFQyDq =8K/F -----END PGP SIGNATURE----- --Apple-Mail=_DD2249E2-4D37-415F-BB34-E906A68C7DE9-- From nobody Tue May 5 13:34:30 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C671F1ACE87; Tue, 5 May 2015 13:34:26 -0700 (PDT) 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 M_LKAcZ4Nq71; Tue, 5 May 2015 13:34:24 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA961ACE98; Tue, 5 May 2015 13:34:24 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 5 May 2015 16:34:23 -0400 From: Dave Dolson To: Joe Touch , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhtp6xe00UGkG+kO9Al9/qga7jZ1t15uA///H7FCAAE/xAP//5JjA Date: Tue, 5 May 2015 20:34:22 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> In-Reply-To: <554904B8.9020504@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 20:34:27 -0000 For IPv6, if the packet doesn't fit in the tunnel, the ICMP6 "too big"=20 message is sent, and the sender fragments it, sends it again, and notes=20 the PMTU for future packets. This is how IPv6 fragmentation is supported. Some of your arguments are that implementations are broken so ICMP doesn't= =20 work. I don't buy that. When the internet doesn't work, it gets fixed or=20 the customers go away. Your one argument I think may be valid is the IPv6 1280 requirement. Let's say N levels of tunneling are required to reduce 1500 bytes to 1280 b= ytes. The person who wants to do the (N+1)th overlay either cannot do it, or they= resort to fragmentation of the outer layer. Nonetheless, the approach of reducing Path-MTU is a valid 3rd choice, provi= ded it is=20 not reduced below 1280. -----Original Message----- From: Joe Touch [mailto:touch@isi.edu]=20 Sent: Tuesday, May 05, 2015 1:58 PM To: Dave Dolson; Xuxiaohu; Donald Eastlake; trill@ietf.org Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip On 5/5/2015 10:18 AM, Dave Dolson wrote: > Joe, > I think this discussion is about fragmenting the outer IP packet. That's feasible for IPv6, but extremely limiting for IPv4 because of the limited ID field size (it would rate-limit the tunnel significantly). > There is a 3rd choice: to fragment the inner datagram, That is not valid for IPv6 or IPv6 DF=3D1, so unless you support only IPv4 DF=3D0 packets, it won't work. > and/or use ICMP "datagram is too big" messages to facilitate > PMTU discovery of the tunnel. That won't work for several reasons: - ICMPs are often blocked - ICMP might not return enough of the nested headers - ICMP cannot validly say "1280 is too big" for IPv6 (which it would need to do if the path supported only 1280, because there wouldn't be space for the additional IP header) > This certainly seems to have been the intent, when one reads about > the IPv4 DF flag. (And IPv6 always requires DF). See above; while the DF issue might be useful in some contexts, it doesn't magically get around the need to fragment in ways that are not supported by the inner header. Joe > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Tuesday, May 05, 2015 12:33 PM > To: Xuxiaohu; Donald Eastlake; trill@ietf.org > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/4/2015 7:23 PM, Xuxiaohu wrote: >> In a word, IP-in-UDP is just intended for those network environments >> where fragmentation on the tunnel layer and strong checksums are not >> desired. >=20 > That's insufficient. They are only applicable where fragmentation and a > strong checksum are not *needed*. >=20 > Once you run IP in IP (IP in UDP in IP qualifies as this), you have only > two choices: >=20 > - support fragmentation >=20 > - use in networks that are engineered so that > fragmentation is never needed >=20 > As to the strong checksum, similarly you have to either support one or > deploy the result where that checksum isn't needed - either because you > know that all apps will have strong enough checksums of their own or > because you know enough about the kinds of errors that will occur that > strong checksums aren't needed. >=20 > But the key there is to define a use case where these properties are > true AND to limit the document solution to uses in those case ONLY. >=20 >> For those network environments where fragmentation on the >> tunnel layer and stronger checksums are required, GUE should be >> considered instead. >=20 > Agreed. >=20 > Joe >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 From nobody Tue May 5 14:08:57 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48721B2A34; Tue, 5 May 2015 14:08:44 -0700 (PDT) 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 NpV89SQZuPOw; Tue, 5 May 2015 14:08:43 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5272C1B29AB; Tue, 5 May 2015 14:08:31 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t45L7lbA028853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 14:07:59 -0700 (PDT) Message-ID: <55493122.1050504@isi.edu> Date: Tue, 05 May 2015 14:07:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> <55491AFD.8000306@isi.edu> <2134F8430051B64F815C691A62D9831832E5AD42@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5AD42@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t45L7lbA028853 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:08:44 -0000 On 5/5/2015 12:42 PM, Templin, Fred L wrote: >> > You cannot assume either that 0x01 always means IPv4 and IPv6 only OR >> > that any other pattern is NOT an IP packet UNLESS GUE is assigned the >> > values you are assuming (e.g., 0x00, 0x10, 0x11), and that's not going >> > to happen. > > You are making this way more complicated than it really is. 0xX1XX means > that this is an IP header - at this moment, either IPv4 or IPv6. But, having > checked the bit the next step is to test the entire nibble to ensure that it > is indeed either 0x0100 or 0x0110. And, if it is neither, the packet is > dropped due to a malformed header. OK, you can declare that. But you are then declaring that the other IP versions with the same pattern cannot be transmitted as uncompressed GUE. > But, 0xX0XX means that the GUE header is present. There is no ambiguity > here, and it just works. You can *declare* that 0xX0XX means a GUE header, but then you are also declaring that 0xX0XX IP versions cannot occur as uncompressed GUE encapsulations. There are implications to these assumptions. Joe From nobody Tue May 5 14:11:45 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FCC1B2A4A; Tue, 5 May 2015 14:11:34 -0700 (PDT) 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 lSWb588f-N_R; Tue, 5 May 2015 14:11:32 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE791A1BC3; Tue, 5 May 2015 14:11:32 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t45LAxWr029515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 14:11:11 -0700 (PDT) Message-ID: <554931E2.5010101@isi.edu> Date: Tue, 05 May 2015 14:10:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t45LAxWr029515 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:11:34 -0000 On 5/5/2015 1:34 PM, Dave Dolson wrote: > For IPv6, if the packet doesn't fit in the tunnel, the ICMP6 "too big" > message is sent, and the sender fragments it, sends it again, and notes > the PMTU for future packets. This is how IPv6 fragmentation is supported. If the ICMP is received (and not blocked). If the ICMP has enough information for the tunnel source to know what happened. But this also then means that the tunnel egress will need to reassemble. > Some of your arguments are that implementations are broken so ICMP doesn't > work. I don't buy that. When the internet doesn't work, it gets fixed or > the customers go away. See RFC 4821. This issue has been known for a long time, and that's why the IETF developed an alternative that doesn't depend on ICMP receipt. > Your one argument I think may be valid is the IPv6 1280 requirement. > Let's say N levels of tunneling are required to reduce 1500 bytes to 1280 bytes. > The person who wants to do the (N+1)th overlay either cannot do it, or they resort > to fragmentation of the outer layer. > > Nonetheless, the approach of reducing Path-MTU is a valid 3rd choice, provided it is > not reduced below 1280. The better solution would be RFC 4821-style probing by the tunnel ingress to the tunnel egress. Joe From nobody Tue May 5 14:24:10 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E991B2A1F; Tue, 5 May 2015 14:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 3PIDn1UOZl2K; Tue, 5 May 2015 14:24:07 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA08F1B2A14; Tue, 5 May 2015 14:24:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t45LO4xx014598; Tue, 5 May 2015 14:24:04 -0700 Received: from XCH-BLV-106.nw.nos.boeing.com (xch-blv-106.nw.nos.boeing.com [130.247.25.122]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t45LNsbY014513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 May 2015 14:23:54 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-106.nw.nos.boeing.com ([169.254.6.188]) with mapi id 14.03.0235.001; Tue, 5 May 2015 14:23:53 -0700 From: "Templin, Fred L" To: Joe Touch , Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQh3nJyhmZ+Lyhk0iSDo4t2tXKbw== Date: Tue, 5 May 2015 21:23:52 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> <554931E2.5010101@isi.edu> In-Reply-To: <554931E2.5010101@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:24:08 -0000 Hi Joe, > The better solution would be RFC 4821-style probing by the tunnel > ingress to the tunnel egress. As you know, I agree with this (per Section 3.13 of AERO) but it is not exactly like RFC4821. With RFC4821, since the source of the probes is also the original source of the data packets (and, since the probes are actually data packets themselves) the probes are guaranteed to travel the same network path as the data packets. When the tunnel probes, however, it may be probing on behalf of many original sources and it becomes more difficult to ensure that the probes travel the same network path as the data packets. For this reason, the tunnel needs to be meticulous about how it assigns n-tuples to the probes and encapsulated data packets. Thanks - Fred fred.l.templin@boeing.com > Joe >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From nobody Tue May 5 15:00:17 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1BD1A700D; Tue, 5 May 2015 15:00:13 -0700 (PDT) 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 LPDoTXAazXjV; Tue, 5 May 2015 15:00:11 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584C71A6FFC; Tue, 5 May 2015 15:00:11 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t45Lwg8v008590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 14:58:52 -0700 (PDT) Message-ID: <55493D10.90609@isi.edu> Date: Tue, 05 May 2015 14:58:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> <554931E2.5010101@isi.edu> <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 22:00:13 -0000 On 5/5/2015 2:23 PM, Templin, Fred L wrote: > Hi Joe, > >> The better solution would be RFC 4821-style probing by the tunnel >> ingress to the tunnel egress. > > As you know, I agree with this (per Section 3.13 of AERO) but it is not > exactly like RFC4821. With RFC4821, since the source of the probes is > also the original source of the data packets (and, since the probes are > actually data packets themselves) the probes are guaranteed to travel > the same network path as the data packets. That depends on how you implement the tunnels. You can easily use the data packets as probes if you design a way for the egress to indicate which probes get through. T> When the tunnel probes, however, it may be probing on behalf of many > original sources and it becomes more difficult to ensure that the probes > travel the same network path as the data packets. That's true only if the network looks into the tunnel packets and treats them differently - which could have happened for any application packets too. Joe From nobody Tue May 5 15:15:27 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E581B2A19; Tue, 5 May 2015 15:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NGe3UXA4CG8A; Tue, 5 May 2015 15:15:20 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 D66321B2A13; Tue, 5 May 2015 15:15:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t45MFKP5063632; Tue, 5 May 2015 15:15:20 -0700 Received: from XCH-BLV-105.nw.nos.boeing.com (xch-blv-105.nw.nos.boeing.com [130.247.25.121]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t45MFHBQ063615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 May 2015 15:15:17 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-105.nw.nos.boeing.com ([169.254.5.90]) with mapi id 14.03.0235.001; Tue, 5 May 2015 15:15:16 -0700 From: "Templin, Fred L" To: Joe Touch , Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQh3nJyhmZ+Lyhk0iSDo4t2tXKb51uY68A//+LwaA= Date: Tue, 5 May 2015 22:15:15 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5AFC1@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> <554931E2.5010101@isi.edu> <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> <55493D10.90609@isi.edu> In-Reply-To: <55493D10.90609@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 22:15:23 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, May 05, 2015 2:59 PM > To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; trill@ietf.o= rg > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/5/2015 2:23 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> The better solution would be RFC 4821-style probing by the tunnel > >> ingress to the tunnel egress. > > > > As you know, I agree with this (per Section 3.13 of AERO) but it is not > > exactly like RFC4821. With RFC4821, since the source of the probes is > > also the original source of the data packets (and, since the probes are > > actually data packets themselves) the probes are guaranteed to travel > > the same network path as the data packets. >=20 > That depends on how you implement the tunnels. You can easily use the > data packets as probes if you design a way for the egress to indicate > which probes get through. >=20 > T> When the tunnel probes, however, it may be probing on behalf of many > > original sources and it becomes more difficult to ensure that the probe= s > > travel the same network path as the data packets. >=20 > That's true only if the network looks into the tunnel packets and treats > them differently - which could have happened for any application packets > too. No, look at Section 5.2 of RFC4821. It acknowledges that MTU needs to be maintained on a per-flow basis. When the source is the originator of the flows, it is easy to keep track of which MTUs are associated with which flows. When the source is a tunnel ingress, however, it may be required to send the data packets of many flows across the tunnel to the egress and, if the network can distinguish the different flows, the data packets and probe packets may take different paths.=20 What this means is that, for tunnels over IPv6, the ingress would need to implement a discipline for setting the flow label in the encapsulation header so that the probes and data packets appear to be part of the same flow. One way is to simply set a constant value (e.g., 0), but then ECMP in the path between the ingress and egress would be disabled. A compromise would be to have the ingress set a finite number of flow label values (e.g., 4) selected, e.g., based on a hash of the payload packet headers. But then, each such flow label value would need to be probed separately. Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Tue May 5 15:24:16 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C591B2A5E; Tue, 5 May 2015 15:24:10 -0700 (PDT) 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 rqIHNpQDKBRC; Tue, 5 May 2015 15:24:08 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D861B2A58; Tue, 5 May 2015 15:24:07 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t45MMvfp015483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 15:23:07 -0700 (PDT) Message-ID: <554942C0.4000601@isi.edu> Date: Tue, 05 May 2015 15:22:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> <554931E2.5010101@isi.edu> <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> <55493D10.90609@isi.edu> <2134F8430051B64F815C691A62D9831832E5AFC1@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5AFC1@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 22:24:11 -0000 On 5/5/2015 3:15 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 05, 2015 2:59 PM >> To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; trill@ietf.org >> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org >> Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip >> >> >> >> On 5/5/2015 2:23 PM, Templin, Fred L wrote: >>> Hi Joe, >>> >>>> The better solution would be RFC 4821-style probing by the tunnel >>>> ingress to the tunnel egress. >>> >>> As you know, I agree with this (per Section 3.13 of AERO) but it is not >>> exactly like RFC4821. With RFC4821, since the source of the probes is >>> also the original source of the data packets (and, since the probes are >>> actually data packets themselves) the probes are guaranteed to travel >>> the same network path as the data packets. >> >> That depends on how you implement the tunnels. You can easily use the >> data packets as probes if you design a way for the egress to indicate >> which probes get through. >> >> T> When the tunnel probes, however, it may be probing on behalf of many >>> original sources and it becomes more difficult to ensure that the probes >>> travel the same network path as the data packets. >> >> That's true only if the network looks into the tunnel packets and treats >> them differently - which could have happened for any application packets >> too. > > No, look at Section 5.2 of RFC4821. It acknowledges that MTU needs to be > maintained on a per-flow basis. When the source is the originator of the > flows, it is easy to keep track of which MTUs are associated with which > flows. When the source is a tunnel ingress, however, Then the tunnel is the source of the flows. Full stop. Any association between the tunnel flows and the flows arriving at the tunnel ingress is the responsibility of the tunnel to maintain. > it may be required > to send the data packets of many flows across the tunnel to the egress > and, if the network can distinguish the different flows, Then what you're saying is that the tunnel ingress - as an app - has flows that are distinguishable by the net. That can happen with any application. > the data packets > and probe packets may take different paths. That can happen with any application. > What this means is that, for tunnels over IPv6, the ingress would need > to implement a discipline for setting the flow label in the encapsulation > header so that the probes and data packets appear to be part of the > same flow. The probe packets can be the data packets. The egress can simply send information back about what data packets succeed. Joe From nobody Tue May 5 15:43:55 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52741B2A64; Tue, 5 May 2015 15:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FqJ__c61xTqT; Tue, 5 May 2015 15:43:49 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 D0FF91B2A67; Tue, 5 May 2015 15:43:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t45Mhnwp049338; Tue, 5 May 2015 15:43:49 -0700 Received: from XCH-BLV-108.nw.nos.boeing.com (xch-blv-108.nw.nos.boeing.com [130.247.25.137]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t45Mhjda049286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 May 2015 15:43:45 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-108.nw.nos.boeing.com ([169.254.13.118]) with mapi id 14.03.0235.001; Tue, 5 May 2015 15:43:45 -0700 From: "Templin, Fred L" To: Joe Touch , Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQh3nJyhmZ+Lyhk0iSDo4t2tXKb51uY68A//+LwaCAAHsHAP//jdww Date: Tue, 5 May 2015 22:43:44 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5B040@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> <554931E2.5010101@isi.edu> <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> <55493D10.90609@isi.edu> <2134F8430051B64F815C691A62D9831832E5AFC1@XCH-BLV-504.nw.nos.boeing.com> <554942C0.4000601@isi.edu> In-Reply-To: <554942C0.4000601@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 22:43:52 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, May 05, 2015 3:23 PM > To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; trill@ietf.o= rg > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/5/2015 3:15 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Tuesday, May 05, 2015 2:59 PM > >> To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; trill@iet= f.org > >> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > >> Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-i= p > >> > >> > >> > >> On 5/5/2015 2:23 PM, Templin, Fred L wrote: > >>> Hi Joe, > >>> > >>>> The better solution would be RFC 4821-style probing by the tunnel > >>>> ingress to the tunnel egress. > >>> > >>> As you know, I agree with this (per Section 3.13 of AERO) but it is n= ot > >>> exactly like RFC4821. With RFC4821, since the source of the probes is > >>> also the original source of the data packets (and, since the probes a= re > >>> actually data packets themselves) the probes are guaranteed to travel > >>> the same network path as the data packets. > >> > >> That depends on how you implement the tunnels. You can easily use the > >> data packets as probes if you design a way for the egress to indicate > >> which probes get through. > >> > >> T> When the tunnel probes, however, it may be probing on behalf of man= y > >>> original sources and it becomes more difficult to ensure that the pro= bes > >>> travel the same network path as the data packets. > >> > >> That's true only if the network looks into the tunnel packets and trea= ts > >> them differently - which could have happened for any application packe= ts > >> too. > > > > No, look at Section 5.2 of RFC4821. It acknowledges that MTU needs to b= e > > maintained on a per-flow basis. When the source is the originator of t= he > > flows, it is easy to keep track of which MTUs are associated with which > > flows. When the source is a tunnel ingress, however, >=20 > Then the tunnel is the source of the flows. Full stop. The tunnel is the source of the encapsulated packets, which may include the original packets of may flows (produced by the original sources). > Any association between the tunnel flows and the flows arriving at the > tunnel ingress is the responsibility of the tunnel to maintain. Right, which is why I said the ingress would need to be meticulous about setting the flow label. > > it may be required > > to send the data packets of many flows across the tunnel to the egress > > and, if the network can distinguish the different flows, >=20 > Then what you're saying is that the tunnel ingress - as an app - has > flows that are distinguishable by the net. That can happen with any > application. But, that's just it - when the original source does the probing the data packets are always part of the same application - always. When the tunnel ingress probes, it may be asked to encapsulate the data pacekts of many applications. So, RFC4821-style probing at the tunnel ingress is *different* from RFC4821-style probing at the original source. > > the data packets > > and probe packets may take different paths. >=20 > That can happen with any application. When the original source does the probing, the probes and application data packets are indistinguishable. That is not true for tunnels. > > What this means is that, for tunnels over IPv6, the ingress would need > > to implement a discipline for setting the flow label in the encapsulati= on > > header so that the probes and data packets appear to be part of the > > same flow. >=20 > The probe packets can be the data packets. The egress can simply send > information back about what data packets succeed. Yes, the probes can be data packets but the question is, which data packets= ? If there are many flows being multiplexed across the same tunnel, there would need to be a way to make sure all of the flows are properly associated with corresponding probes. I have already said many times that this does not make me happy but it does need to be dealt with. Should we just set the flow label to 0 in all tunneled packets and hope for the best? Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Tue May 5 17:28:16 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B251B2A98; Tue, 5 May 2015 17:28:13 -0700 (PDT) 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 mYNu2D8sP-x9; Tue, 5 May 2015 17:28:12 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C401B2A27; Tue, 5 May 2015 17:28:12 -0700 (PDT) Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t460RXSA000400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 17:27:50 -0700 (PDT) Message-ID: <55495FF4.7000100@isi.edu> Date: Tue, 05 May 2015 17:27:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> <554931E2.5010101@isi.edu> <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> <55493D10.90609@isi.edu> <2134F8430051B64F815C691A62D9831832E5AFC1@XCH-BLV-504.nw.nos.boeing.com> <554942C0.4000601@isi.edu> <2134F8430051B64F815C691A62D9831832E5B040@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5B040@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t460RXSA000400 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 00:28:13 -0000 On 5/5/2015 3:43 PM, Templin, Fred L wrote: >> Then what you're saying is that the tunnel ingress - as an app - has >> > flows that are distinguishable by the net. That can happen with any >> > application. > > But, that's just it - when the original source does the probing the data > packets are always part of the same application - always. When the > tunnel ingress probes, it may be asked to encapsulate the data > pacekts of many applications. An "application" is a source of packets. At a tunnel, the ingress arriving packets are that source - they ARE the "application". To correlate flow IDs to behavior within that flow - i.e., to the user programs that generate the packets that arrive at the ingress - requires the ingress to somehow infer those flows, unless they're explicitly marked by the user applications. That's a known limitation of any tunnel ingress. It's equally true of the user application if there are four people using one application, and you want 'flow' to map back to an individual person. Joe From nobody Tue May 5 19:46:41 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8B61B2A4C; Tue, 5 May 2015 19:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 oUcOKyjmMR4h; Tue, 5 May 2015 19:46:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755631B2A49; Tue, 5 May 2015 19:46:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVS04898; Wed, 06 May 2015 02:46:36 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 May 2015 03:46:36 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 6 May 2015 10:46:32 +0800 From: Xuxiaohu To: Joe Touch , Tom Herbert , "Templin, Fred L" Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAYoLZIFwke90qEGncpXxc1v51nAPgAgAQl8XCAAFTXgIABIiUAgABaUYCAABwmAIAAAU+AgAAUpQCAAAMpgIAABfSAgAAF9wCAAAGigIAAC4GAgAAB94CAAPvFMA== Date: Wed, 6 May 2015 02:46:32 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832ABC2@NKGEML512-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> <55491B47.4060400@isi.edu> <55491CED.5070505@isi.edu> In-Reply-To: <55491CED.5070505@isi.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Donald Eastlake , "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" , "trill@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 02:46:41 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9lIFRvdWNoIFttYWls dG86dG91Y2hAaXNpLmVkdV0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMDYsIDIwMTUgMzo0MiBB TQ0KPiBUbzogVG9tIEhlcmJlcnQ7IFRlbXBsaW4sIEZyZWQgTA0KPiBDYzogWHV4aWFvaHU7IERv bmFsZCBFYXN0bGFrZTsgdHJpbGxAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IGludC1hcmVhQGll dGYub3JnOw0KPiBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0cmlsbF0gRndkOiBNYWls IHJlZ2FyZGluZyBkcmFmdC1pZXRmLXRyaWxsLW92ZXItaXANCj4gDQo+IA0KPiANCj4gT24gNS81 LzIwMTUgMTI6MzQgUE0sIEpvZSBUb3VjaCB3cm90ZToNCj4gPj4gT3IganVzdCBkZWZpbmUgYSBz aW1wbGUgdmVyc2lvbiB0cmFuc2xhdGlvbiBhcyBwYXJ0IG9mIGVuY2Fwc3VsYXRpb24uDQo+ID4+ ID4gU28gZm9yIElQdjg6DQo+ID4+ID4NCj4gPj4gPiAweDEwMDAtPjB4MDEwMSBvbiBlbmNhcHN1 bGF0aW9uDQo+ID4+ID4gMHgwMTAxLT4weDEwMDAgb24gZGVjYXBzdWFsdGlvbg0KPiA+IEFuZCB3 aGF0IGhhcHBlbnMgdG8gMHgwMTAxIFdIRU4gaXQgc2hvd3MgdXA/DQo+ID4NCj4gPiBZb3UgbmVl ZCBtb3JlIHBhdHRlcm5zIHRoYW4geW91IGhhdmUgYmVjYXVzZSBJUCBpcyBhbGxvd2VkIHRvIHVz ZSBhbnkNCj4gPiBvZiB0aGVtLg0KPiANCj4gRldJVywgeW91J3JlIGVzc2VudGlhbGx5IGFyZ3Vp bmcgZm9yIGJpdC1zdHVmZmluZywgaS5lLiwgaWYgYSBwYXR0ZXJuIHlvdSB0aGluayB3aWxsDQo+ IGJlIGNvbW1vbiBzaG93cyB1cCwgZG9uJ3Qgc3R1ZmYsIGFuZCBpZiBzb21ldGhpbmcgZWxzZSBz aG93cyB1cCwgdGhlbiBkby4NCj4gDQo+IFRoYXQgd29ya3Mgb25seSBpZiB5b3UgZG8gdHJ1ZSBz dHVmZmluZywgZS5nLiw6DQo+IA0KPiAJMHgwMSoqID0gdW5jb21wcmVzc2VkDQo+IChtaWdodCBh cyB3ZWxsIGFkZCAweDExKiogYW5kIDB4MTAqKiB0byB0aGF0KQ0KPiAJMHgwMCoqID0gY29tcHJl c3NlZA0KPiANCj4gQnV0IHRoZW4gaWYgMHgwMDAwLCAweDAwMDEsIDB4MDAxMCBvciAweDAwMTEg c2hvdyB1cCwgeW91IG5lZWQgdG8gZGVjaWRlDQo+IGhvdyB0byByZXByZXNlbnQgdGhlbSAtIHRo ZXkgQ0FOTk9UIGJlIHVuY29tcHJlc3NlZCB3aXRob3V0IGF0IGxlYXN0IHR3bw0KPiBtb3JlIGJp dHMgc29tZXdoZXJlIGVsc2UgdGhhdCBpbmRpY2F0ZXMgdGhleSdyZSB1bmNvbXByZXNzZWQgYW5k IHRoZWlyIHZhbHVlLg0KPiANCj4gU28gbm93IHlvdXIgR1VFIG1ldGhvZHMgYXJlIHZlcnkgc2Vu c2l0aXZlIHRvIElQIHZlcnNpb24gbnVtYmVycywgd2hpY2ggSU1PDQo+IGRlZmVhdHMgdGhlICJH IiBpbiB0aGUgbmFtZS4gTmV2ZXIgbWluZCBob3cgdGhpcyBjb21wbGljYXRlcyBoYXJkd2FyZSB3 aGVuDQoNCkFncmVlLiBBcyBJIGhhZCBtZW50aW9uZWQgdG8gVG9tIGluIHByaXZhdGUsIEkgZG8g YmVsaWV2ZSB0aGUgYWRkaXRpb25hbCBjYXBhYmlsaXR5IG9mIEdVRSAoZS5nLiwgZnJhZ21lbnRh dGlvbikgd291bGQgYmUgbXVjaCB1c2VmdWwgaW4gc29tZSBuZXR3b3JrIGVudmlyb25tZW50cy4g SG93ZXZlciwgc2luY2UgR1VFIGlzIGludGVuZGVkIHRvIGJlIGEgZ2VuZXJpYyBVRFAgZW5jYXBz dWxhdGlvbiBhcHByb2FjaCwgd2UnZCBiZXR0ZXIgZGVzaWduIGl0IGFzIGdlbmVyaWMgYW5kIGZ1 dHVyZS1wcm9vZiBhcyBwb3NzaWJsZSBmcm9tIHRoZSBiZWdpbm5pbmcsIHNwZWNpZmljYWxseSBz cGVha2luZywgd2l0aG91dCBiZWluZyBkZWVwbHkgaW5mbHVlbmNlZCBieSBhIHBhcnRpY3VsYXIg R1VFIHBheWxvYWQgdHlwZS4gSWYgYm90aCBmb28taW4tR1VFIChmb28gY291bGQgYmUgTlNILCBU UklMTC4uLikgYW5kIGZvby1pbi1VRFAgKGkuZS4sIGEgY29tcGFjdCB2ZXJzaW9uIG9mIGZvby1p bi1HVUUpIGFyZSBuZWVkZWQgc29tZWRheSwgY291bGQgeW91IHN0aWxsIGFjaGlldmUgdGhlIHNh bWUgZWZmZWN0IGFzIHRoYXQgZm9yIElQLWluLVVEUCAoYXMgYSBjb21wYWN0IElQLWluLUdVRSkg YW5kIElQLWluLUdVRT8NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gKG5vdCBpZikgb3Ro ZXIgSVAgdmVyc2lvbnMgYXJlIHVzZWQgKGZvciB3aGF0ZXZlciByZWFzb24pLg0KPiANCj4gSm9l DQo+IA0KPiANCg0K From nobody Tue May 5 19:54:08 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8121ACDE6; Tue, 5 May 2015 19:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 rHZM_gymBAh3; Tue, 5 May 2015 19:54:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6671A89AB; Tue, 5 May 2015 19:54:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSE46487; Wed, 06 May 2015 02:54:02 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 May 2015 03:54:02 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 6 May 2015 10:53:55 +0800 From: Xuxiaohu To: Joe Touch , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAYoLZIFwke90qEGncpXxc1v51nAPgAgAQl8XCAAFTXgIABIiUAgAB14ICAATG/kA== Date: Wed, 6 May 2015 02:53:54 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832ABD8@NKGEML512-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> In-Reply-To: <5548F0B3.80602@isi.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 02:54:06 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Wednesday, May 06, 2015 12:33 AM > To: Xuxiaohu; Donald Eastlake; trill@ietf.org > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/4/2015 7:23 PM, Xuxiaohu wrote: > > In a word, IP-in-UDP is just intended for those network environments > > where fragmentation on the tunnel layer and strong checksums are not > > desired. >=20 > That's insufficient. They are only applicable where fragmentation and a s= trong > checksum are not *needed*. Agree that "needed" is a more appropriate word. > Once you run IP in IP (IP in UDP in IP qualifies as this), you have only = two > choices: >=20 > - support fragmentation >=20 > - use in networks that are engineered so that > fragmentation is never needed >=20 > As to the strong checksum, similarly you have to either support one or de= ploy > the result where that checksum isn't needed - either because you know tha= t all > apps will have strong enough checksums of their own or because you know > enough about the kinds of errors that will occur that strong checksums ar= en't > needed. >=20 > But the key there is to define a use case where these properties are true= AND to > limit the document solution to uses in those case ONLY. The use case is the Softwire networks (including both mesh and hub-spoke mo= des) where IP-in-IP and IP-in-GRE are good enough to address the MTU and ch= ecksum issues. Best regards, Xiaohu > > For those network environments where fragmentation on the tunnel layer > > and stronger checksums are required, GUE should be considered instead. >=20 > Agreed. >=20 > Joe From nobody Wed May 6 07:37:43 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EDA1ACD83; Wed, 6 May 2015 07:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 RqxdT31YEtNL; Wed, 6 May 2015 07:37:40 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2C21ACDB6; Wed, 6 May 2015 07:37:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t46Eb997021224; Wed, 6 May 2015 07:37:09 -0700 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t46Eb1RP021136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 May 2015 07:37:01 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-109.sw.nos.boeing.com ([169.254.9.131]) with mapi id 14.03.0235.001; Wed, 6 May 2015 07:37:00 -0700 From: "Templin, Fred L" To: Joe Touch , Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQh3nJyhmZ+Lyhk0iSDo4t2tXKb51uY68A//+LwaCAAHsHAP//jdwwgACU9ACAAHdOQA== Date: Wed, 6 May 2015 14:37:00 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5B85B@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> <554931E2.5010101@isi.edu> <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> <55493D10.90609@isi.edu> <2134F8430051B64F815C691A62D9831832E5AFC1@XCH-BLV-504.nw.nos.boeing.com> <554942C0.4000601@isi.edu> <2134F8430051B64F815C691A62D9831832E5B040@XCH-BLV-504.nw.nos.boeing.com> <55495FF4.7000100@isi.edu> In-Reply-To: <55495FF4.7000100@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 14:37:42 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, May 05, 2015 5:28 PM > To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; trill@ietf.o= rg > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/5/2015 3:43 PM, Templin, Fred L wrote: > >> Then what you're saying is that the tunnel ingress - as an app - has > >> > flows that are distinguishable by the net. That can happen with any > >> > application. > > > > But, that's just it - when the original source does the probing the dat= a > > packets are always part of the same application - always. When the > > tunnel ingress probes, it may be asked to encapsulate the data > > pacekts of many applications. >=20 > An "application" is a source of packets. >=20 > At a tunnel, the ingress arriving packets are that source - they ARE the > "application". >=20 > To correlate flow IDs to behavior within that flow - i.e., to the user > programs that generate the packets that arrive at the ingress - requires > the ingress to somehow infer those flows, unless they're explicitly > marked by the user applications. >=20 > That's a known limitation of any tunnel ingress. It's equally true of > the user application if there are four people using one application, and > you want 'flow' to map back to an individual person. We are still not reaching. The concern is that if some tunneled packets take a different network path than others then there is a chance that the probes will take a different path than the data. The only way I know to prevent that is to always set the Flow Label in the encapsulation header to some fixed value (e.g., 0). Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Wed May 6 07:43:17 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656551ACD83; Wed, 6 May 2015 07:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qnJgqdDQzHB3; Wed, 6 May 2015 07:43:09 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 7C83F1B2BF3; Wed, 6 May 2015 07:39:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t46Ed4LO059496; Wed, 6 May 2015 07:39:04 -0700 Received: from XCH-BLV-503.nw.nos.boeing.com (xch-blv-503.nw.nos.boeing.com [130.247.25.192]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t46Ed0qI059431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 May 2015 07:39:00 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-503.nw.nos.boeing.com ([169.254.3.97]) with mapi id 14.03.0235.001; Wed, 6 May 2015 07:39:00 -0700 From: "Templin, Fred L" To: Xuxiaohu , Joe Touch , Tom Herbert Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAYjJGxDIiBx0S2BZ0ZWLGtWJ1nAPgAgAQl8XCAAFTXgIABIiUAgABaUYCAABwmAIAAAU+AgAAUpQCAAAMpgIAABfSAgAAF9wCAAAGigIAAC4GAgAAB94CAAPvFMIAAx8gA Date: Wed, 6 May 2015 14:38:59 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5B87C@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> <55491B47.4060400@isi.edu> <55491CED.5070505@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832ABC2@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832ABC2@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: Donald Eastlake , "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" , "trill@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 14:43:14 -0000 SEksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWHV4aWFvaHUgW21h aWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBNYXkgMDUsIDIwMTUg Nzo0NyBQTQ0KPiBUbzogSm9lIFRvdWNoOyBUb20gSGVyYmVydDsgVGVtcGxpbiwgRnJlZCBMDQo+ IENjOiBEb25hbGQgRWFzdGxha2U7IHRyaWxsQGlldGYub3JnOyBudm8zQGlldGYub3JnOyBpbnQt YXJlYUBpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbdHJpbGxdIEZ3ZDog TWFpbCByZWdhcmRpbmcgZHJhZnQtaWV0Zi10cmlsbC1vdmVyLWlwDQo+IA0KPiANCj4gDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBKb2UgVG91Y2ggW21haWx0bzp0 b3VjaEBpc2kuZWR1XQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA2LCAyMDE1IDM6NDIgQU0N Cj4gPiBUbzogVG9tIEhlcmJlcnQ7IFRlbXBsaW4sIEZyZWQgTA0KPiA+IENjOiBYdXhpYW9odTsg RG9uYWxkIEVhc3RsYWtlOyB0cmlsbEBpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZzsgaW50LWFyZWFA aWV0Zi5vcmc7DQo+ID4gc2ZjQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFt0cmlsbF0gRndk OiBNYWlsIHJlZ2FyZGluZyBkcmFmdC1pZXRmLXRyaWxsLW92ZXItaXANCj4gPg0KPiA+DQo+ID4N Cj4gPiBPbiA1LzUvMjAxNSAxMjozNCBQTSwgSm9lIFRvdWNoIHdyb3RlOg0KPiA+ID4+IE9yIGp1 c3QgZGVmaW5lIGEgc2ltcGxlIHZlcnNpb24gdHJhbnNsYXRpb24gYXMgcGFydCBvZiBlbmNhcHN1 bGF0aW9uLg0KPiA+ID4+ID4gU28gZm9yIElQdjg6DQo+ID4gPj4gPg0KPiA+ID4+ID4gMHgxMDAw LT4weDAxMDEgb24gZW5jYXBzdWxhdGlvbg0KPiA+ID4+ID4gMHgwMTAxLT4weDEwMDAgb24gZGVj YXBzdWFsdGlvbg0KPiA+ID4gQW5kIHdoYXQgaGFwcGVucyB0byAweDAxMDEgV0hFTiBpdCBzaG93 cyB1cD8NCj4gPiA+DQo+ID4gPiBZb3UgbmVlZCBtb3JlIHBhdHRlcm5zIHRoYW4geW91IGhhdmUg YmVjYXVzZSBJUCBpcyBhbGxvd2VkIHRvIHVzZSBhbnkNCj4gPiA+IG9mIHRoZW0uDQo+ID4NCj4g PiBGV0lXLCB5b3UncmUgZXNzZW50aWFsbHkgYXJndWluZyBmb3IgYml0LXN0dWZmaW5nLCBpLmUu LCBpZiBhIHBhdHRlcm4geW91IHRoaW5rIHdpbGwNCj4gPiBiZSBjb21tb24gc2hvd3MgdXAsIGRv bid0IHN0dWZmLCBhbmQgaWYgc29tZXRoaW5nIGVsc2Ugc2hvd3MgdXAsIHRoZW4gZG8uDQo+ID4N Cj4gPiBUaGF0IHdvcmtzIG9ubHkgaWYgeW91IGRvIHRydWUgc3R1ZmZpbmcsIGUuZy4sOg0KPiA+ DQo+ID4gCTB4MDEqKiA9IHVuY29tcHJlc3NlZA0KPiA+IChtaWdodCBhcyB3ZWxsIGFkZCAweDEx KiogYW5kIDB4MTAqKiB0byB0aGF0KQ0KPiA+IAkweDAwKiogPSBjb21wcmVzc2VkDQo+ID4NCj4g PiBCdXQgdGhlbiBpZiAweDAwMDAsIDB4MDAwMSwgMHgwMDEwIG9yIDB4MDAxMSBzaG93IHVwLCB5 b3UgbmVlZCB0byBkZWNpZGUNCj4gPiBob3cgdG8gcmVwcmVzZW50IHRoZW0gLSB0aGV5IENBTk5P VCBiZSB1bmNvbXByZXNzZWQgd2l0aG91dCBhdCBsZWFzdCB0d28NCj4gPiBtb3JlIGJpdHMgc29t ZXdoZXJlIGVsc2UgdGhhdCBpbmRpY2F0ZXMgdGhleSdyZSB1bmNvbXByZXNzZWQgYW5kIHRoZWly IHZhbHVlLg0KPiA+DQo+ID4gU28gbm93IHlvdXIgR1VFIG1ldGhvZHMgYXJlIHZlcnkgc2Vuc2l0 aXZlIHRvIElQIHZlcnNpb24gbnVtYmVycywgd2hpY2ggSU1PDQo+ID4gZGVmZWF0cyB0aGUgIkci IGluIHRoZSBuYW1lLiBOZXZlciBtaW5kIGhvdyB0aGlzIGNvbXBsaWNhdGVzIGhhcmR3YXJlIHdo ZW4NCj4gDQo+IEFncmVlLiBBcyBJIGhhZCBtZW50aW9uZWQgdG8gVG9tIGluIHByaXZhdGUsIEkg ZG8gYmVsaWV2ZSB0aGUgYWRkaXRpb25hbCBjYXBhYmlsaXR5IG9mIEdVRSAoZS5nLiwgZnJhZ21l bnRhdGlvbikgd291bGQgYmUgbXVjaCB1c2VmdWwNCj4gaW4gc29tZSBuZXR3b3JrIGVudmlyb25t ZW50cy4gSG93ZXZlciwgc2luY2UgR1VFIGlzIGludGVuZGVkIHRvIGJlIGEgZ2VuZXJpYyBVRFAg ZW5jYXBzdWxhdGlvbiBhcHByb2FjaCwgd2UnZCBiZXR0ZXIgZGVzaWduIGl0IGFzDQo+IGdlbmVy aWMgYW5kIGZ1dHVyZS1wcm9vZiBhcyBwb3NzaWJsZSBmcm9tIHRoZSBiZWdpbm5pbmcsIHNwZWNp ZmljYWxseSBzcGVha2luZywgd2l0aG91dCBiZWluZyBkZWVwbHkgaW5mbHVlbmNlZCBieSBhIHBh cnRpY3VsYXIgR1VFDQo+IHBheWxvYWQgdHlwZS4gSWYgYm90aCBmb28taW4tR1VFIChmb28gY291 bGQgYmUgTlNILCBUUklMTC4uLikgYW5kIGZvby1pbi1VRFAgKGkuZS4sIGEgY29tcGFjdCB2ZXJz aW9uIG9mIGZvby1pbi1HVUUpIGFyZSBuZWVkZWQNCj4gc29tZWRheSwgY291bGQgeW91IHN0aWxs IGFjaGlldmUgdGhlIHNhbWUgZWZmZWN0IGFzIHRoYXQgZm9yIElQLWluLVVEUCAoYXMgYSBjb21w YWN0IElQLWluLUdVRSkgYW5kIElQLWluLUdVRT8NCg0KSSBkb24ndCBnZXQgd2h5IHdlIGFyZSBz dGlsbCB0YWxraW5nIGFib3V0IHRoaXMuIFdlIGhhdmUgYWxyZWFkeSBzaG93biBob3cNCklQLWlu LVVEUCBjYW4gYmUgcHJvcGVybHkgYWNjb21tb2RhdGVkIGJ5IEdVRSB3aXRoIGhlYWRlciBjb21w cmVzc2lvbi4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+ IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IA0KPiA+IChub3QgaWYpIG90aGVyIElQIHZlcnNp b25zIGFyZSB1c2VkIChmb3Igd2hhdGV2ZXIgcmVhc29uKS4NCj4gPg0KPiA+IEpvZQ0KPiA+DQo+ ID4NCg0K From nobody Wed May 6 11:16:39 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A471B2E0E; Wed, 6 May 2015 11:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 krMa5gej3LEl; Wed, 6 May 2015 11:16:29 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDD71B2E0B; Wed, 6 May 2015 11:16:28 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t46IFYjY010703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 May 2015 11:15:35 -0700 (PDT) Message-ID: <554A5A45.2040802@isi.edu> Date: Wed, 06 May 2015 11:15:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> <554931E2.5010101@isi.edu> <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> <55493D10.90609@isi.edu> <2134F8430051B64F815C691A62D9831832E5AFC1@XCH-BLV-504.nw.nos.boeing.com> <554942C0.4000601@isi.edu> <2134F8430051B64F815C691A62D9831832E5B040@XCH-BLV-504.nw.nos.boeing.com> <55495FF4.7000100@isi.edu> <2134F8430051B64F815C691A62D9831832E5B85B@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5B85B@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 18:16:33 -0000 On 5/6/2015 7:37 AM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 05, 2015 5:28 PM >> To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; trill@ietf.org >> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org >> Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip >> >> >> >> On 5/5/2015 3:43 PM, Templin, Fred L wrote: >>>> Then what you're saying is that the tunnel ingress - as an app - has >>>>> flows that are distinguishable by the net. That can happen with any >>>>> application. >>> >>> But, that's just it - when the original source does the probing the data >>> packets are always part of the same application - always. When the >>> tunnel ingress probes, it may be asked to encapsulate the data >>> pacekts of many applications. >> >> An "application" is a source of packets. >> >> At a tunnel, the ingress arriving packets are that source - they ARE the >> "application". >> >> To correlate flow IDs to behavior within that flow - i.e., to the user >> programs that generate the packets that arrive at the ingress - requires >> the ingress to somehow infer those flows, unless they're explicitly >> marked by the user applications. >> >> That's a known limitation of any tunnel ingress. It's equally true of >> the user application if there are four people using one application, and >> you want 'flow' to map back to an individual person. > > We are still not reaching. The concern is that if some tunneled packets > take a different network path than others then there is a chance that > the probes will take a different path than the data. The only way I know > to prevent that is to always set the Flow Label in the encapsulation > header to some fixed value (e.g., 0). You need to track ANY packet difference that could cause a path difference. That could include: - flow label - packet length - traffic class - next-header The only things that all tunneled packets have in common are source and destination address. ANY other field that varies is a potential source of path variance. By your logic, PLMTUD would never work at all, and PMTUD only ever tells you about a specific set of the above fields failing. Yes, if you want to avoid that issue, you need to minimize any differences that could affect path. But that's *already true for all uses of PLMTUD or PMTUD*. The point here is that assuming otherwise is the flaw. Joe From nobody Wed May 6 12:47:01 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF951B2E51; Wed, 6 May 2015 12:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 LQZ5_z-DRbxw; Wed, 6 May 2015 12:46:58 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7211A92B5; Wed, 6 May 2015 12:46:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t46JkvCG017194; Wed, 6 May 2015 14:46:57 -0500 Received: from XCH-BLV-508.nw.nos.boeing.com (xch-blv-508.nw.nos.boeing.com [130.247.25.198]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t46JkpDE017113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 May 2015 14:46:52 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-508.nw.nos.boeing.com ([169.254.8.162]) with mapi id 14.03.0235.001; Wed, 6 May 2015 12:46:51 -0700 From: "Templin, Fred L" To: Joe Touch , Dave Dolson , Xuxiaohu , Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQh3nJyhmZ+Lyhk0iSDo4t2tXKb51uY68A//+LwaCAAHsHAP//jdwwgACU9ACAAHdOQIAAsxiA//+gFXA= Date: Wed, 6 May 2015 19:46:50 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5BF0F@XCH-BLV-504.nw.nos.boeing.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <554904B8.9020504@isi.edu> <554931E2.5010101@isi.edu> <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> <55493D10.90609@isi.edu> <2134F8430051B64F815C691A62D9831832E5AFC1@XCH-BLV-504.nw.nos.boeing.com> <554942C0.4000601@isi.edu> <2134F8430051B64F815C691A62D9831832E5B040@XCH-BLV-504.nw.nos.boeing.com> <55495FF4.7000100@isi.edu> <2134F8430051B64F815C691A62D9831832E5B85B@XCH-BLV-504.nw.nos.boeing.com> <554A5A45.2040802@isi.edu> In-Reply-To: <554A5A45.2040802@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 19:47:00 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Wednesday, May 06, 2015 11:16 AM > To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; trill@ietf.o= rg > Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip >=20 >=20 >=20 > On 5/6/2015 7:37 AM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Tuesday, May 05, 2015 5:28 PM > >> To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; trill@iet= f.org > >> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org > >> Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-i= p > >> > >> > >> > >> On 5/5/2015 3:43 PM, Templin, Fred L wrote: > >>>> Then what you're saying is that the tunnel ingress - as an app - has > >>>>> flows that are distinguishable by the net. That can happen with any > >>>>> application. > >>> > >>> But, that's just it - when the original source does the probing the d= ata > >>> packets are always part of the same application - always. When the > >>> tunnel ingress probes, it may be asked to encapsulate the data > >>> pacekts of many applications. > >> > >> An "application" is a source of packets. > >> > >> At a tunnel, the ingress arriving packets are that source - they ARE t= he > >> "application". > >> > >> To correlate flow IDs to behavior within that flow - i.e., to the user > >> programs that generate the packets that arrive at the ingress - requir= es > >> the ingress to somehow infer those flows, unless they're explicitly > >> marked by the user applications. > >> > >> That's a known limitation of any tunnel ingress. It's equally true of > >> the user application if there are four people using one application, a= nd > >> you want 'flow' to map back to an individual person. > > > > We are still not reaching. The concern is that if some tunneled packets > > take a different network path than others then there is a chance that > > the probes will take a different path than the data. The only way I kno= w > > to prevent that is to always set the Flow Label in the encapsulation > > header to some fixed value (e.g., 0). >=20 > You need to track ANY packet difference that could cause a path > difference. That could include: > - flow label Right. > - packet length An Equal Cost Multipath algorithm that made forwarding decisions based on packet length would be difficult to probe. > - traffic class Traffic Class is in the same category as Flow Label - a single tunnel could be asked to carry multiple traffic classes, which might cause ECMP to select different paths for carrying tunneled traffic. This gets back to whether to copy the inner ToS codepoint into the outer header or not, and I think there were many RFCs that talk about this. > - next-header In this case, next header would be the same for all tunneled packets so no need for concern here. > The only things that all tunneled packets have in common are source and > destination address. and next-header. > ANY other field that varies is a potential source > of path variance. In which case, probes could take a different path than data, which is the whole point of concern. > By your logic, PLMTUD would never work at all, PLMTUD works because it is based on the actual data packets of the actual flow that is being sized. > and PMTUD only ever tells > you about a specific set of the above fields failing. PMTUD (when it works) will always converge to the minimum MTU of all paths that are part of the multipath. When it works, great; when it doesn't= , you need PLMTUD. > Yes, if you want to avoid that issue, you need to minimize any > differences that could affect path. But that's *already true for all > uses of PLMTUD or PMTUD*. Not true for PLMTUD and not applicable for PMTUD (see above). > The point here is that assuming otherwise is the flaw. The point for concern is to find a way to ensure that any path sizing probes sent by the tunnel ingress will follow the same path as the data packets, which may have come from many original flows and/or many original sources. I don't think we have yet figured out how to do that. Thanks - Fred fred.l.templin@boeing.com > Joe >=20 From nobody Wed May 6 18:10:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3491B300C; Wed, 6 May 2015 18:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 UHUXuGqp8j2C; Wed, 6 May 2015 18:10:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F551B3008; Wed, 6 May 2015 18:10:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSF53097; Thu, 07 May 2015 01:10:26 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 May 2015 02:10:25 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 7 May 2015 09:10:22 +0800 From: Xuxiaohu To: "Templin, Fred L" , Joe Touch , Tom Herbert Thread-Topic: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip Thread-Index: AQHQhDAYoLZIFwke90qEGncpXxc1v51nAPgAgAQl8XCAAFTXgIABIiUAgABaUYCAABwmAIAAAU+AgAAUpQCAAAMpgIAABfSAgAAF9wCAAAGigIAAC4GAgAAB94CAAPvFMIAAQgeAgAE2MzA= Date: Thu, 7 May 2015 01:10:22 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832AD90@NKGEML512-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com> <55491B47.4060400@isi.edu> <55491CED.5070505@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832ABC2@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5B87C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5B87C@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Donald Eastlake , "nvo3@ietf.org" , "int-area@ietf.org" , "sfc@ietf.org" , "trill@ietf.org" Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 01:10:32 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVGVtcGxpbiwgRnJlZCBM IFttYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBN YXkgMDYsIDIwMTUgMTA6MzkgUE0NCj4gVG86IFh1eGlhb2h1OyBKb2UgVG91Y2g7IFRvbSBIZXJi ZXJ0DQo+IENjOiBEb25hbGQgRWFzdGxha2U7IHRyaWxsQGlldGYub3JnOyBudm8zQGlldGYub3Jn OyBpbnQtYXJlYUBpZXRmLm9yZzsNCj4gc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbdHJp bGxdIEZ3ZDogTWFpbCByZWdhcmRpbmcgZHJhZnQtaWV0Zi10cmlsbC1vdmVyLWlwDQo+IA0KPiBI SSwNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBYdXhpYW9o dSBbbWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gU2VudDogVHVlc2RheSwgTWF5IDA1 LCAyMDE1IDc6NDcgUE0NCj4gPiBUbzogSm9lIFRvdWNoOyBUb20gSGVyYmVydDsgVGVtcGxpbiwg RnJlZCBMDQo+ID4gQ2M6IERvbmFsZCBFYXN0bGFrZTsgdHJpbGxAaWV0Zi5vcmc7IG52bzNAaWV0 Zi5vcmc7IGludC1hcmVhQGlldGYub3JnOw0KPiA+IHNmY0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6 IFJFOiBbdHJpbGxdIEZ3ZDogTWFpbCByZWdhcmRpbmcgZHJhZnQtaWV0Zi10cmlsbC1vdmVyLWlw DQo+ID4NCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g RnJvbTogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4gPiA+IFNlbnQ6IFdlZG5l c2RheSwgTWF5IDA2LCAyMDE1IDM6NDIgQU0NCj4gPiA+IFRvOiBUb20gSGVyYmVydDsgVGVtcGxp biwgRnJlZCBMDQo+ID4gPiBDYzogWHV4aWFvaHU7IERvbmFsZCBFYXN0bGFrZTsgdHJpbGxAaWV0 Zi5vcmc7IG52bzNAaWV0Zi5vcmc7DQo+ID4gPiBpbnQtYXJlYUBpZXRmLm9yZzsgc2ZjQGlldGYu b3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW3RyaWxsXSBGd2Q6IE1haWwgcmVnYXJkaW5nIGRyYWZ0 LWlldGYtdHJpbGwtb3Zlci1pcA0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gNS81LzIw MTUgMTI6MzQgUE0sIEpvZSBUb3VjaCB3cm90ZToNCj4gPiA+ID4+IE9yIGp1c3QgZGVmaW5lIGEg c2ltcGxlIHZlcnNpb24gdHJhbnNsYXRpb24gYXMgcGFydCBvZiBlbmNhcHN1bGF0aW9uLg0KPiA+ ID4gPj4gPiBTbyBmb3IgSVB2ODoNCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4gMHgxMDAwLT4weDAx MDEgb24gZW5jYXBzdWxhdGlvbg0KPiA+ID4gPj4gPiAweDAxMDEtPjB4MTAwMCBvbiBkZWNhcHN1 YWx0aW9uDQo+ID4gPiA+IEFuZCB3aGF0IGhhcHBlbnMgdG8gMHgwMTAxIFdIRU4gaXQgc2hvd3Mg dXA/DQo+ID4gPiA+DQo+ID4gPiA+IFlvdSBuZWVkIG1vcmUgcGF0dGVybnMgdGhhbiB5b3UgaGF2 ZSBiZWNhdXNlIElQIGlzIGFsbG93ZWQgdG8gdXNlDQo+ID4gPiA+IGFueSBvZiB0aGVtLg0KPiA+ ID4NCj4gPiA+IEZXSVcsIHlvdSdyZSBlc3NlbnRpYWxseSBhcmd1aW5nIGZvciBiaXQtc3R1ZmZp bmcsIGkuZS4sIGlmIGENCj4gPiA+IHBhdHRlcm4geW91IHRoaW5rIHdpbGwgYmUgY29tbW9uIHNo b3dzIHVwLCBkb24ndCBzdHVmZiwgYW5kIGlmIHNvbWV0aGluZw0KPiBlbHNlIHNob3dzIHVwLCB0 aGVuIGRvLg0KPiA+ID4NCj4gPiA+IFRoYXQgd29ya3Mgb25seSBpZiB5b3UgZG8gdHJ1ZSBzdHVm ZmluZywgZS5nLiw6DQo+ID4gPg0KPiA+ID4gCTB4MDEqKiA9IHVuY29tcHJlc3NlZA0KPiA+ID4g KG1pZ2h0IGFzIHdlbGwgYWRkIDB4MTEqKiBhbmQgMHgxMCoqIHRvIHRoYXQpDQo+ID4gPiAJMHgw MCoqID0gY29tcHJlc3NlZA0KPiA+ID4NCj4gPiA+IEJ1dCB0aGVuIGlmIDB4MDAwMCwgMHgwMDAx LCAweDAwMTAgb3IgMHgwMDExIHNob3cgdXAsIHlvdSBuZWVkIHRvDQo+ID4gPiBkZWNpZGUgaG93 IHRvIHJlcHJlc2VudCB0aGVtIC0gdGhleSBDQU5OT1QgYmUgdW5jb21wcmVzc2VkIHdpdGhvdXQN Cj4gPiA+IGF0IGxlYXN0IHR3byBtb3JlIGJpdHMgc29tZXdoZXJlIGVsc2UgdGhhdCBpbmRpY2F0 ZXMgdGhleSdyZSB1bmNvbXByZXNzZWQNCj4gYW5kIHRoZWlyIHZhbHVlLg0KPiA+ID4NCj4gPiA+ IFNvIG5vdyB5b3VyIEdVRSBtZXRob2RzIGFyZSB2ZXJ5IHNlbnNpdGl2ZSB0byBJUCB2ZXJzaW9u IG51bWJlcnMsDQo+ID4gPiB3aGljaCBJTU8gZGVmZWF0cyB0aGUgIkciIGluIHRoZSBuYW1lLiBO ZXZlciBtaW5kIGhvdyB0aGlzDQo+ID4gPiBjb21wbGljYXRlcyBoYXJkd2FyZSB3aGVuDQo+ID4N Cj4gPiBBZ3JlZS4gQXMgSSBoYWQgbWVudGlvbmVkIHRvIFRvbSBpbiBwcml2YXRlLCBJIGRvIGJl bGlldmUgdGhlDQo+ID4gYWRkaXRpb25hbCBjYXBhYmlsaXR5IG9mIEdVRSAoZS5nLiwgZnJhZ21l bnRhdGlvbikgd291bGQgYmUgbXVjaA0KPiA+IHVzZWZ1bCBpbiBzb21lIG5ldHdvcmsgZW52aXJv bm1lbnRzLiBIb3dldmVyLCBzaW5jZSBHVUUgaXMgaW50ZW5kZWQgdG8NCj4gPiBiZSBhIGdlbmVy aWMgVURQIGVuY2Fwc3VsYXRpb24gYXBwcm9hY2gsIHdlJ2QgYmV0dGVyIGRlc2lnbiBpdCBhcw0K PiA+IGdlbmVyaWMgYW5kIGZ1dHVyZS1wcm9vZiBhcyBwb3NzaWJsZSBmcm9tIHRoZSBiZWdpbm5p bmcsIHNwZWNpZmljYWxseSBzcGVha2luZywNCj4gd2l0aG91dCBiZWluZyBkZWVwbHkgaW5mbHVl bmNlZCBieSBhIHBhcnRpY3VsYXIgR1VFIHBheWxvYWQgdHlwZS4gSWYgYm90aA0KPiBmb28taW4t R1VFIChmb28gY291bGQgYmUgTlNILCBUUklMTC4uLikgYW5kIGZvby1pbi1VRFAgKGkuZS4sIGEg Y29tcGFjdCB2ZXJzaW9uDQo+IG9mIGZvby1pbi1HVUUpIGFyZSBuZWVkZWQgc29tZWRheSwgY291 bGQgeW91IHN0aWxsIGFjaGlldmUgdGhlIHNhbWUgZWZmZWN0IGFzDQo+IHRoYXQgZm9yIElQLWlu LVVEUCAoYXMgYSBjb21wYWN0IElQLWluLUdVRSkgYW5kIElQLWluLUdVRT8NCj4gDQo+IEkgZG9u J3QgZ2V0IHdoeSB3ZSBhcmUgc3RpbGwgdGFsa2luZyBhYm91dCB0aGlzLiBXZSBoYXZlIGFscmVh ZHkgc2hvd24gaG93DQo+IElQLWluLVVEUCBjYW4gYmUgcHJvcGVybHkgYWNjb21tb2RhdGVkIGJ5 IEdVRSB3aXRoIGhlYWRlciBjb21wcmVzc2lvbi4NCg0KU2hvdyB1cyBob3cgVFJJTEwtaW4tVURQ IGFuZCBOU0gtaW4tVURQIGNhbiBiZSBwcm9wZXJseSBhY2NvbW1vZGF0ZWQgYnkgR1VFIHdpdGgg aGVhZGVyIGNvbXByZXNzaW9uIGFzIHdlbGwuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+ IFRoYW5rcyAtIEZyZWQNCj4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiANCj4gPiBCZXN0 IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPiA+IChub3QgaWYpIG90aGVyIElQIHZlcnNp b25zIGFyZSB1c2VkIChmb3Igd2hhdGV2ZXIgcmVhc29uKS4NCj4gPiA+DQo+ID4gPiBKb2UNCj4g PiA+DQo+ID4gPg0KDQo= From nobody Sun May 10 06:58:51 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87821A90B1 for ; Sun, 10 May 2015 06:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.51 X-Spam-Level: X-Spam-Status: No, score=-13.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_BACKHAIR_17=1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 l8ALV2cMAJ23 for ; Sun, 10 May 2015 06:58:46 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE181A90B0 for ; Sun, 10 May 2015 06:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25112; q=dns/txt; s=iport; t=1431266326; x=1432475926; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XW2d1J5mHHZmV4G4j38nXBEhGFuyjbsIFbbFk1CtojQ=; b=bb99CrUxGw01ZA+pgXTAA3hm1Zw3UvrdgQ9XaBERRoHGN+Lf8tNeRoja yLIz5xGP7rTCtdHfqFbmQ0/bBJs3KKnILbHFlFZ+vzyGD+p7o3O7vCXcP XrwKgoYun6Gn1YynlG+KLb7GtY1Mcw7v2/oYBFYBjjsC7U0Weswgh+Lew g=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B+BAANY09V/5tdJa1UCIMPVF4GgxjAX2YJgU4BCYYFAoEWOBQBAQEBAQEBgQqEIAEBAQMBAQEBIARHCwUHBAIBCA4DAQMBAQEjBAMCAiEGCxQDBggCBA4FDg2HfAMKCA2zSY1cDYUSAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLOYJNgWEsJwQHBoJiL4EWBZAKgjOCBYE8hU2BVYEkhlaHbYMbg1UjYYEFVIE9b4FFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,401,1427760000"; d="asc'?scan'208,217";a="148788329" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 10 May 2015 13:58:45 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4ADwidX025650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 May 2015 13:58:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.248]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Sun, 10 May 2015 08:58:43 -0500 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Thread-Topic: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdAApPCeAAAQoioAAAVlpgAAPUiMAAAC2YwAAGk5JgAAIF2kABLFt7QA= Date: Sun, 10 May 2015 13:58:42 +0000 Message-ID: <1FF536D9-BA35-46A0-A2A5-98B886A10B11@cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> <7f6156f0085d41fb8c70e8bda7c06513@SEAEXCHMBX04.olympus.F5Net.com> <552EF9CE.30803@joelhalpern.com> <7944a7ecdeb744ff8154133adb75e348@SEAEXCHMBX04.olympus.F5Net.com> <8B3C1D7B-98C7-4379-9F58-7C4A3A0DF94B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.234.241] Content-Type: multipart/signed; boundary="Apple-Mail=_E536F0EA-7DDA-4591-83A2-8B25EA61CE5B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "Joel M. Halpern" , "sfc@ietf.org" , Ian Smith , Linda Dunbar Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 13:58:50 -0000 --Apple-Mail=_E536F0EA-7DDA-4591-83A2-8B25EA61CE5B Content-Type: multipart/alternative; boundary="Apple-Mail=_576B06E6-A122-420B-B92E-26FE1A8023F6" --Apple-Mail=_576B06E6-A122-420B-B92E-26FE1A8023F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alia, Ping, as requested :-) > On Apr 16, 2015, at 12:38 PM, Alia Atlas wrote: >=20 > Carlos, >=20 > Agreed as to the thread convergence. > I'm still woefully behind on review the SFC architecture and other = drafts. > I will try and get to it this week - but if not this week, it may sit = for 3 more weeks > due to vacation, work-travel (a couple days that week might be = possible), and > IESG/IAB retreat. Any progress on draft-ietf-sfc-architecture now that we are past the 3+ = extra weeks of wait? Thanks, =E2=80=94 Carlos. >=20 > Do keep pinging me. >=20 > Alia >=20 > On Thu, Apr 16, 2015 at 8:46 AM, Carlos Pignataro (cpignata) = > wrote: > Net-net, it seems this thread is converging on no change needed. >=20 > Alia, >=20 > What=E2=80=99s the status of your AD review of the SFC Architecture? >=20 > Thanks! >=20 > =E2=80=94 Carlos. >=20 > > On Apr 15, 2015, at 8:13 PM, Ian Smith wrote: > > > > I recall the conversation re: supporting full symmetry, and I get = that people want it and generally think I understand why they want it. > > > > I suppose I'm reading it to say that you MAY have symmetric flows, = and when you do they should look "like this", but they aren't a MUST = requirement of the architecture. Is that what you intended? > > > > If so, I have no issue with it as written, since that is how it is = actually done today. > > > > > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com = ] > > Sent: Wednesday, April 15, 2015 7:53 PM > > To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata) > > Cc: sfc@ietf.org ; 'Alia Atlas' > > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate = various ways of using "Classifier" to achieve SFC Symmetry > > > > I could live with this model for symmetry. I agree with you that it = reflects a common case. We were asked explicitly to include support for = full symmetry, which is generally simpler to handle as a specific case = rather than as a generalization of going through specific functions. > > There are mechanisms people would like to use that fit that model. > > > > Yours, > > Joel > > > > On 4/15/15 12:34 PM, Ian Smith wrote: > >> I think it is also fair to say that there are cases where the chain = itself is not symmetric, but a subset of that chain is. > >> > >> What I've found to be an effective way of looking situations like = this is to treat them as two separate flows - one in each direction (to = the internet & from the internet) and then converge the flows on the = nodes that expect them to be converged. > >> > >> This yields a design paradigm where there is no symmetry, only = persistent nodes where both directions of traffic MUST traverse and = nodes where both directions of traffic MAY traverse. This changes the = problem from one where a single full-duplex symmetry is required = (usually in excess of actuality) to one where two or more half-duplex = symmetries are called for, and it shifts the problem of state from a = wiring problem (or the arrangement of virtual wires) to a routing = problem. > >> > >> Concentrating on this routing problem, not the wiring problem, is = what I read the document to be suggesting is the way forward. > >> > >> When you talk of using controllers, this is implicitly what you're = talking about doing. So there isn't a symmetry problem in your example = of A > network > B, because there is implicitly B > network > A which = doesn't have to have the same value of "network". And in the case of = something like A > D > B, the implication is that the sequence is locked = in below routing in physical or virtual wiring domain so that there is = no choice but to go through D to get to B from A and the inverse. In = those cases, the implication is often that A =3D=3D B or that A and B = share some sort of state management methodology either explicitly (some = sort of distributed systems) or implicitly (because of link-flow = associations). > >> > >> Finally, I'd suggest that a FW, in this kind of scenario, probably = doesn't _need_ to be tracking connections, because either it is being = directed by a controller on a flow by flow basis, in which case there = are two rules in the rule set (in the case of A > network > B), or = because the network state is irrelevant because of a decision that was = made outside of its view before the flow gets to it (in the case of A > = D > B). The bottom line being that if you try to just pick up the = design patterns from an SFC-free network and use them in and SFC = network, the value that SFC adds on top of "Programmable, Elastic, = Virtualized, and Scalable Infrastructure with an API" is being lost. > >> > >> > >> > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org = ] On Behalf Of Linda Dunbar > >> Sent: Wednesday, April 15, 2015 11:55 AM > >> To: Joel M. Halpern; Carlos Pignataro (cpignata) > >> Cc: sfc@ietf.org ; 'Alia Atlas' > >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't = advocate > >> various ways of using "Classifier" to achieve SFC Symmetry > >> > >> Most likely classifiers at either end of the SFC domain don't even = know where the FW (that require bidirectional congruency) in the network = is and which instance of FW that packets will traverse. Bidirectional = congruency, if required, has to be at the SF instance level. > >> > >> Therefore, very complicated mechanisms and coordination are = required for a head-end Classifier (that has an embedded DPI engine) to = enforce bidirectional congruency of a Firewall deployed in the middle of = the network, and the complex mechanisms needed to collaborate with the = other end of Classifier. > >> > >> > >> Yes, it will make so much more sense to say: > >> > >> - symmetry "may be realized by multiple mechanisms", > >> - " The statement itself is needed to indicate that several = mechanism other folks want to use are also permitted by the = architecture.", and > >> - delete the description on Classifier based solutions > >> > >> Linda > >> > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com = ] > >> Sent: Wednesday, April 15, 2015 8:56 AM > >> To: Linda Dunbar; Carlos Pignataro (cpignata) > >> Cc: sfc@ietf.org ; 'Alia Atlas' > >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't = advocate > >> various ways of using "Classifier" to achieve SFC Symmetry > >> > >> I think your correction is backwards. It is true that the behavior = you describe is permitted, and may even be common. It is still true = that symmetry "may be realized ...". If this is a big deal, we could = add a note that control mechanisms may play a role in achieving = symmetry. I am not sure such a statement is needed, but I could live = with it. > >> > >> The statement itself is needed to indicate that several mechanissm = other folks want to use are also permitted by the archtiecture. > >> > >> Yours, > >> Joel > >> > >> On 4/14/15 7:15 PM, Linda Dunbar wrote: > >>> Joel and Carlos, > >>> > >>> Even though draft-ietf-sfc-architecture-07 is already in the = status > >>> of "request for publication", I hope you can make those simple > >>> changes suggested. > >>> > >>> The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 = different > >>> ways of using "Classifiers" to achieve SFC Symmetry. > >>> > >>> The definition of "Classifier" is "An element that performs > >>> Classification", which can be as simple as separating traffic = based > >>> on some matching criteria. > >>> > >>> For traffic between A<->network <-> B, the classifier for traffic > >>> from "A" -> "B" could be at the "network" port facing A; and the > >>> classifier for traffic from "B" -> "A" could be at the "network" = port facing B. > >>> Therefore, using "Classifier" to achieve symmetry can be > >>> cumbersome, as your list describing "stateful classifiers", = "cluster > >>> classifiers"; state exchanging among "classifiers", ... > >>> > >>> If a centralized SFC controller is deployed, classifiers at either > >>> direction don't have to be involved in symmetry decision. > >>> > >>> Therefore, it is not true at all that "Symmetry may be > >>> > >>> realized in several ways depending on the SFF and classifier > >>> > >>> functionality." > >>> > >>> Symmetry is realized in great deal by how SFP is constructed or = controlled. > >>> > >>> Since the sfc-architecture is not to advocate certain solutions, = this > >>> document shouldn't have the description on state exchanges among > >>> classifiers to achieve SFC symmetry, i.e. should delete the 4^th > >>> paragraph and the bullets after. > >>> > >>> Cheers, > >>> > >>> Linda > >>> > >>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc = > >>> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc = > >> >=20 >=20 --Apple-Mail=_576B06E6-A122-420B-B92E-26FE1A8023F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alia,

Ping, as requested :-)

On = Apr 16, 2015, at 12:38 PM, Alia Atlas <akatlas@gmail.com> = wrote:

Carlos,

Agreed as to the thread = convergence.
I'm still woefully behind on review = the SFC architecture and other drafts.
I will try = and get to it this week - but if not this week, it may sit for 3 more = weeks
due to vacation, work-travel (a couple days = that week might be possible), and
IESG/IAB = retreat.

Any = progress on draft-ietf-sfc-architecture now that we are past the 3+ = extra weeks of wait?

Thanks,

=E2=80=94= Carlos.


Do keep pinging me.

Alia

On Thu, = Apr 16, 2015 at 8:46 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Net-net, it seems this = thread is converging on no change needed.

Alia,

What=E2=80=99s the status of your AD review of the SFC Architecture?

Thanks!

=E2=80=94 Carlos.

> On Apr 15, 2015, at 8:13 PM, Ian Smith <I.Smith@F5.com> = wrote:
>
> I recall the conversation re: supporting full symmetry, and I get = that people want it and generally think I understand why they want = it.
>
> I suppose I'm reading it to say that you MAY have symmetric flows, = and when you do they should look "like this", but they aren't a MUST = requirement of the architecture.  Is that what you intended?
>
> If so, I have no issue with it as written, since that is how it is = actually done today.
>
>
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Wednesday, April 15, 2015 7:53 PM
> To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata)
> Cc: sfc@ietf.org; = 'Alia Atlas'
> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't = advocate various ways of using "Classifier" to achieve SFC Symmetry
>
> I could live with this model for symmetry.  I agree with you = that it reflects a common case.  We were asked explicitly to = include support for full symmetry, which is generally simpler to handle = as a specific case rather than as a generalization of going through = specific functions.
> There are mechanisms people would like to use that fit that = model.
>
> Yours,
> Joel
>
> On 4/15/15 12:34 PM, Ian Smith wrote:
>> I think it is also fair to say that there are cases where the = chain itself is not symmetric, but a subset of that chain is.
>>
>> What I've found to be an effective way of looking situations = like this is to treat them as two separate flows - one in each direction = (to the internet & from the internet) and then converge the flows on = the nodes that expect them to be converged.
>>
>> This yields a design paradigm where there is no symmetry, only = persistent nodes where both directions of traffic MUST traverse and = nodes where both directions of traffic MAY traverse.  This changes = the problem from one where a single full-duplex symmetry is required = (usually in excess of actuality) to one where two or more half-duplex = symmetries are called for, and it shifts the problem of state from a = wiring problem (or the arrangement of virtual wires) to a routing = problem.
>>
>> Concentrating on this routing problem, not the wiring problem, = is what I read the document to be suggesting is the way forward.
>>
>> When you talk of using controllers, this is implicitly what = you're talking about doing.  So there isn't a symmetry problem in = your example of   A > network > B, because there is = implicitly B > network > A which doesn't have to have the same = value of "network".    And in the case of something like A = > D > B, the implication is that the sequence is locked in below = routing in physical or virtual  wiring domain so that there is no = choice but to go through D to get to B from A and the inverse.  In = those cases, the implication is often that A =3D=3D B or that A and B = share some sort of state management methodology either explicitly (some = sort of distributed systems) or implicitly (because of link-flow = associations).
>>
>> Finally, I'd suggest that a FW, in this kind of scenario, = probably doesn't _need_ to be tracking connections, because either it is = being directed by a controller on a flow by flow basis, in which case = there are two rules in the rule set (in the case of A > network > = B), or because the network state is irrelevant because of a decision = that was made outside of its view before the flow gets to it (in the = case of A > D > B).  The bottom line being that if you try to = just pick up the design patterns from an SFC-free network and use them = in and SFC network, the value that SFC adds on top of "Programmable, = Elastic, Virtualized, and Scalable Infrastructure with an API" is being = lost.
>>
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar
>> Sent: Wednesday, April 15, 2015 11:55 AM
>> To: Joel M. Halpern; Carlos Pignataro (cpignata)
>> Cc: sfc@ietf.org; = 'Alia Atlas'
>> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't = advocate
>> various ways of using "Classifier" to achieve SFC Symmetry
>>
>> Most likely classifiers at either end of the SFC domain don't = even know where the FW (that require bidirectional congruency) in the = network is and which instance of FW that packets will traverse. = Bidirectional congruency, if required, has to be at the SF instance = level.
>>
>> Therefore, very complicated mechanisms and coordination are = required for a head-end Classifier (that has an embedded DPI engine) to = enforce bidirectional congruency of a Firewall deployed in the middle of = the network, and the complex mechanisms needed to collaborate with the = other end of Classifier.
>>
>>
>> Yes, it will make so much more sense to say:
>>
>>   - symmetry "may be realized by multiple = mechanisms",
>>   - " The statement itself is needed to indicate that = several mechanism other folks want to use are also permitted by the = architecture.", and
>>   - delete the description on Classifier based = solutions
>>
>> Linda
>>
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, April 15, 2015 8:56 AM
>> To: Linda Dunbar; Carlos Pignataro (cpignata)
>> Cc: sfc@ietf.org; = 'Alia Atlas'
>> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't = advocate
>> various ways of using "Classifier" to achieve SFC Symmetry
>>
>> I think your correction is backwards.  It is true that the = behavior you describe is permitted, and may even be common.  It is = still true that symmetry "may be realized ...".  If this is a big = deal, we could add a note that control mechanisms may play a role in = achieving symmetry.  I am not sure such a statement is needed, but = I could live with it.
>>
>> The statement itself is needed to indicate that several = mechanissm other folks want to use are also permitted by the = archtiecture.
>>
>> Yours,
>> Joel
>>
>> On 4/14/15 7:15 PM, Linda Dunbar wrote:
>>> Joel and Carlos,
>>>
>>> Even though draft-ietf-sfc-architecture-07 is already in = the status
>>> of "request for publication", I hope you can make those = simple
>>> changes suggested.
>>>
>>> The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 = different
>>> ways of using "Classifiers" to achieve SFC Symmetry.
>>>
>>> The definition of "Classifier" is "An element that = performs
>>> Classification", which can be as simple as separating = traffic based
>>> on some matching criteria.
>>>
>>> For traffic between  A<->network <-> B, = the classifier for traffic
>>> from "A" -> "B" could be at the "network" port facing A; = and the
>>> classifier for traffic from "B" -> "A" could be at the = "network" port facing B.
>>>   Therefore, using "Classifier" to achieve = symmetry can be
>>> cumbersome, as your list describing "stateful classifiers", = "cluster
>>> classifiers"; state exchanging among "classifiers", ...
>>>
>>> If a centralized SFC controller is deployed, classifiers at = either
>>> direction don't have to be involved in symmetry = decision.
>>>
>>> Therefore, it is not true at all that "Symmetry may be
>>>
>>> realized in several ways depending on the SFF and = classifier
>>>
>>> functionality."
>>>
>>> Symmetry is realized in great deal by how SFP is = constructed or controlled.
>>>
>>> Since the sfc-architecture is not to advocate certain = solutions, this
>>> document shouldn't have the description on state exchanges = among
>>> classifiers to achieve SFC symmetry, i.e. should delete the = 4^th
>>> paragraph and the bullets after.
>>>
>>> Cheers,
>>>
>>> Linda
>>>
>>>
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> sfc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>>



= --Apple-Mail=_576B06E6-A122-420B-B92E-26FE1A8023F6-- --Apple-Mail=_E536F0EA-7DDA-4591-83A2-8B25EA61CE5B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVPZBQACgkQtfDPGTp3USz+swCaAt6lGYruBC6pzsjueaxv6UEc LJEAn2vB6VGS5RBjH0dRIz3XsELGAPWA =hidS -----END PGP SIGNATURE----- --Apple-Mail=_E536F0EA-7DDA-4591-83A2-8B25EA61CE5B-- From nobody Mon May 11 07:56:14 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE70F1A8A9D for ; Mon, 11 May 2015 07:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 OrQrE9AFeMnL for ; Mon, 11 May 2015 07:56:10 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B131A8A92 for ; Mon, 11 May 2015 07:56:10 -0700 (PDT) Received: by oica37 with SMTP id a37so106312461oic.0 for ; Mon, 11 May 2015 07:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2Lg6GVINkOGPhdVrctbvOQyUqTPZnwaD5EDX+IiH734=; b=gnqKSMB6kyNCU+Ek+05jNfOIdrryOTsS49Ecs6ajZ1N8gouuGCEk32fbjDwhHJfaxw S8TPtrdrDZsd/3cKepT78X1zcm9hfzGaKOuWPi0+vwCD1ThZjGd8VEbqU5iaffWyGtJj f/2qxGAslRgP7Grf+R5c5pOR1FRJIwBmup+qyt9MSRnpj65eXcWf2Tk1K8LSFbaXj4AB AuFfKSkuOT0lPiZzdyu/GEZ/Is6hjHOE3p42kxaPAonmcGEkvPB6aBv9JnmTScsil9bI vIJhQN/nbpMFsJEuV2ov1tHKdpd6IrhF9zZIIOOj80cv6cOG4vxfjo+cOV5Wsa8YAB7A LmtQ== MIME-Version: 1.0 X-Received: by 10.60.78.232 with SMTP id e8mr8379902oex.24.1431356169642; Mon, 11 May 2015 07:56:09 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Mon, 11 May 2015 07:56:09 -0700 (PDT) Date: Mon, 11 May 2015 10:56:09 -0400 Message-ID: From: Alia Atlas To: draft-ietf-sfc-architecture@tools.ietf.org, "sfc@ietf.org" Content-Type: multipart/alternative; boundary=089e0111ba6809eac20515cf9473 Archived-At: Subject: [sfc] AD review of draft-ietf-sfc-architecture-07 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 14:56:11 -0000 --089e0111ba6809eac20515cf9473 Content-Type: text/plain; charset=UTF-8 As is usual, I have done my AD review of draft-ietf-sfc-architecture-07. I do apologize that it has taken so long due to other commitments. I found a couple minor issues that can be addresses while IETF Last Call happens and any issues from that are handled. I have scheduled this for the telechat on May 28. Please address all comments received before May 21, so that there is sufficient time for directorate reviews. Thank you all for the hard work. Minor Issues: 1) I found Figure 1 to be less than useful. It isn't clear that branching and rejoining can occur. It isn't clear to me what you are trying to show in the different SFC graphs. Could you, perhaps, say explicitly what each is showing? Perhaps it is: " In the first and second graphs, the chain, based on classification, can skip some of the SFs. In the third graph, the chain can revisit the same SF (7 in this example) twice." I think you are trying to explain more things, but what isn't clear to me. The point that there are branches and rejoining would be useful to illustrate, in my opinion. 2) In Sec 4.4: "Further, from a privacy perspective, an SFC Egress Node is required to ensure that any sensitive information added as part of SFC gets removed." Could you clarify that information may be sensitive due to network concerns or end-customer concerns & that issues of information exposure should also consider flow analysis? My high-level point is that this isn't information just sensitive to the infrastructure/network provider and that sensitive information can be derived. Nit: P.14 bullet 1: "Post-SF, the traffic is returned to the SFF, and if needed forwarded to another SF associated with that SFF." should be "and, if needed, is forwarded" Thanks, Alia --089e0111ba6809eac20515cf9473 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As is usual, I have done my AD review of draft-ietf-sfc-ar= chitecture-07.=C2=A0 I do apologize that it has taken so long due to other = commitments.=C2=A0 I found a couple minor issues that can be addresses whil= e IETF Last Call happens and any issues from that are handled.

I have scheduled this for the telechat on May 28.=C2=A0 Please addre= ss all comments received before May 21, so that there is sufficient time fo= r directorate reviews.

Thank you all for the hard = work.

Minor Issues:

1) I = found Figure 1 to be less than useful. =C2=A0 It isn't clear that branc= hing and rejoining can occur.=C2=A0 It isn't clear to me what you are t= rying to show in the different SFC graphs.=C2=A0 Could you, perhaps, say ex= plicitly what each is showing?=C2=A0 Perhaps it is:

" In the first and second graphs, the chain, based on classification= , can skip some of the SFs.=C2=A0 In the third graph, the chain can revisit= the same SF (7 in this example) twice." =C2=A0

I think you are trying to explain more things, but what isn't clear = to me.=C2=A0 The point that there are branches and rejoining would be usefu= l to illustrate, in my opinion.

2) In Sec 4.4: &qu= ot;Further, from a privacy=C2=A0perspective, an SFC Egress Node is required= to ensure that any=C2=A0sensitive information added as part of SFC gets re= moved." =C2=A0 Could you clarify that information may be sensitive due= to network concerns or end-customer concerns & that issues of informat= ion exposure should also consider flow analysis?=C2=A0 My high-level point = is that this isn't information just sensitive to the infrastructure/net= work provider and that sensitive information can be derived.

=
Nit:

P.14 bullet 1:=C2=A0"Post-SF,= =C2=A0the traffic is returned to the SFF, and if needed forwarded to
<= div>another SF associated with that SFF." =C2=A0should be "and, i= f needed, is forwarded"

Thanks,
Ali= a

--089e0111ba6809eac20515cf9473-- From nobody Mon May 11 10:35:49 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8511ACE47; Mon, 11 May 2015 10:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 VhcmkxQ--XJq; Mon, 11 May 2015 10:35:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6F51ACE4C; Mon, 11 May 2015 10:35:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150511173544.31603.73881.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 10:35:44 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] Last Call: (Service Function Chaining (SFC) Architecture) to Informational RFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 17:35:48 -0000 The IESG has received a request from the Service Function Chaining WG (sfc) to consider the following document: - 'Service Function Chaining (SFC) Architecture' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2315/ https://datatracker.ietf.org/ipr/2281/ https://datatracker.ietf.org/ipr/2283/ From nobody Tue May 12 07:43:46 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BC01B2DF6; Tue, 12 May 2015 07:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4sGAveuCXIRh; Tue, 12 May 2015 07:43:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A03551B2DF7; Tue, 12 May 2015 07:43:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150512144343.21331.36624.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 07:43:43 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-architecture-08.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 14:43:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining (SFC) Architecture Authors : Joel Halpern Carlos Pignataro Filename : draft-ietf-sfc-architecture-08.txt Pages : 28 Date : 2015-05-12 Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-architecture-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 12 08:58:13 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026861A89AC for ; Tue, 12 May 2015 08:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 6I4zoQ8NkbuN for ; Tue, 12 May 2015 08:58:10 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E78D1A8BC0 for ; Tue, 12 May 2015 08:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8482; q=dns/txt; s=iport; t=1431446290; x=1432655890; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=un4qocvMdEkQ/0eX2FKmHN7I6HrTjkBr32/J/f62xkg=; b=btqLKdoPc7P0ENWrz8n57j+9qOyCJzRX3yoyDKaQzl0r99fJGSTB4EtM c48yaiftVd1nUZv5Ib/yAzO3+W9x5EAMad5gFtprDAdT6gKZV8nEXelN0 2Jz7EuaEQN+ajR/dErdc58uwctmK6xaiEevRz7vvPx/+QrAfMXfhOqXUZ I=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfBQAwIlJV/4QNJK1cgw9UXgbEOYJHhgUCgTpMAQEBAQEBgQuEIAEBAQMBeQULAgEIDgQGLiERFw4CBA4FDogJAwoIDcRFDYR8AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLOYJNgjQEB4MXgRYFkBmCNIIKgT5dhHGBVYEkg16KdIMfg1Ujg3dvAYFEgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,415,1427760000"; d="asc'?scan'208,217";a="419094150" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 12 May 2015 15:58:09 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4CFw99p019113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 15:58:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.248]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 12 May 2015 10:58:08 -0500 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Thread-Topic: AD review of draft-ietf-sfc-architecture-07 Thread-Index: AQHQi/qlyrnmKKD5Ck+fFOWfr8JZ3Z141MOA Date: Tue, 12 May 2015 15:58:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.56] Content-Type: multipart/signed; boundary="Apple-Mail=_38B06873-0416-4A49-8E6D-FF924C2BF657"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-architecture@tools.ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] AD review of draft-ietf-sfc-architecture-07 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 15:58:12 -0000 --Apple-Mail=_38B06873-0416-4A49-8E6D-FF924C2BF657 Content-Type: multipart/alternative; boundary="Apple-Mail=_E95D4886-9987-41CC-B35C-581C4DF7AEA4" --Apple-Mail=_E95D4886-9987-41CC-B35C-581C4DF7AEA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Alia, Thanks for your review! Rev -08, which just posted, should address your comments. URL: = https://www.ietf.org/internet-drafts/draft-ietf-sfc-architecture-08.txt = Status: = https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ = Htmlized: = https://tools.ietf.org/html/draft-ietf-sfc-architecture-08 = Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-architecture-08 = Thanks! Carlos. > On May 11, 2015, at 10:56 AM, Alia Atlas wrote: >=20 > As is usual, I have done my AD review of = draft-ietf-sfc-architecture-07. I do apologize that it has taken so = long due to other commitments. I found a couple minor issues that can = be addresses while IETF Last Call happens and any issues from that are = handled. >=20 > I have scheduled this for the telechat on May 28. Please address all = comments received before May 21, so that there is sufficient time for = directorate reviews. >=20 > Thank you all for the hard work. >=20 > Minor Issues: >=20 > 1) I found Figure 1 to be less than useful. It isn't clear that = branching and rejoining can occur. It isn't clear to me what you are = trying to show in the different SFC graphs. Could you, perhaps, say = explicitly what each is showing? Perhaps it is: >=20 > " In the first and second graphs, the chain, based on classification, = can skip some of the SFs. In the third graph, the chain can revisit the = same SF (7 in this example) twice." >=20 > I think you are trying to explain more things, but what isn't clear to = me. The point that there are branches and rejoining would be useful to = illustrate, in my opinion. >=20 > 2) In Sec 4.4: "Further, from a privacy perspective, an SFC Egress = Node is required to ensure that any sensitive information added as part = of SFC gets removed." Could you clarify that information may be = sensitive due to network concerns or end-customer concerns & that issues = of information exposure should also consider flow analysis? My = high-level point is that this isn't information just sensitive to the = infrastructure/network provider and that sensitive information can be = derived. >=20 > Nit: >=20 > P.14 bullet 1: "Post-SF, the traffic is returned to the SFF, and if = needed forwarded to > another SF associated with that SFF." should be "and, if needed, is = forwarded" >=20 > Thanks, > Alia >=20 --Apple-Mail=_E95D4886-9987-41CC-B35C-581C4DF7AEA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, Alia,

Thanks for your review!

Rev -08, which just posted, should = address your comments.

URL: =            https://www.ietf.org/internet-drafts/draft-ietf-sfc-architectur= e-08.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
Htmlized:       https://tools.ietf.org/html/draft-ietf-sfc-architecture-08<= br class=3D"">Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-architecture= -08

Thanks!

Carlos.

On May 11, 2015, at 10:56 AM, = Alia Atlas <akatlas@gmail.com> wrote:

As is usual, I have done my AD = review of draft-ietf-sfc-architecture-07.  I do apologize that it = has taken so long due to other commitments.  I found a couple minor = issues that can be addresses while IETF Last Call happens and any issues = from that are handled.

I have scheduled this for the telechat on May 28.  = Please address all comments received before May 21, so that there is = sufficient time for directorate reviews.

Thank you all for the hard = work.

Minor = Issues:

1) I = found Figure 1 to be less than useful.   It isn't clear that = branching and rejoining can occur.  It isn't clear to me what you = are trying to show in the different SFC graphs.  Could you, = perhaps, say explicitly what each is showing?  Perhaps it = is:

" In the = first and second graphs, the chain, based on classification, can skip = some of the SFs.  In the third graph, the chain can revisit the = same SF (7 in this example) twice."  

I think you are trying to explain more = things, but what isn't clear to me.  The point that there are = branches and rejoining would be useful to illustrate, in my = opinion.

2) In = Sec 4.4: "Further, from a privacy perspective, an SFC Egress Node = is required to ensure that any sensitive information added as part = of SFC gets removed."   Could you clarify that information may be = sensitive due to network concerns or end-customer concerns & that = issues of information exposure should also consider flow analysis?  = My high-level point is that this isn't information just sensitive to the = infrastructure/network provider and that sensitive information can be = derived.

Nit:

P.14 bullet 1: "Post-SF, the traffic is returned to = the SFF, and if needed forwarded to
another SF = associated with that SFF."  should be "and, if needed, is = forwarded"

Thanks,
Alia


= --Apple-Mail=_E95D4886-9987-41CC-B35C-581C4DF7AEA4-- --Apple-Mail=_38B06873-0416-4A49-8E6D-FF924C2BF657 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVSFQIACgkQtfDPGTp3USx/FQCguu3YlNVOU7owafLYvHK5TbNr 6TsAnjmTTAtCz0lDNdXvpcBDPcMFPhGc =ZGxG -----END PGP SIGNATURE----- --Apple-Mail=_38B06873-0416-4A49-8E6D-FF924C2BF657-- From nobody Tue May 12 10:05:55 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4D61ACD0A for ; Tue, 12 May 2015 10:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 tDwHWvWz4Th3 for ; Tue, 12 May 2015 10:05:51 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6441ACD0F for ; Tue, 12 May 2015 10:05:26 -0700 (PDT) Received: by oica37 with SMTP id a37so11254170oic.0 for ; Tue, 12 May 2015 10:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qhYM0/0iwOdLaKZVAnoKjz1RiPWcYUhWnKqZxzXuaM0=; b=i5ZUlYpJ2sFeQp/kqX38h+Kr8+0dBNVLcj0j4x5xXNZYUt6zNpz96gIzT45RIWi2Hc gzICEXlqdmat30UqdiUUxR7kgpYiDO9l6gfZfdk8Yb60prZjqJzhTW6d0wg0+Lvbu0jM fZw2tVSuQTJvalBpLHBxWgofnRi/Fc40Iz8caR07X3brXc0MY3Sui1dYNTHgKZcghF3h BfFG2smoklWdMEl29dXYWJJ6tsEuSZb8D34sleSLgN+I5WaGdeYAgj0/BSujAGWb2czy 3x1CWS5yEwMKOsTW3RqSOXEoYAFj7xC8xe4I+WPZrsYKHl/JmEDzVNETnbnFcq8ZabIN zw2Q== MIME-Version: 1.0 X-Received: by 10.60.52.237 with SMTP id w13mr12752671oeo.58.1431450325632; Tue, 12 May 2015 10:05:25 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Tue, 12 May 2015 10:05:25 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Tue, 12 May 2015 10:05:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 May 2015 13:05:25 -0400 Message-ID: From: Alia Atlas To: Carlos Pignataro Content-Type: multipart/alternative; boundary=001a11333dd62c564a0515e58023 Archived-At: Cc: draft-ietf-sfc-architecture@tools.ietf.org, sfc@ietf.org Subject: Re: [sfc] AD review of draft-ietf-sfc-architecture-07 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 17:05:54 -0000 --001a11333dd62c564a0515e58023 Content-Type: text/plain; charset=UTF-8 Carlos, Thank you for the quick response and update. This looks good. Alia On May 12, 2015 11:58 AM, "Carlos Pignataro (cpignata)" wrote: > Hi, Alia, > > Thanks for your review! > > Rev -08, which just posted, should address your comments. > > URL: > https://www.ietf.org/internet-drafts/draft-ietf-sfc-architecture-08.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ > Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-architecture-08 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-08 > > Thanks! > > Carlos. > > On May 11, 2015, at 10:56 AM, Alia Atlas wrote: > > As is usual, I have done my AD review of draft-ietf-sfc-architecture-07. > I do apologize that it has taken so long due to other commitments. I found > a couple minor issues that can be addresses while IETF Last Call happens > and any issues from that are handled. > > I have scheduled this for the telechat on May 28. Please address all > comments received before May 21, so that there is sufficient time for > directorate reviews. > > Thank you all for the hard work. > > Minor Issues: > > 1) I found Figure 1 to be less than useful. It isn't clear that > branching and rejoining can occur. It isn't clear to me what you are > trying to show in the different SFC graphs. Could you, perhaps, say > explicitly what each is showing? Perhaps it is: > > " In the first and second graphs, the chain, based on classification, can > skip some of the SFs. In the third graph, the chain can revisit the same > SF (7 in this example) twice." > > I think you are trying to explain more things, but what isn't clear to > me. The point that there are branches and rejoining would be useful to > illustrate, in my opinion. > > 2) In Sec 4.4: "Further, from a privacy perspective, an SFC Egress Node is > required to ensure that any sensitive information added as part of SFC gets > removed." Could you clarify that information may be sensitive due to > network concerns or end-customer concerns & that issues of information > exposure should also consider flow analysis? My high-level point is that > this isn't information just sensitive to the infrastructure/network > provider and that sensitive information can be derived. > > Nit: > > P.14 bullet 1: "Post-SF, the traffic is returned to the SFF, and if needed > forwarded to > another SF associated with that SFF." should be "and, if needed, is > forwarded" > > Thanks, > Alia > > > --001a11333dd62c564a0515e58023 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Carlos,

Thank you for the quick response and update.=C2=A0=C2=A0 Thi= s looks good.

Alia

On May 12, 2015 11:58 AM, "Carlos Pignataro= (cpignata)" <cpignata@cisco.= com> wrote:
<= div style=3D"word-wrap:break-word">Hi, Alia,

Thanks for = your review!

Rev -08, which just posted, should ad= dress your comments.

URL: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https:= //www.ietf.org/internet-drafts/draft-ietf-sfc-architecture-08.txt
St= atus: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http= s://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
Htmlized: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/ht= ml/draft-ietf-sfc-architecture-08
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-sfc-architecture-08

=
Thanks!

Carlos.

On May 11, 2015, at 10:56 AM, Alia Atlas <akatlas@gmail.com> w= rote:

As is usual, I have done my AD review = of draft-ietf-sfc-architecture-07.=C2=A0 I do apologize that it has taken s= o long due to other commitments.=C2=A0 I found a couple minor issues that c= an be addresses while IETF Last Call happens and any issues from that are h= andled.

I have scheduled this for the telechat on May 28= .=C2=A0 Please address all comments received before May 21, so that there i= s sufficient time for directorate reviews.

Thank y= ou all for the hard work.

Minor Issues:
=
1) I found Figure 1 to be less than useful. =C2=A0 It isn= 9;t clear that branching and rejoining can occur.=C2=A0 It isn't clear = to me what you are trying to show in the different SFC graphs.=C2=A0 Could = you, perhaps, say explicitly what each is showing?=C2=A0 Perhaps it is:

" In the first and second graphs, the chain, bas= ed on classification, can skip some of the SFs.=C2=A0 In the third graph, t= he chain can revisit the same SF (7 in this example) twice." =C2=A0

I think you are trying to explain more things, but w= hat isn't clear to me.=C2=A0 The point that there are branches and rejo= ining would be useful to illustrate, in my opinion.

2) In Sec 4.4: "Further, from a privacy=C2=A0perspective, an SFC Egr= ess Node is required to ensure that any=C2=A0sensitive information added as= part of SFC gets removed." =C2=A0 Could you clarify that information = may be sensitive due to network concerns or end-customer concerns & tha= t issues of information exposure should also consider flow analysis?=C2=A0 = My high-level point is that this isn't information just sensitive to th= e infrastructure/network provider and that sensitive information can be der= ived.

Nit:

P.14 bullet 1:= =C2=A0"Post-SF,=C2=A0the traffic is returned to the SFF, and if needed= forwarded to
another SF associated with that SFF." =C2=A0sh= ould be "and, if needed, is forwarded"

T= hanks,
Alia


--001a11333dd62c564a0515e58023-- From nobody Thu May 14 05:09:19 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632C61B29C5 for ; Wed, 13 May 2015 16:49:11 -0700 (PDT) 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=unavailable 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 hIa6OzFxla3z for ; Wed, 13 May 2015 16:49:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED641B29BF for ; Wed, 13 May 2015 16:49:10 -0700 (PDT) Received: from localhost ([::1]:44196 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YsgOj-0001n1-T0; Wed, 13 May 2015 16:49:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, sunilvk@f5.com X-Trac-Project: sfc Date: Wed, 13 May 2015 23:49:09 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/11 Message-ID: <052.10d2d35f5eb6a03c2636410fd61e1b2a@tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, sunilvk@f5.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20150513234910.3ED641B29BF@ietfa.amsl.com> Resent-Date: Wed, 13 May 2015 16:49:10 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Thu, 14 May 2015 05:09:18 -0700 Cc: sfc@ietf.org Subject: [sfc] #11 (nsh): Mode bit for Metadata. X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 23:49:11 -0000 #11: Mode bit for Metadata. Ref: draft-quinn-sfc-nsh-07.txt, sections 3.4 and 3.5. In the Metadata Headers (Type 0x1 and 0x2), mode flags seem to be missing. The flags to hint nodes (such as Proxy and others) to: Append only mode and/or Donot Delete, Modify only modes for Metadata. -- ---------------------------+----------------------------------------------- Reporter: | Owner: draft-ietf-sfc-nsh@tools.ietf.org sunilvk@f5.com | Status: new Type: enhancement | Milestone: Priority: major | Version: Component: nsh | Keywords: Severity: - | ---------------------------+----------------------------------------------- Ticket URL: sfc From nobody Tue May 19 18:58:29 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DB01B2B2F for ; Tue, 19 May 2015 18:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 7nUZnaREmwfZ for ; Tue, 19 May 2015 18:58:27 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C649A1B2B2B for ; Tue, 19 May 2015 18:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3363; q=dns/txt; s=iport; t=1432087107; x=1433296707; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gA1aN967HA45uknQMYCWNnWzDDcoD6sGwo6oXp3om1I=; b=WgPP0qRHsZNn0Vk16LJIcCDJz+zHDOoF3HotAvkXsijlXLPEwpb/1J2M AJM+RwkfI2gWYm8WYnvLqiML0gyOjTitI2OcpH/d9Z9e+ERvENxzU/239 GCSJddMYFTuloFpnxmyvXsZXnu81k5pex7EGS0vh/tPdCtH5jCoy+Dz8d Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWBACJ6VtV/49dJa1cgxBUXgbFCQmBUAyFdAKBRjgUAQEBAQEBAYEKhCMBAQQBAQE3LQcLEAIBCBgeECcLJQIEAQ0FiCwNywoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqFBQeELQWLQYcrhDGGTYEnPoMrjieDWSNhgQWCEm8BgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,461,1427760000"; d="scan'208";a="309492" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP; 20 May 2015 01:58:11 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t4K1wBH9006812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 May 2015 01:58:11 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.198]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 19 May 2015 20:58:11 -0500 From: "Surendra Kumar (smkumar)" To: Thomas Narten , "Jim Guichard (jguichar)" , Benson Schliesser , "Jeff Tantsura" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAIAG1heAgADREICAADuJAIAhihCA Date: Wed, 20 May 2015 01:58:10 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <553F334D.2050907@queuefull.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.24.44.175] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Rajeev Manur , "Haeffner, Walter, Vodafone DE" , "Larry Kreeger \(kreeger\)" , Sumandra Majee , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 01:58:28 -0000 Dear Chairs, We submitted the draft on UDP transport for NSH (below) Although we strongly believe it belongs in SFC, we would be happy to present it in RTGWG or NVO3 as suggested by Jeff and Benson. Also, appreciate your consideration in getting a slot for this at Prague. Thanks, Surendra. ------- A new version of I-D, draft-kumar-sfc-nsh-udp-transport-00.txt has been successfully submitted by Surendra Kumar and posted to the IETF repository. Name: draft-kumar-sfc-nsh-udp-transport Revision: 00 Title: UDP Overlay Transport For Network Service Header Document date: 2015-05-16 Group: Individual Submission Pages: 9 URL: =20 https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-udp-transport-00.t xt Status: =20 https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-transport/ Htmlized: =20 https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transport-00 Abstract: This draft describes the transport encapsulation to carry Network Service Header (NSH) over UDP protocol. This enables applications and services using NSH to communicate over a simple layer-3 network without topological constraints. It brings down the barrier to implement overlay transports by not requiring additional overhead as is typical of overlay mechanisms designed on top of UDP. As a first benefit, this method eases the deployment of Service Function Chaining (SFC) by allowing SFC components to utilize the basic UDP/IP stack available in virtually all network elements and end systems to setup the overlays and realize SFCs. =20 =20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ------ On 4/28/15, 10:47 AM, "Surendra Kumar (smkumar)" wrote: >Thanks Benson, Larry! > >I will produce a draft for both the UDP port# and the ether-type and >publish it within SFC WG based on the comments so far. >The chairs can move it to the appropriate WG if they think otherwise. > >Surendra. > >On 4/28/15, 12:14 AM, "Benson Schliesser" wrote: > >>Hi, Larry and Jim - >> >>Larry Kreeger (kreeger) wrote: >>> If someone wanted to write a draft specifying how to carry NSH over >>> UDP, what WG would it be submitted to? >> >>As you probably know, NVO3 WG has adopted VXLAN-GPE which is an example >>of a NSH-capable transport. I think this is a good example of what Jim >>described as a "relevant WG for a given transport". >> >>But in the case of NSH carried directly in UDP, it seems to me that (as >>Larry described) this is normally described in the protocol document >>itself. Since NSH is intentionally flexible with regards to underlying >>transport, I can imagine this being a companion document rather than >>embedded in the NSH text. But in either case I think it makes the most >>sense for the SFC WG to be the home for such a definition. >> >>Cheers, >>-Benson >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Mon May 25 08:20:23 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C7B1A90A1 for ; Mon, 25 May 2015 08:20:20 -0700 (PDT) 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 Mp_qmGkA8wVp for ; Mon, 25 May 2015 08:20:16 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6C61A9090 for ; Mon, 25 May 2015 08:20:16 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 25 May 2015 11:20:14 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Mon, 25 May 2015 11:20:15 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-dolson-sfc-hierarchical-00.txt Thread-Index: AQHQlvzFBVlJgPSmuE+EUZZqr+r3pZ2My+wQ Date: Mon, 25 May 2015 15:20:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: New Version Notification for draft-dolson-sfc-hierarchical-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 15:20:21 -0000 R3JlZXRpbmdzLA0KDQpBZnRlciBwcmVzZW50aW5nIHRoaXMgY29uY2VwdCBvZiBIaWVyYXJjaGlj YWwgU2VydmljZSBDaGFpbmluZyBhdCBJRVRGOTIgaW4gRGFsbGFzLA0Kd2Ugd2VyZSBlbmNvdXJh Z2VkIHRvIGRlZGljYXRlIGEgZHJhZnQgdG8gdGhlIGNvbmNlcHQuIFdlIGhhdmUgbm93IGRvbmUg c28uDQoNClRoZXNlIGxpbmtzIGFyZSBhY3RpdmUgbm93Og0KDQpVUkw6ICAgICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRvbHNvbi1zZmMtaGllcmFy Y2hpY2FsLTAwLnR4dCANClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC8gDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2Fs LTAwIA0KDQpXZSB3ZWxjb21lIHlvdXIgZmVlZGJhY2suDQoNCg0KDQpEYXZpZCBEb2xzb24NClNl bmlvciBTb2Z0d2FyZSBBcmNoaXRlY3QsIFNhbmR2aW5lIEluYy4NCg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBNYXkgMjUsIDIwMTUgMTE6 MDkgQU0NClRvOiBTaHVuc3VrZSBIb21tYTsgRGllZ28gUi4gTG9wZXo7IERhdmUgRG9sc29uOyBE aWVnbyBMb3BlejsgRGF2ZSBEb2xzb247IFNodW5zdWtlIEhvbW1hDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTAwLnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNh bC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRGF2aWQgRG9sc29u IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1kb2xz b24tc2ZjLWhpZXJhcmNoaWNhbA0KUmV2aXNpb246CTAwDQpUaXRsZToJCUhpZXJhcmNoaWNhbCBT ZXJ2aWNlIENoYWluaW5nDQpEb2N1bWVudCBkYXRlOgkyMDE1LTA1LTI1DQpHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0w MC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDAJDQoNCg0K QWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG5ldHdvcmsgYXJjaGl0ZWN0 dXJlIGZvciBkZXBsb3lpbmcgc2VydmljZQ0KICAgZnVuY3Rpb24gY2hhaW5pbmcgd2l0aCBtdWx0 aXBsZSBsZXZlbHMgb2YgYWRtaW5pc3RyYXRpb24gd2l0aGluIGFuDQogICBvcmdhbml6YXRpb24u DQoNCiAgIFRoZSBtdWx0aXBsZSBsZXZlbHMgb2YgYWRtaW5pc3RyYXRpb24gYWxsb3cgb3BlcmF0 b3JzIHRvDQogICBjb21wYXJ0bWVudGFsaXplIGEgbGFyZ2UgbmV0d29yayBpbnRvIG11bHRpcGxl IGRvbWFpbnMgb2YNCiAgIHJlc3BvbnNpYmlsaXR5LCB3aXRoIGVhY2ggZG9tYWluIGJlaW5nIGlu ZGVwZW5kZW50bHkgbWFuYWdlZCBhbmQNCiAgIGNvbnNlcXVlbnRseSBlYXNpZXIgdG8gcmVhc29u IGFib3V0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue May 26 06:24:10 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197711B2CE1 for ; Tue, 26 May 2015 06:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 co_t5DO584oU for ; Tue, 26 May 2015 06:24:06 -0700 (PDT) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08D21B2D22 for ; Tue, 26 May 2015 06:23:40 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0224.002; Tue, 26 May 2015 06:23:39 -0700 From: Ron Parker To: Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-dolson-sfc-hierarchical-00.txt Thread-Index: AQHQlvzFBVlJgPSmuE+EUZZqr+r3pZ2My+wQgAFyP6A= Date: Tue, 26 May 2015 13:23:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] FW: New Version Notification for draft-dolson-sfc-hierarchical-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 13:24:08 -0000 Hi, Dave. I'm very supportive of the hierarchical approach you describe in this draft= . One comment regarding the flow-aware domain gateway. There are limitation= s to what is allowed within the the sub-domain under this approach. In pa= rticular, 5-tuple modification such as would happen with NAT is disallowed.= =20 Also, certain higher order service functions, such as those that terminate = HTTP may launch separate "sympathetic" flows -- on behalf of the original f= low but with a unique 5-tuple. The domain gateway would see "returning" p= ackets for which it has no flow knowledge. Treatment of "unrecognized" fl= ows seen from the subdomain should be covered in the draft. This HTTP termination also brings up another use case which I think is a po= werful but orthogonal application of hierarchical SFC that you may wish to = consider. If you were to couple a domain gateway, as you've described it,= with an HTTP terminating service function, then the subdomain could operat= e at the transaction level (i.e., sub-flow). For the very same HTTP-over= -TCP connection, one GET could visit a certain sequence of service function= s whereas the next (possibly pipelined) GET could visit a different sequenc= e of service functions. The domain gateway/HTTP terminator would not only= restore the higher domain SFC context, but reinsert the packets into the a= ppropriate side of the split-TCP connection that it manages. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, May 25, 2015 11:20 AM To: sfc@ietf.org Subject: [sfc] FW: New Version Notification for draft-dolson-sfc-hierarchic= al-00.txt Greetings, After presenting this concept of Hierarchical Service Chaining at IETF92 in= Dallas, we were encouraged to dedicate a draft to the concept. We have now= done so. These links are active now: URL: https://www.ietf.org/internet-drafts/draft-dolson-sfc-hiera= rchical-00.txt=20 Status: https://datatracker.ietf.org/doc/draft-dolson-sfc-hierarchi= cal/=20 Htmlized: https://tools.ietf.org/html/draft-dolson-sfc-hierarchical-0= 0=20 We welcome your feedback. David Dolson Senior Software Architect, Sandvine Inc. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, May 25, 2015 11:09 AM To: Shunsuke Homma; Diego R. Lopez; Dave Dolson; Diego Lopez; Dave Dolson; = Shunsuke Homma Subject: New Version Notification for draft-dolson-sfc-hierarchical-00.txt A new version of I-D, draft-dolson-sfc-hierarchical-00.txt has been successfully submitted by David Dolson and posted to the IETF repository. Name: draft-dolson-sfc-hierarchical Revision: 00 Title: Hierarchical Service Chaining Document date: 2015-05-25 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-dolson-sfc-hiera= rchical-00.txt Status: https://datatracker.ietf.org/doc/draft-dolson-sfc-hierarchi= cal/ Htmlized: https://tools.ietf.org/html/draft-dolson-sfc-hierarchical-0= 0=09 Abstract: This document describes a network architecture for deploying service function chaining with multiple levels of administration within an organization. The multiple levels of administration allow operators to compartmentalize a large network into multiple domains of responsibility, with each domain being independently managed and consequently easier to reason about. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue May 26 11:35:10 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A06D1B2FD6 for ; Tue, 26 May 2015 11:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 f6m7eMdJCXH6 for ; Tue, 26 May 2015 11:35:07 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id A00531B2F63 for ; Tue, 26 May 2015 11:35:07 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Tue, 26 May 2015 14:35:06 -0400 From: Dave Dolson To: Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-dolson-sfc-hierarchical-00.txt Thread-Index: AQHQl7cvGGAgeIW8WEurFYAv11mO3p2OhASA Date: Tue, 26 May 2015 18:35:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] FW: New Version Notification for draft-dolson-sfc-hierarchical-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 18:35:09 -0000 Ron, Thank you for taking the time to read it. You make some very good points. I will add your points about the limitations of the stateful approach to se= ction 3.1.1. State cannot be created by packets arriving from the lower-leve= l=20 chain; when state cannot be found for such packets, they MUST b= e=20 dropped. This stateful approach is limited to use with lower-level servi= ce=20 functions that retain the 5-tuple of the packet. This approach cannot be used with lower-level service functions that modify t= he 5-tuple (e.g., as done by a NAT) or otherwise create packets fo= r new 5-tuples other than those received (e.g., as an HTTP cache migh= t do to retrieve content on behalf of the original flow). In both ca= ses,=20 the fundamental problem is the inability to forward packets whe= n=20 state cannot be found for the packet 5-tuples. I'm not inclined to incorporate the HTTP gateway idea at this time, since I= think it requires the gateway to become a TCP endpoint, vs. just decapsula= ting/encapsulating/forwarding packets. -Dave -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Tuesday, May 26, 2015 9:24 AM To: Dave Dolson; sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-dolson-sfc-hierar= chical-00.txt Hi, Dave. I'm very supportive of the hierarchical approach you describe in this draft= . One comment regarding the flow-aware domain gateway. There are limitation= s to what is allowed within the the sub-domain under this approach. In pa= rticular, 5-tuple modification such as would happen with NAT is disallowed.= =20 Also, certain higher order service functions, such as those that terminate = HTTP may launch separate "sympathetic" flows -- on behalf of the original f= low but with a unique 5-tuple. The domain gateway would see "returning" p= ackets for which it has no flow knowledge. Treatment of "unrecognized" fl= ows seen from the subdomain should be covered in the draft. This HTTP termination also brings up another use case which I think is a po= werful but orthogonal application of hierarchical SFC that you may wish to = consider. If you were to couple a domain gateway, as you've described it,= with an HTTP terminating service function, then the subdomain could operat= e at the transaction level (i.e., sub-flow). For the very same HTTP-over= -TCP connection, one GET could visit a certain sequence of service function= s whereas the next (possibly pipelined) GET could visit a different sequenc= e of service functions. The domain gateway/HTTP terminator would not only= restore the higher domain SFC context, but reinsert the packets into the a= ppropriate side of the split-TCP connection that it manages. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, May 25, 2015 11:20 AM To: sfc@ietf.org Subject: [sfc] FW: New Version Notification for draft-dolson-sfc-hierarchic= al-00.txt Greetings, After presenting this concept of Hierarchical Service Chaining at IETF92 in= Dallas, we were encouraged to dedicate a draft to the concept. We have now= done so. These links are active now: URL: https://www.ietf.org/internet-drafts/draft-dolson-sfc-hiera= rchical-00.txt=20 Status: https://datatracker.ietf.org/doc/draft-dolson-sfc-hierarchi= cal/=20 Htmlized: https://tools.ietf.org/html/draft-dolson-sfc-hierarchical-0= 0=20 We welcome your feedback. David Dolson Senior Software Architect, Sandvine Inc. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, May 25, 2015 11:09 AM To: Shunsuke Homma; Diego R. Lopez; Dave Dolson; Diego Lopez; Dave Dolson; = Shunsuke Homma Subject: New Version Notification for draft-dolson-sfc-hierarchical-00.txt A new version of I-D, draft-dolson-sfc-hierarchical-00.txt has been successfully submitted by David Dolson and posted to the IETF repository. Name: draft-dolson-sfc-hierarchical Revision: 00 Title: Hierarchical Service Chaining Document date: 2015-05-25 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-dolson-sfc-hiera= rchical-00.txt Status: https://datatracker.ietf.org/doc/draft-dolson-sfc-hierarchi= cal/ Htmlized: https://tools.ietf.org/html/draft-dolson-sfc-hierarchical-0= 0=09 Abstract: This document describes a network architecture for deploying service function chaining with multiple levels of administration within an organization. The multiple levels of administration allow operators to compartmentalize a large network into multiple domains of responsibility, with each domain being independently managed and consequently easier to reason about. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed May 27 19:05:29 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E6E1B2B8E; Wed, 27 May 2015 19:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZL4Jc3ls1OuT; Wed, 27 May 2015 19:05:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9984A1AC3C1; Wed, 27 May 2015 19:05:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> Date: Wed, 27 May 2015 19:05:23 -0700 Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 02:05:25 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-sfc-architecture-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I want to talk about the intended status of this document: right now (-08) it is marked as Informational, but up to -06 it was intended to be on the Standards Track. Why did this change? [I looked at the archives, but couldn’t find a specific reason or discussion.] >From the Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. If this architecture is what ongoing standardization of SFC should be based on, then I think it should be on the Standards Track. There are already a number of drafts that intend to be on the standards track that are using this document as a normative reference [1], which makes sense based on the text above. Note that none of the drafts that use the document as a normative reference have been adopted by the WG, but the point is still the same: if the intent is for this document to be used as a base for future standardization, then I think it should belong in the standards track. I know that we can always add a downref exception, but why would that be necessary if this document is intended to be guide future standardization for SFC? OTOH, if the WG decided that this is just “an architecture†(vs. *the* architecture), and that is why the intended status changed in -07, then it should be made clear in the text. [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/referencedby/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a couple of other comments: 1. Section 1.1(Scope): “This document defines the architecture for Service Function Chaining (SFC) with minimum requirements on the physical topology of the network, as standardized in the IETF.†What is standardized, the physical topology? Confusing sentence. 2. Section 5.2 (SFC Control Plane): “This is part of the overall architecture but outside the scope of this document.†I don’t understand how the control plane, being part of the architecture, is not in scope of the architecture document..?? Especially since in this section there is a discussion of the functionality to be provided by the control plane. What am I missing? From nobody Wed May 27 19:44:18 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C132C1A0387; Wed, 27 May 2015 19:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 2nVpDNyKjwEm; Wed, 27 May 2015 19:44:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE391A0111; Wed, 27 May 2015 19:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6665; q=dns/txt; s=iport; t=1432781054; x=1433990654; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l8VikYMtreyhS1ICGGvn/Xnq9XofdA2LDWp/rFaAf88=; b=BGr2TNxB48ie7ytlozUSNS+dsnqgv2yn9NgUC21VqEsROn1bMqKe0I3p f3aCDrMUPwyfnPxO67kBkT5AhxW+pWZD1sg1LQzKeBvj2N/5DWawKxPci SDrCPh2/SsIZPraJpzGAbPr2ki8Zm5g2H/d8z/7zaSY9DG31Y18QEtlER s=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ATBACIgGZV/5FdJa1cgxBUUQ0Ggxi9ZGYJgVyFdQKBRjgUAQEBAQEBAYEKhCIBAQEDASNWBQsCAQgSBioCAjIXDgIEDgUOiBcIDa8TpA0BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs6hCIRAVECBYJoL4EWBYZrjB2CEoFDYIZagSmDcY48g1kjYYEpHBWBPW8BgQs6gQEBAQE X-IronPort-AV: E=Sophos; i="5.13,510,1427760000"; d="asc'?scan'208"; a="2397771" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 28 May 2015 02:44:13 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4S2iDMY001888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 02:44:13 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 27 May 2015 21:44:13 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" Thread-Topic: Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmOrEEsv6EGLzPU647i5P9hxl1Z2RAliA Date: Thu, 28 May 2015 02:44:12 +0000 Message-ID: References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> In-Reply-To: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.244.154] Content-Type: multipart/signed; boundary="Apple-Mail=_705B3C5E-A222-47F7-B5C5-AEA94BE68019"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 02:44:16 -0000 --Apple-Mail=_705B3C5E-A222-47F7-B5C5-AEA94BE68019 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Alvaro, Thanks for your review! Please see inline. > On May 27, 2015, at 10:05 PM, Alvaro Retana (aretana) = wrote: >=20 > Alvaro Retana has entered the following ballot position for > draft-ietf-sfc-architecture-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I want to talk about the intended status of this document: right now > (-08) it is marked as Informational, but up to -06 it was intended to = be > on the Standards Track. Why did this change? [I looked at the = archives, > but couldn=E2=80=99t find a specific reason or discussion.] Initially we (editors) thought STD was appropriate for the exact same = reasons you list below. For context, the question of the intended status arose when the chairs = were preparing the write up. An analysis of other architectures showed no definitive pattern, = although other working groups seemed to now be using Informational for = their architecture documents (e.g., I2RS, although 6tisch is targeting = STD) Thomas summarized the criteria as follows: =E2=80=9COne key test is "how would you advance the document up the = standards track and what would the interoperability tests be?=E2=80=9D = Some (not many) architecture documents do have protocol-like stuff in = them. I can't say this one does.=E2=80=9D And we changed it to Info before submitting to the IESG. Frankly, we take your guidance on this. Neither chairs, editors, or the = WG seemed hang up on either intended status =E2=80=94 please discuss it = and let us know. >=20 >> =46rom the Abstract: >=20 > This document describes an architecture for the specification, > creation, and ongoing maintenance of Service Function Chains (SFC) = in > a network. It includes architectural concepts, principles, and > components used in the construction of composite services through > deployment of SFCs, with a focus on those to be standardized in the > IETF. >=20 > If this architecture is what ongoing standardization of SFC should be > based on, then I think it should be on the Standards Track. There are > already a number of drafts that intend to be on the standards track = that > are using this document as a normative reference [1], which makes = sense > based on the text above. Note that none of the drafts that use the > document as a normative reference have been adopted by the WG, but the > point is still the same: if the intent is for this document to be used = as > a base for future standardization, then I think it should belong in = the > standards track. I know that we can always add a downref exception, = but > why would that be necessary if this document is intended to be guide > future standardization for SFC? >=20 > OTOH, if the WG decided that this is just =E2=80=9Can architecture=E2=80= =9D (vs. *the* > architecture), and that is why the intended status changed in -07, = then > it should be made clear in the text. >=20 > [1] > = https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/referencedby/= >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Just a couple of other comments: >=20 > 1. Section 1.1(Scope): =E2=80=9CThis document defines the architecture = for > Service Function Chaining (SFC) with minimum requirements on the = physical > topology of the network, as standardized in the IETF.=E2=80=9D What = is > standardized, the physical topology? Confusing sentence. Will fix =E2=80=94 thanks. >=20 > 2. Section 5.2 (SFC Control Plane): =E2=80=9CThis is part of the = overall > architecture but outside the scope of this document.=E2=80=9D I = don=E2=80=99t > understand how the control plane, being part of the architecture, is = not > in scope of the architecture document..?? Especially since in this > section there is a discussion of the functionality to be provided by = the > control plane. What am I missing? >=20 The WG agreement was that a detailed analysis of the control plane = mechanisms to set up SFCs was outside the scope. While we list = high-level CP functions, this document does not prescribe CP details. This said, I agree that the way that particular sentence reads seems = self-contradicting. Perhaps, something like this? The SFC Control Plane is part of the overall SFC architecture, and this section describes its high-level functions. However, the detailed definition of the SFC Control Plane is outside the scope of this document. Thanks, =E2=80=94 Carlos. >=20 --Apple-Mail=_705B3C5E-A222-47F7-B5C5-AEA94BE68019 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZoD9AAoJEIXgpQGOZny9gaUQAJmrq8amEbzR40DliJMaIlV1 vOH/12q2LGGvquSkU1v/Crpy6S7z7KWkydu8Yvv3bAdb7AWH8d1ZU5jioLNjr+Or 6Jb1jHOFGXNUZzcLjtDJqGYO3JVJOW4oMQh5bGYIwLIeA5B6mRt+RAZuabPhULvD ht+zu6wL8dMWOBWbkgJRat7UvWyDh+vQfHl70LKkqS9Yv64wv6Y79A7O1kibLAbo rfd3UfUKjYUViyfEfmN0do5/+erz8EKd3tAwx+N+zwRMJvqqZDEcUwbrjQhQS9Ec XMkOLiKNGOI7Z8CsBmUYcxEUK8gxjOdfJu0LXNnBH8Wp94pejA4UpVuOGMUBjPqS Lbg0WWDRacrQIt8dfmlS5ZMoto8NSiGf8gHEiCgXE5R4Tz8+/c+kV1/nuISDUhKu t4q7k82VhWE8g/3QOo/nFulZ8vOqmCqxmX4ZlJVrTnJamlL0W1HpRSxtaUZnp060 QTWC6LZo/opf74hM37sTPqB/OLPEPIFFqrgAHMtnHQUrcSYDPtLymWdZRuizG6Ro kiJdtdMh2sB4tvjQ8dPLKf1Q0Asr7GIdswjyVdtxh6SA6qZP0RKntl0JLef387pG 8zOM5WxD9JKT7R+tJCz+YkSKq2tIFvEz0BwCepK2bQOoVNH+WE4HRZJEzcC5Zquh zr1anBnqvpnfKuovnUsK =16du -----END PGP SIGNATURE----- --Apple-Mail=_705B3C5E-A222-47F7-B5C5-AEA94BE68019-- From nobody Wed May 27 19:55:07 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A741A19E4; Wed, 27 May 2015 19:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 oasP4rmoSNVQ; Wed, 27 May 2015 19:55:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662491A0AFE; Wed, 27 May 2015 19:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1125; q=dns/txt; s=iport; t=1432781702; x=1433991302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jouLlnr4C3+K2ldTFcKwwCF1PZGkeyQpwO8fLs/HmPs=; b=VrTnW54gfTBuyIkh+P1o+FCQkOIbYpvZugI3mNVkhOg/JRHfKDh3wGse PnvM0Pg2aQOTTw2PmxrARbYUWeuqwXX/aHUB1+nqI3EcY5ZGuiaUFThjH dO1yUkcK61MBYOd+r6CaDd9wAexe9T2WI0z6nfgpIbPZjjGljEOCcIpD0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALBQBqgmZV/5BdJa1cgxCBJQ0GyTwCgUZMAQEBAQEBgQuEIwEBBHkQAgEIEjQyFw4CBA4FiC3TLQEBAQEBAQEBAQEBAQEBAQEBAQEBGIs6hQUHhC0BBIwKhEKCPIsPly8jYYEpHBWBPW+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,510,1427760000"; d="scan'208";a="423202915" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP; 28 May 2015 02:55:01 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t4S2sxhp032316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 02:54:59 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.46]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 27 May 2015 21:54:59 -0500 From: "Alvaro Retana (aretana)" To: "Carlos Pignataro (cpignata)" Thread-Topic: Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmOrE2jQzr4zLR0e0cgVj7CwKup2RAlcA//+/5gA= Date: Thu, 28 May 2015 02:54:58 +0000 Message-ID: References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 02:55:02 -0000 On 5/27/15, 10:44 PM, "Carlos Pignataro (cpignata)" wrote: Carlos: Hi! >>2. Section 5.2 (SFC Control Plane): =B3This is part of the overall >>architecture but outside the scope of this document.=B2 I don=B9t >>understand how the control plane, being part of the architecture, is not >>in scope of the architecture document..?? Especially since in this >>section there is a discussion of the functionality to be provided by the >>control plane. What am I missing? > >The WG agreement was that a detailed analysis of the control plane >mechanisms to set up SFCs was outside the scope. While we list high-level >CP functions, this document does not prescribe CP details. > >This said, I agree that the way that particular sentence reads seems >self-contradicting. > >Perhaps, something like this? > > The SFC Control Plane is part of the overall SFC architecture, > and this section describes its high-level functions. However, the > detailed definition of the SFC Control Plane is outside the scope > of this document. That works for me. Thanks! Alvaro. From nobody Wed May 27 19:56:14 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE0B1A19EC; Wed, 27 May 2015 19:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Wjfnbz23bWB0; Wed, 27 May 2015 19:56:11 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469241A1A0C; Wed, 27 May 2015 19:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2588; q=dns/txt; s=iport; t=1432781770; x=1433991370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uT08/A2JDMWRC0Ij5LCnJPUpTWHKGMhK8PkZ9YLPmJE=; b=GGDSjUks2CWSGEyDj1QiL+LAhS2xnnmJObqCJqAnkXM+dlWm2i3IfsUe AHvXQx+cr2DkLzmgozehdYizF4LJDm/nMj5n6PPofjwut6baovou0U3HX Mqj8HmfWJTdgdNJsciyQm/txd88m9fvB9CfAcpEjVDLkAdkHE26qdCAuD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AnBQAyg2ZV/4YNJK1cgxCBJQ0Ggxi9ZG+HUQIcgSo6EgEBAQEBAQGBCoQiAQEBBDRFDAQCAQgRAQIBAgUoAgIwFwYIAgQOBYgtkg+dCQakDwEBAQEBAQEBAQEBAQEBAQEBAQEBGIEbih+EUjMHBoJcgUsBBJMIiw+XLyNhgSkcFYE9b4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,510,1427760000"; d="scan'208";a="154071072" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 28 May 2015 02:56:09 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4S2u9BD030356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 02:56:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 27 May 2015 21:56:09 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" Thread-Topic: Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmOrEEsv6EGLzPU647i5P9hxl1Z2RAliAgAADAQD//71EgA== Date: Thu, 28 May 2015 02:56:08 +0000 Message-ID: References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [10.82.244.154] Content-Type: text/plain; charset="euc-kr" Content-ID: <56EE8E8522CB8641AC12653789906658@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 02:56:12 -0000 VGhhbmtzIKGqIGNoYW5nZXMgbWFkZSBpbiBvdXIgd29ya2luZyBjb3B5Lg0KDQqhqiBDYXJsb3Mu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbHZhcm8gUmV0YW5hIDxhcmV0 YW5hQGNpc2NvLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgTWF5IDI3LCAyMDE1IGF0IDEwOjU0IFBN DQpUbzogQ2FybG9zIFBpZ25hdGFybyA8Y3BpZ25hdGFAY2lzY28uY29tPg0KQ2M6IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPiwgInNmYy1jaGFpcnNAaWV0Zi5vcmciIDxzZmMtY2hhaXJzQGlldGYu b3JnPiwNCkppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPiwNCiJkcmFmdC1pZXRmLXNm Yy1hcmNoaXRlY3R1cmUuYWRAaWV0Zi5vcmciDQo8ZHJhZnQtaWV0Zi1zZmMtYXJjaGl0ZWN0dXJl LmFkQGlldGYub3JnPiwNCiJkcmFmdC1pZXRmLXNmYy1hcmNoaXRlY3R1cmVAaWV0Zi5vcmciDQo8 ZHJhZnQtaWV0Zi1zZmMtYXJjaGl0ZWN0dXJlQGlldGYub3JnPiwNCiJkcmFmdC1pZXRmLXNmYy1h cmNoaXRlY3R1cmUuc2hlcGhlcmRAaWV0Zi5vcmciDQo8ZHJhZnQtaWV0Zi1zZmMtYXJjaGl0ZWN0 dXJlLnNoZXBoZXJkQGlldGYub3JnPiwgInNmY0BpZXRmLm9yZyINCjxzZmNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogQWx2YXJvIFJldGFuYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zZmMtYXJj aGl0ZWN0dXJlLTA4Og0KKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KPk9uIDUvMjcvMTUs IDEwOjQ0IFBNLCAiQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIiA8Y3BpZ25hdGFAY2lzY28u Y29tPg0KPndyb3RlOg0KPg0KPkNhcmxvczoNCj4NCj5IaSENCj4NCj4+PjIuIFNlY3Rpb24gNS4y IChTRkMgQ29udHJvbCBQbGFuZSk6IKn4VGhpcyBpcyBwYXJ0IG9mIHRoZSBvdmVyYWxsDQo+Pj5h cmNoaXRlY3R1cmUgYnV0IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuqfcgICBJ IGRvbqn2dA0KPj4+dW5kZXJzdGFuZCBob3cgdGhlIGNvbnRyb2wgcGxhbmUsIGJlaW5nIHBhcnQg b2YgdGhlIGFyY2hpdGVjdHVyZSwgaXMgbm90DQo+Pj5pbiBzY29wZSBvZiB0aGUgYXJjaGl0ZWN0 dXJlIGRvY3VtZW50Li4/PyAgIEVzcGVjaWFsbHkgc2luY2UgaW4gdGhpcw0KPj4+c2VjdGlvbiB0 aGVyZSBpcyBhIGRpc2N1c3Npb24gb2YgdGhlIGZ1bmN0aW9uYWxpdHkgdG8gYmUgcHJvdmlkZWQg YnkgdGhlDQo+Pj5jb250cm9sIHBsYW5lLiAgV2hhdCBhbSBJIG1pc3Npbmc/DQo+Pg0KPj5UaGUg V0cgYWdyZWVtZW50IHdhcyB0aGF0IGEgZGV0YWlsZWQgYW5hbHlzaXMgb2YgdGhlIGNvbnRyb2wg cGxhbmUNCj4+bWVjaGFuaXNtcyB0byBzZXQgdXAgU0ZDcyB3YXMgb3V0c2lkZSB0aGUgc2NvcGUu IFdoaWxlIHdlIGxpc3QgaGlnaC1sZXZlbA0KPj5DUCBmdW5jdGlvbnMsIHRoaXMgZG9jdW1lbnQg ZG9lcyBub3QgcHJlc2NyaWJlIENQIGRldGFpbHMuDQo+Pg0KPj5UaGlzIHNhaWQsIEkgYWdyZWUg dGhhdCB0aGUgd2F5IHRoYXQgcGFydGljdWxhciBzZW50ZW5jZSByZWFkcyBzZWVtcw0KPj5zZWxm LWNvbnRyYWRpY3RpbmcuDQo+Pg0KPj5QZXJoYXBzLCBzb21ldGhpbmcgbGlrZSB0aGlzPw0KPj4N Cj4+ICAgVGhlIFNGQyBDb250cm9sIFBsYW5lIGlzIHBhcnQgb2YgdGhlIG92ZXJhbGwgU0ZDIGFy Y2hpdGVjdHVyZSwNCj4+ICAgYW5kIHRoaXMgc2VjdGlvbiBkZXNjcmliZXMgaXRzIGhpZ2gtbGV2 ZWwgZnVuY3Rpb25zLiBIb3dldmVyLCB0aGUNCj4+ICAgZGV0YWlsZWQgZGVmaW5pdGlvbiBvZiB0 aGUgU0ZDIENvbnRyb2wgUGxhbmUgaXMgb3V0c2lkZSB0aGUgc2NvcGUNCj4+ICAgb2YgdGhpcyBk b2N1bWVudC4NCj4NCj5UaGF0IHdvcmtzIGZvciBtZS4NCj4NCj5UaGFua3MhDQo+DQo+QWx2YXJv Lg0KPg0KDQo= From nobody Wed May 27 21:14:16 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD3E1A897D; Wed, 27 May 2015 21:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 6V1tOV0Len03; Wed, 27 May 2015 21:14:06 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687071A1A4E; Wed, 27 May 2015 21:14:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0845624075F; Wed, 27 May 2015 21:14:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D51A72406AB; Wed, 27 May 2015 21:13:58 -0700 (PDT) Message-ID: <55669602.3050104@joelhalpern.com> Date: Thu, 28 May 2015 00:13:54 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Alvaro Retana (aretana)" , "Carlos Pignataro (cpignata)" References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 04:14:08 -0000 It is fine with me too. Yours, Joel On 5/27/15 10:54 PM, Alvaro Retana (aretana) wrote: > On 5/27/15, 10:44 PM, "Carlos Pignataro (cpignata)" > wrote: > > Carlos: > > Hi! > >>> 2. Section 5.2 (SFC Control Plane): ³This is part of the overall >>> architecture but outside the scope of this document.² I don¹t >>> understand how the control plane, being part of the architecture, is not >>> in scope of the architecture document..?? Especially since in this >>> section there is a discussion of the functionality to be provided by the >>> control plane. What am I missing? >> >> The WG agreement was that a detailed analysis of the control plane >> mechanisms to set up SFCs was outside the scope. While we list high-level >> CP functions, this document does not prescribe CP details. >> >> This said, I agree that the way that particular sentence reads seems >> self-contradicting. >> >> Perhaps, something like this? >> >> The SFC Control Plane is part of the overall SFC architecture, >> and this section describes its high-level functions. However, the >> detailed definition of the SFC Control Plane is outside the scope >> of this document. > > That works for me. > > Thanks! > > Alvaro. > > From nobody Thu May 28 05:53:04 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139121A92BC; Thu, 28 May 2015 05:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3] 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 1koG9hCNS4kx; Thu, 28 May 2015 05:52:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E84B1A9233; Thu, 28 May 2015 05:52:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 05:52:59 -0700 Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 12:53:02 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sfc-architecture-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I note the charter calls for this deliverable to "provide a description of... security models" The charter also generally notes that "The SFC WG will closely consider and address the management and security implications when documenting these deliverables." My conclusion is that this deliverable needs to reflect the results of a security analysis that the wg are suppoed to have carried out but that it's currently too vague only saying that solutions need to consider this. (Essentially this is a continuation of the mail threads from the secdir review [1] and a satisfactory resolution of that will probably resolve this.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html (2) Metadata that contains information that is protected in the data plane SHOULD be equally well protected when passed about by SFC. I hope that's acceptable and documented. I'm not sure myself if "passed about" ought also include within a device but maybe it should really. But at minimum, I do think you need to define confidentiality and origin authentication services for SFC metadata and/or for the SFC encapsulation as a whole. And I think this architecture document needs to say that those services have to be well-defined as part of any solution. (And I am not saying that this draft needs to define how to do those.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - It occurs to me that it might really be better for the WG to not publish this as an RFC now, but rather to put it on hold until they've made progress on the solutions. Perhaps revistiting this when the solutions are just at WGLC would result in the eventual RFC being a much more useful document. I think this one has to hedge so many bets that it's quite vague and won't be very useful even in the medium term. But that's just a suggestion, I can see why the WG might prefer to push this out, even if that might only give the appearance of progress and not reflect real progress. - While IPR on an architecture document is sad to see, esp with what seems like it may be restrictive licensing, I do see the wg debated that and decided to move on. - The charter text describing this deliverable notes that "The initial scope is restricted to a single administrative domain, keeping in mind that architectural decisions made for the intra-domain case may have implications for the inter-domain case." So I think there is also a currently missing analysis (or the results of that) as to how the single-domain elements of this architecture might impinge on a later inter-domain architecture. So the text at the end of section 1.1 appears to contradict the chartered goals. - Chains will require some representation, and re-ordering that is security sensitive (e.g. swap order of f/w and nat for fun) therefore there must be a requirement for some data integrity service and origin authentication and an authorisation decision function and therefore there must (istm) be a need for the architecture to define a chain producing entity of some kind that could be authenticated. That is an example of the missing security analysis that really is needed before this proceeds. (See my discuss point 2) - 1.1: "classified on ingress" and applicable to mobile networks are slightly incongrous. In the case of WiFi when do the packet ingress? (When it gets to the AP or leaves the mobile node transmitter?) I suspect you really mean the wired bits of a mobile network so it might be better to say that. - 1.2 should follow 1.3 I think. - 1.2: What does "chaining logic" mean? You say there's no standard chaining logic, which is maybe right, but then you imply that a fully ordered set of SF's is a well defined thing. I'm not sure that makes sense. Perhaps what you want to say is that the architecture doesn't determine if an SFC {{A,B},C} is or is not the same as {{B,A},C} but that later protocol work will have to do that. (In fact, I think you could say a lot more here and probably should.) - 1.2: what is a "chaining policy"? Isn't here where those terms need to be defined. - 1.3: SFC definition: by ordered do you mean fully or partially ordered? - 1.3: I'd omit LI as a SF - we won't be standardising that (cf. RFC2804) so better to not drag in the controversy really. Similarly, HOST_ID injection is not afaik any kind of standard and perhaps not likely to be (cf. some confict reviews on the same telechat as this) so I'd also drop that. And I think all of the exemplar SF's should really have a reference (ideally an RFC). - Figure 1 caption is misleading. That seems to me to show a set of paths through (one or more) graphs but doesn't show the full graphs themselves. - 2.2: The concept of a bi-directional SFC seems odd. Does the example given imply that all traffic (of what kind?) that followed SF1->SF2->SF3 on the way "in" must follow SF3->SF2->SF1 on the way "out"? If so, then I think more precision is needed really. The hybrid concept seems even odder to me. - 2.3: How can an SFP "be vague" - surely the point of an architecture is to avoid such vagueness? If you mean that an SFP representation can embody an if-statement then saying that would be the thing to do. - Section 3: I think there's maybe a missing principle here about not making security and privacy worse in general. - 4.1: I wonder if one could ever get enough SFC control traffic that congestion would be an issue? If so, should you say rather that any transport that has some way of handling congestion is ok. If not, then I guess the current text is fine. From nobody Thu May 28 06:11:33 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4BE1AC418; Thu, 28 May 2015 06:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6] 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 cDy85BIjIkOd; Thu, 28 May 2015 06:11:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D49BD1AC40A; Thu, 28 May 2015 06:11:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528131130.27173.8471.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 06:11:30 -0700 Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: [sfc] Benoit Claise's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:11:32 -0000 Benoit Claise has entered the following ballot position for draft-ietf-sfc-architecture-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- DISCUSS-DISCUSS: no action from the authors is expected at this point. This will be discussed during the telechat. - Can you explain this disconnect: >From the charter: It will produce an architecture for service function chaining that includes the necessary protocols or protocol extensions to convey the Service Function Chain and Service Function Path information to nodes that are involved in the implementation of service functions and Service Function Chains, as well as mechanisms for steering traffic through service functions. >From the abstract: This document does not propose solutions, protocols, or extensions to existing protocols. While I'm on the charter, I'm always available for this milestone: Apr 2014 Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Section 1.1 What does "minimum requirements on the physical topology"mean in: This document defines the architecture for Service Function Chaining (SFC) with minimum requirements on the physical topology of the network, as standardized in the IETF. It seems to me that "independent" is what you're after, like in: "it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities." or "This SFC architecture is predicated on topological independence from the underlying forwarding topology." - Service Function Path definition: I'm confused. you don't explain what it is, but only explain why you need it. Later on, I see "As an example of such an intermediate specificity, there may be two SFPs associated with a given SFC". I'm confused. Not too clear on how the SFP and RSP relate to each others. Is the Service Function Path the ordered list of SFs, while the RSP is the ordered list of SFFs? - "Traffic from SFs eventually returns to the same SFF, which is responsible for injecting traffic back onto the network. Am I correct that it only applies in case of a SFC proxy? Related question, along the same lines: 1. SFP forwarding : Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. Post-SF, the traffic is returned to the SFF, and, if needed, is forwarded to another SF associated with that SFF. If there is another non- local (i.e., different SFF) hop in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Returned to the initial SFF, or to the next SFF in the RSP? I guess the next SFF in the chain (again, unless we speak about a proxy) This would be consistent with section 5.4: "Due to the overlay constraints, the packet-forwarding path may need to visit the same SFF multiple times, and in some less common cases may even need to visit the same SF more than once." - Section 4.4 and 4.6: what about SFC-enabled domain and SFC proxy. In figure 3, the SFC proxy is inside the domain, right? But what about the SFC-unaware Service Function? Inside or outside? - 6. Service function chain independence: The creation, modification, or deletion of an SFC has no impact on other SFCs. The same is true for SFPs. Except if one SF depends on the shared metadata from a previous SF in the chain, right? Editorial. - OLD: SFC Proxy: Removes and inserts SFC encapsulation on behalf of an NEW: SFC Proxy: Removes and inserts SFC Encapsulation on behalf of an From nobody Thu May 28 06:24:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BB21A87E7; Thu, 28 May 2015 06:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 wB1jE9kEpkcw; Thu, 28 May 2015 06:24:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 869D71A8798; Thu, 28 May 2015 06:24:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 06:24:29 -0700 Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:24:31 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sfc-architecture-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I agree with Stephen's discuss and comment points and am just adding a few that I think are also important. 1. The Security Considerations section only talks about privacy of the SFC information for classification. The more important point may be the privacy of any data gathered from a payload used for the classification and this needs to be mentioned. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. For the Service Functions, I would think you would want to leave out "Lawful Intercept" as a device type since it's not a universal requirement on networks and immediately raises privacy concerns. 2. Section 3, #3 Classification on part of the packet payload will become increasingly more difficult as encryption is rolled out. The IETF and IAB both support the increased use of encryption for privacy and security purposes and are looking to have it end-to-end where possible. With the work out of TCPInc, encryption will be even more prevalent. From nobody Thu May 28 06:28:26 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94261AC41C; Thu, 28 May 2015 06:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nckKnMXD8aGZ; Thu, 28 May 2015 06:28:23 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF991AC41A; Thu, 28 May 2015 06:28:23 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so114106080igb.1; Thu, 28 May 2015 06:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=j7HD/temL9aFJ7CweidAR5ZM4Vh8zqe6oX1HlLg+gfo=; b=sVz55Y9h/ZDITKUvxjqR0i+AMmnUSr8on+t9rYl18wUm34pV1LhYyi/3O9fEnK4zBk Z5v40h/6JjzDC71IHEYw9yvWAvTmRJWArWjc2JH5RFsv9qPSZWkFEiRC8LeQk6d8P/9c PFzA3pS1KkxECmRIqSdQIowx+W0H7Rvm2koRgwQeQJsHHl6V+2wCygMT4F+1w+Hm8w80 xBDynsrawgA6uK0TVzIts32vTdz16ZD0GQIlwHf5WtYDRm5046DSOc64B8xMFzeq8ztB 7geM7GSw+NaVbjDNdBwG3CSyHoAZGaf4nuFJSIgecc79mIyCZaOnS3EzDe83KXkLspMs 5yUg== MIME-Version: 1.0 X-Received: by 10.107.138.31 with SMTP id m31mr3386427iod.75.1432819703170; Thu, 28 May 2015 06:28:23 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Thu, 28 May 2015 06:28:23 -0700 (PDT) In-Reply-To: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 09:28:23 -0400 X-Google-Sender-Auth: IverzSUo5gtBheZI3Wj-W-Uy4NY Message-ID: From: Barry Leiba To: Alvaro Retana Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org, "Jim Guichard \(jguichar\)" , The IESG , draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.ad@ietf.org Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:28:25 -0000 > If this architecture is what ongoing standardization of SFC should be > based on, then I think it should be on the Standards Track. I was thinking the same thing when I started to look at this document (I haven't finished, and won't have time to finish before the telechat). I agree with =C3=80lvaro in the general case: unlike, say, use cases, architecture on which Standards-Track protocols will be based should itself be Standards Track. Barry From nobody Thu May 28 06:33:29 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCDD1AC40A; Thu, 28 May 2015 06:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 dUdX4uIUwfrg; Thu, 28 May 2015 06:33:22 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B461A8775; Thu, 28 May 2015 06:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1981; q=dns/txt; s=iport; t=1432820001; x=1434029601; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0uiWEoeb5bMkPRvqs3lp8dB9WQemhVqac/9S4hITfT4=; b=TsSsOwPGPfAAl9TU8fCtOlmlAMJj9l+LxZfBer57jVBipI7vcDD9rYM9 DsmIcipMD22kK5FLn3cE6FN+2j7pN7t3rwyeqFNFf2CEkw7FFA4AJ3yyd aiHIkea3U5+Y+1jXVTNxIgG1PPLSK0cdQAmqnV8+Z3r1/r+9cvTiAmYl2 0=; X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="scan'208";a="500301580" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 28 May 2015 13:33:18 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4SDXIA0004060; Thu, 28 May 2015 13:33:18 GMT Message-ID: <5567191E.4010202@cisco.com> Date: Thu, 28 May 2015 15:33:18 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kathleen Moriarty , The IESG References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> In-Reply-To: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:33:24 -0000 Kathleen, > Kathleen Moriarty has entered the following ballot position for > draft-ietf-sfc-architecture-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I agree with Stephen's discuss and comment points and am just adding a > few that I think are also important. > > 1. The Security Considerations section only talks about privacy of the > SFC information for classification. The more important point may be the > privacy of any data gathered from a payload used for the classification > and this needs to be mentioned. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1. For the Service Functions, I would think you would want to leave out > "Lawful Intercept" as a device type since it's not a universal > requirement on networks and immediately raises privacy concerns. > > 2. Section 3, #3 > Classification on part of the packet payload will become increasingly > more difficult as encryption is rolled out. The IETF and IAB both > support the increased use of encryption for privacy and security purposes > and are looking to have it end-to-end where possible. With the work out > of TCPInc, encryption will be even more prevalent. And? Is this a valid reason not to mention it? Regards, Benoit > > > . > From nobody Thu May 28 06:37:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5201AC44D; Thu, 28 May 2015 06:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 UW8-ngSUFsW7; Thu, 28 May 2015 06:37:31 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8364A1AC41C; Thu, 28 May 2015 06:37:31 -0700 (PDT) Received: by obcnx10 with SMTP id nx10so27502558obc.2; Thu, 28 May 2015 06:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+9eCx/ddmXMTFI2KgRAfNCHeOrxYP9lwtl4MqG2TDOg=; b=iXXwLctIn7ZNn1dCTF18YJoQvX1dXtSilQZv2O23MSDfmH81W0xH/rbKfPrO6fRCCf 48eN9MciXDMkQ62vYLXJ3g81BQ8uZaSAI02GYOUITybZ4oMN7dfhaLQfA/mEpb4LCQKQ 7C0FHGZwz56zDWe0It3TF/Us6otMOQ/hhh+opZ0MmuLExC+IUYKcwSfK8RduaJbA0VOn p4KUGl78Eepld+zwJT/No1tIAWLw8gRqe+MMhGb9sJOFrmK36ZUMA+ers8L2u/1m7S44 ysXJAC65shlFGq59tTFhr3bl+/PtKUqnibSt0p4YEgrDUB9sHhS5HL7l2re+QgwyX95U Oxyg== MIME-Version: 1.0 X-Received: by 10.182.186.106 with SMTP id fj10mr2466354obc.54.1432820250923; Thu, 28 May 2015 06:37:30 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Thu, 28 May 2015 06:37:30 -0700 (PDT) In-Reply-To: References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 09:37:30 -0400 Message-ID: From: Alia Atlas To: Barry Leiba Content-Type: multipart/alternative; boundary=089e0149bbb01557c60517247630 Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.shepherd@ietf.org, "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.ad@ietf.org, Alvaro Retana , draft-ietf-sfc-architecture@ietf.org, The IESG Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:37:33 -0000 --089e0149bbb01557c60517247630 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't see anything specifically implementable in this architecture. I can't see how it could proceed from PS to IS. That isn't the case for all architecture docs, but for this one, I think that Informational is fine. I'm happy to discuss why you think otherwise. Alia On Thu, May 28, 2015 at 9:28 AM, Barry Leiba wrote: > > If this architecture is what ongoing standardization of SFC should be > > based on, then I think it should be on the Standards Track. > > I was thinking the same thing when I started to look at this document > (I haven't finished, and won't have time to finish before the > telechat). I agree with =C3=80lvaro in the general case: unlike, say, us= e > cases, architecture on which Standards-Track protocols will be based > should itself be Standards Track. > > Barry > --089e0149bbb01557c60517247630 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't see anything specifically implementable in thi= s architecture.=C2=A0 I can't see how it could proceed
from PS to I= S.=C2=A0 That isn't the case for all architecture docs, but for this on= e, I think that Informational
is fine.=C2=A0 I'm happy to dis= cuss why you think otherwise.

Alia

On Thu, May 28, 2015 = at 9:28 AM, Barry Leiba <barryleiba@computer.org> wrot= e:
> If this architec= ture is what ongoing standardization of SFC should be
> based on, then I think it should be on the Standards Track.

I was thinking the same thing when I started to look at this documen= t
(I haven't finished, and won't have time to finish before the
telechat).=C2=A0 I agree with =C3=80lvaro in the general case: unlike, say,= use
cases, architecture on which Standards-Track protocols will be based
should itself be Standards Track.

Barry

--089e0149bbb01557c60517247630-- From nobody Thu May 28 06:37:54 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF591AC44D; Thu, 28 May 2015 06:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 d7D9Ac5lXwie; Thu, 28 May 2015 06:37:42 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197C31AC428; Thu, 28 May 2015 06:37:42 -0700 (PDT) Received: by labko7 with SMTP id ko7so28343007lab.2; Thu, 28 May 2015 06:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y2IwIu1N6MgwUvr9deXtulQZXw9NJeUCsb1V8qLUbLA=; b=p8XdXDaZdHP4qmBlbSolDDk7o1T02fbkDfKVb0NfczyiTyZ+SoYYQ7GVwgnf3OE2t5 tMwFA4/q1VwraBiKJbrnC+QxsK21VfkYvwwWVWHQwhSNEMG3yxmYyyjjv5ho6KjEpddT 5Xu7cr/vz6NBBedLWyRECvXOceOTNoBsaZ85O2KFp1Xaj0YdyfUGgQuv8yh97x3SqBNI FqlDzAYt10LPgy+evwuOoCL+HDF0oMtbDWhAO9dIPkS9a+NpMwMI60/POtahkWRHThVE E0HHzyU0ZWopYwV7sPrkAvOmajTFjenQLJtvDMk2C/gqEiP3ICszv6r0rH2Hox1j1x0n UiUg== MIME-Version: 1.0 X-Received: by 10.152.4.72 with SMTP id i8mr2967778lai.32.1432820260613; Thu, 28 May 2015 06:37:40 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 28 May 2015 06:37:40 -0700 (PDT) In-Reply-To: <5567191E.4010202@cisco.com> References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <5567191E.4010202@cisco.com> Date: Thu, 28 May 2015 09:37:40 -0400 Message-ID: From: Kathleen Moriarty To: Benoit Claise Content-Type: multipart/alternative; boundary=089e01494248a932e50517247647 Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.shepherd@ietf.org, "Jim Guichard \(jguichar\)" , The IESG , draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.ad@ietf.org Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:37:45 -0000 --089e01494248a932e50517247647 Content-Type: text/plain; charset=UTF-8 On Thu, May 28, 2015 at 9:33 AM, Benoit Claise wrote: > Kathleen, > > Kathleen Moriarty has entered the following ballot position for >> draft-ietf-sfc-architecture-08: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I agree with Stephen's discuss and comment points and am just adding a >> few that I think are also important. >> >> 1. The Security Considerations section only talks about privacy of the >> SFC information for classification. The more important point may be the >> privacy of any data gathered from a payload used for the classification >> and this needs to be mentioned. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 1. For the Service Functions, I would think you would want to leave out >> "Lawful Intercept" as a device type since it's not a universal >> requirement on networks and immediately raises privacy concerns. >> >> 2. Section 3, #3 >> Classification on part of the packet payload will become increasingly >> more difficult as encryption is rolled out. The IETF and IAB both >> support the increased use of encryption for privacy and security purposes >> and are looking to have it end-to-end where possible. With the work out >> of TCPInc, encryption will be even more prevalent. >> > And? Is this a valid reason not to mention it? > Do you mean not to mention the privacy concerns? If so, no as we are not there yet and it will take years before we get to a state where this won't matter. There are too many protocols that we do not have answers for yet and then deployment of those that have been approved will also take time. There's too much of a gap, so the concern is valid and should be mentioned. Thanks, Kathleen > Regards, Benoit > >> >> >> . >> >> > -- Best regards, Kathleen --089e01494248a932e50517247647 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 28, 2015 at 9:33 AM, Benoit Claise <bclaise@cisco.com&= gt; wrote:
Kathleen,

Kathleen Moriarty has entered the following ballot position for
draft-ietf-sfc-architecture-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-cr= iteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-architectu= re/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I agree with Stephen's discuss and comment points and am just adding a<= br> few that I think are also important.

1. The Security Considerations section only talks about privacy of the
SFC information for classification.=C2=A0 The more important point may be t= he
privacy of any data gathered from a payload used for the classification
and this needs to be mentioned.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. For the Service Functions, I would think you would want to leave out
"Lawful Intercept" as a device type since it's not a universa= l
requirement on networks and immediately raises privacy concerns.

2. Section 3, #3
Classification on part of the packet payload will become increasingly
more difficult as encryption is rolled out.=C2=A0 The IETF and IAB both
support the increased use of encryption for privacy and security purposes and are looking to have it end-to-end where possible.=C2=A0 With the work o= ut
of TCPInc, encryption will be even more prevalent.
And? Is this a valid reason not to mention it?

Do you mean not to mention the privacy concerns?=C2=A0 If so, no as= we are not there yet and it will take years before we get to a state where= this won't matter.=C2=A0 There are too many protocols that we do not h= ave answers for yet and then deployment of those that have been approved wi= ll also take time.=C2=A0 There's too much of a gap, so the concern is v= alid and should be mentioned.

Thanks,
Ka= thleen


Regards, Benoit


.





--

Best regards,
Kath= leen
--089e01494248a932e50517247647-- From nobody Thu May 28 06:42:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A931ACC85; Thu, 28 May 2015 06:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 IXUTSbQ4gnQJ; Thu, 28 May 2015 06:42:35 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA0C1AC3BE; Thu, 28 May 2015 06:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10520; q=dns/txt; s=iport; t=1432820555; x=1434030155; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=EKFNXFLAs8metC0y1u+QnvTU/0IKwaX2hjuFtxSULLo=; b=HczgMJv1fe4vdMSW3Jih4a8GStaZUEazpWPEwAJhpDiTcEHk2ny0lhad zcMqd2+JIhom79s1NNFXOMOM+kvjBuLQbAsy8D61MhRDbYkhp6/EC1lfk MllnFNQ3XedLSoFUxEAFVyjPPd8cJqjoRnUnohVT06Ydd6znKn2Kc3VoB s=; X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="scan'208,217";a="493909563" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 28 May 2015 13:42:32 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4SDgWeL001391; Thu, 28 May 2015 13:42:32 GMT Message-ID: <55671B47.7030101@cisco.com> Date: Thu, 28 May 2015 15:42:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <5567191E.4010202@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050508010309080906010209" Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.shepherd@ietf.org, "Jim Guichard \(jguichar\)" , The IESG , draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.ad@ietf.org Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:42:38 -0000 This is a multi-part message in MIME format. --------------050508010309080906010209 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 28/05/2015 15:37, Kathleen Moriarty wrote: > > > On Thu, May 28, 2015 at 9:33 AM, Benoit Claise > wrote: > > Kathleen, > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-sfc-architecture-08: Discuss > > When responding, please keep the subject line intact and reply > to all > email addresses included in the To and CC lines. (Feel free to > cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found > here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I agree with Stephen's discuss and comment points and am just > adding a > few that I think are also important. > > 1. The Security Considerations section only talks about > privacy of the > SFC information for classification. The more important point > may be the > privacy of any data gathered from a payload used for the > classification > and this needs to be mentioned. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1. For the Service Functions, I would think you would want to > leave out > "Lawful Intercept" as a device type since it's not a universal > requirement on networks and immediately raises privacy concerns. > > 2. Section 3, #3 > Classification on part of the packet payload will become > increasingly > more difficult as encryption is rolled out. The IETF and IAB both > support the increased use of encryption for privacy and > security purposes > and are looking to have it end-to-end where possible. With > the work out > of TCPInc, encryption will be even more prevalent. > > And? Is this a valid reason not to mention it? > > > Do you mean not to mention the privacy concerns? No, "Classification on part of the packet payload". I agree that the privacy concerns must be mentioned. Maybe I misunderstood your comment that you wanted to remove the "Classification on part of the packet payload" from the draft. Regards, Benoit > If so, no as we are not there yet and it will take years before we get > to a state where this won't matter. There are too many protocols that > we do not have answers for yet and then deployment of those that have > been approved will also take time. There's too much of a gap, so the > concern is valid and should be mentioned. > > Thanks, > Kathleen > > > Regards, Benoit > > > > . > > > > > > -- > > Best regards, > Kathleen --------------050508010309080906010209 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 28/05/2015 15:37, Kathleen Moriarty wrote:


On Thu, May 28, 2015 at 9:33 AM, Benoit Claise <bclaise@cisco.com> wrote:
Kathleen,

Kathleen Moriarty has entered the following ballot position for
draft-ietf-sfc-architecture-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I agree with Stephen's discuss and comment points and am just adding a
few that I think are also important.

1. The Security Considerations section only talks about privacy of the
SFC information for classification.  The more important point may be the
privacy of any data gathered from a payload used for the classification
and this needs to be mentioned.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. For the Service Functions, I would think you would want to leave out
"Lawful Intercept" as a device type since it's not a universal
requirement on networks and immediately raises privacy concerns.

2. Section 3, #3
Classification on part of the packet payload will become increasingly
more difficult as encryption is rolled out.  The IETF and IAB both
support the increased use of encryption for privacy and security purposes
and are looking to have it end-to-end where possible.  With the work out
of TCPInc, encryption will be even more prevalent.
And? Is this a valid reason not to mention it?

Do you mean not to mention the privacy concerns?
No, "Classification on part of the packet payload". I agree that the privacy concerns must be mentioned.
Maybe I misunderstood your comment that you wanted to remove the "Classification on part of the packet payload" from the draft.

Regards, Benoit
If so, no as we are not there yet and it will take years before we get to a state where this won't matter.  There are too many protocols that we do not have answers for yet and then deployment of those that have been approved will also take time.  There's too much of a gap, so the concern is valid and should be mentioned.

Thanks,
Kathleen


Regards, Benoit


.





--

Best regards,
Kathleen

--------------050508010309080906010209-- From nobody Thu May 28 06:48:10 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290771A90D1; Thu, 28 May 2015 06:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 SQMEyFcPDwrI; Thu, 28 May 2015 06:48:06 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E371A890E; Thu, 28 May 2015 06:48:06 -0700 (PDT) Received: by laat2 with SMTP id t2so32249232laa.1; Thu, 28 May 2015 06:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5WXh4VpmUouQcZ6tda4uL6RXyLyCJE2U3q3N1frQol8=; b=dVYlYuxWmNSlETt0vbM5CnsoZz9vqtTqtNpj+V68/LH9MbHxe7uQUB/ujVvlubvw0Q cjT2LWvw3NGDXY0dDR85cH9ELXIsQvXb1TcFIvvd9MMko3Qrp0nvJ2u1oM0o2gaPzoqL G+3+qT7Ze0GfOIxqyf932qhKFlnn/b4PezN2j5ijUEb3mvkmGJYy7rpr/uwEvNK5eTJI HeWkk/ZGu+lj9BrctvKs9vGa7f0uNdnWl+WhOi7n9bJMQuvf3+lZR3gQitYLyuS2s+Ls kUMhHWNuA2ZlbDNLCY4xjiPkag1AioOAeWNib20HTfbAzt2GUFVKEr5XEDzNWuDqHxdN NKZA== MIME-Version: 1.0 X-Received: by 10.112.50.74 with SMTP id a10mr2938887lbo.4.1432820884672; Thu, 28 May 2015 06:48:04 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 28 May 2015 06:48:04 -0700 (PDT) In-Reply-To: <55671B47.7030101@cisco.com> References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <5567191E.4010202@cisco.com> <55671B47.7030101@cisco.com> Date: Thu, 28 May 2015 09:48:04 -0400 Message-ID: From: Kathleen Moriarty To: Benoit Claise Content-Type: multipart/alternative; boundary=001a1133bb46db98b70517249bba Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.shepherd@ietf.org, "Jim Guichard \(jguichar\)" , The IESG , draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.ad@ietf.org Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:48:09 -0000 --001a1133bb46db98b70517249bba Content-Type: text/plain; charset=UTF-8 On Thu, May 28, 2015 at 9:42 AM, Benoit Claise wrote: > On 28/05/2015 15:37, Kathleen Moriarty wrote: > > > > On Thu, May 28, 2015 at 9:33 AM, Benoit Claise wrote: > >> Kathleen, >> >> Kathleen Moriarty has entered the following ballot position for >>> draft-ietf-sfc-architecture-08: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I agree with Stephen's discuss and comment points and am just adding a >>> few that I think are also important. >>> >>> 1. The Security Considerations section only talks about privacy of the >>> SFC information for classification. The more important point may be the >>> privacy of any data gathered from a payload used for the classification >>> and this needs to be mentioned. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> 1. For the Service Functions, I would think you would want to leave out >>> "Lawful Intercept" as a device type since it's not a universal >>> requirement on networks and immediately raises privacy concerns. >>> >>> 2. Section 3, #3 >>> Classification on part of the packet payload will become increasingly >>> more difficult as encryption is rolled out. The IETF and IAB both >>> support the increased use of encryption for privacy and security purposes >>> and are looking to have it end-to-end where possible. With the work out >>> of TCPInc, encryption will be even more prevalent. >>> >> And? Is this a valid reason not to mention it? >> > > Do you mean not to mention the privacy concerns? > > No, "Classification on part of the packet payload". I agree that the > privacy concerns must be mentioned. > Maybe I misunderstood your comment that you wanted to remove the > "Classification on part of the packet payload" from the draft. > I just want the security consideration to be stated clearly, thanks. This functionality will go away in time. SPs are already having trouble with DLP solutions, so a warning is enough I think and is what is appropriate for the section (considerations). Thanks, Kathleen > > Regards, Benoit > > If so, no as we are not there yet and it will take years before we get > to a state where this won't matter. There are too many protocols that we > do not have answers for yet and then deployment of those that have been > approved will also take time. There's too much of a gap, so the concern is > valid and should be mentioned. > > Thanks, > Kathleen > > >> Regards, Benoit >> >>> >>> >>> . >>> >>> >> > > > -- > > Best regards, > Kathleen > > > -- Best regards, Kathleen --001a1133bb46db98b70517249bba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 28, 2015 at 9:42 AM, Benoit Claise <bclaise@cisco.com&= gt; wrote:
=20 =20 =20
On 28/05/2015 15:37, Kathleen Moriarty wrote:
=20


On Thu, May 28, 2015 at 9:33 AM, Benoit Claise <bclaise@cisco.com> wrote:
Kathleen,

Kathleen Moriarty has entered the following ballot position for
draft-ietf-sfc-architecture-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/= statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft= -ietf-sfc-architecture/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I agree with Stephen's discuss and comment points and am just adding a
few that I think are also important.

1. The Security Considerations section only talks about privacy of the
SFC information for classification.=C2=A0 The more important point may be the
privacy of any data gathered from a payload used for the classification
and this needs to be mentioned.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. For the Service Functions, I would think you would want to leave out
"Lawful Intercept" as a device type since it&= #39;s not a universal
requirement on networks and immediately raises privacy concerns.

2. Section 3, #3
Classification on part of the packet payload will become increasingly
more difficult as encryption is rolled out.=C2=A0 The IETF and IAB both
support the increased use of encryption for privacy and security purposes
and are looking to have it end-to-end where possible.=C2=A0 With the work out
of TCPInc, encryption will be even more prevalent.
And? Is this a valid reason not to mention it?

Do you mean not to mention the privacy concerns?
No, "Classification on part of the packet payload". I agree t= hat the privacy concerns must be mentioned.
Maybe I misunderstood your comment that you wanted to remove the "Classification on part of the packet payload" from the draft= .

I just want the security consid= eration to be stated clearly, thanks.=C2=A0 This functionality will go away= in time.=C2=A0 SPs are already having trouble with DLP solutions, so a war= ning is enough I think and is what is appropriate for the section (consider= ations).

Thanks,
Kathleen

=
=C2=A0

Regards, Benoit
If so, no as we are not there yet and it will take years before we get to a state where this won't matter.= =C2=A0 There are too many protocols that we do not have answers for yet and then deployment of those that have been approved will also take time.=C2=A0 There's too much of a= gap, so the concern is valid and should be mentioned.

Thanks,
Kathleen


Regards, Benoit


.





--

Best regards,
Kathleen




--

Best regards,
Kath= leen
--001a1133bb46db98b70517249bba-- From nobody Thu May 28 06:56:37 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7051A90D1; Thu, 28 May 2015 06:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfJZqNrCkpYj; Thu, 28 May 2015 06:56:34 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59A71A8A23; Thu, 28 May 2015 06:56:34 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so114855844igb.1; Thu, 28 May 2015 06:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qDCotUPPIRC50dvuYZa/ydZ45ZAEE4LUXmsHtqOFoAU=; b=mu0UtJudXpBxJyJb5x1ATLImQcikOdDAhjYZMFqQMNd2/qth564kY70y6xn1vCpjD6 gzO+WXV3j+dldic686s2m9Z823y6i/vkPKeVCathvVkLEQYyXSAS5u5DbisqW3W17JL4 Fq4si1GdahIhtfw6smlpLu8KhBblT3leH7+DsecXrVThnmslLrUXxj/4f0r6uAzgzNzh DUNTdt4LHiDDW+/3t9cn2oxE9dtW2sDJ3W7uRZJtsQrrmcfz7H0jl5+zbkZ37WK3WknX RZW1U2ZgNWSn9r73oQ8MJ+cTfNSjOi500XkzQvO7/Z56Ts8RX42vIQCD5rcVv/sqAcX9 wgPw== MIME-Version: 1.0 X-Received: by 10.107.137.210 with SMTP id t79mr3485392ioi.60.1432821394116; Thu, 28 May 2015 06:56:34 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Thu, 28 May 2015 06:56:34 -0700 (PDT) In-Reply-To: References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 09:56:34 -0400 X-Google-Sender-Auth: NelsX5q339mddX75k5eI8EXYap0 Message-ID: From: Barry Leiba To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.shepherd@ietf.org, The IESG , Alvaro Retana , draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.ad@ietf.org Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:56:35 -0000 > I don't see anything specifically implementable in this architecture. I > can't see how it could proceed > from PS to IS. That isn't the case for all architecture docs, but for this > one, I think that Informational is fine. I could see how the proposed architecture could be refined and eventually moved past "proposed", but that's not the main point I'm thinking about. For me, it's a question of the type of review Standards Track documents get ("Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?") as compared with Informational ("Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?"). We are proposing the former: building a significant part of the Internet infrastructure on this. Barry From nobody Thu May 28 06:58:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E25C1A889A; Thu, 28 May 2015 06:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoiDaZlhnAol; Thu, 28 May 2015 06:58:28 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770D11A7022; Thu, 28 May 2015 06:58:26 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so112310393igb.1; Thu, 28 May 2015 06:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kMA4ppQIZFdF20zDiKOUQe3poC+QmyezYSlvGQpTM9k=; b=bh1hagpWBKpC2SKlfX4YXO6L5AJUuNPB5uswvNmkF8ew1bXfH60f1aElouWVBNo3j1 pMIU/UqV/yeqoSjkiBkgdmzbfO1vZF3WOWL3FUChcgTDdHL4mMf7ybDeG/dFQuLxr/pb 3HIg4C5y73a24kCTYx1pT7ZMmJpW4Zt8xAQLADpjQGUVs7UD6kS5DGiJmwsVDYdpzLkm keQMv4Hm1KYFshlQasZH7HSs9oQaSkhON1ncS813MvmVNfb+sEOr9H21Uk4ZMrKOXlbW BNRhXs9sIvIdaXqJs+0T7+QM72ZQb/ofv1kgqp0xB2wBhna+X2augKlXRr2hk3hwC0fi qrRg== MIME-Version: 1.0 X-Received: by 10.107.25.199 with SMTP id 190mr3628584ioz.11.1432821505934; Thu, 28 May 2015 06:58:25 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Thu, 28 May 2015 06:58:25 -0700 (PDT) In-Reply-To: References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 09:58:25 -0400 X-Google-Sender-Auth: _5JVey65Zgw37eUbrS_T4_0ZpNw Message-ID: From: Barry Leiba To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.shepherd@ietf.org, The IESG , Alvaro Retana , draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.ad@ietf.org Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:58:30 -0000 >> I don't see anything specifically implementable in this architecture. I >> can't see how it could proceed >> from PS to IS. That isn't the case for all architecture docs, but for this >> one, I think that Informational is fine. > > I could see how the proposed architecture could be refined and > eventually moved past "proposed", but that's not the main point I'm > thinking about. For me, it's a question of the type of review > Standards Track documents get ("Is this document a reasonable basis on > which to build the salient part of the Internet infrastructure? If > not, what changes would make it so?") as compared with Informational > ("Is this document a reasonable contribution to the area of Internet > engineering which it covers? If not, what changes would make it so?"). > > We are proposing the former: building a significant part of the > Internet infrastructure on this. That said, I'll add that the IESG review does seem to be in line with the former already. Barry From nobody Thu May 28 07:03:46 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E571A8A25; Thu, 28 May 2015 07:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeTXougrUrFM; Thu, 28 May 2015 07:03:40 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDF21A8A23; Thu, 28 May 2015 07:03:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A73F72464B7; Thu, 28 May 2015 07:03:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 774AD2410FB; Thu, 28 May 2015 07:03:39 -0700 (PDT) Message-ID: <55672033.4000201@joelhalpern.com> Date: Thu, 28 May 2015 10:03:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> In-Reply-To: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:03:44 -0000 I am not sure what you mean by "Metadata that contains information that is protected in the data plane". Most of what ends up in the metadata is information that is passed on other interfaces directly to relevant functions, or locally determine and locally processed. The protection used for policy systems (which provide much of the information) is based on the presence of persistent connections and usage which crosses domains. Are you arguing that if AAA is encrypted then policy delivered by AAA resulting in metadata in the packet must be encrypted in the data packets? Yours, Joel On 5/28/15 8:52 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-sfc-architecture-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > (1) I note the charter calls for this deliverable to "provide > a description of... security models" The charter also > generally notes that "The SFC WG will closely consider and > address the management and security implications when > documenting these deliverables." My conclusion is that this > deliverable needs to reflect the results of a security > analysis that the wg are suppoed to have carried out but that > it's currently too vague only saying that solutions need to > consider this. (Essentially this is a continuation of the > mail threads from the secdir review [1] and a satisfactory > resolution of that will probably resolve this.) > > [1] > https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html > > (2) Metadata that contains information that is protected in > the data plane SHOULD be equally well protected when passed > about by SFC. I hope that's acceptable and documented. I'm > not sure myself if "passed about" ought also include within a > device but maybe it should really. But at minimum, I do > think you need to define confidentiality and origin > authentication services for SFC metadata and/or for the SFC > encapsulation as a whole. And I think this architecture > document needs to say that those services have to be > well-defined as part of any solution. (And I am not > saying that this draft needs to define how to do those.) > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - It occurs to me that it might really be better for the WG > to not publish this as an RFC now, but rather to put it on > hold until they've made progress on the solutions. Perhaps > revistiting this when the solutions are just at WGLC would > result in the eventual RFC being a much more useful document. > I think this one has to hedge so many bets that it's quite > vague and won't be very useful even in the medium term. But > that's just a suggestion, I can see why the WG might prefer > to push this out, even if that might only give the appearance > of progress and not reflect real progress. > > - While IPR on an architecture document is sad to see, esp > with what seems like it may be restrictive licensing, I do > see the wg debated that and decided to move on. > > - The charter text describing this deliverable notes that > "The initial scope is restricted to a single administrative > domain, keeping in mind that architectural decisions made for > the intra-domain case may have implications for the > inter-domain case." So I think there is also a currently > missing analysis (or the results of that) as to how the > single-domain elements of this architecture might impinge on > a later inter-domain architecture. So the text at the > end of section 1.1 appears to contradict the chartered > goals. > > - Chains will require some representation, and re-ordering > that is security sensitive (e.g. swap order of f/w and nat > for fun) therefore there must be a requirement for some data > integrity service and origin authentication and an > authorisation decision function and therefore there must > (istm) be a need for the architecture to define a chain > producing entity of some kind that could be authenticated. > That is an example of the missing security analysis that > really is needed before this proceeds. (See my discuss point > 2) > > - 1.1: "classified on ingress" and applicable to mobile > networks are slightly incongrous. In the case of WiFi when do > the packet ingress? (When it gets to the AP or leaves the > mobile node transmitter?) I suspect you really mean the wired > bits of a mobile network so it might be better to say that. > > - 1.2 should follow 1.3 I think. > > - 1.2: What does "chaining logic" mean? You say there's no > standard chaining logic, which is maybe right, but then you > imply that a fully ordered set of SF's is a well defined > thing. I'm not sure that makes sense. Perhaps what you want > to say is that the architecture doesn't determine if an SFC > {{A,B},C} is or is not the same as {{B,A},C} but that later > protocol work will have to do that. (In fact, I think you > could say a lot more here and probably should.) > > - 1.2: what is a "chaining policy"? Isn't here where those > terms need to be defined. > > - 1.3: SFC definition: by ordered do you mean fully or > partially ordered? > > - 1.3: I'd omit LI as a SF - we won't be standardising that > (cf. RFC2804) so better to not drag in the controversy > really. Similarly, HOST_ID injection is not afaik any kind of > standard and perhaps not likely to be (cf. some confict > reviews on the same telechat as this) so I'd also drop that. > And I think all of the exemplar SF's should really have a > reference (ideally an RFC). > > - Figure 1 caption is misleading. That seems to me to show a > set of paths through (one or more) graphs but doesn't show > the full graphs themselves. > > - 2.2: The concept of a bi-directional SFC seems odd. Does > the example given imply that all traffic (of what kind?) that > followed SF1->SF2->SF3 on the way "in" must follow > SF3->SF2->SF1 on the way "out"? If so, then I think more > precision is needed really. The hybrid concept seems even > odder to me. > > - 2.3: How can an SFP "be vague" - surely the point of an > architecture is to avoid such vagueness? If you mean that an > SFP representation can embody an if-statement then saying > that would be the thing to do. > > - Section 3: I think there's maybe a missing principle here > about not making security and privacy worse in general. > > - 4.1: I wonder if one could ever get enough SFC control > traffic that congestion would be an issue? If so, should you > say rather that any transport that has some way of handling > congestion is ok. If not, then I guess the current text is > fine. > > > From nobody Thu May 28 07:06:14 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD601ACD2B; Thu, 28 May 2015 07:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 HcE05M9-MpZU; Thu, 28 May 2015 07:05:58 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E72F1ACD38; Thu, 28 May 2015 07:05:52 -0700 (PDT) Received: by obew15 with SMTP id w15so33587854obe.1; Thu, 28 May 2015 07:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hzTLQNWe3mDnefoeTzcwK/uMa8c2D3uN3oD9Vhyuc6E=; b=vEagYrimypFnzApyopsuJs6Z3bSmoUuix0Zo629BZ28RVlyvlOthdiArEvL+CAbkpx o4GS14HKuiAMTodLKOMhAMZ4j5RW22S9bEtE+O5dcct33IMKIxc3uj2Kd2GL+C6be7ws g6v+WW37Y/ZkXNTUJjzS9I59G7ZbC748ONCW2ro66xIIfieXDCAy565KMxJZgkFkzhYz hk2CoSfcbzYl/HSQMnICVDArJwzs2vetsSPBKravRTYosiSNer1JbuxaPpfJVasGwqxE 0byN5rITLpXTPHn70dV0mqYLTF3AMqey5bo+BDhh7PKdftTlMiKgy/3yAVPshimfPQ28 kPZw== MIME-Version: 1.0 X-Received: by 10.60.35.71 with SMTP id f7mr2663878oej.24.1432821951787; Thu, 28 May 2015 07:05:51 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Thu, 28 May 2015 07:05:51 -0700 (PDT) In-Reply-To: References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 10:05:51 -0400 Message-ID: From: Alia Atlas To: Barry Leiba Content-Type: multipart/alternative; boundary=089e013c6a7c7679b1051724db83 Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.shepherd@ietf.org, The IESG , Alvaro Retana , draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.ad@ietf.org Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:06:00 -0000 --089e013c6a7c7679b1051724db83 Content-Type: text/plain; charset=UTF-8 Barry, On Thu, May 28, 2015 at 9:56 AM, Barry Leiba wrote: > > I don't see anything specifically implementable in this architecture. I > > can't see how it could proceed > > from PS to IS. That isn't the case for all architecture docs, but for > this > > one, I think that Informational is fine. > > I could see how the proposed architecture could be refined and > eventually moved past "proposed", but that's not the main point I'm > thinking about. For me, it's a question of the type of review > Standards Track documents get ("Is this document a reasonable basis on > which to build the salient part of the Internet infrastructure? If > not, what changes would make it so?") as compared with Informational > ("Is this document a reasonable contribution to the area of Internet > engineering which it covers? If not, what changes would make it so?"). > I don't feel that this draft has suffered in any way from a lack of review. I think that we do review architectures with a good expectation that they are a solid basis. I think that the status should depend on what the draft is - not on the level of review that we think is appropriate. > We are proposing the former: building a significant part of the > Internet infrastructure on this. Well, not precisely. I do expect it to be significantly deployed but I also see it as being within individual administrative domains. Alia Barry > --089e013c6a7c7679b1051724db83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry,


On Thu, May 28, 2015 at 9:56 AM, Barry Leib= a <barryleiba@computer.org> wrote:
> I don't see anything specifically implementabl= e in this architecture.=C2=A0 I
> can't see how it could proceed
> from PS to IS.=C2=A0 That isn't the case for all architecture docs= , but for this
> one, I think that Informational is fine.

I could see how the proposed architecture could be refined and
eventually moved past "proposed", but that's not the main poi= nt I'm
thinking about.=C2=A0 For me, it's a question of the type of review
Standards Track documents get ("Is this document a reasonable basis on=
which to build the salient part of the Internet infrastructure? If
not, what changes would make it so?") as compared with Informational ("Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?").=

I don't feel that this draft has s= uffered in any way from a lack of review.
I think that we do revi= ew architectures with a good expectation that they are
a solid ba= sis. =C2=A0

I think that the status should depend = on what the draft is - not on the level of
review that we think i= s appropriate. =C2=A0 =C2=A0
=C2=A0
We are proposing the former: building a significant part of the
Internet infrastructure on this.

Well, not = precisely.=C2=A0 I do expect it to be significantly deployed but I also see= it
as being within individual administrative domains. =C2=A0

Alia=C2=A0

Barry

--089e013c6a7c7679b1051724db83-- From nobody Thu May 28 07:06:36 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526F41ACD35; Thu, 28 May 2015 07:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 H3mGC3qXs7BC; Thu, 28 May 2015 07:06:26 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DCCF1ACD34; Thu, 28 May 2015 07:06:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7B587250F50; Thu, 28 May 2015 07:06:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 80BFD240840; Thu, 28 May 2015 07:06:25 -0700 (PDT) Message-ID: <556720DA.30306@joelhalpern.com> Date: Thu, 28 May 2015 10:06:18 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kathleen Moriarty , The IESG References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> In-Reply-To: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:06:31 -0000 I do not know what it would mean to apply privacy to information that is a) gathered from a payload b) and delivered along with that unprotected payload? Yours, Joel On 5/28/15 9:24 AM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-sfc-architecture-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I agree with Stephen's discuss and comment points and am just adding a > few that I think are also important. > > 1. The Security Considerations section only talks about privacy of the > SFC information for classification. The more important point may be the > privacy of any data gathered from a payload used for the classification > and this needs to be mentioned. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1. For the Service Functions, I would think you would want to leave out > "Lawful Intercept" as a device type since it's not a universal > requirement on networks and immediately raises privacy concerns. > > 2. Section 3, #3 > Classification on part of the packet payload will become increasingly > more difficult as encryption is rolled out. The IETF and IAB both > support the increased use of encryption for privacy and security purposes > and are looking to have it end-to-end where possible. With the work out > of TCPInc, encryption will be even more prevalent. > > > From nobody Thu May 28 07:11:05 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FE41ACD3F; Thu, 28 May 2015 07:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 U_wxUQUnMp00; Thu, 28 May 2015 07:11:00 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0D01ACD43; Thu, 28 May 2015 07:10:48 -0700 (PDT) Received: by lagv1 with SMTP id v1so32786453lag.3; Thu, 28 May 2015 07:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ynirThvYUlDtNGycj+WrJR9S7E2Z5QfLx+1Tg//DIoU=; b=pBodPw25GkO/Y9FTrFGvFGZ7fgRmDghpjz+l5CcvjdJRUb3sSfWPVXO4iR9FQ1BJfy eVRJ5mXI4OSY2g17TsJZ9lfTWacRURvCdvwVeVGM6L006fkCWWvDo2KzPZX+xxh3X7YF Ayp2pT8/y91C93Eo+z3i1D5PXg6JW+9C5Kfb4BckRxDyrRCgv6fZVesfyRyLJ49fcPsZ kknuba8FpslVnN7ldSW9P47mx6LZ0XSY5Ctf61veClfEn5HcpJ4qXWmS1wxTlaerwoz5 Hh60TSMW/11BRQAVriVq7xXCg/nk2V6dm/QTGG5f/mdty1V3stDsvBFJP3ywVPQQ2gEg nhpg== MIME-Version: 1.0 X-Received: by 10.112.93.230 with SMTP id cx6mr3042453lbb.65.1432822247039; Thu, 28 May 2015 07:10:47 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 28 May 2015 07:10:46 -0700 (PDT) In-Reply-To: <556720DA.30306@joelhalpern.com> References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> Date: Thu, 28 May 2015 10:10:46 -0400 Message-ID: From: Kathleen Moriarty To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a113497c20fa6e4051724edaf Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.ad@ietf.org, "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.shepherd@ietf.org, draft-ietf-sfc-architecture@ietf.org, The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:11:04 -0000 --001a113497c20fa6e4051724edaf Content-Type: text/plain; charset=UTF-8 Hi Joel, On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern wrote: > I do not know what it would mean to apply privacy to information that is > a) gathered from a payload > b) and delivered along with that unprotected payload? > If you go back to the text in my discuss, I'm concerned about privacy of data that is in a payload that may be used in the SFC architecture. I am not saying that you have to apply privacy, just that it may be exposed when payloads are accessed and used. Thanks, Kathleen > Yours, > Joel > > > On 5/28/15 9:24 AM, Kathleen Moriarty wrote: > >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-sfc-architecture-08: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I agree with Stephen's discuss and comment points and am just adding a >> few that I think are also important. >> >> 1. The Security Considerations section only talks about privacy of the >> SFC information for classification. The more important point may be the >> privacy of any data gathered from a payload used for the classification >> and this needs to be mentioned. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 1. For the Service Functions, I would think you would want to leave out >> "Lawful Intercept" as a device type since it's not a universal >> requirement on networks and immediately raises privacy concerns. >> >> 2. Section 3, #3 >> Classification on part of the packet payload will become increasingly >> more difficult as encryption is rolled out. The IETF and IAB both >> support the increased use of encryption for privacy and security purposes >> and are looking to have it end-to-end where possible. With the work out >> of TCPInc, encryption will be even more prevalent. >> >> >> >> -- Best regards, Kathleen --001a113497c20fa6e4051724edaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel,

On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern <jmh@joelh= alpern.com> wrote:
I do not= know what it would mean to apply privacy to information that is
a) gathered from a payload
b) and delivered along with that unprotected payload?
= =C2=A0
If you go back to the text in my discuss, I'm conc= erned about privacy of data that is in a payload that may be used in the SF= C architecture.=C2=A0 I am not saying that you have to apply privacy, just = that it may be exposed when payloads are accessed and used.=C2=A0

Thanks,
Kathleen


Yours,
Joel


On 5/28/15 9:24 AM, Kathleen Moriarty wrote:
Kathleen Moriarty has entered the following ballot position for
draft-ietf-sfc-architecture-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-cr= iteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-architectu= re/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I agree with Stephen's discuss and comment points and am just adding a<= br> few that I think are also important.

1. The Security Considerations section only talks about privacy of the
SFC information for classification.=C2=A0 The more important point may be t= he
privacy of any data gathered from a payload used for the classification
and this needs to be mentioned.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. For the Service Functions, I would think you would want to leave out
"Lawful Intercept" as a device type since it's not a universa= l
requirement on networks and immediately raises privacy concerns.

2. Section 3, #3
Classification on part of the packet payload will become increasingly
more difficult as encryption is rolled out.=C2=A0 The IETF and IAB both
support the increased use of encryption for privacy and security purposes and are looking to have it end-to-end where possible.=C2=A0 With the work o= ut
of TCPInc, encryption will be even more prevalent.






--
=

Best regards,
Kathleen
--001a113497c20fa6e4051724edaf-- From nobody Thu May 28 07:15:04 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A0A1ACD63; Thu, 28 May 2015 07:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF6k80d3e9qt; Thu, 28 May 2015 07:14:58 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D64B1ACD9C; Thu, 28 May 2015 07:14:58 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so112778905igb.1; Thu, 28 May 2015 07:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OKSrTx4IlDew/6qse1q3nb1e1aKwfZSinnn18GhiZG4=; b=wz32onlUBJ24IkQCSmr1NskdePEq9sPu65UKhn6dy5W2idxVXv9C44HEiwCQp8iNGe he6h9+80oA1f8UWr86TOFqfBOuZyCOuHsNiB3r3UmrPtcvtemJAJ0I0761KoT/KhyViM X680KMxHhnoax1FfQa6fgPuQwHC1NjmAjf2LEQCHjOmMv58/7vCgMQoS82DPqSZf4ahV /g8C1yZWeUBibyjmKTkbcro2HPzoHsY1fXq7q4p4nd0sff5GD7CnsRneqCfVd9UDbIvi HoX1WqsG7ohElZtc8LkegDSIe37x4aHN6SYrbdOQjJwZOpmRIZ2jE3jblAZjdJEw4JNs T9/w== MIME-Version: 1.0 X-Received: by 10.50.30.137 with SMTP id s9mr1964943igh.11.1432822498029; Thu, 28 May 2015 07:14:58 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Thu, 28 May 2015 07:14:57 -0700 (PDT) In-Reply-To: References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 10:14:57 -0400 X-Google-Sender-Auth: MvAcGZkLclDCGXXCXnBiMf_S6SA Message-ID: From: Barry Leiba To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.ad@ietf.org, "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.shepherd@ietf.org, Alvaro Retana , draft-ietf-sfc-architecture@ietf.org, The IESG Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:14:59 -0000 >> I could see how the proposed architecture could be refined and >> eventually moved past "proposed", but that's not the main point I'm >> thinking about. For me, it's a question of the type of review >> Standards Track documents get ("Is this document a reasonable basis on >> which to build the salient part of the Internet infrastructure? If >> not, what changes would make it so?") as compared with Informational >> ("Is this document a reasonable contribution to the area of Internet >> engineering which it covers? If not, what changes would make it so?"). > > I don't feel that this draft has suffered in any way from a lack of review. > I think that we do review architectures with a good expectation that they > are a solid basis. As I said in my follow-up note, I do agree with what you say there. > I think that the status should depend on what the draft is - not on the > level of review that we think is appropriate. That's something we can discuss in another thread/context; I don't think I agree, but discussion would be lovely. >> We are proposing the former: building a significant part of the >> Internet infrastructure on this. > > Well, not precisely. I do expect it to be significantly deployed but I also > see it as being within individual administrative domains. Ack. Given that I think the review of this document has been good, I'm not a holdout here either way. I just wanted to make my point, and I have. T'anks. Barry From nobody Thu May 28 07:19:32 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6A81ACD3E; Thu, 28 May 2015 07:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 VKrOI94cGTX6; Thu, 28 May 2015 07:19:26 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49ACB1ACDA9; Thu, 28 May 2015 07:19:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 38B8A240690; Thu, 28 May 2015 07:19:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1C459240108; Thu, 28 May 2015 07:19:25 -0700 (PDT) Message-ID: <556723E0.5040603@joelhalpern.com> Date: Thu, 28 May 2015 10:19:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.ad@ietf.org, "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.shepherd@ietf.org, draft-ietf-sfc-architecture@ietf.org, The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:19:28 -0000 I am missing your point. Sorry. If it is in the payload, it is exposed. If the payload is protected from exposure, then SFC won't be able to extract it, so can't expose it. We are clear already in the document that SFC metadata has to be protected from exposure outside of the domain, noit because it is in the payload, but for cases where it is derived from other sources that may be sensitive. So I have real trouble figuring out how to address this concern. As for your comments, I have no problem removing LI as an example. I also have no problem leaving it in. it is a service functions a significant number of operators are looking at. There is no service function that will be used by all operators. As for pervasive encryption, it is true that it will become much more common, and such will affect which service functions are useful. Which is one of several reasons why the architecture does not try to define the set of service functions. Yours, Joel On 5/28/15 10:10 AM, Kathleen Moriarty wrote: > Hi Joel, > > On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern > wrote: > > I do not know what it would mean to apply privacy to information that is > a) gathered from a payload > b) and delivered along with that unprotected payload? > > > If you go back to the text in my discuss, I'm concerned about privacy of > data that is in a payload that may be used in the SFC architecture. I > am not saying that you have to apply privacy, just that it may be > exposed when payloads are accessed and used. > > Thanks, > Kathleen > > > Yours, > Joel > > > On 5/28/15 9:24 AM, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-sfc-architecture-08: Discuss > > When responding, please keep the subject line intact and reply > to all > email addresses included in the To and CC lines. (Feel free to > cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I agree with Stephen's discuss and comment points and am just > adding a > few that I think are also important. > > 1. The Security Considerations section only talks about privacy > of the > SFC information for classification. The more important point > may be the > privacy of any data gathered from a payload used for the > classification > and this needs to be mentioned. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1. For the Service Functions, I would think you would want to > leave out > "Lawful Intercept" as a device type since it's not a universal > requirement on networks and immediately raises privacy concerns. > > 2. Section 3, #3 > Classification on part of the packet payload will become > increasingly > more difficult as encryption is rolled out. The IETF and IAB both > support the increased use of encryption for privacy and security > purposes > and are looking to have it end-to-end where possible. With the > work out > of TCPInc, encryption will be even more prevalent. > > > > > > > -- > > Best regards, > Kathleen From nobody Thu May 28 07:20:53 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B721ACDB8; Thu, 28 May 2015 07:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 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_MESSAGE=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 O5Gl0NrHAS6m; Thu, 28 May 2015 07:20:44 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1099B1ACDAF; Thu, 28 May 2015 07:20:44 -0700 (PDT) Received: by obbea2 with SMTP id ea2so33810455obb.3; Thu, 28 May 2015 07:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5QRPDq21jCpYvPB9Ga/5REA5+7yVecGSzOxLYqsLQsw=; b=cfw7T+YbSHNYjs8I5q4gaMYjytk5SH+quE04GWq8H0RxRygSmubKJaKesU9sIriEX8 ybufenBacqM/Z6dI9uGsefSutxTQ/4JGOZp/39TMtEHHL28WpX6Cb5fwQ61mGTUO4j7Z prC9aGi3Kj8E5ZwwnOGSY0sd/8vH6ANh+Z9stHfxo/5YDZCgXJ1mUxbZd4q2goHHTeKh 0pTxw9fn9SwJY+j2eJYM9Yl8K3Eqq70eSm9V8MUnoKlnIUCmAbGDjhXzv2j45tY3uDTv 0pXLtM57FJVK5ASuLmEzToaxsySDYWx9UgCvcmKmmyJKIVW3kJfdrTPUCsSRtDH/vMnV XMHg== MIME-Version: 1.0 X-Received: by 10.60.44.167 with SMTP id f7mr2685787oem.58.1432822843364; Thu, 28 May 2015 07:20:43 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Thu, 28 May 2015 07:20:43 -0700 (PDT) In-Reply-To: <20150528131130.27173.8471.idtracker@ietfa.amsl.com> References: <20150528131130.27173.8471.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 10:20:43 -0400 Message-ID: From: Alia Atlas To: Benoit Claise Content-Type: multipart/alternative; boundary=001a113346d29adb220517251036 Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.ad@ietf.org, "jguichar@cisco.com" , draft-ietf-sfc-architecture.shepherd@ietf.org, draft-ietf-sfc-architecture@ietf.org, The IESG Subject: Re: [sfc] Benoit Claise's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:20:47 -0000 --001a113346d29adb220517251036 Content-Type: text/plain; charset=UTF-8 Hi Benoit, On Thu, May 28, 2015 at 9:11 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-sfc-architecture-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > DISCUSS-DISCUSS: no action from the authors is expected at this point. > This will be discussed during the telechat. > > - Can you explain this disconnect: > >From the charter: > > It will produce an architecture for service function > chaining that includes the necessary protocols or protocol extensions > to > convey the Service Function Chain and Service Function Path > information > to nodes that are involved in the implementation of service > functions > and Service Function Chains, as well as mechanisms for steering > traffic > through service functions. > > >From the abstract: > > This document does not propose solutions, protocols, or > extensions to existing protocols. > If you read further down in the charter, it specifically describes the architecture deliverable as: "2. Architecture: This document will provide a description of the SFC architectural building blocks and their relationships including interconnection, placement of SFC specific capabilities, management, diagnostics, design analysis, and security models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single administrative domain, keeping in mind that architectural decisions made for the intra-domain case may have implications for the inter-domain case. " The architecture isn't specifying what protocols or extensions to use. I agree that the architecture doesn't clearly define the requirements on the protocol(s) but there is also another deliverable in the charter: "4. Control Plane Mechanisms: A document will be developed to describe requirements for conveying information between control or management elements and SFC implementation points. All protocol extension work resulting from these requirements should be carried out in the working group responsible for the protocol being modified in coordination with this working group, but may be done in this working group under a revised charter after agreement with all the relevant WG chairs and responsible ADs." and that is where I'd expect to see this work handled. While I'm on the charter, I'm always available for this milestone: > > Apr 2014 Consult with OPS area on possible SFC charter modifications > for management and configuration of SFC components related to the support > of Service Function Chaining > I've certainly seen drafts and discussion about OAM work. Agreed that it'd be useful for that conversation to happen. Regards, Alia > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - Section 1.1 > What does "minimum requirements on the physical topology"mean in: > > This document defines the architecture for Service Function Chaining > (SFC) with minimum requirements on the physical topology of the > network, as standardized in the IETF. > > It seems to me that "independent" is what you're after, like in: > "it describes a method for deploying SFs in a way that enables > dynamic ordering and topological independence of those SFs as well as > the exchange of metadata between participating entities." > > or > "This SFC architecture is predicated on topological independence from > the underlying forwarding topology." > > > > - Service Function Path definition: I'm confused. you don't explain what > it is, but only explain why you need it. > Later on, I see "As an example of such an intermediate specificity, there > may be two > SFPs associated with a given SFC". I'm confused. > Not too clear on how the SFP and RSP relate to each others. > Is the Service Function Path the ordered list of SFs, while the RSP is > the ordered list of SFFs? > > - > "Traffic from SFs eventually returns to the same SFF, which is > responsible for injecting traffic back onto the network. > > Am I correct that it only applies in case of a SFC proxy? > Related question, along the same lines: > > 1. SFP forwarding : Traffic arrives at an SFF from the network. > The > SFF determines the appropriate SF the traffic should be forwarded > to via information contained in the SFC encapsulation. Post-SF, > the traffic is returned to the SFF, and, if needed, is forwarded > to another SF associated with that SFF. If there is another non- > local (i.e., different SFF) hop in the SFP, the SFF further > encapsulates the traffic in the appropriate network transport > protocol and delivers it to the network for delivery to the next > SFF along the path. > > Returned to the initial SFF, or to the next SFF in the RSP? > I guess the next SFF in the chain (again, unless we speak about a proxy) > > This would be consistent with section 5.4: > "Due to the overlay constraints, the packet-forwarding path may > need to visit the same SFF multiple times, and in some less common > cases may even need to visit the same SF more than once." > > > - Section 4.4 and 4.6: what about SFC-enabled domain and SFC proxy. > In figure 3, the SFC proxy is inside the domain, right? > But what about the SFC-unaware Service Function? Inside or outside? > > - > 6. Service function chain independence: The creation, modification, > or deletion of an SFC has no impact on other SFCs. The same is > true for SFPs. > > Except if one SF depends on the shared metadata from a previous SF in the > chain, right? > > > Editorial. > > - > OLD: > SFC Proxy: Removes and inserts SFC encapsulation on behalf of an > NEW: > SFC Proxy: Removes and inserts SFC Encapsulation on behalf of an > > > --001a113346d29adb220517251036 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit,

On Thu, May 28, 2015 at 9:11 AM, Benoit Claise <bclaise@cisc= o.com> wrote:
Benoit Claise has entered t= he following ballot position for
draft-ietf-sfc-architecture-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-cr= iteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-architectu= re/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

DISCUSS-DISCUSS: no action from the authors is expected at this point.
This will be discussed during the telechat.

- Can you explain this disconnect:
>From the charter:

=C2=A0 =C2=A0 It will produce an architecture for service function
=C2=A0 =C2=A0 chaining that includes the necessary protocols or protocol ex= tensions
to
=C2=A0 =C2=A0 convey the Service Function Chain and Service Function Path information
=C2=A0 =C2=A0 to nodes that are involved in the implementation of service functions
=C2=A0 =C2=A0 and Service Function Chains, as well as mechanisms for steeri= ng
traffic
=C2=A0 =C2=A0 through service functions.

>From the abstract:

=C2=A0 =C2=A0 This document does not propose solutions, protocols, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0extensions to existing protocols.

If you read further down in the charter, it specifica= lly describes the architecture
deliverable as:

"2. Archi= tecture: This document will provide a description of the SFC=C2=A0
architectural building blocks a= nd their relationships including=C2=A0
interconnection, placement of SFC specific capabilities, management,
diagnostics, design analysis, and security = models, as well as
requirements on the= protocol mechanisms. The initial scope is
restricted to a single administrative domain, keeping in mind that
architectural decisions made for the intr= a-domain case may have=C2=A0
impl= ications for the inter-domain case.=C2=A0"

=
The architecture isn't specifying what protocols or extensions to = use. =C2=A0 I agree that=C2=A0
the architecture doesn't clear= ly define the requirements on the protocol(s) but there
is also a= nother deliverable in the charter:

"4. Control Plane Mechanisms: A= document will be developed to describe
requirements for conveying information betwe= en control or management
elements and = SFC implementation points. All protocol extension work=C2=A0
resulting from these requirements should be carried = out in the=C2=A0
= working group respons= ible for the protocol being modified in=C2=A0
coordination with this working group, but may be done in this worki= ng
group under a revised charter after= agreement with all the relevant
WG ch= airs and responsible ADs."

and that is wher= e I'd expect to see this work handled.
=C2=A0

<= /div>
While I'm on the charter, I'm always available for this milestone:<= br>
=C2=A0 =C2=A0 Apr 2014 Consult with OPS area on possible SFC charter modifi= cations
for management and configuration of SFC components related to the support of Service Function Chaining

I've c= ertainly seen drafts and discussion about OAM work.=C2=A0 Agreed that it= 9;d be
useful for that conversation to happen.

Regards,
Alia=C2=A0
=C2=A0

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Section 1.1
What does "minimum requirements on the physical topology"mean in:=

=C2=A0 =C2=A0This document defines the architecture for Service Function Ch= aining
=C2=A0 =C2=A0(SFC) with minimum requirements on the physical topology of th= e
=C2=A0 =C2=A0network, as standardized in the IETF.

It seems to me that "independent" is what you're after, like = in:
=C2=A0 =C2=A0"it describes a method for deploying SFs in a way that en= ables
=C2=A0 =C2=A0dynamic ordering and topological independence of those SFs as = well as
=C2=A0 =C2=A0the exchange of metadata between participating entities."=

or
=C2=A0 =C2=A0"This SFC architecture is predicated on topological indep= endence from
=C2=A0 =C2=A0the underlying forwarding topology."



- Service Function Path definition: I'm confused. you don't explain= what
it is, but only explain why you need it.
Later on, I see "As an example of such an intermediate specificity, th= ere
may be two
SFPs associated with a given SFC". I'm confused.
Not too clear on how the SFP and RSP relate to each others.
Is the Service Function Path the ordered list of SFs, while the RSP is
the ordered list of SFFs?

-
"Traffic from SFs eventually returns to the same SFF, which is
responsible for injecting traffic back onto the network.

Am I correct that it only applies in case of a SFC proxy?
Related question, along the same lines:

=C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2=A0 SFP forwarding : Traffic arrives at an = SFF from the network.
The
=C2=A0 =C2=A0 =C2=A0 =C2=A0SFF determines the appropriate SF the traffic sh= ould be forwarded
=C2=A0 =C2=A0 =C2=A0 =C2=A0to via information contained in the SFC encapsul= ation.=C2=A0 Post-SF,
=C2=A0 =C2=A0 =C2=A0 =C2=A0the traffic is returned to the SFF, and, if need= ed, is forwarded
=C2=A0 =C2=A0 =C2=A0 =C2=A0to another SF associated with that SFF.=C2=A0 If= there is another non-
=C2=A0 =C2=A0 =C2=A0 =C2=A0local (i.e., different SFF) hop in the SFP, the = SFF further
=C2=A0 =C2=A0 =C2=A0 =C2=A0encapsulates the traffic in the appropriate netw= ork transport
=C2=A0 =C2=A0 =C2=A0 =C2=A0protocol and delivers it to the network for deli= very to the next
=C2=A0 =C2=A0 =C2=A0 =C2=A0SFF along the path.

Returned to the initial SFF, or to the next SFF in the RSP?
I guess the next SFF in the chain (again, unless we speak about a proxy)
This would be consistent with section 5.4:
=C2=A0 =C2=A0"Due to the overlay constraints, the packet-forwarding pa= th may
=C2=A0 =C2=A0need to visit the same SFF multiple times, and in some less co= mmon
=C2=A0 =C2=A0cases may even need to visit the same SF more than once."=


- Section 4.4 and 4.6: what about SFC-enabled domain and SFC proxy.
In figure 3, the SFC proxy is inside the domain, right?
But what about the SFC-unaware Service Function? Inside or outside?

-
6.=C2=A0 Service function chain independence: The creation, modification, =C2=A0 =C2=A0 =C2=A0 =C2=A0or deletion of an SFC has no impact on other SFC= s.=C2=A0 The same is
=C2=A0 =C2=A0 =C2=A0 =C2=A0true for SFPs.

Except if one SF depends on the shared metadata from a previous SF in the chain, right?


Editorial.

-
OLD:
=C2=A0 =C2=A0SFC Proxy:=C2=A0 Removes and inserts SFC encapsulation on beha= lf of an
NEW:
=C2=A0 =C2=A0SFC Proxy:=C2=A0 Removes and inserts SFC Encapsulation on beha= lf of an



--001a113346d29adb220517251036-- From nobody Thu May 28 07:31:23 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E24A1ACDD5; Thu, 28 May 2015 07:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 976Sl2V6s4_K; Thu, 28 May 2015 07:31:18 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3018B1ACDDB; Thu, 28 May 2015 07:30:32 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so29593027lbb.2; Thu, 28 May 2015 07:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9r1JS5X8jNOP3tPPKuk2IfyM456wsM11buVrLKQz750=; b=0ir5SYSZ8O/1GHme9U4Jsv7FkwG9nCqquwYzDlpXNAhaZPupuZzGFAYM61BGOMRlfd nCgGD7rN2e8qB+2KOGhaJRwNL4k3JliJyMWkRFWhHQsArVDRH0waEZTKxWVb6NBYCrBn 5thV3aI+v9fjXMggrL6vjTd0HtxrLXkhd5R9DFiFd82LAQZ0dadcxY+j7EjL5z7p1uIx 3/NGr95RbjvVPnxWavREH28G7cpxsJ26TQlMyCtA43kUs0V7D677A1I3jD5l/iVgCeLA GVkMT7HLx/0J5zOEl0VKdyDiedsZbHespeZVywdfbTGJt7zWIm0n+SoLveRTItO/JrfD 5NTw== MIME-Version: 1.0 X-Received: by 10.152.43.110 with SMTP id v14mr3150568lal.4.1432823430720; Thu, 28 May 2015 07:30:30 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 28 May 2015 07:30:30 -0700 (PDT) In-Reply-To: <556723E0.5040603@joelhalpern.com> References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> <556723E0.5040603@joelhalpern.com> Date: Thu, 28 May 2015 10:30:30 -0400 Message-ID: From: Kathleen Moriarty To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c351529d325a05172533fe Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.ad@ietf.org, "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.shepherd@ietf.org, draft-ietf-sfc-architecture@ietf.org, The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:31:21 -0000 --001a11c351529d325a05172533fe Content-Type: text/plain; charset=UTF-8 On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern wrote: > I am missing your point. Sorry. If it is in the payload, it is exposed. > If the payload is protected from exposure, then SFC won't be able to > extract it, so can't expose it. We are clear already in the document that > SFC metadata has to be protected from exposure outside of the domain, noit > because it is in the payload, but for cases where it is derived from other > sources that may be sensitive. > > Right, but you are pulling that content out and using it in ways that may not have been intended by those who created it and didn't encrypt it. This raises the security/privacy concern that their data may be used in ways they did not intend and be put into places they didn't expect. If it's data that has to be tracked for record retention, through an ESI data map or similar, its one more place this data resides that needs to be tracked. If the warning is there that this could happen and is a possible privacy concern, my point is addressed. Thank you, Kathleen > So I have real trouble figuring out how to address this concern. > > As for your comments, > I have no problem removing LI as an example. I also have no problem > leaving it in. it is a service functions a significant number of operators > are looking at. There is no service function that will be used by all > operators. > As for pervasive encryption, it is true that it will become much more > common, and such will affect which service functions are useful. Which is > one of several reasons why the architecture does not try to define the set > of service functions. > > Yours, > Joel > > On 5/28/15 10:10 AM, Kathleen Moriarty wrote: > >> Hi Joel, >> >> On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern > > wrote: >> >> I do not know what it would mean to apply privacy to information that >> is >> a) gathered from a payload >> b) and delivered along with that unprotected payload? >> >> >> If you go back to the text in my discuss, I'm concerned about privacy of >> data that is in a payload that may be used in the SFC architecture. I >> am not saying that you have to apply privacy, just that it may be >> exposed when payloads are accessed and used. >> >> Thanks, >> Kathleen >> >> >> Yours, >> Joel >> >> >> On 5/28/15 9:24 AM, Kathleen Moriarty wrote: >> >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-sfc-architecture-08: Discuss >> >> When responding, please keep the subject line intact and reply >> to all >> email addresses included in the To and CC lines. (Feel free to >> cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >> >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> >> ---------------------------------------------------------------------- >> >> I agree with Stephen's discuss and comment points and am just >> adding a >> few that I think are also important. >> >> 1. The Security Considerations section only talks about privacy >> of the >> SFC information for classification. The more important point >> may be the >> privacy of any data gathered from a payload used for the >> classification >> and this needs to be mentioned. >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> >> ---------------------------------------------------------------------- >> >> 1. For the Service Functions, I would think you would want to >> leave out >> "Lawful Intercept" as a device type since it's not a universal >> requirement on networks and immediately raises privacy concerns. >> >> 2. Section 3, #3 >> Classification on part of the packet payload will become >> increasingly >> more difficult as encryption is rolled out. The IETF and IAB both >> support the increased use of encryption for privacy and security >> purposes >> and are looking to have it end-to-end where possible. With the >> work out >> of TCPInc, encryption will be even more prevalent. >> >> >> >> >> >> >> -- >> >> Best regards, >> Kathleen >> > -- Best regards, Kathleen --001a11c351529d325a05172533fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern <= ;jmh@joelhalpern.c= om> wrote:
I am missing you= r point.=C2=A0 Sorry.=C2=A0 If it is in the payload, it is exposed.=C2=A0 I= f the payload is protected from exposure, then SFC won't be able to ext= ract it, so can't expose it.=C2=A0 We are clear already in the document= that SFC metadata has to be protected from exposure outside of the domain,= noit because it is in the payload, but for cases where it is derived from = other sources that may be sensitive.

Right, but you are pulling that content out and using= it in ways that may not have been intended by those who created it and did= n't encrypt it.=C2=A0 This raises the security/privacy concern that the= ir data may be used in ways they did not intend and be put into places they= didn't expect.=C2=A0 If it's data that has to be tracked for recor= d retention, through an ESI data map or similar, its one more place this da= ta resides that needs to be tracked.=C2=A0 If the warning is there that thi= s could happen and is a possible privacy concern, my point is addressed.

Thank you,
Kathleen

=C2=A0
So I have real trouble figuring out how to address this concern.

As for your comments,
I have no problem removing LI as an example.=C2=A0 I also have no problem l= eaving it in.=C2=A0 it is a service functions a significant number of opera= tors are looking at.=C2=A0 There is no service function that will be used b= y all operators.
As for pervasive encryption, it is true that it will become much more commo= n, and such will affect which service functions are useful.=C2=A0 Which is = one of several reasons why the architecture does not try to define the set = of service functions.

Yours,
Joel

On 5/28/15 10:10 AM, Kathleen Moriarty wrote:
Hi Joel,

On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern <jmh@joelhalpern.com
=
<mailto:jmh@joe= lhalpern.com>> wrote:

=C2=A0 =C2=A0 I do not know what it would mean to apply privacy to informat= ion that is
=C2=A0 =C2=A0 a) gathered from a payload
=C2=A0 =C2=A0 b) and delivered along with that unprotected payload?


If you go back to the text in my discuss, I'm concerned about privacy o= f
data that is in a payload that may be used in the SFC architecture.=C2=A0 I=
am not saying that you have to apply privacy, just that it may be
exposed when payloads are accessed and used.

Thanks,
Kathleen


=C2=A0 =C2=A0 Yours,
=C2=A0 =C2=A0 Joel


=C2=A0 =C2=A0 On 5/28/15 9:24 AM, Kathleen Moriarty wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Kathleen Moriarty has entered the following bal= lot position for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-sfc-architecture-08: Discuss

=C2=A0 =C2=A0 =C2=A0 =C2=A0 When responding, please keep the subject line i= ntact and reply
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 email addresses included in the To and CC lines= . (Feel free to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cut this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 introductory paragraph, however.)


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Please refer to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/iesg/statemen= t/discuss-criteria.html
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for more information about IESG DISCUSS and COM= MENT positions.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 The document, along with other ballot positions= , can be found here:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/d= oc/draft-ietf-sfc-architecture/



=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------------------------------------= -----------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DISCUSS:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------------------------------------= -----------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree with Stephen's discuss and comment = points and am just
=C2=A0 =C2=A0 =C2=A0 =C2=A0 adding a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 few that I think are also important.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1. The Security Considerations section only tal= ks about privacy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SFC information for classification.=C2=A0 The m= ore important point
=C2=A0 =C2=A0 =C2=A0 =C2=A0 may be the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 privacy of any data gathered from a payload use= d for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 classification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and this needs to be mentioned.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------------------------------------= -----------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 COMMENT:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------------------------------------= -----------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1. For the Service Functions, I would think you= would want to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leave out
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Lawful Intercept" as a device type s= ince it's not a universal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 requirement on networks and immediately raises = privacy concerns.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2. Section 3, #3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Classification on part of the packet payload wi= ll become
=C2=A0 =C2=A0 =C2=A0 =C2=A0 increasingly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 more difficult as encryption is rolled out.=C2= =A0 The IETF and IAB both
=C2=A0 =C2=A0 =C2=A0 =C2=A0 support the increased use of encryption for pri= vacy and security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 purposes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and are looking to have it end-to-end where pos= sible.=C2=A0 With the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 work out
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of TCPInc, encryption will be even more prevale= nt.






--

Best regards,
Kathleen



--

Best regards,
Kath= leen
--001a11c351529d325a05172533fe-- From nobody Thu May 28 07:35:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0E31ACDD5; Thu, 28 May 2015 07:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 qdMNT76ynHaK; Thu, 28 May 2015 07:35:22 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4012A1ACE24; Thu, 28 May 2015 07:35:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2E621240C18; Thu, 28 May 2015 07:35:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id DFB09240690; Thu, 28 May 2015 07:35:17 -0700 (PDT) Message-ID: <5567279E.9000701@joelhalpern.com> Date: Thu, 28 May 2015 10:35:10 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> <556723E0.5040603@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.ad@ietf.org, "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.shepherd@ietf.org, draft-ietf-sfc-architecture@ietf.org, The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:35:26 -0000 There is already text about letting information out of the service chaining domain. As for recording information a) that would be a service function behavior, not an SFC behavior b) that is not made easier or harder by the use of SFC In the abstract warning operators that retaining subscriber information is a sensitive undertaking is sensible. But it seems a really bad fit for this document. It is an application issue. Yours, Joel On 5/28/15 10:30 AM, Kathleen Moriarty wrote: > > > On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern > wrote: > > I am missing your point. Sorry. If it is in the payload, it is > exposed. If the payload is protected from exposure, then SFC won't > be able to extract it, so can't expose it. We are clear already in > the document that SFC metadata has to be protected from exposure > outside of the domain, noit because it is in the payload, but for > cases where it is derived from other sources that may be sensitive. > > Right, but you are pulling that content out and using it in ways that > may not have been intended by those who created it and didn't encrypt > it. This raises the security/privacy concern that their data may be > used in ways they did not intend and be put into places they didn't > expect. If it's data that has to be tracked for record retention, > through an ESI data map or similar, its one more place this data resides > that needs to be tracked. If the warning is there that this could > happen and is a possible privacy concern, my point is addressed. > > Thank you, > Kathleen > > So I have real trouble figuring out how to address this concern. > > As for your comments, > I have no problem removing LI as an example. I also have no problem > leaving it in. it is a service functions a significant number of > operators are looking at. There is no service function that will be > used by all operators. > As for pervasive encryption, it is true that it will become much > more common, and such will affect which service functions are > useful. Which is one of several reasons why the architecture does > not try to define the set of service functions. > > Yours, > Joel > > On 5/28/15 10:10 AM, Kathleen Moriarty wrote: > > Hi Joel, > > On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern > > >> wrote: > > I do not know what it would mean to apply privacy to > information that is > a) gathered from a payload > b) and delivered along with that unprotected payload? > > > If you go back to the text in my discuss, I'm concerned about > privacy of > data that is in a payload that may be used in the SFC > architecture. I > am not saying that you have to apply privacy, just that it may be > exposed when payloads are accessed and used. > > Thanks, > Kathleen > > > Yours, > Joel > > > On 5/28/15 9:24 AM, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot > position for > draft-ietf-sfc-architecture-08: Discuss > > When responding, please keep the subject line intact > and reply > to all > email addresses included in the To and CC lines. (Feel > free to > cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT > positions. > > > The document, along with other ballot positions, can be > found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ > > > > > ---------------------------------------------------------------------- > DISCUSS: > > ---------------------------------------------------------------------- > > I agree with Stephen's discuss and comment points and > am just > adding a > few that I think are also important. > > 1. The Security Considerations section only talks about > privacy > of the > SFC information for classification. The more important > point > may be the > privacy of any data gathered from a payload used for the > classification > and this needs to be mentioned. > > > > ---------------------------------------------------------------------- > COMMENT: > > ---------------------------------------------------------------------- > > 1. For the Service Functions, I would think you would > want to > leave out > "Lawful Intercept" as a device type since it's not a > universal > requirement on networks and immediately raises privacy > concerns. > > 2. Section 3, #3 > Classification on part of the packet payload will become > increasingly > more difficult as encryption is rolled out. The IETF > and IAB both > support the increased use of encryption for privacy and > security > purposes > and are looking to have it end-to-end where possible. > With the > work out > of TCPInc, encryption will be even more prevalent. > > > > > > > -- > > Best regards, > Kathleen > > > > > -- > > Best regards, > Kathleen From nobody Thu May 28 07:36:40 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56591ACE52; Thu, 28 May 2015 07:36:36 -0700 (PDT) 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, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 V4huWhoaxfTz; Thu, 28 May 2015 07:36:32 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02D41ACE7C; Thu, 28 May 2015 07:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8D500BF04; Thu, 28 May 2015 15:35:41 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHRFhKg3cgu1; Thu, 28 May 2015 15:35:41 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 60FCCBF03; Thu, 28 May 2015 15:35:41 +0100 (IST) Message-ID: <556727BD.3080309@cs.tcd.ie> Date: Thu, 28 May 2015 15:35:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> In-Reply-To: <55672033.4000201@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:36:36 -0000 On 28/05/15 15:03, Joel M. Halpern wrote: > I am not sure what you mean by "Metadata that contains information that > is protected in the data plane". Most of what ends up in the metadata > is information that is passed on other interfaces directly to relevant > functions, or locally determine and locally processed. So what I had in mind were things like the following. - Packet is sent along a SFP A,B,C - B to C link is via say a TLS VPN - Metadata is created at A and is in the SFC encapsulation and not protected by the VPN - That seems bad S. > > The protection used for policy systems (which provide much of the > information) is based on the presence of persistent connections and > usage which crosses domains. Are you arguing that if AAA is encrypted > then policy delivered by AAA resulting in metadata in the packet must be > encrypted in the data packets? > > Yours, > Joel > > On 5/28/15 8:52 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-sfc-architecture-08: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> (1) I note the charter calls for this deliverable to "provide >> a description of... security models" The charter also >> generally notes that "The SFC WG will closely consider and >> address the management and security implications when >> documenting these deliverables." My conclusion is that this >> deliverable needs to reflect the results of a security >> analysis that the wg are suppoed to have carried out but that >> it's currently too vague only saying that solutions need to >> consider this. (Essentially this is a continuation of the >> mail threads from the secdir review [1] and a satisfactory >> resolution of that will probably resolve this.) >> >> [1] >> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >> >> (2) Metadata that contains information that is protected in >> the data plane SHOULD be equally well protected when passed >> about by SFC. I hope that's acceptable and documented. I'm >> not sure myself if "passed about" ought also include within a >> device but maybe it should really. But at minimum, I do >> think you need to define confidentiality and origin >> authentication services for SFC metadata and/or for the SFC >> encapsulation as a whole. And I think this architecture >> document needs to say that those services have to be >> well-defined as part of any solution. (And I am not >> saying that this draft needs to define how to do those.) >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - It occurs to me that it might really be better for the WG >> to not publish this as an RFC now, but rather to put it on >> hold until they've made progress on the solutions. Perhaps >> revistiting this when the solutions are just at WGLC would >> result in the eventual RFC being a much more useful document. >> I think this one has to hedge so many bets that it's quite >> vague and won't be very useful even in the medium term. But >> that's just a suggestion, I can see why the WG might prefer >> to push this out, even if that might only give the appearance >> of progress and not reflect real progress. >> >> - While IPR on an architecture document is sad to see, esp >> with what seems like it may be restrictive licensing, I do >> see the wg debated that and decided to move on. >> >> - The charter text describing this deliverable notes that >> "The initial scope is restricted to a single administrative >> domain, keeping in mind that architectural decisions made for >> the intra-domain case may have implications for the >> inter-domain case." So I think there is also a currently >> missing analysis (or the results of that) as to how the >> single-domain elements of this architecture might impinge on >> a later inter-domain architecture. So the text at the >> end of section 1.1 appears to contradict the chartered >> goals. >> >> - Chains will require some representation, and re-ordering >> that is security sensitive (e.g. swap order of f/w and nat >> for fun) therefore there must be a requirement for some data >> integrity service and origin authentication and an >> authorisation decision function and therefore there must >> (istm) be a need for the architecture to define a chain >> producing entity of some kind that could be authenticated. >> That is an example of the missing security analysis that >> really is needed before this proceeds. (See my discuss point >> 2) >> >> - 1.1: "classified on ingress" and applicable to mobile >> networks are slightly incongrous. In the case of WiFi when do >> the packet ingress? (When it gets to the AP or leaves the >> mobile node transmitter?) I suspect you really mean the wired >> bits of a mobile network so it might be better to say that. >> >> - 1.2 should follow 1.3 I think. >> >> - 1.2: What does "chaining logic" mean? You say there's no >> standard chaining logic, which is maybe right, but then you >> imply that a fully ordered set of SF's is a well defined >> thing. I'm not sure that makes sense. Perhaps what you want >> to say is that the architecture doesn't determine if an SFC >> {{A,B},C} is or is not the same as {{B,A},C} but that later >> protocol work will have to do that. (In fact, I think you >> could say a lot more here and probably should.) >> >> - 1.2: what is a "chaining policy"? Isn't here where those >> terms need to be defined. >> >> - 1.3: SFC definition: by ordered do you mean fully or >> partially ordered? >> >> - 1.3: I'd omit LI as a SF - we won't be standardising that >> (cf. RFC2804) so better to not drag in the controversy >> really. Similarly, HOST_ID injection is not afaik any kind of >> standard and perhaps not likely to be (cf. some confict >> reviews on the same telechat as this) so I'd also drop that. >> And I think all of the exemplar SF's should really have a >> reference (ideally an RFC). >> >> - Figure 1 caption is misleading. That seems to me to show a >> set of paths through (one or more) graphs but doesn't show >> the full graphs themselves. >> >> - 2.2: The concept of a bi-directional SFC seems odd. Does >> the example given imply that all traffic (of what kind?) that >> followed SF1->SF2->SF3 on the way "in" must follow >> SF3->SF2->SF1 on the way "out"? If so, then I think more >> precision is needed really. The hybrid concept seems even >> odder to me. >> >> - 2.3: How can an SFP "be vague" - surely the point of an >> architecture is to avoid such vagueness? If you mean that an >> SFP representation can embody an if-statement then saying >> that would be the thing to do. >> >> - Section 3: I think there's maybe a missing principle here >> about not making security and privacy worse in general. >> >> - 4.1: I wonder if one could ever get enough SFC control >> traffic that congestion would be an issue? If so, should you >> say rather that any transport that has some way of handling >> congestion is ok. If not, then I guess the current text is >> fine. >> >> >> From nobody Thu May 28 07:40:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8B31AD0C6; Thu, 28 May 2015 07:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4j6F_bQbTWL; Thu, 28 May 2015 07:40:13 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920ED1ACE62; Thu, 28 May 2015 07:39:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 748FE240690; Thu, 28 May 2015 07:39:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BEF92400FB; Thu, 28 May 2015 07:39:00 -0700 (PDT) Message-ID: <5567287C.6080905@joelhalpern.com> Date: Thu, 28 May 2015 10:38:52 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> In-Reply-To: <556727BD.3080309@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:40:15 -0000 IF A, B, and C are service function forwarders (SFF), with a TLS protected link for SFC, then the metadata will be protected. (Such a link would be a transport mechanism, which SFC does not describe or mandate. The SFC architecture is transport agnostic.) If A, B, and C are service functions used by SFC, then there is no link between B and C, so it can't be protected by TLS. So I can not see what more needs to be said? Yours, Joel On 5/28/15 10:35 AM, Stephen Farrell wrote: > > > On 28/05/15 15:03, Joel M. Halpern wrote: >> I am not sure what you mean by "Metadata that contains information that >> is protected in the data plane". Most of what ends up in the metadata >> is information that is passed on other interfaces directly to relevant >> functions, or locally determine and locally processed. > > So what I had in mind were things like the following. > > - Packet is sent along a SFP A,B,C > - B to C link is via say a TLS VPN > - Metadata is created at A and is in the SFC encapsulation > and not protected by the VPN > - That seems bad > > S. > > >> >> The protection used for policy systems (which provide much of the >> information) is based on the presence of persistent connections and >> usage which crosses domains. Are you arguing that if AAA is encrypted >> then policy delivered by AAA resulting in metadata in the packet must be >> encrypted in the data packets? >> >> Yours, >> Joel >> >> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-sfc-architecture-08: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> (1) I note the charter calls for this deliverable to "provide >>> a description of... security models" The charter also >>> generally notes that "The SFC WG will closely consider and >>> address the management and security implications when >>> documenting these deliverables." My conclusion is that this >>> deliverable needs to reflect the results of a security >>> analysis that the wg are suppoed to have carried out but that >>> it's currently too vague only saying that solutions need to >>> consider this. (Essentially this is a continuation of the >>> mail threads from the secdir review [1] and a satisfactory >>> resolution of that will probably resolve this.) >>> >>> [1] >>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>> >>> (2) Metadata that contains information that is protected in >>> the data plane SHOULD be equally well protected when passed >>> about by SFC. I hope that's acceptable and documented. I'm >>> not sure myself if "passed about" ought also include within a >>> device but maybe it should really. But at minimum, I do >>> think you need to define confidentiality and origin >>> authentication services for SFC metadata and/or for the SFC >>> encapsulation as a whole. And I think this architecture >>> document needs to say that those services have to be >>> well-defined as part of any solution. (And I am not >>> saying that this draft needs to define how to do those.) >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> - It occurs to me that it might really be better for the WG >>> to not publish this as an RFC now, but rather to put it on >>> hold until they've made progress on the solutions. Perhaps >>> revistiting this when the solutions are just at WGLC would >>> result in the eventual RFC being a much more useful document. >>> I think this one has to hedge so many bets that it's quite >>> vague and won't be very useful even in the medium term. But >>> that's just a suggestion, I can see why the WG might prefer >>> to push this out, even if that might only give the appearance >>> of progress and not reflect real progress. >>> >>> - While IPR on an architecture document is sad to see, esp >>> with what seems like it may be restrictive licensing, I do >>> see the wg debated that and decided to move on. >>> >>> - The charter text describing this deliverable notes that >>> "The initial scope is restricted to a single administrative >>> domain, keeping in mind that architectural decisions made for >>> the intra-domain case may have implications for the >>> inter-domain case." So I think there is also a currently >>> missing analysis (or the results of that) as to how the >>> single-domain elements of this architecture might impinge on >>> a later inter-domain architecture. So the text at the >>> end of section 1.1 appears to contradict the chartered >>> goals. >>> >>> - Chains will require some representation, and re-ordering >>> that is security sensitive (e.g. swap order of f/w and nat >>> for fun) therefore there must be a requirement for some data >>> integrity service and origin authentication and an >>> authorisation decision function and therefore there must >>> (istm) be a need for the architecture to define a chain >>> producing entity of some kind that could be authenticated. >>> That is an example of the missing security analysis that >>> really is needed before this proceeds. (See my discuss point >>> 2) >>> >>> - 1.1: "classified on ingress" and applicable to mobile >>> networks are slightly incongrous. In the case of WiFi when do >>> the packet ingress? (When it gets to the AP or leaves the >>> mobile node transmitter?) I suspect you really mean the wired >>> bits of a mobile network so it might be better to say that. >>> >>> - 1.2 should follow 1.3 I think. >>> >>> - 1.2: What does "chaining logic" mean? You say there's no >>> standard chaining logic, which is maybe right, but then you >>> imply that a fully ordered set of SF's is a well defined >>> thing. I'm not sure that makes sense. Perhaps what you want >>> to say is that the architecture doesn't determine if an SFC >>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>> protocol work will have to do that. (In fact, I think you >>> could say a lot more here and probably should.) >>> >>> - 1.2: what is a "chaining policy"? Isn't here where those >>> terms need to be defined. >>> >>> - 1.3: SFC definition: by ordered do you mean fully or >>> partially ordered? >>> >>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>> (cf. RFC2804) so better to not drag in the controversy >>> really. Similarly, HOST_ID injection is not afaik any kind of >>> standard and perhaps not likely to be (cf. some confict >>> reviews on the same telechat as this) so I'd also drop that. >>> And I think all of the exemplar SF's should really have a >>> reference (ideally an RFC). >>> >>> - Figure 1 caption is misleading. That seems to me to show a >>> set of paths through (one or more) graphs but doesn't show >>> the full graphs themselves. >>> >>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>> the example given imply that all traffic (of what kind?) that >>> followed SF1->SF2->SF3 on the way "in" must follow >>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>> precision is needed really. The hybrid concept seems even >>> odder to me. >>> >>> - 2.3: How can an SFP "be vague" - surely the point of an >>> architecture is to avoid such vagueness? If you mean that an >>> SFP representation can embody an if-statement then saying >>> that would be the thing to do. >>> >>> - Section 3: I think there's maybe a missing principle here >>> about not making security and privacy worse in general. >>> >>> - 4.1: I wonder if one could ever get enough SFC control >>> traffic that congestion would be an issue? If so, should you >>> say rather that any transport that has some way of handling >>> congestion is ok. If not, then I guess the current text is >>> fine. >>> >>> >>> From nobody Thu May 28 07:42:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D001AD182; Thu, 28 May 2015 07:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6] 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 Ld-U-BM_nhfv; Thu, 28 May 2015 07:42:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C50A11ACE77; Thu, 28 May 2015 07:40:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528144052.22967.42222.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 07:40:52 -0700 Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: [sfc] Benoit Claise's No Record on draft-ietf-sfc-architecture-08: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:42:40 -0000 Benoit Claise has entered the following ballot position for draft-ietf-sfc-architecture-08: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Section 1.1 What does "minimum requirements on the physical topology"mean in: This document defines the architecture for Service Function Chaining (SFC) with minimum requirements on the physical topology of the network, as standardized in the IETF. It seems to me that "independent" is what you're after, like in: "it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities." or "This SFC architecture is predicated on topological independence from the underlying forwarding topology." - Service Function Path definition: I'm confused. you don't explain what it is, but only explain why you need it. Later on, I see "As an example of such an intermediate specificity, there may be two SFPs associated with a given SFC". I'm confused. Not too clear on how the SFP and RSP relate to each others. Is the Service Function Path the ordered list of SFs, while the RSP is the ordered list of SFFs? - "Traffic from SFs eventually returns to the same SFF, which is responsible for injecting traffic back onto the network. Am I correct that it only applies in case of a SFC proxy? Related question, along the same lines: 1. SFP forwarding : Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. Post-SF, the traffic is returned to the SFF, and, if needed, is forwarded to another SF associated with that SFF. If there is another non- local (i.e., different SFF) hop in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Returned to the initial SFF, or to the next SFF in the RSP? I guess the next SFF in the chain (again, unless we speak about a proxy) This would be consistent with section 5.4: "Due to the overlay constraints, the packet-forwarding path may need to visit the same SFF multiple times, and in some less common cases may even need to visit the same SF more than once." - Section 4.4 and 4.6: what about SFC-enabled domain and SFC proxy. In figure 3, the SFC proxy is inside the domain, right? But what about the SFC-unaware Service Function? Inside or outside? - 6. Service function chain independence: The creation, modification, or deletion of an SFC has no impact on other SFCs. The same is true for SFPs. Except if one SF depends on the shared metadata from a previous SF in the chain, right? Editorial. - OLD: SFC Proxy: Removes and inserts SFC encapsulation on behalf of an NEW: SFC Proxy: Removes and inserts SFC Encapsulation on behalf of an THIS TEXT BELOW IS DOCUMENTED FOR THE RECORD (AND THIS DISCUSS-DISCUSS HAS BEEN DISCUSSED) - Can you explain this disconnect: >From the charter: It will produce an architecture for service function chaining that includes the necessary protocols or protocol extensions to convey the Service Function Chain and Service Function Path information to nodes that are involved in the implementation of service functions and Service Function Chains, as well as mechanisms for steering traffic through service functions. >From the abstract: This document does not propose solutions, protocols, or extensions to existing protocols. While I'm on the charter, I'm always available for this milestone: Apr 2014 Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining From nobody Thu May 28 07:45:20 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E4D1ACE65; Thu, 28 May 2015 07:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6] 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 F1wo_qjdI8mJ; Thu, 28 May 2015 07:45:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2C81ACEF0; Thu, 28 May 2015 07:44:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528144454.10612.14109.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 07:44:54 -0700 Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: [sfc] Benoit Claise's No Objection on draft-ietf-sfc-architecture-08: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:45:16 -0000 Benoit Claise has entered the following ballot position for draft-ietf-sfc-architecture-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Section 1.1 What does "minimum requirements on the physical topology"mean in: This document defines the architecture for Service Function Chaining (SFC) with minimum requirements on the physical topology of the network, as standardized in the IETF. It seems to me that "independent" is what you're after, like in: "it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities." or "This SFC architecture is predicated on topological independence from the underlying forwarding topology." - Service Function Path definition: I'm confused. you don't explain what it is, but only explain why you need it. Later on, I see "As an example of such an intermediate specificity, there may be two SFPs associated with a given SFC". I'm confused. Not too clear on how the SFP and RSP relate to each others. Is the Service Function Path the ordered list of SFs, while the RSP is the ordered list of SFFs? - "Traffic from SFs eventually returns to the same SFF, which is responsible for injecting traffic back onto the network. Am I correct that it only applies in case of a SFC proxy? Related question, along the same lines: 1. SFP forwarding : Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. Post-SF, the traffic is returned to the SFF, and, if needed, is forwarded to another SF associated with that SFF. If there is another non- local (i.e., different SFF) hop in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Returned to the initial SFF, or to the next SFF in the RSP? I guess the next SFF in the chain (again, unless we speak about a proxy) This would be consistent with section 5.4: "Due to the overlay constraints, the packet-forwarding path may need to visit the same SFF multiple times, and in some less common cases may even need to visit the same SF more than once." - Section 4.4 and 4.6: what about SFC-enabled domain and SFC proxy. In figure 3, the SFC proxy is inside the domain, right? But what about the SFC-unaware Service Function? Inside or outside? - 6. Service function chain independence: The creation, modification, or deletion of an SFC has no impact on other SFCs. The same is true for SFPs. Except if one SF depends on the shared metadata from a previous SF in the chain, right? Editorial. - OLD: SFC Proxy: Removes and inserts SFC encapsulation on behalf of an NEW: SFC Proxy: Removes and inserts SFC Encapsulation on behalf of an THIS TEXT BELOW IS DOCUMENTED FOR THE RECORD (AND THIS DISCUSS-DISCUSS HAS BEEN DISCUSSED) - Can you explain this disconnect: >From the charter: It will produce an architecture for service function chaining that includes the necessary protocols or protocol extensions to convey the Service Function Chain and Service Function Path information to nodes that are involved in the implementation of service functions and Service Function Chains, as well as mechanisms for steering traffic through service functions. >From the abstract: This document does not propose solutions, protocols, or extensions to existing protocols. While I'm on the charter, I'm always available for this milestone: Apr 2014 Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining From nobody Thu May 28 08:11:44 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E261AD28D; Thu, 28 May 2015 08:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 s-PbY7tEXI9A; Thu, 28 May 2015 08:11:33 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954561AD186; Thu, 28 May 2015 08:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6572; q=dns/txt; s=iport; t=1432825892; x=1434035492; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4eiHE+V1qskn4/T6okVgcyG2ur8qzuYij+fNZCjDsqo=; b=kzlBGmW0/sgtSfIbOq4KTlcKEWnJO8oBnPUB0gGbg8UQvVoh4x/6Myxn ASxoYG6pghn7m/21eRJ3R2cE4Xvq82LXRngqKNIugD6or7LDIzsYQiLot N+4CIgTwtkCbQmKkx14p/B5hRW0I3dIjoWsdGKWFBrcU3+EiOxASDwsKI Y=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABBACYL2dV/4YNJK1cgxBUUQ0Ggxi5ZmYJgVqFdwKBTDgUAQEBAQEBAYEKhCIBAQEDASNWBQsCAQgSBioCAjIXDgIEDgUODYgKCA2wcaQWAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLQ4QhAhEBUQIFgmgvgRYFhmuMHYISgUNghlqBKYNxkhUjYYEFVYE9bwGBAgkXI4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="asc'?scan'208";a="154242818" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 28 May 2015 15:11:31 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4SFBV4l005631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 15:11:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Thu, 28 May 2015 10:11:31 -0500 From: "Carlos Pignataro (cpignata)" To: "Benoit Claise (bclaise)" Thread-Topic: Benoit Claise's No Objection on draft-ietf-sfc-architecture-08: (with COMMENT) Thread-Index: AQHQmVTpxRaqH1qWLkSTH/C2kz7TNJ2R0lAA Date: Thu, 28 May 2015 15:11:30 +0000 Message-ID: References: <20150528144454.10612.14109.idtracker@ietfa.amsl.com> In-Reply-To: <20150528144454.10612.14109.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/signed; boundary="Apple-Mail=_1F1FEBC5-3821-46D3-8F5C-6BD059736742"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Benoit Claise's No Objection on draft-ietf-sfc-architecture-08: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 15:11:38 -0000 --Apple-Mail=_1F1FEBC5-3821-46D3-8F5C-6BD059736742 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Benoit. I believe we=E2=80=99ve addressed all these comments in = our working version, which we will submit when Alia says =E2=80=9CGo!=E2=80= =9D Thanks, =E2=80=94 Carlos. > On May 28, 2015, at 10:44 AM, Benoit Claise (bclaise) = wrote: >=20 > Benoit Claise has entered the following ballot position for > draft-ietf-sfc-architecture-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - Section 1.1 > What does "minimum requirements on the physical topology"mean in: >=20 > This document defines the architecture for Service Function Chaining > (SFC) with minimum requirements on the physical topology of the > network, as standardized in the IETF. >=20 > It seems to me that "independent" is what you're after, like in: > "it describes a method for deploying SFs in a way that enables > dynamic ordering and topological independence of those SFs as well = as > the exchange of metadata between participating entities." >=20 > or > "This SFC architecture is predicated on topological independence = from > the underlying forwarding topology." >=20 >=20 >=20 > - Service Function Path definition: I'm confused. you don't explain = what > it is, but only explain why you need it. > Later on, I see "As an example of such an intermediate specificity, = there > may be two > SFPs associated with a given SFC". I'm confused. > Not too clear on how the SFP and RSP relate to each others. > Is the Service Function Path the ordered list of SFs, while the RSP is > the ordered list of SFFs? >=20 > - > "Traffic from SFs eventually returns to the same SFF, which is > responsible for injecting traffic back onto the network. >=20 > Am I correct that it only applies in case of a SFC proxy? > Related question, along the same lines: >=20 > 1. SFP forwarding : Traffic arrives at an SFF from the network. > The > SFF determines the appropriate SF the traffic should be = forwarded > to via information contained in the SFC encapsulation. Post-SF, > the traffic is returned to the SFF, and, if needed, is forwarded > to another SF associated with that SFF. If there is another = non- > local (i.e., different SFF) hop in the SFP, the SFF further > encapsulates the traffic in the appropriate network transport > protocol and delivers it to the network for delivery to the next > SFF along the path. >=20 > Returned to the initial SFF, or to the next SFF in the RSP? > I guess the next SFF in the chain (again, unless we speak about a = proxy) >=20 > This would be consistent with section 5.4: > "Due to the overlay constraints, the packet-forwarding path may > need to visit the same SFF multiple times, and in some less common > cases may even need to visit the same SF more than once." >=20 >=20 > - Section 4.4 and 4.6: what about SFC-enabled domain and SFC proxy. > In figure 3, the SFC proxy is inside the domain, right? > But what about the SFC-unaware Service Function? Inside or outside? >=20 > - > 6. Service function chain independence: The creation, modification, > or deletion of an SFC has no impact on other SFCs. The same is > true for SFPs. >=20 > Except if one SF depends on the shared metadata from a previous SF in = the > chain, right? >=20 >=20 > Editorial. >=20 > - > OLD: > SFC Proxy: Removes and inserts SFC encapsulation on behalf of an > NEW: > SFC Proxy: Removes and inserts SFC Encapsulation on behalf of an >=20 >=20 > THIS TEXT BELOW IS DOCUMENTED FOR THE RECORD (AND THIS = DISCUSS-DISCUSS > HAS BEEN DISCUSSED) >=20 > - Can you explain this disconnect: >> =46rom the charter: >=20 > It will produce an architecture for service function > chaining that includes the necessary protocols or protocol = extensions > to > convey the Service Function Chain and Service Function Path > information > to nodes that are involved in the implementation of service > functions > and Service Function Chains, as well as mechanisms for steering > traffic > through service functions. >=20 >> =46rom the abstract: >=20 > This document does not propose solutions, protocols, or > extensions to existing protocols. >=20 > While I'm on the charter, I'm always available for this milestone: >=20 > Apr 2014 Consult with OPS area on possible SFC charter = modifications > for management and configuration of SFC components related to the = support > of Service Function Chaining >=20 >=20 --Apple-Mail=_1F1FEBC5-3821-46D3-8F5C-6BD059736742 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZzAjAAoJEIXgpQGOZny9eHkQAIj27r6z/jGqWZnpLm8qw9GC XonIB+I1azan31WKwlTE/IbumGENfY9j12CsyHQd0cWVd+GUlh2aCShlDqVlJzdW x297RTVgCGYMTNgZlEeZZzpD5APaa8kvDCP3E2VW0OmDcVJaximy+gDlNY/tRgMX cmNvoFK29tGyyAC7EzL4+IDvigNImiUfQ8bJlVfv870eXirFdmylScRPhrO3SwIA oLGKej4Uno2owYhaEzYurJwOjMyk/3QMMS1lo2J1rS6h/ZpUUwCIgu8H2eXSXZlo kyqr3G7011a+YZaqJoaODnGvH7+dOvxdE57xtrFFtaFFiGWG3asl4KoNvAy1q2hA oFciDvcKddEqkLdOE0p8V8+ffeJJ8Mdwe0lG7PM8br90zkGt1PbNZL5J3G+fGgBp gbGbm+bYxTcoclYr5i39vtF1cKnMkOydWZO3PqFVL0agTZcfBFw6HTMgLd7ljWme CmOabo5hyNTiWlJrXOLVlAJhslXigijHZkcSWm10pGOmHB3D2aJcbPL/qD1tXVXe uwceyKOmqnKO92t+4Jk8m2rSMUaaBXHkvVDZN4cpq6GHFKZrEglZ6c1VcHTu+y4f z946k/mR0lYBk1AlSGiMlzrmDkQxUFXyK8d8wYoK2DBZTuMpEEckklTgXZNvBGAC cBU3OAqYpGpmr1+AqdMA =eKdt -----END PGP SIGNATURE----- --Apple-Mail=_1F1FEBC5-3821-46D3-8F5C-6BD059736742-- From nobody Thu May 28 08:15:44 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0A1A8A23; Thu, 28 May 2015 06:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wmlcf18LaUjd; Thu, 28 May 2015 06:59:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CB31A889A; Thu, 28 May 2015 06:59:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 41890BEE7; Thu, 28 May 2015 14:59:38 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GBhxQWP4wkP; Thu, 28 May 2015 14:59:38 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0BC3ABEF6; Thu, 28 May 2015 14:59:38 +0100 (IST) Message-ID: <55671F49.20605@cs.tcd.ie> Date: Thu, 28 May 2015 14:59:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , Alia Atlas References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 28 May 2015 08:15:41 -0700 Cc: sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.ad@ietf.org, "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.shepherd@ietf.org, Alvaro Retana , draft-ietf-sfc-architecture@ietf.org, The IESG Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:59:45 -0000 On 28/05/15 14:56, Barry Leiba wrote: >> I don't see anything specifically implementable in this architecture. I >> can't see how it could proceed >> from PS to IS. That isn't the case for all architecture docs, but for this >> one, I think that Informational is fine. > > I could see how the proposed architecture could be refined and > eventually moved past "proposed", but that's not the main point I'm > thinking about. For me, it's a question of the type of review > Standards Track documents get ("Is this document a reasonable basis on > which to build the salient part of the Internet infrastructure? If > not, what changes would make it so?") as compared with Informational > ("Is this document a reasonable contribution to the area of Internet > engineering which it covers? If not, what changes would make it so?"). > > We are proposing the former: building a significant part of the > Internet infrastructure on this. I don't care about the RFC status. But one of my comments was to the effect that I think this would be much more useful if the WG took it back and put it on ice until they'd developed the protocol and then go back and tweak this. I think the result would be much more useful then. (And would be obviously a thing for the standards track, I bet.) S. > > Barry > From nobody Thu May 28 08:15:45 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AC11AC3CD; Thu, 28 May 2015 07:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 f1CfFaulqS7x; Thu, 28 May 2015 07:07:44 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7A91ACD3C; Thu, 28 May 2015 07:07:43 -0700 (PDT) Received: by obbea2 with SMTP id ea2so33476051obb.3; Thu, 28 May 2015 07:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WDkMPzz1atpn7HeYDXlw0WtU38Jw3Pq44KIID/0Aolk=; b=joghCK9gMXQoYWjxdB2rvxzj1FOoJd/YdS6ZxHcoRBjpOudf2bPEDvB6NmBwMmWdIn DaUo4B5X85VSUTNkq8UoKMRC88bd/3bgun7adtWz5LTXzOup8LtoL8OSsa3DPX0utnBw Ul4VGaZSWXLVa1ZwF96EqNR+PkwT0YfoRDZ3VVYUHx1GBCsRq0xevQCRToUTEMiCi7Zz 2ftn3PHvroTXMq4I1Ih1FyeX64PtGoMEmAnzUJhfg9ObpD9D89GvpTnAETojPYeAdiMi wrwuhtTBEHUe42tWk/9VD97EQODuqguRB1H789eShjBVkhxX09WCcWzwikmYk1FwEEiB IYDQ== MIME-Version: 1.0 X-Received: by 10.202.175.87 with SMTP id y84mr2540634oie.22.1432822063076; Thu, 28 May 2015 07:07:43 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Thu, 28 May 2015 07:07:42 -0700 (PDT) In-Reply-To: <55671F49.20605@cs.tcd.ie> References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> <55671F49.20605@cs.tcd.ie> Date: Thu, 28 May 2015 10:07:42 -0400 Message-ID: From: Alia Atlas To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113ce638189c93051724e2d1 Archived-At: X-Mailman-Approved-At: Thu, 28 May 2015 08:15:42 -0700 Cc: draft-ietf-sfc-architecture@ietf.org, sfc-chairs@ietf.org, "sfc@ietf.org" , draft-ietf-sfc-architecture.ad@ietf.org, "Jim Guichard \(jguichar\)" , draft-ietf-sfc-architecture.shepherd@ietf.org, Alvaro Retana , Barry Leiba , The IESG Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 14:07:48 -0000 --001a113ce638189c93051724e2d1 Content-Type: text/plain; charset=UTF-8 Stephen, On Thu, May 28, 2015 at 9:59 AM, Stephen Farrell wrote: > > > On 28/05/15 14:56, Barry Leiba wrote: > >> I don't see anything specifically implementable in this architecture. I > >> can't see how it could proceed > >> from PS to IS. That isn't the case for all architecture docs, but for > this > >> one, I think that Informational is fine. > > > > I could see how the proposed architecture could be refined and > > eventually moved past "proposed", but that's not the main point I'm > > thinking about. For me, it's a question of the type of review > > Standards Track documents get ("Is this document a reasonable basis on > > which to build the salient part of the Internet infrastructure? If > > not, what changes would make it so?") as compared with Informational > > ("Is this document a reasonable contribution to the area of Internet > > engineering which it covers? If not, what changes would make it so?"). > > > > We are proposing the former: building a significant part of the > > Internet infrastructure on this. > > I don't care about the RFC status. > > But one of my comments was to the effect that I think this > would be much more useful if the WG took it back and put > it on ice until they'd developed the protocol and then go > back and tweak this. I think the result would be much more > useful then. (And would be obviously a thing for the > standards track, I bet.) > I did see that suggestion. The WG has been focusing on the architecture and encapsulation. There are many different ways of doing the protocol and the WG is just barely starting to consider discussing them. I do agree that the architecture is a carefully crafted compromise. Alia > S. > > > > > Barry > > > --001a113ce638189c93051724e2d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephen,

On Thu, May 28, 2015 at 9:59 AM, Stephen Farrell = <stephen.= farrell@cs.tcd.ie> wrote:
<= div class=3D"HOEnZb">


On 28/05/15 14:56, Barry Leiba wrote:
>> I don't see anything specifically implementable in this archit= ecture.=C2=A0 I
>> can't see how it could proceed
>> from PS to IS.=C2=A0 That isn't the case for all architecture = docs, but for this
>> one, I think that Informational is fine.
>
> I could see how the proposed architecture could be refined and
> eventually moved past "proposed", but that's not the mai= n point I'm
> thinking about.=C2=A0 For me, it's a question of the type of revie= w
> Standards Track documents get ("Is this document a reasonable bas= is on
> which to build the salient part of the Internet infrastructure? If
> not, what changes would make it so?") as compared with Informatio= nal
> ("Is this document a reasonable contribution to the area of Inter= net
> engineering which it covers? If not, what changes would make it so?&qu= ot;).
>
> We are proposing the former: building a significant part of the
> Internet infrastructure on this.

I don't care about the RFC status.

But one of my comments was to the effect that I think this
would be much more useful if the WG took it back and put
it on ice until they'd developed the protocol and then go
back and tweak this. I think the result would be much more
useful then. (And would be obviously a thing for the
standards track, I bet.)

I did see that= suggestion.=C2=A0 The WG has been focusing on the architecture and
encapsulation.=C2=A0 There are many different ways of doing the protocol= and the
WG is just barely starting to consider discussing them.= =C2=A0 I do agree that the
architecture is a carefully crafted co= mpromise.=C2=A0

Alia
=C2=A0
S.

>
> Barry
>

--001a113ce638189c93051724e2d1-- From nobody Thu May 28 09:40:13 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222CD1A039B; Thu, 28 May 2015 09:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 dTbghsJoqbB9; Thu, 28 May 2015 09:40:06 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEABE1A1A40; Thu, 28 May 2015 09:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14236; q=dns/txt; s=iport; t=1432831186; x=1434040786; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RHJXOwbiurk/r2sA4weeNBSwW1DLLwKP4GM8wz42DHc=; b=UUwULDztNlypA+zmtxMpYv6B5fHuXf0iu7UWdcMBNbV1+VeTboVmE0G2 WgR/f6su9jZHM+hstdNMhu98Ld5CWAv1086CO8EWUk0sQmivx+j4+4Avw RIvjqqlkc6itVJd9MLWyRZIelSj1LtxFUiH+AHAyS+b31drmzCE2CkUTG E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQCBQ2dV/4ENJK1cgxCBMgaDGLlrb4dRAoFMORMBAQEBAQEBgQqEIgEBAQMBI1YFCwIBCBIGJwMCAiERFAMOAgQOBQ6ICgMKCLEynwgNhH4BAQEBAQEBAQEBAQEBAQEBAQEBARiLQ4JNgVYRAVEHgmgvgRYFhmuMHYISgUOFYYFZgSmDcYsSgyqDWSNhgSkcFYE9bwGBCzqBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="asc'?scan'208,217";a="154093995" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 28 May 2015 16:39:45 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4SGdiXS001377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 16:39:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 28 May 2015 11:39:44 -0500 From: "Carlos Pignataro (cpignata)" To: Kathleen Moriarty Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmVFPkEdW80Ovx0KvMcwtrOuud52RxuAAgAAkHYA= Date: Thu, 28 May 2015 16:39:43 +0000 Message-ID: <4C97F2B0-7AAE-49A4-9D63-65B5494AABBE@cisco.com> References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> <556723E0.5040603@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/signed; boundary="Apple-Mail=_B3D68E0F-6783-4329-BC2E-9DA2DADB58D4"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "Joel M. Halpern" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "Jim Guichard \(jguichar\)" , The IESG , "draft-ietf-sfc-architecture@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 16:40:08 -0000 --Apple-Mail=_B3D68E0F-6783-4329-BC2E-9DA2DADB58D4 Content-Type: multipart/alternative; boundary="Apple-Mail=_629F4067-38BF-4D54-9EAF-032CC0AA6726" --Apple-Mail=_629F4067-38BF-4D54-9EAF-032CC0AA6726 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kathleen, Thank you for taking the time to review this document. I am responding to this email on the thread, because I think it is the = one that most clearly explains your concerns. I also include an = additional clarification you wrote on a different email, all below for = context. Below you say: =E2=80=9CI'm concerned about privacy of data that is in a payload that = may be used in the SFC architecture.=E2=80=9D and =E2=80=9Cyou are pulling that content out and using it in ways that may = not have been intended by those who created it and didn't encrypt it.=E2=80= =9D I am also having some trouble exemplifying and visualizing your concern, = and how to address it. Could you please, perhaps, be more explicit as to how =E2=80=98content = is pulled from the payload and used in unintended ways=E2=80=99? What = exactly do you have in mind? Can you share an example? The payload is being used to classify =E2=80=94 what other unintended = use do you see? Classification based on inspecting a payload is certainly not a new = element created by this architecture. Thanks, =E2=80=94 Carlos. > On May 28, 2015, at 10:10 AM, Kathleen Moriarty = wrote: >=20 > Hi Joel, >=20 > On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern > wrote: > I do not know what it would mean to apply privacy to information that = is > a) gathered from a payload > b) and delivered along with that unprotected payload? >=20 > If you go back to the text in my discuss, I'm concerned about privacy = of data that is in a payload that may be used in the SFC architecture. = I am not saying that you have to apply privacy, just that it may be = exposed when payloads are accessed and used. >=20 > Thanks, > Kathleen >=20 [=E2=80=A6] > On May 28, 2015, at 10:30 AM, Kathleen Moriarty = wrote: >=20 >=20 >=20 > On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern > wrote: > I am missing your point. Sorry. If it is in the payload, it is = exposed. If the payload is protected from exposure, then SFC won't be = able to extract it, so can't expose it. We are clear already in the = document that SFC metadata has to be protected from exposure outside of = the domain, noit because it is in the payload, but for cases where it is = derived from other sources that may be sensitive. >=20 > Right, but you are pulling that content out and using it in ways that = may not have been intended by those who created it and didn't encrypt = it. This raises the security/privacy concern that their data may be = used in ways they did not intend and be put into places they didn't = expect. If it's data that has to be tracked for record retention, = through an ESI data map or similar, its one more place this data resides = that needs to be tracked. If the warning is there that this could = happen and is a possible privacy concern, my point is addressed. >=20 > Thank you, > Kathleen >=20 >=20 > So I have real trouble figuring out how to address this concern. >=20 >=20 > = ---------------------------------------------------------------------- > DISCUSS: > = ---------------------------------------------------------------------- >=20 > I agree with Stephen's discuss and comment points and am just > adding a > few that I think are also important. >=20 > 1. The Security Considerations section only talks about = privacy > of the > SFC information for classification. The more important point > may be the > privacy of any data gathered from a payload used for the > classification > and this needs to be mentioned. >=20 >=20 > = ---------------------------------------------------------------------- > COMMENT: > = ---------------------------------------------------------------------- >=20 >=20 >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen --Apple-Mail=_629F4067-38BF-4D54-9EAF-032CC0AA6726 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kathleen,

Thank you for taking the time to review this = document.

I am = responding to this email on the thread, because I think it is the one = that most clearly explains your concerns. I also include an additional = clarification you wrote on a different email, all below for = context.

Below = you say:
=E2=80=9CI'm concerned about = privacy of data that is in a payload that may be used in the SFC = architecture.=E2=80=9D
and
=E2=80=9Cyou are pulling that content out and = using it in ways that may not have been intended by those who created it = and didn't encrypt it.=E2=80=9D

I am also having some trouble = exemplifying and visualizing your concern, and how to address = it.

Could you = please, perhaps, be more explicit as to how =E2=80=98content is pulled = from the payload and used in unintended ways=E2=80=99? What exactly do = you have in mind? Can you share an example?

The payload is being used to classify = =E2=80=94 what other unintended use do you see?

Classification based on inspecting a = payload is certainly not a new element created by this = architecture.

Thanks,

=E2=80=94 Carlos.

On May 28, 2015, at 10:10 AM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi Joel,

On Thu, May 28, 2015 at 10:06 AM, = Joel M. Halpern <jmh@joelhalpern.com> wrote:
I do not know what = it would mean to apply privacy to information that is
a) = gathered from a payload
b) and delivered along with that = unprotected payload?
 
If you go back to the text in my = discuss, I'm concerned about privacy of data that is in a payload that = may be used in the SFC architecture.  I am not saying that you have = to apply privacy, just that it may be exposed when payloads are accessed = and used. 

Thanks,
Kathleen


[=E2=80=A6]
=

On May 28, 2015, at 10:30 AM, Kathleen = Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Thu, = May 28, 2015 at 10:19 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
I am missing your = point.  Sorry.  If it is in the payload, it is exposed.  = If the payload is protected from exposure, then SFC won't be able to = extract it, so can't expose it.  We are clear already in the = document that SFC metadata has to be protected from exposure outside of = the domain, noit because it is in the payload, but for cases where it is = derived from other sources that may be sensitive.

Right, but you are pulling = that content out and using it in ways that may not have been intended by = those who created it and didn't encrypt it.  This raises the = security/privacy concern that their data may be used in ways they did = not intend and be put into places they didn't expect.  If it's data = that has to be tracked for record retention, through an ESI data map or = similar, its one more place this data resides that needs to be = tracked.  If the warning is there that this could happen and is a = possible privacy concern, my point is addressed.

Thank you,
Kathleen

 
So I have real trouble figuring out how to address this concern.


        = ----------------------------------------------------------------------
        DISCUSS:
        = ----------------------------------------------------------------------

        I agree with Stephen's discuss and comment = points and am just
        adding a
        few that I think are also important.

        1. The Security Considerations section only = talks about privacy
        of the
        SFC information for classification.  = The more important point
        may be the
        privacy of any data gathered from a payload = used for the
        classification
        and this needs to be mentioned.
=

        = ----------------------------------------------------------------------
        COMMENT:
        = ----------------------------------------------------------------------





--

Best regards,
Kathleen



--

Best regards,
Kathleen

= --Apple-Mail=_629F4067-38BF-4D54-9EAF-032CC0AA6726-- --Apple-Mail=_B3D68E0F-6783-4329-BC2E-9DA2DADB58D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZ0TRAAoJEIXgpQGOZny9DNUQALFWxDqD7vM5DkMlC/V4LNnM cDc8PVmjMMpclOGuf4ZWfw9y5RjlOGQu4gCo4uEum3n8e5C8nNCvYzXEqJhTWIQl wJJEo02z8MXWwZc9poXtMXg2/g3qVnasI/NkvE9vpEgEIuhd4qhQ0Lmwm5T25BxV czF+z1g3JoDL6p7vEkcW0jE6bUnxqf0gdLcTNPsys3vKbmf7oVRn0B1DlWv1NHZl q68FlHBFQwRC78X+kaJi3nQQkunKwyAGoHau3K4TEBBlk0dQ+kID/mz1qj5xUHsm gj5417fP1Quoo9Q7aceYHXeO2UsH66HxCxwkyU2r2ci6lVPON0KDERWJUrpPFHx8 TnPvGwF0yOPKfDPDGcYC0DgE3TtidXpz/lK7fMTVNxyOHAF/8r6XAbugnrFGn8Tn rwY2ulLFvOH6zdGNPjl0i2tDboI/ZI3tEGJ8MQbo0vIrunuWOSzHKw1uSbRWFNST 6pTaYP1rmi7/a1wSzV57dtlUVXfL/DuVOR2n1Y5FC+/CXtgSfy02xudb8xtIxUAI Ad3qPq+gKWI38pLiSIHJUhcYjPqdOe4UBEpgzoay76DwDzGGf6FW7gptAIvf0k91 0v5uMS4/cyKXQ3PLkMLzOfoRqQioYEkJ+qZ9Q0N4lycgBxT1mlXs2jcPqNyNvCve f5iW5hhaZ/DdrpESOzCF =6O2s -----END PGP SIGNATURE----- --Apple-Mail=_B3D68E0F-6783-4329-BC2E-9DA2DADB58D4-- From nobody Thu May 28 09:47:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B1E1A1A46; Thu, 28 May 2015 09:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 ixsL3P4n3Bc7; Thu, 28 May 2015 09:47:17 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E5D1A0398; Thu, 28 May 2015 09:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10690; q=dns/txt; s=iport; t=1432831636; x=1434041236; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jL4/S8j3Ra684apQL4qK9uT+JAAjSOQVubeXvRc/uKI=; b=fn5gB74xImTRVFHrIhiShn4rcbVm5hsWVkqAfXe4kONX6uu14ecQ8znt K7a6NJiDSJ79jAl+riLVXduEOncDMOGwUMg1rIEJsSa1fN454F48oY9RG pmEqYnmUopurqT/wYahr7Rnu/VAaGyW3kOQt7D8TVP5lVNSquldE7GLyE k=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABBADeRWdV/4QNJK1cgxBUXgaDGLlsZgmBWoUtSgKBTDgUAQEBAQEBAYEKhCIBAQEDASMEQAkJBQsCAQgSBioCAjIXDgIEDgUODYgKCA2xJ6QSAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLQ4QjEAIBUAIFgmgvgRYFhmuMHYISgUNggk+EC4Epg3GSFSNhgQUkBRcVgT1vAYFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="asc'?scan'208";a="154127982" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP; 28 May 2015 16:47:15 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4SGlFOl027622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 16:47:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 28 May 2015 11:47:14 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmUU9UNzRkq1wJU2Wvlf+qhp5bp2Rv2+AgAAI/ICAAADkAIAAI9+A Date: Thu, 28 May 2015 16:47:14 +0000 Message-ID: <73AFBBC8-4E77-40DC-8976-28A7BBE0B88A@cisco.com> References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> In-Reply-To: <5567287C.6080905@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/signed; boundary="Apple-Mail=_DDAFFBF1-0979-4A20-994D-F8C1569C2BF9"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Stephen Farrell , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.ad@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 16:47:19 -0000 --Apple-Mail=_DDAFFBF1-0979-4A20-994D-F8C1569C2BF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephen, > On May 28, 2015, at 10:38 AM, Joel M. Halpern = wrote: >=20 > IF A, B, and C are service function forwarders (SFF), with a TLS = protected link for SFC, then the metadata will be protected. (Such a = link would be a transport mechanism, which SFC does not describe or = mandate. The SFC architecture is transport agnostic.) >=20 Further to this point, the =E2=80=9CService Overlay=E2=80=9D section of = the =E2=80=9CSecurity Considerations=E2=80=9D already covers this (see = last sentence). The example below would equally protect the metadata created at A as the = payload. Thanks, =E2=80=94 Carlos. > If A, B, and C are service functions used by SFC, then there is no = link between B and C, so it can't be protected by TLS. >=20 > So I can not see what more needs to be said? >=20 > Yours, > Joel >=20 > On 5/28/15 10:35 AM, Stephen Farrell wrote: >>=20 >>=20 >> On 28/05/15 15:03, Joel M. Halpern wrote: >>> I am not sure what you mean by "Metadata that contains information = that >>> is protected in the data plane". Most of what ends up in the = metadata >>> is information that is passed on other interfaces directly to = relevant >>> functions, or locally determine and locally processed. >>=20 >> So what I had in mind were things like the following. >>=20 >> - Packet is sent along a SFP A,B,C >> - B to C link is via say a TLS VPN >> - Metadata is created at A and is in the SFC encapsulation >> and not protected by the VPN >> - That seems bad >>=20 >> S. >>=20 >>=20 >>>=20 >>> The protection used for policy systems (which provide much of the >>> information) is based on the presence of persistent connections and >>> usage which crosses domains. Are you arguing that if AAA is = encrypted >>> then policy delivered by AAA resulting in metadata in the packet = must be >>> encrypted in the data packets? >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-sfc-architecture-08: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>>=20 >>>> (1) I note the charter calls for this deliverable to "provide >>>> a description of... security models" The charter also >>>> generally notes that "The SFC WG will closely consider and >>>> address the management and security implications when >>>> documenting these deliverables." My conclusion is that this >>>> deliverable needs to reflect the results of a security >>>> analysis that the wg are suppoed to have carried out but that >>>> it's currently too vague only saying that solutions need to >>>> consider this. (Essentially this is a continuation of the >>>> mail threads from the secdir review [1] and a satisfactory >>>> resolution of that will probably resolve this.) >>>>=20 >>>> [1] >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>=20 >>>> (2) Metadata that contains information that is protected in >>>> the data plane SHOULD be equally well protected when passed >>>> about by SFC. I hope that's acceptable and documented. I'm >>>> not sure myself if "passed about" ought also include within a >>>> device but maybe it should really. But at minimum, I do >>>> think you need to define confidentiality and origin >>>> authentication services for SFC metadata and/or for the SFC >>>> encapsulation as a whole. And I think this architecture >>>> document needs to say that those services have to be >>>> well-defined as part of any solution. (And I am not >>>> saying that this draft needs to define how to do those.) >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>>=20 >>>> - It occurs to me that it might really be better for the WG >>>> to not publish this as an RFC now, but rather to put it on >>>> hold until they've made progress on the solutions. Perhaps >>>> revistiting this when the solutions are just at WGLC would >>>> result in the eventual RFC being a much more useful document. >>>> I think this one has to hedge so many bets that it's quite >>>> vague and won't be very useful even in the medium term. But >>>> that's just a suggestion, I can see why the WG might prefer >>>> to push this out, even if that might only give the appearance >>>> of progress and not reflect real progress. >>>>=20 >>>> - While IPR on an architecture document is sad to see, esp >>>> with what seems like it may be restrictive licensing, I do >>>> see the wg debated that and decided to move on. >>>>=20 >>>> - The charter text describing this deliverable notes that >>>> "The initial scope is restricted to a single administrative >>>> domain, keeping in mind that architectural decisions made for >>>> the intra-domain case may have implications for the >>>> inter-domain case." So I think there is also a currently >>>> missing analysis (or the results of that) as to how the >>>> single-domain elements of this architecture might impinge on >>>> a later inter-domain architecture. So the text at the >>>> end of section 1.1 appears to contradict the chartered >>>> goals. >>>>=20 >>>> - Chains will require some representation, and re-ordering >>>> that is security sensitive (e.g. swap order of f/w and nat >>>> for fun) therefore there must be a requirement for some data >>>> integrity service and origin authentication and an >>>> authorisation decision function and therefore there must >>>> (istm) be a need for the architecture to define a chain >>>> producing entity of some kind that could be authenticated. >>>> That is an example of the missing security analysis that >>>> really is needed before this proceeds. (See my discuss point >>>> 2) >>>>=20 >>>> - 1.1: "classified on ingress" and applicable to mobile >>>> networks are slightly incongrous. In the case of WiFi when do >>>> the packet ingress? (When it gets to the AP or leaves the >>>> mobile node transmitter?) I suspect you really mean the wired >>>> bits of a mobile network so it might be better to say that. >>>>=20 >>>> - 1.2 should follow 1.3 I think. >>>>=20 >>>> - 1.2: What does "chaining logic" mean? You say there's no >>>> standard chaining logic, which is maybe right, but then you >>>> imply that a fully ordered set of SF's is a well defined >>>> thing. I'm not sure that makes sense. Perhaps what you want >>>> to say is that the architecture doesn't determine if an SFC >>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>> protocol work will have to do that. (In fact, I think you >>>> could say a lot more here and probably should.) >>>>=20 >>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>> terms need to be defined. >>>>=20 >>>> - 1.3: SFC definition: by ordered do you mean fully or >>>> partially ordered? >>>>=20 >>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>> (cf. RFC2804) so better to not drag in the controversy >>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>> standard and perhaps not likely to be (cf. some confict >>>> reviews on the same telechat as this) so I'd also drop that. >>>> And I think all of the exemplar SF's should really have a >>>> reference (ideally an RFC). >>>>=20 >>>> - Figure 1 caption is misleading. That seems to me to show a >>>> set of paths through (one or more) graphs but doesn't show >>>> the full graphs themselves. >>>>=20 >>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>> the example given imply that all traffic (of what kind?) that >>>> followed SF1->SF2->SF3 on the way "in" must follow >>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>> precision is needed really. The hybrid concept seems even >>>> odder to me. >>>>=20 >>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>> architecture is to avoid such vagueness? If you mean that an >>>> SFP representation can embody an if-statement then saying >>>> that would be the thing to do. >>>>=20 >>>> - Section 3: I think there's maybe a missing principle here >>>> about not making security and privacy worse in general. >>>>=20 >>>> - 4.1: I wonder if one could ever get enough SFC control >>>> traffic that congestion would be an issue? If so, should you >>>> say rather that any transport that has some way of handling >>>> congestion is ok. If not, then I guess the current text is >>>> fine. >>>>=20 >>>>=20 >>>>=20 --Apple-Mail=_DDAFFBF1-0979-4A20-994D-F8C1569C2BF9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZ0aTAAoJEIXgpQGOZny9WkQQAKmhRMEc/8L2fZPDlWMwi9uG xMOb2Wo9v9UirFQ0apYCA8jWF1qVZUKdY9iIyAK4o4DOuLAO3TS0lvQvTd+LgvrO BMeXf+XhNA/hEkIJyyItLZablfQKGaoZH+FHKAJsX+mbMKFMx+xFi/W8O313nAll n8cVY+XAgVFxcR0V50KvPw2MU16FQxsj/wisSR87H0r9Nx2aGGs67Sz7wDJ48V4/ ILgOn/sKbBXOO59Pyf7lesZ4k/jyYVhcWaOg2JqAbnsZ54eUdpdcp17uJfPpV5JK GRC5pFFUyaMqTXrnqJVhkJTI4plGonYQFoXZVWV/jqdwZGR67oMIEkvORHPUB14i 8ura1jV05tG6kxpOhZaDEwxhdyN0kQT9RQm7lksoNnHgZAKhmTkbX/TXxuZPJQiK fbQoUz5uRuDs9lal3bNfaQKOvmE8GafZZ4zPKRuOHHIUm6iDPsuDWDVXES0DaNiW 6HVlATxyx5bsbjV0V1uQ91ARUS4lmUbTgrcptiBDLmrig+gfVpnJrVNM69a5aZ2F +RJPH6nJwXgFDQCO7ORX1KlvNAadk1GrSP9RtXLz1WwUYa67sZE0PjpN4qAnpaAj ZZTiy57XCamehyNkUpARyfmyE+6q6F4k7P966laQqOOHx8+M/mIL0+GiiG7SYCou QgGz2IxGA0ERCWW2eNIp =yOKQ -----END PGP SIGNATURE----- --Apple-Mail=_DDAFFBF1-0979-4A20-994D-F8C1569C2BF9-- From nobody Thu May 28 10:05:45 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702A01A1BFF; Thu, 28 May 2015 10:05:40 -0700 (PDT) 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, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 i4P1-XNKB-P7; Thu, 28 May 2015 10:05:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178341A1BE3; Thu, 28 May 2015 10:05:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B99EABEF5; Thu, 28 May 2015 18:05:31 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cfsm__1r38CH; Thu, 28 May 2015 18:05:31 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8620EBEB6; Thu, 28 May 2015 18:05:31 +0100 (IST) Message-ID: <55674AD7.6030408@cs.tcd.ie> Date: Thu, 28 May 2015 18:05:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , "Joel M. Halpern" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <73AFBBC8-4E77-40DC-8976-28A7BBE0B88A@cisco.com> In-Reply-To: <73AFBBC8-4E77-40DC-8976-28A7BBE0B88A@cisco.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L8mrT0hOCdqRoUo3VjexNNDMVKRqOTgIi" Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 17:05:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L8mrT0hOCdqRoUo3VjexNNDMVKRqOTgIi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I have to say I'm not understanding either your or Joel's responses here but I'll look at it again later on (don't have time now). S. On 28/05/15 17:47, Carlos Pignataro (cpignata) wrote: > Stephen, >=20 >> On May 28, 2015, at 10:38 AM, Joel M. Halpern wr= ote: >> >> IF A, B, and C are service function forwarders (SFF), with a TLS prote= cted link for SFC, then the metadata will be protected. (Such a link wou= ld be a transport mechanism, which SFC does not describe or mandate. The= SFC architecture is transport agnostic.) >> >=20 > Further to this point, the =E2=80=9CService Overlay=E2=80=9D section of= the =E2=80=9CSecurity Considerations=E2=80=9D already covers this (see l= ast sentence). >=20 > The example below would equally protect the metadata created at A as th= e payload. >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> If A, B, and C are service functions used by SFC, then there is no lin= k between B and C, so it can't be protected by TLS. >> >> So I can not see what more needs to be said? >> >> Yours, >> Joel >> >> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>> >>> >>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>> I am not sure what you mean by "Metadata that contains information t= hat >>>> is protected in the data plane". Most of what ends up in the metada= ta >>>> is information that is passed on other interfaces directly to releva= nt >>>> functions, or locally determine and locally processed. >>> >>> So what I had in mind were things like the following. >>> >>> - Packet is sent along a SFP A,B,C >>> - B to C link is via say a TLS VPN >>> - Metadata is created at A and is in the SFC encapsulation >>> and not protected by the VPN >>> - That seems bad >>> >>> S. >>> >>> >>>> >>>> The protection used for policy systems (which provide much of the >>>> information) is based on the presence of persistent connections and >>>> usage which crosses domains. Are you arguing that if AAA is encrypt= ed >>>> then policy delivered by AAA resulting in metadata in the packet mus= t be >>>> encrypted in the data packets? >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-sfc-architecture-08: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to a= ll >>>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteri= a.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here:= >>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------= --- >>>>> DISCUSS: >>>>> -------------------------------------------------------------------= --- >>>>> >>>>> >>>>> (1) I note the charter calls for this deliverable to "provide >>>>> a description of... security models" The charter also >>>>> generally notes that "The SFC WG will closely consider and >>>>> address the management and security implications when >>>>> documenting these deliverables." My conclusion is that this >>>>> deliverable needs to reflect the results of a security >>>>> analysis that the wg are suppoed to have carried out but that >>>>> it's currently too vague only saying that solutions need to >>>>> consider this. (Essentially this is a continuation of the >>>>> mail threads from the secdir review [1] and a satisfactory >>>>> resolution of that will probably resolve this.) >>>>> >>>>> [1] >>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>> >>>>> (2) Metadata that contains information that is protected in >>>>> the data plane SHOULD be equally well protected when passed >>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>> not sure myself if "passed about" ought also include within a >>>>> device but maybe it should really. But at minimum, I do >>>>> think you need to define confidentiality and origin >>>>> authentication services for SFC metadata and/or for the SFC >>>>> encapsulation as a whole. And I think this architecture >>>>> document needs to say that those services have to be >>>>> well-defined as part of any solution. (And I am not >>>>> saying that this draft needs to define how to do those.) >>>>> >>>>> >>>>> -------------------------------------------------------------------= --- >>>>> COMMENT: >>>>> -------------------------------------------------------------------= --- >>>>> >>>>> >>>>> - It occurs to me that it might really be better for the WG >>>>> to not publish this as an RFC now, but rather to put it on >>>>> hold until they've made progress on the solutions. Perhaps >>>>> revistiting this when the solutions are just at WGLC would >>>>> result in the eventual RFC being a much more useful document. >>>>> I think this one has to hedge so many bets that it's quite >>>>> vague and won't be very useful even in the medium term. But >>>>> that's just a suggestion, I can see why the WG might prefer >>>>> to push this out, even if that might only give the appearance >>>>> of progress and not reflect real progress. >>>>> >>>>> - While IPR on an architecture document is sad to see, esp >>>>> with what seems like it may be restrictive licensing, I do >>>>> see the wg debated that and decided to move on. >>>>> >>>>> - The charter text describing this deliverable notes that >>>>> "The initial scope is restricted to a single administrative >>>>> domain, keeping in mind that architectural decisions made for >>>>> the intra-domain case may have implications for the >>>>> inter-domain case." So I think there is also a currently >>>>> missing analysis (or the results of that) as to how the >>>>> single-domain elements of this architecture might impinge on >>>>> a later inter-domain architecture. So the text at the >>>>> end of section 1.1 appears to contradict the chartered >>>>> goals. >>>>> >>>>> - Chains will require some representation, and re-ordering >>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>> for fun) therefore there must be a requirement for some data >>>>> integrity service and origin authentication and an >>>>> authorisation decision function and therefore there must >>>>> (istm) be a need for the architecture to define a chain >>>>> producing entity of some kind that could be authenticated. >>>>> That is an example of the missing security analysis that >>>>> really is needed before this proceeds. (See my discuss point >>>>> 2) >>>>> >>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>> networks are slightly incongrous. In the case of WiFi when do >>>>> the packet ingress? (When it gets to the AP or leaves the >>>>> mobile node transmitter?) I suspect you really mean the wired >>>>> bits of a mobile network so it might be better to say that. >>>>> >>>>> - 1.2 should follow 1.3 I think. >>>>> >>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>> standard chaining logic, which is maybe right, but then you >>>>> imply that a fully ordered set of SF's is a well defined >>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>> to say is that the architecture doesn't determine if an SFC >>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>> protocol work will have to do that. (In fact, I think you >>>>> could say a lot more here and probably should.) >>>>> >>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>> terms need to be defined. >>>>> >>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>> partially ordered? >>>>> >>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>> (cf. RFC2804) so better to not drag in the controversy >>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>> standard and perhaps not likely to be (cf. some confict >>>>> reviews on the same telechat as this) so I'd also drop that. >>>>> And I think all of the exemplar SF's should really have a >>>>> reference (ideally an RFC). >>>>> >>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>> set of paths through (one or more) graphs but doesn't show >>>>> the full graphs themselves. >>>>> >>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>> the example given imply that all traffic (of what kind?) that >>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>> precision is needed really. The hybrid concept seems even >>>>> odder to me. >>>>> >>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>> architecture is to avoid such vagueness? If you mean that an >>>>> SFP representation can embody an if-statement then saying >>>>> that would be the thing to do. >>>>> >>>>> - Section 3: I think there's maybe a missing principle here >>>>> about not making security and privacy worse in general. >>>>> >>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>> traffic that congestion would be an issue? If so, should you >>>>> say rather that any transport that has some way of handling >>>>> congestion is ok. If not, then I guess the current text is >>>>> fine. >>>>> >>>>> >>>>> >=20 --L8mrT0hOCdqRoUo3VjexNNDMVKRqOTgIi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVZ0rbAAoJEC88hzaAX42iQwwH/3x1YWkBLdF3fAUXA+gYbAte cxBUbgItdMS0puYaVE+46h8pZ1RIBs6B4BO+Y2m3d6VE++pqy0YuA0wFSPVGEhLM VDLlmbsiVC0A+Vd+UZ6lVN92/Dg8j8vZgvbZG0mHDRJhm0bGi9ox6niLSsF7Yoz9 NQxiHAYj2IW5cbuoZCKDJLfOaRJdDKhS/hR+kegfDB5es0c6fHTBL/ZywW3B9giw GZL2TZipZwgkc1XqjYIs5lleHwUdqG1Jv88MeuPKVwbSdhR8BcyBROICDfi/ZycV oFUCbl5x+UNRlX8CZNy1ayBAp53NHNMD8SbfKnupy8B8o0EQFXzL2gXmuS4mSfs= =KzXK -----END PGP SIGNATURE----- --L8mrT0hOCdqRoUo3VjexNNDMVKRqOTgIi-- From nobody Thu May 28 11:05:35 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14931B2CA4; Thu, 28 May 2015 11:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 gQhh3QTbs9_F; Thu, 28 May 2015 11:05:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783AD1A87B3; Thu, 28 May 2015 11:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22696; q=dns/txt; s=iport; t=1432836321; x=1434045921; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=duHp1s+POmA5HYKqE7cV1emW6TPJ7mzjuEiakxy9CQU=; b=I+OVN1MSNOEAx+8TGbV25p5mj5pQv2nS6bUTFReypgewoxkUq+p0WTRu kgAsqWt55FgiXLUjosQ3hdi3g0KsPAnQtgww79G+TlmG/eRpIMflgLoi8 O8T28qdXPdg4rnfibW5bbZlKNXvhqIxbUlErIbcHrrdTm2F16hUOS7nnm s=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ATBQAnWGdV/5pdJa1cgxBUUQ0Ggxi5boJJhXcCgUxMAQEBAQEBgQuEIgEBAQIBASMEUgULAgEGAhIGKgICMhcOAgQOBQ4NiAoIDZQlnRGkFwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0OEIQIRAU0EB4JoL4EWBYZriWGCPIISgUNghloBgSiDcY48g1kjYYEFVYE9bwGBAgkXI4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="asc'?scan'208,217";a="423488775" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 28 May 2015 18:05:19 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4SI5JlR032629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 18:05:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 28 May 2015 13:05:18 -0500 From: "Carlos Pignataro (cpignata)" To: "Benoit Claise (bclaise)" Thread-Topic: Benoit Claise's No Objection on draft-ietf-sfc-architecture-08: (with COMMENT) Thread-Index: AQHQmVTpxRaqH1qWLkSTH/C2kz7TNJ2R0lAAgAAwjQA= Date: Thu, 28 May 2015 18:05:17 +0000 Message-ID: References: <20150528144454.10612.14109.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/signed; boundary="Apple-Mail=_603DA736-32EB-4F18-8FAC-C3E467E5EF08"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Benoit Claise's No Objection on draft-ietf-sfc-architecture-08: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 18:05:28 -0000 --Apple-Mail=_603DA736-32EB-4F18-8FAC-C3E467E5EF08 Content-Type: multipart/alternative; boundary="Apple-Mail=_2CB8DFD7-5861-49AA-88BC-19790670EFA7" --Apple-Mail=_2CB8DFD7-5861-49AA-88BC-19790670EFA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Benoit, Many thanks again for your review =E2=80=94 let me also reply to your = COMMENTs point-by-point below, to make sure we are on the same page. > On May 28, 2015, at 11:11 AM, Carlos Pignataro (cpignata) = wrote: >=20 > Thanks, Benoit. I believe we=E2=80=99ve addressed all these comments = in our working version, which we will submit when Alia says =E2=80=9CGo!=E2= =80=9D >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> On May 28, 2015, at 10:44 AM, Benoit Claise (bclaise) = wrote: >>=20 >> Benoit Claise has entered the following ballot position for >> draft-ietf-sfc-architecture-08: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >>=20 >> - Section 1.1 >> What does "minimum requirements on the physical topology"mean in: >>=20 >> This document defines the architecture for Service Function Chaining >> (SFC) with minimum requirements on the physical topology of the >> network, as standardized in the IETF. >>=20 >> It seems to me that "independent" is what you're after, like in: >> "it describes a method for deploying SFs in a way that enables >> dynamic ordering and topological independence of those SFs as well = as >> the exchange of metadata between participating entities." >>=20 >> or >> "This SFC architecture is predicated on topological independence = from >> the underlying forwarding topology.=E2=80=9D >>=20 I agree, =E2=80=9Cindependent=E2=80=9D is the right word here =E2=80=94 = as it is also used elsewhere in the document. I like your suggestion = immediately above, thanks for catching. >>=20 >>=20 >> - Service Function Path definition: I'm confused. you don't explain = what >> it is, but only explain why you need it. The definition of SFP took quite significant crafting and wording, and = WG cycles. It is correct, yet a bit complex. You can see some of the background at: https://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf#page=3D8 = https://tools.ietf.org/agenda/91/slides/slides-91-sfc-2.pdf#page=3D3 = >> Later on, I see "As an example of such an intermediate specificity, = there >> may be two >> SFPs associated with a given SFC". I'm confused. >> Not too clear on how the SFP and RSP relate to each others. >> Is the Service Function Path the ordered list of SFs, while the RSP = is >> the ordered list of SFFs? The SFC is an ordered set of abstract functions =E2=80=94 e.g., =E2=80=9Ca= firewall=E2=80=9D. An SFP applies (policy, service function, etc) = constrains as e.g., =E2=80=9Cthis firewall=E2=80=9D, or =E2=80=9Cthis = firewall via this SFF =E2=80=A6=E2=80=9D; as detailed in Section 2.3, = SFPs do not have a requirement of full specificity. SFPs can have = varying degrees of specificity (from fully specified SFFs and SFs to = reach that SF and there=E2=80=99s degree of freedom over which SFFs to = use). Lastly, an RSP is the fully specified set of SFFs and SFs actually = visited. In other words, from less specified to fully specified: SFC -> = SFP -> RSP. >>=20 >> - >> "Traffic from SFs eventually returns to the same SFF, which is >> responsible for injecting traffic back onto the network. >>=20 >> Am I correct that it only applies in case of a SFC proxy? Please note also that SFFs and SFs are architectural functional blocks, = and an IPS might include both functions. >> Related question, along the same lines: >>=20 >> 1. SFP forwarding : Traffic arrives at an SFF from the network. >> The >> SFF determines the appropriate SF the traffic should be = forwarded >> to via information contained in the SFC encapsulation. Post-SF, >> the traffic is returned to the SFF, and, if needed, is forwarded >> to another SF associated with that SFF. If there is another = non- >> local (i.e., different SFF) hop in the SFP, the SFF further >> encapsulates the traffic in the appropriate network transport >> protocol and delivers it to the network for delivery to the next >> SFF along the path. >>=20 >> Returned to the initial SFF, or to the next SFF in the RSP? >> I guess the next SFF in the chain (again, unless we speak about a = proxy) Not about proxy. Traffic returns from the SF to the SFF that sent it to = that SF. =46rom that SFF, it can go to another SF or to another SFF -> = SF. To exemplify (what I believe might be the confusion), if a classifier = sends traffic to a firewall, traffic does not return to the classifier. = After the firewall SF is applied, it returns to the functional SFF. >>=20 >> This would be consistent with section 5.4: >> "Due to the overlay constraints, the packet-forwarding path may >> need to visit the same SFF multiple times, and in some less common >> cases may even need to visit the same SF more than once." >>=20 >>=20 >> - Section 4.4 and 4.6: what about SFC-enabled domain and SFC proxy. >> In figure 3, the SFC proxy is inside the domain, right? >> But what about the SFC-unaware Service Function? Inside or outside? >>=20 Good point again. Added this sentence at the end of S4.4: =E2=80=9CAn SFC Proxy and corresponding SFC-unaware Service Function = (see Figure 3) are inside the SFC-enabled domain." >> - >> 6. Service function chain independence: The creation, modification, >> or deletion of an SFC has no impact on other SFCs. The same is >> true for SFPs. >>=20 >> Except if one SF depends on the shared metadata from a previous SF in = the >> chain, right? >>=20 No. If one SF depends on shared metadata from a previous SF, that would = be within a chain. The statement above is about SFC independence, not SF = independence. Removing a chain would not affect another chain (which = includes the two SFs from your example). >>=20 >> Editorial. >>=20 >> - >> OLD: >> SFC Proxy: Removes and inserts SFC encapsulation on behalf of an >> NEW: >> SFC Proxy: Removes and inserts SFC Encapsulation on behalf of an >>=20 Done. Thanks again, please let us know if there are comments that need further = clarification or fixes. Thanks, =E2=80=94 Carlos. >>=20 >> THIS TEXT BELOW IS DOCUMENTED FOR THE RECORD (AND THIS = DISCUSS-DISCUSS >> HAS BEEN DISCUSSED) >>=20 >> - Can you explain this disconnect: >>> =46rom the charter: >>=20 >> It will produce an architecture for service function >> chaining that includes the necessary protocols or protocol = extensions >> to >> convey the Service Function Chain and Service Function Path >> information >> to nodes that are involved in the implementation of service >> functions >> and Service Function Chains, as well as mechanisms for steering >> traffic >> through service functions. >>=20 >>> =46rom the abstract: >>=20 >> This document does not propose solutions, protocols, or >> extensions to existing protocols. >>=20 >> While I'm on the charter, I'm always available for this milestone: >>=20 >> Apr 2014 Consult with OPS area on possible SFC charter = modifications >> for management and configuration of SFC components related to the = support >> of Service Function Chaining >>=20 >>=20 >=20 --Apple-Mail=_2CB8DFD7-5861-49AA-88BC-19790670EFA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Benoit,

Many thanks again for your review =E2=80=94 let me also reply = to your COMMENTs point-by-point below, to make sure we are on the same = page.

On May 28, 2015, at 11:11 AM, Carlos = Pignataro (cpignata) <cpignata@cisco.com> wrote:

Thanks, Benoit. I = believe we=E2=80=99ve addressed all these comments in our working = version, which we will submit when Alia says =E2=80=9CGo!=E2=80=9D

Thanks,

=E2=80=94 = Carlos.

On May 28, 2015, at 10:44 AM, Benoit Claise (bclaise) <bclaise@cisco.com> = wrote:

Benoit Claise has entered the = following ballot position for
draft-ietf-sfc-architecture-08: No Objection

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------


- Section 1.1
What does "minimum requirements on the physical topology"mean = in:

 This document defines the = architecture for Service Function Chaining
 (SFC) = with minimum requirements on the physical topology of the
=  network, as standardized in the IETF.

It seems to me that "independent" is what you're after, like = in:
 "it describes a method for deploying SFs in a = way that enables
 dynamic ordering and topological = independence of those SFs as well as
 the exchange = of metadata between participating entities."

or
 "This SFC architecture is predicated = on topological independence from
 the underlying = forwarding topology.=E2=80=9D


I = agree, =E2=80=9Cindependent=E2=80=9D is the right word here =E2=80=94 as = it is also used elsewhere in the document. I like your suggestion = immediately above, thanks for catching.



- Service Function Path definition: I'm confused. you don't = explain what
it is, but only explain why you need it.

The definition of SFP took quite significant = crafting and wording, and WG cycles. It is correct, yet a bit = complex.

You can see some of the = background at:


Later on, I see "As an example of such an intermediate = specificity, there
may be two
SFPs = associated with a given SFC". I'm confused.
Not too clear = on how the SFP and RSP relate to each others.
Is the = Service Function Path the ordered list of SFs, while the RSP is
the ordered list of SFFs?

The SFC is an ordered set of abstract functions = =E2=80=94 e.g., =E2=80=9Ca firewall=E2=80=9D. An SFP applies (policy, = service function, etc) constrains as e.g., =E2=80=9Cthis firewall=E2=80=9D= , or =E2=80=9Cthis firewall via this SFF =E2=80=A6=E2=80=9D; as detailed = in Section 2.3, SFPs do not have a requirement of full specificity. SFPs = can have varying degrees of specificity (from fully specified SFFs and = SFs to reach that SF and there=E2=80=99s degree of freedom over which = SFFs to use). Lastly, an RSP is the fully specified set of SFFs and SFs = actually visited. In other words, from less specified to fully = specified: SFC -> SFP -> RSP.



-
"Traffic from SFs eventually returns to the same SFF, which = is
responsible for injecting traffic back onto the = network.

Am I correct that it only applies = in case of a SFC proxy?

Please note also that SFFs and SFs are = architectural functional blocks, and an IPS might include both = functions.

Related question, along = the same lines:

=      1.  SFP forwarding : Traffic arrives = at an SFF from the network.
The
=      SFF determines the appropriate SF the = traffic should be forwarded
=      to via information contained in the SFC = encapsulation.  Post-SF,
=      the traffic is returned to the SFF, and, = if needed, is forwarded
     to = another SF associated with that SFF.  If there is another non-
     local (i.e., different SFF) = hop in the SFP, the SFF further
=      encapsulates the traffic in the = appropriate network transport
=      protocol and delivers it to the network = for delivery to the next
=      SFF along the path.

Returned to the initial SFF, or to the next SFF in the = RSP?
I guess the next SFF in the chain (again, unless we = speak about a proxy)

Not about proxy. Traffic returns from the SF to = the SFF that sent it to that SF. =46rom that SFF, it can go to another = SF or to another SFF -> SF.

To = exemplify (what I believe might be the confusion), if a classifier sends = traffic to a firewall, traffic does not return to the classifier. After = the firewall SF is applied, it returns to the functional SFF.


This = would be consistent with section 5.4:
 "Due to the = overlay constraints, the packet-forwarding path may
=  need to visit the same SFF multiple times, and in some less = common
 cases may even need to visit the same SF = more than once."


- Section = 4.4 and 4.6: what about SFC-enabled domain and SFC proxy.
In= figure 3, the SFC proxy is inside the domain, right?
But = what about the SFC-unaware Service Function? Inside or outside?


Good point again. Added this sentence at the end = of S4.4:

=E2=80=9CAn SFC Proxy and = corresponding SFC-unaware Service Function (see =
Figure 3) are inside the SFC-enabled domain."

-
6. =  Service function chain independence: The creation, = modification,
     or deletion = of an SFC has no impact on other SFCs.  The same is
=      true for SFPs.

Except if one SF depends on the shared metadata from a = previous SF in the
chain, right?


No. If one SF depends on shared metadata from a = previous SF, that would be within a chain. The statement above is about = SFC independence, not SF independence. Removing a chain would not affect = another chain (which includes the two SFs from your example).


Editorial.

-
OLD:  SFC Proxy:  Removes and inserts SFC = encapsulation on behalf of an
NEW:
=  SFC Proxy:  Removes and inserts SFC Encapsulation on behalf = of an


Done.

Thanks = again, please let us know if there are comments that need further = clarification or fixes.

Thanks,

=E2=80=94= Carlos.


THIS TEXT = BELOW IS DOCUMENTED FOR THE RECORD  (AND THIS DISCUSS-DISCUSS
HAS BEEN DISCUSSED)

- Can you = explain this disconnect:
=46rom the charter:

=   It will produce an architecture for service function
  chaining that includes the necessary protocols = or protocol extensions
to
=   convey the Service Function Chain and Service Function = Path
information
  to nodes that = are involved in the implementation of service
functions
  and Service Function Chains, as well as = mechanisms for steering
traffic
=   through service functions.

=46rom the abstract:

  This document does = not propose solutions, protocols, or
=      extensions to existing protocols.

While I'm on the charter, I'm always available = for this milestone:

  Apr 2014 = Consult with OPS area on possible SFC charter modifications
for management and configuration of SFC components related to = the support
of Service Function Chaining




= --Apple-Mail=_2CB8DFD7-5861-49AA-88BC-19790670EFA7-- --Apple-Mail=_603DA736-32EB-4F18-8FAC-C3E467E5EF08 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZ1jeAAoJEIXgpQGOZny9ea4P/0ejnT/arFWtbXujiJUVjwcS PPxj+0BrTI08CQzbyxWLVjERNu/FFZM5p3g5ju6toM4j1TzZGFTfebI6IXhjUFIY waM6yLnl8WUQk/ycoA63dzTn05R00xtUPtX1KjqYf8nd1oBRHrjIL5i5Iecmnixu yHtMZZbr2v+NbWoTIrd7zSopKGo0gUoHu+NxHbZc9tSdV9TTcSThLJy/YfHmw1oz t6ckhznUi/CgTJuJOQO6wxWt4Y0aAECS2CCT4qpjK52kDgJtukdWs5w/K9HrIc8q p5IivX0f92ZU0RVyp4iMh9Vu4jpxf3ZFDPfelDOJSgh+kR/faWktzl9dEIcii8Yg pEYFNMLrJgg6S0ophDPg037YTxL75E/j3H6VqZjgV+K+/O2hfIzpR2HO4WEysXOO ZI/6eXSgyzUR2uHrghq6coq/F/uz4o0RntSAsake3mEy5nhJI26tvSX9de7UG/en XQWquhvoLC5mLcveIcmqwjqCZhP7jIzr6wEJ2GF7cZMtqp0QVRtY6mmjM0V9n8Iu HdUXaVUK0aitXVYFOJZd7+FC+RnlUP9Aw6RgYXeuG/TM6ocyOtOFLYKNPqTehGVw jHTT1WoJOdBGh+cIdmaxzzhAhwKkLRFzf529Vkn/WouEtD3Rwfs/hPzvLxeU1kZe nhOuo+A/EuqOBrVn/r1l =fmYo -----END PGP SIGNATURE----- --Apple-Mail=_603DA736-32EB-4F18-8FAC-C3E467E5EF08-- From nobody Thu May 28 13:32:16 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F661A8880; Thu, 28 May 2015 13:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 f9Y4J2Q-RUc4; Thu, 28 May 2015 13:32:08 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03F01A88F5; Thu, 28 May 2015 13:32:07 -0700 (PDT) Received: by obew15 with SMTP id w15so42525429obe.1; Thu, 28 May 2015 13:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EZ5O6X2Uza5qLxYwJX8k0ZPT2GpjMi4r03wIXQ1u2hQ=; b=Q4oiV3rWj2/09ECuxN5I0SuyuK6PeDXV3VFlbDPfpW7yY0l8EpYOV/H8Fz5fd21kFF BtH3Iv7Ag94QfxssWG0vbNCP+x/FgeJC1H2HiUK5dEpcd9oGyABBnzMlBts3/ZHEQt5P Pr1l92A/rllqCqtNOhZLLOZfmCh4wh9w8XfE/7xCqV/JovORhRdBzedcaTir7LisK5oM Oux7S49t016+GHEWe4ej8fW6Mhcosl+lIoNk+XFDwJdri0XPHXzgi6/FZxM8930uqFpi ge9fosqJFsnCT1VrBYGys5fWtZjH77VLS4YBe8DNGXJfinW0MfhGF7nKFtovtRM42QId LY5g== MIME-Version: 1.0 X-Received: by 10.202.89.131 with SMTP id n125mr3894834oib.91.1432845127273; Thu, 28 May 2015 13:32:07 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Thu, 28 May 2015 13:32:07 -0700 (PDT) In-Reply-To: <4C97F2B0-7AAE-49A4-9D63-65B5494AABBE@cisco.com> References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> <556723E0.5040603@joelhalpern.com> <4C97F2B0-7AAE-49A4-9D63-65B5494AABBE@cisco.com> Date: Thu, 28 May 2015 16:32:07 -0400 Message-ID: From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a113d381ed4525e05172a40ad Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , Kathleen Moriarty , The IESG , "draft-ietf-sfc-architecture@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 20:32:10 -0000 --001a113d381ed4525e05172a40ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carlos & Joel, Apologies for top-posting, but just quickly.... Private information could absolutely be pulled from the packet and even placed into metadata as an easy shortcut for flow identification. Consider a case where the packet included the EMEI and that was used as part of a flow identifier. It does a great job as a unique part of a flow identifier tuple - but it also reveals the user and handset. Perhaps something along the lines of: "The SFC architecture does not define what types of service functions might be included. However, it does allow for the passing of information from one service function to the next in the SFP. This information might be passed indirectly via metadata that identifies the flow and allows the next service function to look up that information. Alternately, that information might be passed directly in a packet's metadata. It is important to consider the privacy considerations of how that information is shared along the SFP and that it is removed promptly when no longer needed operationally for the SFP. For instance, one type of service function that may exist is a flow classifier. Depending upon whether or not the packet is encrypted, as is increasingly common [ REFERENCE NEEDED], metadata to identify the flow might be pulled from the packet's headers and/or from DPI. When metadata is derived from information that a user may consider private (i.e. identity, equipment, URI, application, etc.), there are many ways [see RFC 6973] to mitigate the threat of leaking such pre-processed private data across the SFC. For example, one method might be to process and provide an otherwise unrelated identifier or tuple to be forwarded along the SFP as metadata or associated indirectly with that metadata." When you combine the reality of pervasive monitoring - even within some administrative domains that have not agreed to it - with passing private information along with the packets, I do think it is useful to have some considerations that address this. Obviously, as the control plane and details for passing along meta-data gets further developed, this can be better articulated. Please let me know if this helps clarify. Thanks, Alia On Thu, May 28, 2015 at 12:39 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Kathleen, > > Thank you for taking the time to review this document. > > I am responding to this email on the thread, because I think it is the on= e > that most clearly explains your concerns. I also include an additional > clarification you wrote on a different email, all below for context. > > Below you say: > *=E2=80=9CI'm concerned about privacy of data that is in a payload that m= ay be > used in the SFC architecture.=E2=80=9D* > and > *=E2=80=9Cyou are pulling that content out and using it in ways that may = not have > been intended by those who created it and didn't encrypt it.=E2=80=9D* > > I am also having some trouble exemplifying and visualizing your concern, > and how to address it. > > Could you please, perhaps, be more explicit as to how =E2=80=98content is= pulled > from the payload and used in unintended ways=E2=80=99? What exactly do yo= u have in > mind? Can you share an example? > > The payload is being used to classify =E2=80=94 what other unintended use= do you > see? > > Classification based on inspecting a payload is certainly not a new > element created by this architecture. > > Thanks, > > =E2=80=94 Carlos. > > On May 28, 2015, at 10:10 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > Hi Joel, > > On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern > wrote: > >> I do not know what it would mean to apply privacy to information that is >> a) gathered from a payload >> b) and delivered along with that unprotected payload? >> > > If you go back to the text in my discuss, I'm concerned about privacy of > data that is in a payload that may be used in the SFC architecture. I am > not saying that you have to apply privacy, just that it may be exposed wh= en > payloads are accessed and used. > > Thanks, > Kathleen > > > [=E2=80=A6] > > On May 28, 2015, at 10:30 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern > wrote: > >> I am missing your point. Sorry. If it is in the payload, it is >> exposed. If the payload is protected from exposure, then SFC won't be a= ble >> to extract it, so can't expose it. We are clear already in the document >> that SFC metadata has to be protected from exposure outside of the domai= n, >> noit because it is in the payload, but for cases where it is derived fro= m >> other sources that may be sensitive. >> >> Right, but you are pulling that content out and using it in ways that ma= y > not have been intended by those who created it and didn't encrypt it. Th= is > raises the security/privacy concern that their data may be used in ways > they did not intend and be put into places they didn't expect. If it's > data that has to be tracked for record retention, through an ESI data map > or similar, its one more place this data resides that needs to be tracked= . > If the warning is there that this could happen and is a possible privacy > concern, my point is addressed. > > Thank you, > Kathleen > > > >> So I have real trouble figuring out how to address this concern. >> >> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> >>> ---------------------------------------------------------------------- >>> >>> I agree with Stephen's discuss and comment points and am just >>> adding a >>> few that I think are also important. >>> >>> 1. The Security Considerations section only talks about privacy >>> of the >>> SFC information for classification. The more important point >>> may be the >>> privacy of any data gathered from a payload used for the >>> classification >>> and this needs to be mentioned. >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> >>> ---------------------------------------------------------------------- >>> >>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >> > > > -- > > Best regards, > Kathleen > > > --001a113d381ed4525e05172a40ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos & Joel,

Apologies for top-po= sting, but just quickly....

Private information co= uld absolutely be pulled from the packet and even placed into metadata as a= n easy shortcut for flow identification. =C2=A0 Consider a case where the p= acket included the EMEI and that was used as part of a flow identifier.=C2= =A0 It does a great job as a unique part of a flow identifier tuple - but i= t also reveals the user and handset.

Perhaps somet= hing along the lines of:

"The SFC architectur= e does not define what types of service functions might be included.=C2=A0 = However, it does allow for the passing of information from one service func= tion to the next in the SFP.=C2=A0 This information might be passed indirec= tly via metadata that identifies the flow and allows the next service funct= ion to look up that information.=C2=A0 Alternately, that information might = be passed directly in a packet's metadata.=C2=A0 It is important to con= sider the privacy considerations of how that information is shared along th= e SFP and that it is removed promptly when no longer needed operationally f= or the SFP. =C2=A0

For instance, one type of servi= ce function that may exist is a flow classifier.=C2=A0 Depending upon wheth= er or not the packet is encrypted, as is increasingly common [ REFERENCE NE= EDED], metadata to identify the flow might be pulled from the packet's = headers and/or from DPI.=C2=A0 When metadata is derived from information th= at a user may consider private (i.e. identity, equipment, URI, application,= etc.), there are many ways [see RFC 6973] to mitigate the threat of leakin= g such pre-processed private data across the SFC. =C2=A0 For example, one m= ethod might be to process and provide an otherwise unrelated identifier or = tuple to be forwarded along the SFP as metadata or associated indirectly wi= th that metadata."

When you combine the reali= ty of pervasive monitoring - even within some administrative domains that h= ave not agreed to it - with passing private information along with the pack= ets, I do think it is useful to have some considerations that address this.=

Obviously, as the control plane and details for p= assing along meta-data gets further developed, this can be better articulat= ed.

Please let me know if this helps clarify.

Thanks,
Alia

On Thu, May 28, 2015 at 12:39 PM, Car= los Pignataro (cpignata) <cpignata@cisco.com> wrote:
Kathleen,
Thank you for taking the time to review this document.

I am responding to this email on the thread, because= I think it is the one that most clearly explains your concerns. I also inc= lude an additional clarification you wrote on a different email, all below = for context.

Below you say:
=E2=80=9C= I'm concerned about privacy of data that is in a payload that may be us= ed in the SFC architecture.=E2=80=9D
and
=E2=80= =9Cyou are pulling that content out and using it in ways that may not have = been intended by those who created it and didn't encrypt it.=E2=80=9D

I am also having some trouble exemplifying and = visualizing your concern, and how to address it.

C= ould you please, perhaps, be more explicit as to how =E2=80=98content is pu= lled from the payload and used in unintended ways=E2=80=99? What exactly do= you have in mind? Can you share an example?

The p= ayload is being used to classify =E2=80=94 what other unintended use do you= see?

Classification based on inspecting a payload= is certainly not a new element created by this architecture.
Thanks,

=E2=80=94 Carlos.
On May 28, 2015, a= t 10:10 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote= :

Hi Joel,

On Thu, May 28, 2015 at= 10:06 AM, Joel M. Halpern=C2=A0<jmh@joelhalpern.com>=C2= =A0wrote:
I do not know what it would mean to apply pri= vacy to information that is
a) gathered from a payload
b) and deliver= ed along with that unprotected payload?
=C2=A0
If you go back to the text in my discuss, I'm concerned about pr= ivacy of data that is in a payload that may be used in the SFC architecture= .=C2=A0 I am not saying that you have to apply privacy, just that it may be= exposed when payloads are accessed and used.=C2=A0

Thanks,
Kathleen

<= /div>

[=E2=80=A6]

On = May 28, 2015, at 10:30 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co= m> wrote:



On Thu, May 28, = 2015 at 10:19 AM, Joel M. Halpern <jmh@joelhalpern.com> wr= ote:
I am missing your point.=C2=A0 Sorry= .=C2=A0 If it is in the payload, it is exposed.=C2=A0 If the payload is pro= tected from exposure, then SFC won't be able to extract it, so can'= t expose it.=C2=A0 We are clear already in the document that SFC metadata h= as to be protected from exposure outside of the domain, noit because it is = in the payload, but for cases where it is derived from other sources that m= ay be sensitive.

Right, but you are pulling that content out and using= it in ways that may not have been intended by those who created it and did= n't encrypt it.=C2=A0 This raises the security/privacy concern that the= ir data may be used in ways they did not intend and be put into places they= didn't expect.=C2=A0 If it's data that has to be tracked for recor= d retention, through an ESI data map or similar, its one more place this da= ta resides that needs to be tracked.=C2=A0 If the warning is there that thi= s could happen and is a possible privacy concern, my point is addressed.

Thank you,
Kathleen

=C2=A0
So I have real trouble figuring out how to address this concern.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------------------------------------= -----------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DISCUSS:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------------------------------------= -----------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree with Stephen's discuss and comment = points and am just
=C2=A0 =C2=A0 =C2=A0 =C2=A0 adding a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 few that I think are also important.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1. The Security Considerations section only tal= ks about privacy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SFC information for classification.=C2=A0 The m= ore important point
=C2=A0 =C2=A0 =C2=A0 =C2=A0 may be the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 privacy of any data gathered from a payload use= d for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 classification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and this needs to be mentioned.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------------------------------------= -----------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 COMMENT:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------------------------------------= -----------------------





 --

Best regards,
Kathleen



--

=
Best regards,
Kathleen


--001a113d381ed4525e05172a40ad-- From nobody Thu May 28 13:35:21 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779441A88F5; Thu, 28 May 2015 13:35:19 -0700 (PDT) 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, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 0aOJvx3vEW3e; Thu, 28 May 2015 13:35:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235ED1A8880; Thu, 28 May 2015 13:35:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 82413BF03; Thu, 28 May 2015 21:35:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KybmMVSUoVB3; Thu, 28 May 2015 21:35:12 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BAD14BF01; Thu, 28 May 2015 21:35:11 +0100 (IST) Message-ID: <55677BFD.5030808@cs.tcd.ie> Date: Thu, 28 May 2015 21:35:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> In-Reply-To: <5567287C.6080905@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 20:35:19 -0000 On 28/05/15 15:38, Joel M. Halpern wrote: > IF A, B, and C are service function forwarders (SFF), with a TLS > protected link for SFC, then the metadata will be protected. (Such a > link would be a transport mechanism, which SFC does not describe or > mandate. The SFC architecture is transport agnostic.) Ah, no the scenario I was thinking about is where, from the perspective of SFC, the TLS packets are the payload that is encapsulated. I guess A, B and C could be mail servers with starttls only turned on between B and C because that link is "external" (though within the same administrative domain). If some SFC thing at A were to dive into the SMTP traffic and pull out sensitive meta0 data then we wouldn't want that sent in clear from B to C because of the SFC encapsulation, right? S. > > If A, B, and C are service functions used by SFC, then there is no link > between B and C, so it can't be protected by TLS. > > So I can not see what more needs to be said? > > Yours, > Joel > > On 5/28/15 10:35 AM, Stephen Farrell wrote: >> >> >> On 28/05/15 15:03, Joel M. Halpern wrote: >>> I am not sure what you mean by "Metadata that contains information that >>> is protected in the data plane". Most of what ends up in the metadata >>> is information that is passed on other interfaces directly to relevant >>> functions, or locally determine and locally processed. >> >> So what I had in mind were things like the following. >> >> - Packet is sent along a SFP A,B,C >> - B to C link is via say a TLS VPN >> - Metadata is created at A and is in the SFC encapsulation >> and not protected by the VPN >> - That seems bad >> >> S. >> >> >>> >>> The protection used for policy systems (which provide much of the >>> information) is based on the presence of persistent connections and >>> usage which crosses domains. Are you arguing that if AAA is encrypted >>> then policy delivered by AAA resulting in metadata in the packet must be >>> encrypted in the data packets? >>> >>> Yours, >>> Joel >>> >>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-sfc-architecture-08: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> (1) I note the charter calls for this deliverable to "provide >>>> a description of... security models" The charter also >>>> generally notes that "The SFC WG will closely consider and >>>> address the management and security implications when >>>> documenting these deliverables." My conclusion is that this >>>> deliverable needs to reflect the results of a security >>>> analysis that the wg are suppoed to have carried out but that >>>> it's currently too vague only saying that solutions need to >>>> consider this. (Essentially this is a continuation of the >>>> mail threads from the secdir review [1] and a satisfactory >>>> resolution of that will probably resolve this.) >>>> >>>> [1] >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>> >>>> (2) Metadata that contains information that is protected in >>>> the data plane SHOULD be equally well protected when passed >>>> about by SFC. I hope that's acceptable and documented. I'm >>>> not sure myself if "passed about" ought also include within a >>>> device but maybe it should really. But at minimum, I do >>>> think you need to define confidentiality and origin >>>> authentication services for SFC metadata and/or for the SFC >>>> encapsulation as a whole. And I think this architecture >>>> document needs to say that those services have to be >>>> well-defined as part of any solution. (And I am not >>>> saying that this draft needs to define how to do those.) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> - It occurs to me that it might really be better for the WG >>>> to not publish this as an RFC now, but rather to put it on >>>> hold until they've made progress on the solutions. Perhaps >>>> revistiting this when the solutions are just at WGLC would >>>> result in the eventual RFC being a much more useful document. >>>> I think this one has to hedge so many bets that it's quite >>>> vague and won't be very useful even in the medium term. But >>>> that's just a suggestion, I can see why the WG might prefer >>>> to push this out, even if that might only give the appearance >>>> of progress and not reflect real progress. >>>> >>>> - While IPR on an architecture document is sad to see, esp >>>> with what seems like it may be restrictive licensing, I do >>>> see the wg debated that and decided to move on. >>>> >>>> - The charter text describing this deliverable notes that >>>> "The initial scope is restricted to a single administrative >>>> domain, keeping in mind that architectural decisions made for >>>> the intra-domain case may have implications for the >>>> inter-domain case." So I think there is also a currently >>>> missing analysis (or the results of that) as to how the >>>> single-domain elements of this architecture might impinge on >>>> a later inter-domain architecture. So the text at the >>>> end of section 1.1 appears to contradict the chartered >>>> goals. >>>> >>>> - Chains will require some representation, and re-ordering >>>> that is security sensitive (e.g. swap order of f/w and nat >>>> for fun) therefore there must be a requirement for some data >>>> integrity service and origin authentication and an >>>> authorisation decision function and therefore there must >>>> (istm) be a need for the architecture to define a chain >>>> producing entity of some kind that could be authenticated. >>>> That is an example of the missing security analysis that >>>> really is needed before this proceeds. (See my discuss point >>>> 2) >>>> >>>> - 1.1: "classified on ingress" and applicable to mobile >>>> networks are slightly incongrous. In the case of WiFi when do >>>> the packet ingress? (When it gets to the AP or leaves the >>>> mobile node transmitter?) I suspect you really mean the wired >>>> bits of a mobile network so it might be better to say that. >>>> >>>> - 1.2 should follow 1.3 I think. >>>> >>>> - 1.2: What does "chaining logic" mean? You say there's no >>>> standard chaining logic, which is maybe right, but then you >>>> imply that a fully ordered set of SF's is a well defined >>>> thing. I'm not sure that makes sense. Perhaps what you want >>>> to say is that the architecture doesn't determine if an SFC >>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>> protocol work will have to do that. (In fact, I think you >>>> could say a lot more here and probably should.) >>>> >>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>> terms need to be defined. >>>> >>>> - 1.3: SFC definition: by ordered do you mean fully or >>>> partially ordered? >>>> >>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>> (cf. RFC2804) so better to not drag in the controversy >>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>> standard and perhaps not likely to be (cf. some confict >>>> reviews on the same telechat as this) so I'd also drop that. >>>> And I think all of the exemplar SF's should really have a >>>> reference (ideally an RFC). >>>> >>>> - Figure 1 caption is misleading. That seems to me to show a >>>> set of paths through (one or more) graphs but doesn't show >>>> the full graphs themselves. >>>> >>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>> the example given imply that all traffic (of what kind?) that >>>> followed SF1->SF2->SF3 on the way "in" must follow >>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>> precision is needed really. The hybrid concept seems even >>>> odder to me. >>>> >>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>> architecture is to avoid such vagueness? If you mean that an >>>> SFP representation can embody an if-statement then saying >>>> that would be the thing to do. >>>> >>>> - Section 3: I think there's maybe a missing principle here >>>> about not making security and privacy worse in general. >>>> >>>> - 4.1: I wonder if one could ever get enough SFC control >>>> traffic that congestion would be an issue? If so, should you >>>> say rather that any transport that has some way of handling >>>> congestion is ok. If not, then I guess the current text is >>>> fine. >>>> >>>> >>>> > From nobody Thu May 28 13:44:56 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E82F1A892A; Thu, 28 May 2015 13:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLISn7fzE0yD; Thu, 28 May 2015 13:44:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003011A8902; Thu, 28 May 2015 13:44:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DA3A8240840; Thu, 28 May 2015 13:44:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9A10824082E; Thu, 28 May 2015 13:44:48 -0700 (PDT) Message-ID: <55677E37.1070203@joelhalpern.com> Date: Thu, 28 May 2015 16:44:39 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , "Joel M. Halpern" , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> In-Reply-To: <55677BFD.5030808@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 20:44:52 -0000 That case would not occur within a service chain. A service chain is about delivery of a packet to a series of services to which it is not addressed (generally followed by delivery to the target to which it is addressed.) An SMTP server relaying email produces separate packets. The packets from the user to the SMTP server are on one chain. The packets from that server to another are completely separate, and on a different chain. As such, those TLS SMTP packets between the servers would not have any metadata from the first transfer. Mail servers are not SFC service functions. The only time it gets close is when you are doing port 25 redirection, and then the service chain ends at the mail server. Yours, Joel On 5/28/15 4:35 PM, Stephen Farrell wrote: > > > On 28/05/15 15:38, Joel M. Halpern wrote: >> IF A, B, and C are service function forwarders (SFF), with a TLS >> protected link for SFC, then the metadata will be protected. (Such a >> link would be a transport mechanism, which SFC does not describe or >> mandate. The SFC architecture is transport agnostic.) > > Ah, no the scenario I was thinking about is where, from > the perspective of SFC, the TLS packets are the payload > that is encapsulated. I guess A, B and C could be mail > servers with starttls only turned on between B and C > because that link is "external" (though within the same > administrative domain). If some SFC thing at A were to > dive into the SMTP traffic and pull out sensitive meta0 > data then we wouldn't want that sent in clear from B to C > because of the SFC encapsulation, right? > > S. > > >> >> If A, B, and C are service functions used by SFC, then there is no link >> between B and C, so it can't be protected by TLS. >> >> So I can not see what more needs to be said? >> >> Yours, >> Joel >> >> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>> >>> >>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>> I am not sure what you mean by "Metadata that contains information that >>>> is protected in the data plane". Most of what ends up in the metadata >>>> is information that is passed on other interfaces directly to relevant >>>> functions, or locally determine and locally processed. >>> >>> So what I had in mind were things like the following. >>> >>> - Packet is sent along a SFP A,B,C >>> - B to C link is via say a TLS VPN >>> - Metadata is created at A and is in the SFC encapsulation >>> and not protected by the VPN >>> - That seems bad >>> >>> S. >>> >>> >>>> >>>> The protection used for policy systems (which provide much of the >>>> information) is based on the presence of persistent connections and >>>> usage which crosses domains. Are you arguing that if AAA is encrypted >>>> then policy delivered by AAA resulting in metadata in the packet must be >>>> encrypted in the data packets? >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-sfc-architecture-08: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> (1) I note the charter calls for this deliverable to "provide >>>>> a description of... security models" The charter also >>>>> generally notes that "The SFC WG will closely consider and >>>>> address the management and security implications when >>>>> documenting these deliverables." My conclusion is that this >>>>> deliverable needs to reflect the results of a security >>>>> analysis that the wg are suppoed to have carried out but that >>>>> it's currently too vague only saying that solutions need to >>>>> consider this. (Essentially this is a continuation of the >>>>> mail threads from the secdir review [1] and a satisfactory >>>>> resolution of that will probably resolve this.) >>>>> >>>>> [1] >>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>> >>>>> (2) Metadata that contains information that is protected in >>>>> the data plane SHOULD be equally well protected when passed >>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>> not sure myself if "passed about" ought also include within a >>>>> device but maybe it should really. But at minimum, I do >>>>> think you need to define confidentiality and origin >>>>> authentication services for SFC metadata and/or for the SFC >>>>> encapsulation as a whole. And I think this architecture >>>>> document needs to say that those services have to be >>>>> well-defined as part of any solution. (And I am not >>>>> saying that this draft needs to define how to do those.) >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> - It occurs to me that it might really be better for the WG >>>>> to not publish this as an RFC now, but rather to put it on >>>>> hold until they've made progress on the solutions. Perhaps >>>>> revistiting this when the solutions are just at WGLC would >>>>> result in the eventual RFC being a much more useful document. >>>>> I think this one has to hedge so many bets that it's quite >>>>> vague and won't be very useful even in the medium term. But >>>>> that's just a suggestion, I can see why the WG might prefer >>>>> to push this out, even if that might only give the appearance >>>>> of progress and not reflect real progress. >>>>> >>>>> - While IPR on an architecture document is sad to see, esp >>>>> with what seems like it may be restrictive licensing, I do >>>>> see the wg debated that and decided to move on. >>>>> >>>>> - The charter text describing this deliverable notes that >>>>> "The initial scope is restricted to a single administrative >>>>> domain, keeping in mind that architectural decisions made for >>>>> the intra-domain case may have implications for the >>>>> inter-domain case." So I think there is also a currently >>>>> missing analysis (or the results of that) as to how the >>>>> single-domain elements of this architecture might impinge on >>>>> a later inter-domain architecture. So the text at the >>>>> end of section 1.1 appears to contradict the chartered >>>>> goals. >>>>> >>>>> - Chains will require some representation, and re-ordering >>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>> for fun) therefore there must be a requirement for some data >>>>> integrity service and origin authentication and an >>>>> authorisation decision function and therefore there must >>>>> (istm) be a need for the architecture to define a chain >>>>> producing entity of some kind that could be authenticated. >>>>> That is an example of the missing security analysis that >>>>> really is needed before this proceeds. (See my discuss point >>>>> 2) >>>>> >>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>> networks are slightly incongrous. In the case of WiFi when do >>>>> the packet ingress? (When it gets to the AP or leaves the >>>>> mobile node transmitter?) I suspect you really mean the wired >>>>> bits of a mobile network so it might be better to say that. >>>>> >>>>> - 1.2 should follow 1.3 I think. >>>>> >>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>> standard chaining logic, which is maybe right, but then you >>>>> imply that a fully ordered set of SF's is a well defined >>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>> to say is that the architecture doesn't determine if an SFC >>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>> protocol work will have to do that. (In fact, I think you >>>>> could say a lot more here and probably should.) >>>>> >>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>> terms need to be defined. >>>>> >>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>> partially ordered? >>>>> >>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>> (cf. RFC2804) so better to not drag in the controversy >>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>> standard and perhaps not likely to be (cf. some confict >>>>> reviews on the same telechat as this) so I'd also drop that. >>>>> And I think all of the exemplar SF's should really have a >>>>> reference (ideally an RFC). >>>>> >>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>> set of paths through (one or more) graphs but doesn't show >>>>> the full graphs themselves. >>>>> >>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>> the example given imply that all traffic (of what kind?) that >>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>> precision is needed really. The hybrid concept seems even >>>>> odder to me. >>>>> >>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>> architecture is to avoid such vagueness? If you mean that an >>>>> SFP representation can embody an if-statement then saying >>>>> that would be the thing to do. >>>>> >>>>> - Section 3: I think there's maybe a missing principle here >>>>> about not making security and privacy worse in general. >>>>> >>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>> traffic that congestion would be an issue? If so, should you >>>>> say rather that any transport that has some way of handling >>>>> congestion is ok. If not, then I guess the current text is >>>>> fine. >>>>> >>>>> >>>>> >> From nobody Thu May 28 13:50:22 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AE31A8938; Thu, 28 May 2015 13:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 NIdSyNwpzGel; Thu, 28 May 2015 13:50:16 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331651A8937; Thu, 28 May 2015 13:50:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1BB2825101A; Thu, 28 May 2015 13:50:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id EC3B32410FB; Thu, 28 May 2015 13:50:14 -0700 (PDT) Message-ID: <55677F7D.1070807@joelhalpern.com> Date: Thu, 28 May 2015 16:50:05 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alia Atlas , "Carlos Pignataro (cpignata)" References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> <556723E0.5040603@joelhalpern.com> <4C97F2B0-7AAE-49A4-9D63-65B5494AABBE@cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , Kathleen Moriarty , The IESG , "draft-ietf-sfc-architecture@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 20:50:18 -0000 If the data is already in the packet, and the packet is not protected, then while copying it may make it easier to extract, that ease is pretty small, and the data was already extractable before service chaining. If the data is in the packet and the packet is encrypted, then SFC does not see it, and can not use it. As for information that is derived from other sources, we already have text in the document that this can be sensitive and needs to be handled with care. For the most part, the text you propose is harmless, but does not add anything to what the document already says. The one exception is with the notion of removing the metadata when it is no longer needed. Since service chaining does not know the semantics or users of the metadata, it can't perform such removal. And a service function has no way to know if some later service function may need the data. Which leaves us only removal at exit from service chaining, which is already required. Yours, Joel On 5/28/15 4:32 PM, Alia Atlas wrote: > Carlos & Joel, > > Apologies for top-posting, but just quickly.... > > Private information could absolutely be pulled from the packet and even > placed into metadata as an easy shortcut for flow identification. > Consider a case where the packet included the EMEI and that was used as > part of a flow identifier. It does a great job as a unique part of a flow > identifier tuple - but it also reveals the user and handset. > > Perhaps something along the lines of: > > "The SFC architecture does not define what types of service functions might > be included. However, it does allow for the passing of information from > one service function to the next in the SFP. This information might be > passed indirectly via metadata that identifies the flow and allows the next > service function to look up that information. Alternately, that > information might be passed directly in a packet's metadata. It is > important to consider the privacy considerations of how that information is > shared along the SFP and that it is removed promptly when no longer needed > operationally for the SFP. > > For instance, one type of service function that may exist is a flow > classifier. Depending upon whether or not the packet is encrypted, as is > increasingly common [ REFERENCE NEEDED], metadata to identify the flow > might be pulled from the packet's headers and/or from DPI. When metadata > is derived from information that a user may consider private (i.e. > identity, equipment, URI, application, etc.), there are many ways [see RFC > 6973] to mitigate the threat of leaking such pre-processed private data > across the SFC. For example, one method might be to process and provide > an otherwise unrelated identifier or tuple to be forwarded along the SFP as > metadata or associated indirectly with that metadata." > > When you combine the reality of pervasive monitoring - even within some > administrative domains that have not agreed to it - with passing private > information along with the packets, I do think it is useful to have some > considerations that address this. > > Obviously, as the control plane and details for passing along meta-data > gets further developed, this can be better articulated. > > Please let me know if this helps clarify. > > Thanks, > Alia > > On Thu, May 28, 2015 at 12:39 PM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Kathleen, >> >> Thank you for taking the time to review this document. >> >> I am responding to this email on the thread, because I think it is the one >> that most clearly explains your concerns. I also include an additional >> clarification you wrote on a different email, all below for context. >> >> Below you say: >> *“I'm concerned about privacy of data that is in a payload that may be >> used in the SFC architecture.â€* >> and >> *“you are pulling that content out and using it in ways that may not have >> been intended by those who created it and didn't encrypt it.â€* >> >> I am also having some trouble exemplifying and visualizing your concern, >> and how to address it. >> >> Could you please, perhaps, be more explicit as to how ‘content is pulled >> from the payload and used in unintended ways’? What exactly do you have in >> mind? Can you share an example? >> >> The payload is being used to classify — what other unintended use do you >> see? >> >> Classification based on inspecting a payload is certainly not a new >> element created by this architecture. >> >> Thanks, >> >> — Carlos. >> >> On May 28, 2015, at 10:10 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >> Hi Joel, >> >> On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern >> wrote: >> >>> I do not know what it would mean to apply privacy to information that is >>> a) gathered from a payload >>> b) and delivered along with that unprotected payload? >>> >> >> If you go back to the text in my discuss, I'm concerned about privacy of >> data that is in a payload that may be used in the SFC architecture. I am >> not saying that you have to apply privacy, just that it may be exposed when >> payloads are accessed and used. >> >> Thanks, >> Kathleen >> >> >> […] >> >> On May 28, 2015, at 10:30 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >> >> >> On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern >> wrote: >> >>> I am missing your point. Sorry. If it is in the payload, it is >>> exposed. If the payload is protected from exposure, then SFC won't be able >>> to extract it, so can't expose it. We are clear already in the document >>> that SFC metadata has to be protected from exposure outside of the domain, >>> noit because it is in the payload, but for cases where it is derived from >>> other sources that may be sensitive. >>> >>> Right, but you are pulling that content out and using it in ways that may >> not have been intended by those who created it and didn't encrypt it. This >> raises the security/privacy concern that their data may be used in ways >> they did not intend and be put into places they didn't expect. If it's >> data that has to be tracked for record retention, through an ESI data map >> or similar, its one more place this data resides that needs to be tracked From nobody Thu May 28 13:57:06 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5791A894B; Thu, 28 May 2015 13:56:59 -0700 (PDT) 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, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 PKOPcUw5Sta1; Thu, 28 May 2015 13:56:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFCE1A8944; Thu, 28 May 2015 13:56:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9AAADBF03; Thu, 28 May 2015 21:56:54 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y39LrdYIt7s; Thu, 28 May 2015 21:56:52 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CA0A8BF01; Thu, 28 May 2015 21:56:50 +0100 (IST) Message-ID: <5567810F.9020207@cs.tcd.ie> Date: Thu, 28 May 2015 21:56:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Joel Halpern Direct , "Joel M. Halpern" , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> In-Reply-To: <55677E37.1070203@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 20:56:59 -0000 Joel, If you are asserting that SFC cannot be used in a manner that has the problem I was trying to exemplify then I have to say, I'm skeptical. I also note that so-called HTTP "enrichment" is one of the examples cited in the arch draft, and there's not much difference between that and email from the relevant perspective. I also hope that I've succeeded in explaining the problem as I see it. If not please ask and I'll try some more to clarify. (Since you did not ask that, I assume you do get what I mean, but it would be helpful if you would acknowledge that so we can communicate more easily.) Can you point me at some piece of text in some draft that ensures that this problem cannot occur? If not, (which I think is the case), wouldn't we be better off acknowledging that it is an issue and one that needs to be tackled as best we can, as indeed Alia's earlier mail seems (to me) to suggest? Thanks, S. On 28/05/15 21:44, Joel Halpern Direct wrote: > That case would not occur within a service chain. > A service chain is about delivery of a packet to a series of services to > which it is not addressed (generally followed by delivery to the target > to which it is addressed.) > An SMTP server relaying email produces separate packets. The packets > from the user to the SMTP server are on one chain. The packets from > that server to another are completely separate, and on a different > chain. As such, those TLS SMTP packets between the servers would not > have any metadata from the first transfer. > > Mail servers are not SFC service functions. The only time it gets close > is when you are doing port 25 redirection, and then the service chain > ends at the mail server. > > Yours, > Joel > > On 5/28/15 4:35 PM, Stephen Farrell wrote: >> >> >> On 28/05/15 15:38, Joel M. Halpern wrote: >>> IF A, B, and C are service function forwarders (SFF), with a TLS >>> protected link for SFC, then the metadata will be protected. (Such a >>> link would be a transport mechanism, which SFC does not describe or >>> mandate. The SFC architecture is transport agnostic.) >> >> Ah, no the scenario I was thinking about is where, from >> the perspective of SFC, the TLS packets are the payload >> that is encapsulated. I guess A, B and C could be mail >> servers with starttls only turned on between B and C >> because that link is "external" (though within the same >> administrative domain). If some SFC thing at A were to >> dive into the SMTP traffic and pull out sensitive meta0 >> data then we wouldn't want that sent in clear from B to C >> because of the SFC encapsulation, right? >> >> S. >> >> >>> >>> If A, B, and C are service functions used by SFC, then there is no link >>> between B and C, so it can't be protected by TLS. >>> >>> So I can not see what more needs to be said? >>> >>> Yours, >>> Joel >>> >>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>> >>>> >>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>> I am not sure what you mean by "Metadata that contains information >>>>> that >>>>> is protected in the data plane". Most of what ends up in the metadata >>>>> is information that is passed on other interfaces directly to relevant >>>>> functions, or locally determine and locally processed. >>>> >>>> So what I had in mind were things like the following. >>>> >>>> - Packet is sent along a SFP A,B,C >>>> - B to C link is via say a TLS VPN >>>> - Metadata is created at A and is in the SFC encapsulation >>>> and not protected by the VPN >>>> - That seems bad >>>> >>>> S. >>>> >>>> >>>>> >>>>> The protection used for policy systems (which provide much of the >>>>> information) is based on the presence of persistent connections and >>>>> usage which crosses domains. Are you arguing that if AAA is encrypted >>>>> then policy delivered by AAA resulting in metadata in the packet >>>>> must be >>>>> encrypted in the data packets? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>> Stephen Farrell has entered the following ballot position for >>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>> >>>>>> When responding, please keep the subject line intact and reply to all >>>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>> this >>>>>> introductory paragraph, however.) >>>>>> >>>>>> >>>>>> Please refer to >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> DISCUSS: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> (1) I note the charter calls for this deliverable to "provide >>>>>> a description of... security models" The charter also >>>>>> generally notes that "The SFC WG will closely consider and >>>>>> address the management and security implications when >>>>>> documenting these deliverables." My conclusion is that this >>>>>> deliverable needs to reflect the results of a security >>>>>> analysis that the wg are suppoed to have carried out but that >>>>>> it's currently too vague only saying that solutions need to >>>>>> consider this. (Essentially this is a continuation of the >>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>> resolution of that will probably resolve this.) >>>>>> >>>>>> [1] >>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>> >>>>>> (2) Metadata that contains information that is protected in >>>>>> the data plane SHOULD be equally well protected when passed >>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>> not sure myself if "passed about" ought also include within a >>>>>> device but maybe it should really. But at minimum, I do >>>>>> think you need to define confidentiality and origin >>>>>> authentication services for SFC metadata and/or for the SFC >>>>>> encapsulation as a whole. And I think this architecture >>>>>> document needs to say that those services have to be >>>>>> well-defined as part of any solution. (And I am not >>>>>> saying that this draft needs to define how to do those.) >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> - It occurs to me that it might really be better for the WG >>>>>> to not publish this as an RFC now, but rather to put it on >>>>>> hold until they've made progress on the solutions. Perhaps >>>>>> revistiting this when the solutions are just at WGLC would >>>>>> result in the eventual RFC being a much more useful document. >>>>>> I think this one has to hedge so many bets that it's quite >>>>>> vague and won't be very useful even in the medium term. But >>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>> to push this out, even if that might only give the appearance >>>>>> of progress and not reflect real progress. >>>>>> >>>>>> - While IPR on an architecture document is sad to see, esp >>>>>> with what seems like it may be restrictive licensing, I do >>>>>> see the wg debated that and decided to move on. >>>>>> >>>>>> - The charter text describing this deliverable notes that >>>>>> "The initial scope is restricted to a single administrative >>>>>> domain, keeping in mind that architectural decisions made for >>>>>> the intra-domain case may have implications for the >>>>>> inter-domain case." So I think there is also a currently >>>>>> missing analysis (or the results of that) as to how the >>>>>> single-domain elements of this architecture might impinge on >>>>>> a later inter-domain architecture. So the text at the >>>>>> end of section 1.1 appears to contradict the chartered >>>>>> goals. >>>>>> >>>>>> - Chains will require some representation, and re-ordering >>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>> for fun) therefore there must be a requirement for some data >>>>>> integrity service and origin authentication and an >>>>>> authorisation decision function and therefore there must >>>>>> (istm) be a need for the architecture to define a chain >>>>>> producing entity of some kind that could be authenticated. >>>>>> That is an example of the missing security analysis that >>>>>> really is needed before this proceeds. (See my discuss point >>>>>> 2) >>>>>> >>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>> networks are slightly incongrous. In the case of WiFi when do >>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>> mobile node transmitter?) I suspect you really mean the wired >>>>>> bits of a mobile network so it might be better to say that. >>>>>> >>>>>> - 1.2 should follow 1.3 I think. >>>>>> >>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>> standard chaining logic, which is maybe right, but then you >>>>>> imply that a fully ordered set of SF's is a well defined >>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>> to say is that the architecture doesn't determine if an SFC >>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>> protocol work will have to do that. (In fact, I think you >>>>>> could say a lot more here and probably should.) >>>>>> >>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>> terms need to be defined. >>>>>> >>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>> partially ordered? >>>>>> >>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>>> standard and perhaps not likely to be (cf. some confict >>>>>> reviews on the same telechat as this) so I'd also drop that. >>>>>> And I think all of the exemplar SF's should really have a >>>>>> reference (ideally an RFC). >>>>>> >>>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>>> set of paths through (one or more) graphs but doesn't show >>>>>> the full graphs themselves. >>>>>> >>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>> the example given imply that all traffic (of what kind?) that >>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>> precision is needed really. The hybrid concept seems even >>>>>> odder to me. >>>>>> >>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>> architecture is to avoid such vagueness? If you mean that an >>>>>> SFP representation can embody an if-statement then saying >>>>>> that would be the thing to do. >>>>>> >>>>>> - Section 3: I think there's maybe a missing principle here >>>>>> about not making security and privacy worse in general. >>>>>> >>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>> traffic that congestion would be an issue? If so, should you >>>>>> say rather that any transport that has some way of handling >>>>>> congestion is ok. If not, then I guess the current text is >>>>>> fine. >>>>>> >>>>>> >>>>>> >>> > From nobody Thu May 28 14:18:39 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE32F1A89ED; Thu, 28 May 2015 14:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbgBUFKe_ZnR; Thu, 28 May 2015 14:18:31 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CA01A89B5; Thu, 28 May 2015 14:18:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7FAE22464B7; Thu, 28 May 2015 14:18:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4225F251016; Thu, 28 May 2015 14:18:30 -0700 (PDT) Message-ID: <5567861D.9020301@joelhalpern.com> Date: Thu, 28 May 2015 17:18:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , Joel Halpern Direct , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> In-Reply-To: <5567810F.9020207@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 21:18:34 -0000 While SMTP servers are a bad example, service chaining can be use with HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. Both of those terminate connections and create new packets. As such, the two sides of such devices are on separate service chains. In order for the two sides to be on the same chain, the service function would have to copy the service chaining and related metadata from one side to the other. I can't stop them from doing so, but in most cases it would be misleading. What we have done is to recognize that these are generally different service chains. Because the packets will get different treatments. Yours, Joel On 5/28/15 4:56 PM, Stephen Farrell wrote: > > Joel, > > If you are asserting that SFC cannot be used in a manner that > has the problem I was trying to exemplify then I have to say, > I'm skeptical. I also note that so-called HTTP "enrichment" > is one of the examples cited in the arch draft, and there's > not much difference between that and email from the relevant > perspective. > > I also hope that I've succeeded in explaining the problem as > I see it. If not please ask and I'll try some more to clarify. > (Since you did not ask that, I assume you do get what I mean, > but it would be helpful if you would acknowledge that so we > can communicate more easily.) > > Can you point me at some piece of text in some draft that > ensures that this problem cannot occur? If not, (which I > think is the case), wouldn't we be better off acknowledging > that it is an issue and one that needs to be tackled as > best we can, as indeed Alia's earlier mail seems (to me) > to suggest? > > Thanks, > S. > > > On 28/05/15 21:44, Joel Halpern Direct wrote: >> That case would not occur within a service chain. >> A service chain is about delivery of a packet to a series of services to >> which it is not addressed (generally followed by delivery to the target >> to which it is addressed.) >> An SMTP server relaying email produces separate packets. The packets >> from the user to the SMTP server are on one chain. The packets from >> that server to another are completely separate, and on a different >> chain. As such, those TLS SMTP packets between the servers would not >> have any metadata from the first transfer. >> >> Mail servers are not SFC service functions. The only time it gets close >> is when you are doing port 25 redirection, and then the service chain >> ends at the mail server. >> >> Yours, >> Joel >> >> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>> >>> >>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>> IF A, B, and C are service function forwarders (SFF), with a TLS >>>> protected link for SFC, then the metadata will be protected. (Such a >>>> link would be a transport mechanism, which SFC does not describe or >>>> mandate. The SFC architecture is transport agnostic.) >>> >>> Ah, no the scenario I was thinking about is where, from >>> the perspective of SFC, the TLS packets are the payload >>> that is encapsulated. I guess A, B and C could be mail >>> servers with starttls only turned on between B and C >>> because that link is "external" (though within the same >>> administrative domain). If some SFC thing at A were to >>> dive into the SMTP traffic and pull out sensitive meta0 >>> data then we wouldn't want that sent in clear from B to C >>> because of the SFC encapsulation, right? >>> >>> S. >>> >>> >>>> >>>> If A, B, and C are service functions used by SFC, then there is no link >>>> between B and C, so it can't be protected by TLS. >>>> >>>> So I can not see what more needs to be said? >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>> >>>>> >>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>> I am not sure what you mean by "Metadata that contains information >>>>>> that >>>>>> is protected in the data plane". Most of what ends up in the metadata >>>>>> is information that is passed on other interfaces directly to relevant >>>>>> functions, or locally determine and locally processed. >>>>> >>>>> So what I had in mind were things like the following. >>>>> >>>>> - Packet is sent along a SFP A,B,C >>>>> - B to C link is via say a TLS VPN >>>>> - Metadata is created at A and is in the SFC encapsulation >>>>> and not protected by the VPN >>>>> - That seems bad >>>>> >>>>> S. >>>>> >>>>> >>>>>> >>>>>> The protection used for policy systems (which provide much of the >>>>>> information) is based on the presence of persistent connections and >>>>>> usage which crosses domains. Are you arguing that if AAA is encrypted >>>>>> then policy delivered by AAA resulting in metadata in the packet >>>>>> must be >>>>>> encrypted in the data packets? >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>> >>>>>>> When responding, please keep the subject line intact and reply to all >>>>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>>> this >>>>>>> introductory paragraph, however.) >>>>>>> >>>>>>> >>>>>>> Please refer to >>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>> >>>>>>> >>>>>>> The document, along with other ballot positions, can be found here: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> DISCUSS: >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>>> (1) I note the charter calls for this deliverable to "provide >>>>>>> a description of... security models" The charter also >>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>> address the management and security implications when >>>>>>> documenting these deliverables." My conclusion is that this >>>>>>> deliverable needs to reflect the results of a security >>>>>>> analysis that the wg are suppoed to have carried out but that >>>>>>> it's currently too vague only saying that solutions need to >>>>>>> consider this. (Essentially this is a continuation of the >>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>> resolution of that will probably resolve this.) >>>>>>> >>>>>>> [1] >>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>> >>>>>>> (2) Metadata that contains information that is protected in >>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>> not sure myself if "passed about" ought also include within a >>>>>>> device but maybe it should really. But at minimum, I do >>>>>>> think you need to define confidentiality and origin >>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>> encapsulation as a whole. And I think this architecture >>>>>>> document needs to say that those services have to be >>>>>>> well-defined as part of any solution. (And I am not >>>>>>> saying that this draft needs to define how to do those.) >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> COMMENT: >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>>> - It occurs to me that it might really be better for the WG >>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>> result in the eventual RFC being a much more useful document. >>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>> vague and won't be very useful even in the medium term. But >>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>> to push this out, even if that might only give the appearance >>>>>>> of progress and not reflect real progress. >>>>>>> >>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>> see the wg debated that and decided to move on. >>>>>>> >>>>>>> - The charter text describing this deliverable notes that >>>>>>> "The initial scope is restricted to a single administrative >>>>>>> domain, keeping in mind that architectural decisions made for >>>>>>> the intra-domain case may have implications for the >>>>>>> inter-domain case." So I think there is also a currently >>>>>>> missing analysis (or the results of that) as to how the >>>>>>> single-domain elements of this architecture might impinge on >>>>>>> a later inter-domain architecture. So the text at the >>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>> goals. >>>>>>> >>>>>>> - Chains will require some representation, and re-ordering >>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>> for fun) therefore there must be a requirement for some data >>>>>>> integrity service and origin authentication and an >>>>>>> authorisation decision function and therefore there must >>>>>>> (istm) be a need for the architecture to define a chain >>>>>>> producing entity of some kind that could be authenticated. >>>>>>> That is an example of the missing security analysis that >>>>>>> really is needed before this proceeds. (See my discuss point >>>>>>> 2) >>>>>>> >>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>> networks are slightly incongrous. In the case of WiFi when do >>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>> mobile node transmitter?) I suspect you really mean the wired >>>>>>> bits of a mobile network so it might be better to say that. >>>>>>> >>>>>>> - 1.2 should follow 1.3 I think. >>>>>>> >>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>> could say a lot more here and probably should.) >>>>>>> >>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>> terms need to be defined. >>>>>>> >>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>> partially ordered? >>>>>>> >>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>> reviews on the same telechat as this) so I'd also drop that. >>>>>>> And I think all of the exemplar SF's should really have a >>>>>>> reference (ideally an RFC). >>>>>>> >>>>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>> the full graphs themselves. >>>>>>> >>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>> the example given imply that all traffic (of what kind?) that >>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>> precision is needed really. The hybrid concept seems even >>>>>>> odder to me. >>>>>>> >>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>> architecture is to avoid such vagueness? If you mean that an >>>>>>> SFP representation can embody an if-statement then saying >>>>>>> that would be the thing to do. >>>>>>> >>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>> about not making security and privacy worse in general. >>>>>>> >>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>> traffic that congestion would be an issue? If so, should you >>>>>>> say rather that any transport that has some way of handling >>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>> fine. >>>>>>> >>>>>>> >>>>>>> >>>> >> > From nobody Thu May 28 14:20:59 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11301A8A48; Thu, 28 May 2015 14:20:55 -0700 (PDT) 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 RJntUDAksvfA; Thu, 28 May 2015 14:20:53 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCC61A8A15; Thu, 28 May 2015 14:20:53 -0700 (PDT) Received: by qgg60 with SMTP id 60so22088643qgg.2; Thu, 28 May 2015 14:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GQYVA5z0Sr1EBWL0TDzZ93syKXUsqmowvnppGPTwIP4=; b=iwW9XnxXORAxr8ge1bQKHK3wbHLvbNyu7nLET04nAR1v25+9h7fhEBTtoXKKnHm4h0 k/abDvcmhfdShqSwPh4ZICKBLfscrou/2ffkwTrla9mn1Mk4jJ2EaYZ7uYOGwcT4O41+ XE/LXZYxjOfJFI1VY3k+I80cxSvKhylBImTck/LLGGZUV8LEAhBiP0hXm1B+jZe9Gfa4 quj41p0cIUiLh6toWkuuZ3OMz5d4dYzp3QMurQ+hnC2z00iIUcJibKymQ2iKNufCnrCP BI78btTQL0M6pm56FQn9uSiwRwC92MNHkwaqJVYIGzpYW5NXPGlL8PMifPCg7V/jVUn/ sR7w== X-Received: by 10.140.98.36 with SMTP id n33mr5846322qge.62.1432848052662; Thu, 28 May 2015 14:20:52 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id k133sm1114725qhc.35.2015.05.28.14.20.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 May 2015 14:20:51 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <55677F7D.1070807@joelhalpern.com> Date: Thu, 28 May 2015 17:20:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2F403ACA-D45B-4184-9E39-9DE527DC7A35@gmail.com> References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> <556723E0.5040603@joelhalpern.com> <4C97F2B0-7AAE-49A4-9D63-65B5494AABBE@cisco.com> <55677F7D.1070807@joelhalpern.com> To: "Joel M. Halpern" Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , Alia Atlas , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 21:20:55 -0000 Joel, Sent from my iPhone > On May 28, 2015, at 4:50 PM, "Joel M. Halpern" wrote= : >=20 > If the data is already in the packet, and the packet is not protected, the= n while copying it may make it easier to extract, that ease is pretty small,= and the data was already extractable before service chaining. > If the data is in the packet and the packet is encrypted, then SFC does no= t see it, and can not use it. >=20 I can see your point of view, but that does not mean that a warning is not n= eeded. Someone may not be aware that their plain text traffic could be used= in the ways that are possible. Alia's suggested text addresses this possib= le concern and is much appreciated to remove my discuss. Let me know if/when this text is incorporated. Best regards, Kathleen=20 > As for information that is derived from other sources, we already have tex= t in the document that this can be sensitive and needs to be handled with ca= re. >=20 > For the most part, the text you propose is harmless, but does not add anyt= hing to what the document already says. > The one exception is with the notion of removing the metadata when it is n= o longer needed. Since service chaining does not know the semantics or user= s of the metadata, it can't perform such removal. And a service function ha= s no way to know if some later service function may need the data. Which le= aves us only removal at exit from service chaining, which is already require= d. >=20 > Yours, > Joel >=20 >> On 5/28/15 4:32 PM, Alia Atlas wrote: >> Carlos & Joel, >>=20 >> Apologies for top-posting, but just quickly.... >>=20 >> Private information could absolutely be pulled from the packet and even >> placed into metadata as an easy shortcut for flow identification. >> Consider a case where the packet included the EMEI and that was used as >> part of a flow identifier. It does a great job as a unique part of a flo= w >> identifier tuple - but it also reveals the user and handset. >>=20 >> Perhaps something along the lines of: >>=20 >> "The SFC architecture does not define what types of service functions mig= ht >> be included. However, it does allow for the passing of information from >> one service function to the next in the SFP. This information might be >> passed indirectly via metadata that identifies the flow and allows the ne= xt >> service function to look up that information. Alternately, that >> information might be passed directly in a packet's metadata. It is >> important to consider the privacy considerations of how that information i= s >> shared along the SFP and that it is removed promptly when no longer neede= d >> operationally for the SFP. >>=20 >> For instance, one type of service function that may exist is a flow >> classifier. Depending upon whether or not the packet is encrypted, as is= >> increasingly common [ REFERENCE NEEDED], metadata to identify the flow >> might be pulled from the packet's headers and/or from DPI. When metadata= >> is derived from information that a user may consider private (i.e. >> identity, equipment, URI, application, etc.), there are many ways [see RFC= >> 6973] to mitigate the threat of leaking such pre-processed private data >> across the SFC. For example, one method might be to process and provide= >> an otherwise unrelated identifier or tuple to be forwarded along the SFP a= s >> metadata or associated indirectly with that metadata." >>=20 >> When you combine the reality of pervasive monitoring - even within some >> administrative domains that have not agreed to it - with passing private >> information along with the packets, I do think it is useful to have some >> considerations that address this. >>=20 >> Obviously, as the control plane and details for passing along meta-data >> gets further developed, this can be better articulated. >>=20 >> Please let me know if this helps clarify. >>=20 >> Thanks, >> Alia >>=20 >> On Thu, May 28, 2015 at 12:39 PM, Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >>=20 >>> Kathleen, >>>=20 >>> Thank you for taking the time to review this document. >>>=20 >>> I am responding to this email on the thread, because I think it is the o= ne >>> that most clearly explains your concerns. I also include an additional >>> clarification you wrote on a different email, all below for context. >>>=20 >>> Below you say: >>> *=E2=80=9CI'm concerned about privacy of data that is in a payload that m= ay be >>> used in the SFC architecture.=E2=80=9D* >>> and >>> *=E2=80=9Cyou are pulling that content out and using it in ways that may= not have >>> been intended by those who created it and didn't encrypt it.=E2=80=9D* >>>=20 >>> I am also having some trouble exemplifying and visualizing your concern,= >>> and how to address it. >>>=20 >>> Could you please, perhaps, be more explicit as to how =E2=80=98content i= s pulled >>> from the payload and used in unintended ways=E2=80=99? What exactly do y= ou have in >>> mind? Can you share an example? >>>=20 >>> The payload is being used to classify =E2=80=94 what other unintended us= e do you >>> see? >>>=20 >>> Classification based on inspecting a payload is certainly not a new >>> element created by this architecture. >>>=20 >>> Thanks, >>>=20 >>> =E2=80=94 Carlos. >>>=20 >>> On May 28, 2015, at 10:10 AM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>>=20 >>> Hi Joel, >>>=20 >>> On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern >>> wrote: >>>=20 >>>> I do not know what it would mean to apply privacy to information that i= s >>>> a) gathered from a payload >>>> b) and delivered along with that unprotected payload? >>>=20 >>> If you go back to the text in my discuss, I'm concerned about privacy of= >>> data that is in a payload that may be used in the SFC architecture. I a= m >>> not saying that you have to apply privacy, just that it may be exposed w= hen >>> payloads are accessed and used. >>>=20 >>> Thanks, >>> Kathleen >>>=20 >>>=20 >>> [=E2=80=A6] >>>=20 >>> On May 28, 2015, at 10:30 AM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>>=20 >>>=20 >>>=20 >>> On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern >>> wrote: >>>=20 >>>> I am missing your point. Sorry. If it is in the payload, it is >>>> exposed. If the payload is protected from exposure, then SFC won't be a= ble >>>> to extract it, so can't expose it. We are clear already in the documen= t >>>> that SFC metadata has to be protected from exposure outside of the doma= in, >>>> noit because it is in the payload, but for cases where it is derived fr= om >>>> other sources that may be sensitive. >>>>=20 >>>> Right, but you are pulling that content out and using it in ways that m= ay >>> not have been intended by those who created it and didn't encrypt it. T= his >>> raises the security/privacy concern that their data may be used in ways >>> they did not intend and be put into places they didn't expect. If it's >>> data that has to be tracked for record retention, through an ESI data ma= p >>> or similar, its one more place this data resides that needs to be tracke= d From nobody Thu May 28 14:23:28 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87991A8A48; Thu, 28 May 2015 14:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 3plZHPVGQKFO; Thu, 28 May 2015 14:23:23 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC40F1A8A15; Thu, 28 May 2015 14:23:22 -0700 (PDT) Received: by oiww2 with SMTP id w2so42663682oiw.0; Thu, 28 May 2015 14:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y8eaHx4TnbVtXf3LSpSwArYrbGJbFXiuDlOUaXIf0+w=; b=upzqaxONt5Dl7Eg5e9JVHdMEbhLMGzZXVw64KYQvUHiIkytQ9yJCK79xhN/fiszvN3 atuFPdNlWmqSzseToACehWXvnWwpGW8ZmLSp10wOGnOiHvybVBkkx9IVLioSSq9Zt464 NpDJTgBQHOYU3jXt9Qp8zxx80xMi469Aur51XQs4+Z5Hmc236ks8GdEvabXRoFs76lG+ Xfj1o8uyJf82wT7PGEvpyIC9sgG3xpzBgH2QL1M1oA1xP3tXnQLk8LDh1NjFNKbyOIvK ydAmkCjXqMZ4g8yN8HpAZSml+wAY9xSEP2RRg+YQTwt9yNnaUPSyer+LVQpq8Vm3Y1/C bv1w== MIME-Version: 1.0 X-Received: by 10.202.89.131 with SMTP id n125mr4059239oib.91.1432848202203; Thu, 28 May 2015 14:23:22 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Thu, 28 May 2015 14:23:22 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Thu, 28 May 2015 14:23:22 -0700 (PDT) In-Reply-To: <55677F7D.1070807@joelhalpern.com> References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> <556723E0.5040603@joelhalpern.com> <4C97F2B0-7AAE-49A4-9D63-65B5494AABBE@cisco.com> <55677F7D.1070807@joelhalpern.com> Date: Thu, 28 May 2015 17:23:22 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a113d381e1c09f605172af823 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , sfc-chairs@ietf.org, "sfc@ietf.org" , Kathleen Moriarty , The IESG , draft-ietf-sfc-architecture@ietf.org, "draft-ietf-sfc-architecture.shepherd@ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 21:23:26 -0000 --001a113d381e1c09f605172af823 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joel, On May 28, 2015 4:50 PM, "Joel M. Halpern" wrote: > > If the data is already in the packet, and the packet is not protected, then while copying it may make it easier to extract, that ease is pretty small, and the data was already extractable before service chaining. > If the data is in the packet and the packet is encrypted, then SFC does not see it, and can not use it. First, there are scenarios where it isn't as clear-cut. For instance, perhaps the classifier can decrypt or perhaps the classifier encrypts the packet afterwards. The extra ease makes the difference for a collector that is picking up headers rather than full packets. It makes a difference for service functions that may work only on the header and meta-data. If your point is that there are no concerns around privacy, then that meets to be reasoned and spelled out clearly. While in routing, we are not aware of many of the attacks & pervasive monitoring that is happening, that doesn't mean we don't need to consider it. > As for information that is derived from other sources, we already have text in the document that this can be sensitive and needs to be handled with care. Yes, I appreciate that you added that. However, as is obvious from the discussion, the kind of privacy concerns and motivations don't spring really to mind for many readers. > For the most part, the text you propose is harmless, but does not add anything to what the document already says. It is pretty bland, with the exception of references to RFC 6973. I would be happy to see better text suggested that indicates significant consideration of the concerns. > The one exception is with the notion of removing the metadata when it is no longer needed. Since service chaining does not know the semantics or users of the metadata, it can't perform such removal. And a service function has no way to know if some later service function may need the data. Which leaves us only removal at exit from service chaining, which is already required. I would think that could depend upon the control-plane or orchestration system. For the case of information indirectly pointed to by meta-data, this also indicates that the data should be removed when the flow or SFP is no longer in use. Regards, Alia > Yours, > Joel > > > On 5/28/15 4:32 PM, Alia Atlas wrote: >> >> Carlos & Joel, >> >> Apologies for top-posting, but just quickly.... >> >> Private information could absolutely be pulled from the packet and even >> placed into metadata as an easy shortcut for flow identification. >> Consider a case where the packet included the EMEI and that was used as >> part of a flow identifier. It does a great job as a unique part of a flow >> identifier tuple - but it also reveals the user and handset. >> >> Perhaps something along the lines of: >> >> "The SFC architecture does not define what types of service functions might >> be included. However, it does allow for the passing of information from >> one service function to the next in the SFP. This information might be >> passed indirectly via metadata that identifies the flow and allows the next >> service function to look up that information. Alternately, that >> information might be passed directly in a packet's metadata. It is >> important to consider the privacy considerations of how that information is >> shared along the SFP and that it is removed promptly when no longer needed >> operationally for the SFP. >> >> For instance, one type of service function that may exist is a flow >> classifier. Depending upon whether or not the packet is encrypted, as i= s >> increasingly common [ REFERENCE NEEDED], metadata to identify the flow >> might be pulled from the packet's headers and/or from DPI. When metadat= a >> is derived from information that a user may consider private (i.e. >> identity, equipment, URI, application, etc.), there are many ways [see RFC >> 6973] to mitigate the threat of leaking such pre-processed private data >> across the SFC. For example, one method might be to process and provid= e >> an otherwise unrelated identifier or tuple to be forwarded along the SFP as >> metadata or associated indirectly with that metadata." >> >> When you combine the reality of pervasive monitoring - even within some >> administrative domains that have not agreed to it - with passing private >> information along with the packets, I do think it is useful to have some >> considerations that address this. >> >> Obviously, as the control plane and details for passing along meta-data >> gets further developed, this can be better articulated. >> >> Please let me know if this helps clarify. >> >> Thanks, >> Alia >> >> On Thu, May 28, 2015 at 12:39 PM, Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> >>> Kathleen, >>> >>> Thank you for taking the time to review this document. >>> >>> I am responding to this email on the thread, because I think it is the one >>> that most clearly explains your concerns. I also include an additional >>> clarification you wrote on a different email, all below for context. >>> >>> Below you say: >>> *=E2=80=9CI'm concerned about privacy of data that is in a payload that= may be >>> used in the SFC architecture.=E2=80=9D* >>> and >>> *=E2=80=9Cyou are pulling that content out and using it in ways that ma= y not have >>> been intended by those who created it and didn't encrypt it.=E2=80=9D* >>> >>> >>> I am also having some trouble exemplifying and visualizing your concern= , >>> and how to address it. >>> >>> Could you please, perhaps, be more explicit as to how =E2=80=98content = is pulled >>> from the payload and used in unintended ways=E2=80=99? What exactly do = you have in >>> mind? Can you share an example? >>> >>> The payload is being used to classify =E2=80=94 what other unintended u= se do you >>> see? >>> >>> Classification based on inspecting a payload is certainly not a new >>> element created by this architecture. >>> >>> Thanks, >>> >>> =E2=80=94 Carlos. >>> >>> On May 28, 2015, at 10:10 AM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>> Hi Joel, >>> >>> On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern >>> wrote: >>> >>>> I do not know what it would mean to apply privacy to information that is >>>> a) gathered from a payload >>>> b) and delivered along with that unprotected payload? >>>> >>> >>> If you go back to the text in my discuss, I'm concerned about privacy o= f >>> data that is in a payload that may be used in the SFC architecture. I am >>> not saying that you have to apply privacy, just that it may be exposed when >>> payloads are accessed and used. >>> >>> Thanks, >>> Kathleen >>> >>> >>> [=E2=80=A6] >>> >>> On May 28, 2015, at 10:30 AM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>> >>> >>> On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern >>> wrote: >>> >>>> I am missing your point. Sorry. If it is in the payload, it is >>>> exposed. If the payload is protected from exposure, then SFC won't be able >>>> to extract it, so can't expose it. We are clear already in the document >>>> that SFC metadata has to be protected from exposure outside of the domain, >>>> noit because it is in the payload, but for cases where it is derived from >>>> other sources that may be sensitive. >>>> >>>> Right, but you are pulling that content out and using it in ways that may >>> >>> not have been intended by those who created it and didn't encrypt it. This >>> raises the security/privacy concern that their data may be used in ways >>> they did not intend and be put into places they didn't expect. If it's >>> data that has to be tracked for record retention, through an ESI data map >>> or similar, its one more place this data resides that needs to be tracked --001a113d381e1c09f605172af823 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Joel,
On May 28, 2015 4:50 PM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:
>
> If the data is already in the packet, and the packet is not protected,= then while copying it may make it easier to extract, that ease is pretty s= mall, and the data was already extractable before service chaining.
> If the data is in the packet and the packet is encrypted, then SFC doe= s not see it, and can not use it.

First,=C2=A0 there are scenarios where it isn't as clear= -cut.=C2=A0 For instance,=C2=A0 perhaps the classifier can decrypt or perha= ps the classifier encrypts the packet afterwards.

The extra ease makes the difference for a collector that is = picking up headers rather than full packets.

It makes a difference for service functions that may work on= ly on the header and meta-data.

If your point is that there are no concerns around privacy, = then that meets to be reasoned and spelled out clearly.=C2=A0=C2=A0 While i= n routing, we are not aware of many of the attacks & pervasive monitori= ng that is happening,=C2=A0 that doesn't mean we don't need to cons= ider it.

> As for information that is derived from other sources, = we already have text in the document that this can be sensitive and needs t= o be handled with care.

Yes, I appreciate that you added that.=C2=A0=C2=A0 However,= =C2=A0 as is obvious from the discussion,=C2=A0 the kind of privacy concern= s and motivations don't spring really to mind for many readers.

> For the most part, the text you propose is harmless, bu= t does not add anything to what the document already says.

It is pretty bland,=C2=A0 with the exception of references t= o RFC 6973.=C2=A0 I would be happy to see better text suggested that indica= tes significant consideration of the concerns.

> The one exception is with the notion of removing the me= tadata when it is no longer needed.=C2=A0 Since service chaining does not k= now the semantics or users of the metadata, it can't perform such remov= al.=C2=A0 And a service function has no way to know if some later service f= unction may need the data.=C2=A0 Which leaves us only removal at exit from = service chaining, which is already required.

I would think that could depend upon the control-plane or or= chestration system.=C2=A0=C2=A0 For the case of information indirectly poin= ted to by meta-data, this also indicates that the data should be removed wh= en the flow or SFP is no longer in use.

Regards,
Alia

> Yours,
> Joel
>
>
> On 5/28/15 4:32 PM, Alia Atlas wrote:
>>
>> Carlos & Joel,
>>
>> Apologies for top-posting, but just quickly....
>>
>> Private information could absolutely be pulled from the packet and= even
>> placed into metadata as an easy shortcut for flow identification.<= br> >> Consider a case where the packet included the EMEI and that was us= ed as
>> part of a flow identifier.=C2=A0 It does a great job as a unique p= art of a flow
>> identifier tuple - but it also reveals the user and handset.
>>
>> Perhaps something along the lines of:
>>
>> "The SFC architecture does not define what types of service f= unctions might
>> be included.=C2=A0 However, it does allow for the passing of infor= mation from
>> one service function to the next in the SFP.=C2=A0 This informatio= n might be
>> passed indirectly via metadata that identifies the flow and allows= the next
>> service function to look up that information.=C2=A0 Alternately, t= hat
>> information might be passed directly in a packet's metadata.= =C2=A0 It is
>> important to consider the privacy considerations of how that infor= mation is
>> shared along the SFP and that it is removed promptly when no longe= r needed
>> operationally for the SFP.
>>
>> For instance, one type of service function that may exist is a flo= w
>> classifier.=C2=A0 Depending upon whether or not the packet is encr= ypted, as is
>> increasingly common [ REFERENCE NEEDED], metadata to identify the = flow
>> might be pulled from the packet's headers and/or from DPI.=C2= =A0 When metadata
>> is derived from information that a user may consider private (i.e.=
>> identity, equipment, URI, application, etc.), there are many ways = [see RFC
>> 6973] to mitigate the threat of leaking such pre-processed private= data
>> across the SFC.=C2=A0 =C2=A0For example, one method might be to pr= ocess and provide
>> an otherwise unrelated identifier or tuple to be forwarded along t= he SFP as
>> metadata or associated indirectly with that metadata."
>>
>> When you combine the reality of pervasive monitoring - even within= some
>> administrative domains that have not agreed to it - with passing p= rivate
>> information along with the packets, I do think it is useful to hav= e some
>> considerations that address this.
>>
>> Obviously, as the control plane and details for passing along meta= -data
>> gets further developed, this can be better articulated.
>>
>> Please let me know if this helps clarify.
>>
>> Thanks,
>> Alia
>>
>> On Thu, May 28, 2015 at 12:39 PM, Carlos Pignataro (cpignata) <=
>> cpignata@cisco.com> w= rote:
>>
>>> Kathleen,
>>>
>>> Thank you for taking the time to review this document.
>>>
>>> I am responding to this email on the thread, because I think i= t is the one
>>> that most clearly explains your concerns. I also include an ad= ditional
>>> clarification you wrote on a different email, all below for co= ntext.
>>>
>>> Below you say:
>>> *=E2=80=9CI'm concerned about privacy of data that is in a= payload that may be
>>> used in the SFC architecture.=E2=80=9D*
>>> and
>>> *=E2=80=9Cyou are pulling that content out and using it in way= s that may not have
>>> been intended by those who created it and didn't encrypt i= t.=E2=80=9D*
>>>
>>>
>>> I am also having some trouble exemplifying and visualizing you= r concern,
>>> and how to address it.
>>>
>>> Could you please, perhaps, be more explicit as to how =E2=80= =98content is pulled
>>> from the payload and used in unintended ways=E2=80=99? What ex= actly do you have in
>>> mind? Can you share an example?
>>>
>>> The payload is being used to classify =E2=80=94 what other uni= ntended use do you
>>> see?
>>>
>>> Classification based on inspecting a payload is certainly not = a new
>>> element created by this architecture.
>>>
>>> Thanks,
>>>
>>> =E2=80=94 Carlos.
>>>
>>> On May 28, 2015, at 10:10 AM, Kathleen Moriarty <
>>> kathleen.m= oriarty.ietf@gmail.com> wrote:
>>>
>>> Hi Joel,
>>>
>>> On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern <jmh@joelhalpern.com>
>>> =C2=A0 wrote:
>>>
>>>> I do not know what it would mean to apply privacy to infor= mation that is
>>>> a) gathered from a payload
>>>> b) and delivered along with that unprotected payload?
>>>>
>>>
>>> If you go back to the text in my discuss, I'm concerned ab= out privacy of
>>> data that is in a payload that may be used in the SFC architec= ture.=C2=A0 I am
>>> not saying that you have to apply privacy, just that it may be= exposed when
>>> payloads are accessed and used.
>>>
>>> Thanks,
>>> Kathleen
>>>
>>>
>>> [=E2=80=A6]
>>>
>>> On May 28, 2015, at 10:30 AM, Kathleen Moriarty <
>>> kathleen.m= oriarty.ietf@gmail.com> wrote:
>>>
>>>
>>>
>>> On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern <jmh@joelhalpern.com>
>>> wrote:
>>>
>>>> I am missing your point.=C2=A0 Sorry.=C2=A0 If it is in th= e payload, it is
>>>> exposed.=C2=A0 If the payload is protected from exposure, = then SFC won't be able
>>>> to extract it, so can't expose it.=C2=A0 We are clear = already in the document
>>>> that SFC metadata has to be protected from exposure outsid= e of the domain,
>>>> noit because it is in the payload, but for cases where it = is derived from
>>>> other sources that may be sensitive.
>>>>
>>>> Right, but you are pulling that content out and using it i= n ways that may
>>>
>>> not have been intended by those who created it and didn't = encrypt it.=C2=A0 This
>>> raises the security/privacy concern that their data may be use= d in ways
>>> they did not intend and be put into places they didn't exp= ect.=C2=A0 If it's
>>> data that has to be tracked for record retention, through an E= SI data map
>>> or similar, its one more place this data resides that needs to= be tracked

--001a113d381e1c09f605172af823-- From nobody Thu May 28 14:25:12 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A8E1A8A73; Thu, 28 May 2015 14:25:06 -0700 (PDT) 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, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 uc46M6tHe-43; Thu, 28 May 2015 14:25:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F201A8A5A; Thu, 28 May 2015 14:25:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A56DBEFB; Thu, 28 May 2015 22:25:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D5KaE_AfOVz; Thu, 28 May 2015 22:24:58 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C0780BEF2; Thu, 28 May 2015 22:24:56 +0100 (IST) Message-ID: <556787A5.9050808@cs.tcd.ie> Date: Thu, 28 May 2015 22:24:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , Joel Halpern Direct , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> In-Reply-To: <5567861D.9020301@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 21:25:06 -0000 Joel, I'm afraid you've lost me again, but since it's now time for me to go to the pub, that's fine:-) For me the important thing is if meta-data is inserted at A and then packets are encrypted by something between B and C, then we do not want cleartext meta-data attached to the ciphertext sent from B to C to always have to risk making the encryption pointless. To me, that means that this architecture needs to call for the existence of a confidentiality service that can be used to protect at least the meta-data. (And it could protect more too I guess but the details would be for the WG to figure later.) I think additional scenarios can similarly justify a need for the definition of a data origin authentication service. If we agreed about that and could move on to how that ought be expressed in the arch document, that'd be great. (But as I'll be in the pub, I won't find out 'till tomorrow:-) Cheers, S. On 28/05/15 22:18, Joel M. Halpern wrote: > While SMTP servers are a bad example, service chaining can be use with > HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. Both of > those terminate connections and create new packets. As such, the two > sides of such devices are on separate service chains. In order for the > two sides to be on the same chain, the service function would have to > copy the service chaining and related metadata from one side to the > other. I can't stop them from doing so, but in most cases it would be > misleading. > > What we have done is to recognize that these are generally different > service chains. Because the packets will get different treatments. > > Yours, > Joel > > On 5/28/15 4:56 PM, Stephen Farrell wrote: >> >> Joel, >> >> If you are asserting that SFC cannot be used in a manner that >> has the problem I was trying to exemplify then I have to say, >> I'm skeptical. I also note that so-called HTTP "enrichment" >> is one of the examples cited in the arch draft, and there's >> not much difference between that and email from the relevant >> perspective. >> >> I also hope that I've succeeded in explaining the problem as >> I see it. If not please ask and I'll try some more to clarify. >> (Since you did not ask that, I assume you do get what I mean, >> but it would be helpful if you would acknowledge that so we >> can communicate more easily.) >> >> Can you point me at some piece of text in some draft that >> ensures that this problem cannot occur? If not, (which I >> think is the case), wouldn't we be better off acknowledging >> that it is an issue and one that needs to be tackled as >> best we can, as indeed Alia's earlier mail seems (to me) >> to suggest? >> >> Thanks, >> S. >> >> >> On 28/05/15 21:44, Joel Halpern Direct wrote: >>> That case would not occur within a service chain. >>> A service chain is about delivery of a packet to a series of services to >>> which it is not addressed (generally followed by delivery to the target >>> to which it is addressed.) >>> An SMTP server relaying email produces separate packets. The packets >>> from the user to the SMTP server are on one chain. The packets from >>> that server to another are completely separate, and on a different >>> chain. As such, those TLS SMTP packets between the servers would not >>> have any metadata from the first transfer. >>> >>> Mail servers are not SFC service functions. The only time it gets close >>> is when you are doing port 25 redirection, and then the service chain >>> ends at the mail server. >>> >>> Yours, >>> Joel >>> >>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>> >>>> >>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>> IF A, B, and C are service function forwarders (SFF), with a TLS >>>>> protected link for SFC, then the metadata will be protected. (Such a >>>>> link would be a transport mechanism, which SFC does not describe or >>>>> mandate. The SFC architecture is transport agnostic.) >>>> >>>> Ah, no the scenario I was thinking about is where, from >>>> the perspective of SFC, the TLS packets are the payload >>>> that is encapsulated. I guess A, B and C could be mail >>>> servers with starttls only turned on between B and C >>>> because that link is "external" (though within the same >>>> administrative domain). If some SFC thing at A were to >>>> dive into the SMTP traffic and pull out sensitive meta0 >>>> data then we wouldn't want that sent in clear from B to C >>>> because of the SFC encapsulation, right? >>>> >>>> S. >>>> >>>> >>>>> >>>>> If A, B, and C are service functions used by SFC, then there is no >>>>> link >>>>> between B and C, so it can't be protected by TLS. >>>>> >>>>> So I can not see what more needs to be said? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>> >>>>>> >>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>> I am not sure what you mean by "Metadata that contains information >>>>>>> that >>>>>>> is protected in the data plane". Most of what ends up in the >>>>>>> metadata >>>>>>> is information that is passed on other interfaces directly to >>>>>>> relevant >>>>>>> functions, or locally determine and locally processed. >>>>>> >>>>>> So what I had in mind were things like the following. >>>>>> >>>>>> - Packet is sent along a SFP A,B,C >>>>>> - B to C link is via say a TLS VPN >>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>> and not protected by the VPN >>>>>> - That seems bad >>>>>> >>>>>> S. >>>>>> >>>>>> >>>>>>> >>>>>>> The protection used for policy systems (which provide much of the >>>>>>> information) is based on the presence of persistent connections and >>>>>>> usage which crosses domains. Are you arguing that if AAA is >>>>>>> encrypted >>>>>>> then policy delivered by AAA resulting in metadata in the packet >>>>>>> must be >>>>>>> encrypted in the data packets? >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>> >>>>>>>> When responding, please keep the subject line intact and reply >>>>>>>> to all >>>>>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>>>> this >>>>>>>> introductory paragraph, however.) >>>>>>>> >>>>>>>> >>>>>>>> Please refer to >>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>> >>>>>>>> >>>>>>>> The document, along with other ballot positions, can be found here: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> DISCUSS: >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (1) I note the charter calls for this deliverable to "provide >>>>>>>> a description of... security models" The charter also >>>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>>> address the management and security implications when >>>>>>>> documenting these deliverables." My conclusion is that this >>>>>>>> deliverable needs to reflect the results of a security >>>>>>>> analysis that the wg are suppoed to have carried out but that >>>>>>>> it's currently too vague only saying that solutions need to >>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>>> resolution of that will probably resolve this.) >>>>>>>> >>>>>>>> [1] >>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>> >>>>>>>> (2) Metadata that contains information that is protected in >>>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>>> not sure myself if "passed about" ought also include within a >>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>> think you need to define confidentiality and origin >>>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>> document needs to say that those services have to be >>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> COMMENT: >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - It occurs to me that it might really be better for the WG >>>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>>> result in the eventual RFC being a much more useful document. >>>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>>> vague and won't be very useful even in the medium term. But >>>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>>> to push this out, even if that might only give the appearance >>>>>>>> of progress and not reflect real progress. >>>>>>>> >>>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>>> see the wg debated that and decided to move on. >>>>>>>> >>>>>>>> - The charter text describing this deliverable notes that >>>>>>>> "The initial scope is restricted to a single administrative >>>>>>>> domain, keeping in mind that architectural decisions made for >>>>>>>> the intra-domain case may have implications for the >>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>> single-domain elements of this architecture might impinge on >>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>> goals. >>>>>>>> >>>>>>>> - Chains will require some representation, and re-ordering >>>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>>> for fun) therefore there must be a requirement for some data >>>>>>>> integrity service and origin authentication and an >>>>>>>> authorisation decision function and therefore there must >>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>> producing entity of some kind that could be authenticated. >>>>>>>> That is an example of the missing security analysis that >>>>>>>> really is needed before this proceeds. (See my discuss point >>>>>>>> 2) >>>>>>>> >>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>> networks are slightly incongrous. In the case of WiFi when do >>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>> mobile node transmitter?) I suspect you really mean the wired >>>>>>>> bits of a mobile network so it might be better to say that. >>>>>>>> >>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>> >>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>> could say a lot more here and probably should.) >>>>>>>> >>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>>> terms need to be defined. >>>>>>>> >>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>> partially ordered? >>>>>>>> >>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>> reviews on the same telechat as this) so I'd also drop that. >>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>> reference (ideally an RFC). >>>>>>>> >>>>>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>>> the full graphs themselves. >>>>>>>> >>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>>> the example given imply that all traffic (of what kind?) that >>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>> odder to me. >>>>>>>> >>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>> architecture is to avoid such vagueness? If you mean that an >>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>> that would be the thing to do. >>>>>>>> >>>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>>> about not making security and privacy worse in general. >>>>>>>> >>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>> traffic that congestion would be an issue? If so, should you >>>>>>>> say rather that any transport that has some way of handling >>>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>>> fine. >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>> >> > From nobody Thu May 28 14:28:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974241A8A97; Thu, 28 May 2015 14:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3aaP7gWoCBU; Thu, 28 May 2015 14:28:29 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51531A8A0C; Thu, 28 May 2015 14:28:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D63A7240673; Thu, 28 May 2015 14:28:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6A58C2400FB; Thu, 28 May 2015 14:28:28 -0700 (PDT) Message-ID: <55678873.3090802@joelhalpern.com> Date: Thu, 28 May 2015 17:28:19 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> In-Reply-To: <556787A5.9050808@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 21:28:32 -0000 Enjoy the pub. No, I do not agree. I do not see that the archtiecture needs to mandate a confidentiality service to protect the meta-data. The data can only leak across the kind of boundary you describe if the service function chooses to leak it. Given taht it will have to have access to the meta data, no confidentiality mechanism will prevent that. Note that the encrypted packet produced by the service function is addressed to some end point. I am failing to see how the problem you are asking us to address could arise. Yours, Joel On 5/28/15 5:24 PM, Stephen Farrell wrote: > > Joel, > > I'm afraid you've lost me again, but since it's now time for > me to go to the pub, that's fine:-) > > For me the important thing is if meta-data is inserted at A and > then packets are encrypted by something between B and C, then > we do not want cleartext meta-data attached to the ciphertext > sent from B to C to always have to risk making the encryption > pointless. > > To me, that means that this architecture needs to call for the > existence of a confidentiality service that can be used to > protect at least the meta-data. (And it could protect more too > I guess but the details would be for the WG to figure later.) > > I think additional scenarios can similarly justify a need for > the definition of a data origin authentication service. > > If we agreed about that and could move on to how that ought be > expressed in the arch document, that'd be great. (But as I'll > be in the pub, I won't find out 'till tomorrow:-) > > Cheers, > S. > > > On 28/05/15 22:18, Joel M. Halpern wrote: >> While SMTP servers are a bad example, service chaining can be use with >> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. Both of >> those terminate connections and create new packets. As such, the two >> sides of such devices are on separate service chains. In order for the >> two sides to be on the same chain, the service function would have to >> copy the service chaining and related metadata from one side to the >> other. I can't stop them from doing so, but in most cases it would be >> misleading. >> >> What we have done is to recognize that these are generally different >> service chains. Because the packets will get different treatments. >> >> Yours, >> Joel >> >> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>> >>> Joel, >>> >>> If you are asserting that SFC cannot be used in a manner that >>> has the problem I was trying to exemplify then I have to say, >>> I'm skeptical. I also note that so-called HTTP "enrichment" >>> is one of the examples cited in the arch draft, and there's >>> not much difference between that and email from the relevant >>> perspective. >>> >>> I also hope that I've succeeded in explaining the problem as >>> I see it. If not please ask and I'll try some more to clarify. >>> (Since you did not ask that, I assume you do get what I mean, >>> but it would be helpful if you would acknowledge that so we >>> can communicate more easily.) >>> >>> Can you point me at some piece of text in some draft that >>> ensures that this problem cannot occur? If not, (which I >>> think is the case), wouldn't we be better off acknowledging >>> that it is an issue and one that needs to be tackled as >>> best we can, as indeed Alia's earlier mail seems (to me) >>> to suggest? >>> >>> Thanks, >>> S. >>> >>> >>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>> That case would not occur within a service chain. >>>> A service chain is about delivery of a packet to a series of services to >>>> which it is not addressed (generally followed by delivery to the target >>>> to which it is addressed.) >>>> An SMTP server relaying email produces separate packets. The packets >>>> from the user to the SMTP server are on one chain. The packets from >>>> that server to another are completely separate, and on a different >>>> chain. As such, those TLS SMTP packets between the servers would not >>>> have any metadata from the first transfer. >>>> >>>> Mail servers are not SFC service functions. The only time it gets close >>>> is when you are doing port 25 redirection, and then the service chain >>>> ends at the mail server. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>> >>>>> >>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>> IF A, B, and C are service function forwarders (SFF), with a TLS >>>>>> protected link for SFC, then the metadata will be protected. (Such a >>>>>> link would be a transport mechanism, which SFC does not describe or >>>>>> mandate. The SFC architecture is transport agnostic.) >>>>> >>>>> Ah, no the scenario I was thinking about is where, from >>>>> the perspective of SFC, the TLS packets are the payload >>>>> that is encapsulated. I guess A, B and C could be mail >>>>> servers with starttls only turned on between B and C >>>>> because that link is "external" (though within the same >>>>> administrative domain). If some SFC thing at A were to >>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>> data then we wouldn't want that sent in clear from B to C >>>>> because of the SFC encapsulation, right? >>>>> >>>>> S. >>>>> >>>>> >>>>>> >>>>>> If A, B, and C are service functions used by SFC, then there is no >>>>>> link >>>>>> between B and C, so it can't be protected by TLS. >>>>>> >>>>>> So I can not see what more needs to be said? >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>> >>>>>>> >>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>> I am not sure what you mean by "Metadata that contains information >>>>>>>> that >>>>>>>> is protected in the data plane". Most of what ends up in the >>>>>>>> metadata >>>>>>>> is information that is passed on other interfaces directly to >>>>>>>> relevant >>>>>>>> functions, or locally determine and locally processed. >>>>>>> >>>>>>> So what I had in mind were things like the following. >>>>>>> >>>>>>> - Packet is sent along a SFP A,B,C >>>>>>> - B to C link is via say a TLS VPN >>>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>>> and not protected by the VPN >>>>>>> - That seems bad >>>>>>> >>>>>>> S. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> The protection used for policy systems (which provide much of the >>>>>>>> information) is based on the presence of persistent connections and >>>>>>>> usage which crosses domains. Are you arguing that if AAA is >>>>>>>> encrypted >>>>>>>> then policy delivered by AAA resulting in metadata in the packet >>>>>>>> must be >>>>>>>> encrypted in the data packets? >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>> >>>>>>>>> When responding, please keep the subject line intact and reply >>>>>>>>> to all >>>>>>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>>>>> this >>>>>>>>> introductory paragraph, however.) >>>>>>>>> >>>>>>>>> >>>>>>>>> Please refer to >>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>>> >>>>>>>>> >>>>>>>>> The document, along with other ballot positions, can be found here: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> DISCUSS: >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (1) I note the charter calls for this deliverable to "provide >>>>>>>>> a description of... security models" The charter also >>>>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>>>> address the management and security implications when >>>>>>>>> documenting these deliverables." My conclusion is that this >>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>> analysis that the wg are suppoed to have carried out but that >>>>>>>>> it's currently too vague only saying that solutions need to >>>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>>> >>>>>>>>> (2) Metadata that contains information that is protected in >>>>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>>>> not sure myself if "passed about" ought also include within a >>>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>>> think you need to define confidentiality and origin >>>>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>> document needs to say that those services have to be >>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> COMMENT: >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> - It occurs to me that it might really be better for the WG >>>>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>>>> result in the eventual RFC being a much more useful document. >>>>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>>>> vague and won't be very useful even in the medium term. But >>>>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>>>> to push this out, even if that might only give the appearance >>>>>>>>> of progress and not reflect real progress. >>>>>>>>> >>>>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>> >>>>>>>>> - The charter text describing this deliverable notes that >>>>>>>>> "The initial scope is restricted to a single administrative >>>>>>>>> domain, keeping in mind that architectural decisions made for >>>>>>>>> the intra-domain case may have implications for the >>>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>> single-domain elements of this architecture might impinge on >>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>> goals. >>>>>>>>> >>>>>>>>> - Chains will require some representation, and re-ordering >>>>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>>>> for fun) therefore there must be a requirement for some data >>>>>>>>> integrity service and origin authentication and an >>>>>>>>> authorisation decision function and therefore there must >>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>> producing entity of some kind that could be authenticated. >>>>>>>>> That is an example of the missing security analysis that >>>>>>>>> really is needed before this proceeds. (See my discuss point >>>>>>>>> 2) >>>>>>>>> >>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>> networks are slightly incongrous. In the case of WiFi when do >>>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>>> mobile node transmitter?) I suspect you really mean the wired >>>>>>>>> bits of a mobile network so it might be better to say that. >>>>>>>>> >>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>> >>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>>> could say a lot more here and probably should.) >>>>>>>>> >>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>>>> terms need to be defined. >>>>>>>>> >>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>> partially ordered? >>>>>>>>> >>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>> reviews on the same telechat as this) so I'd also drop that. >>>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>>> reference (ideally an RFC). >>>>>>>>> >>>>>>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>>>> the full graphs themselves. >>>>>>>>> >>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>>>> the example given imply that all traffic (of what kind?) that >>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>>> odder to me. >>>>>>>>> >>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>>> architecture is to avoid such vagueness? If you mean that an >>>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>>> that would be the thing to do. >>>>>>>>> >>>>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>>>> about not making security and privacy worse in general. >>>>>>>>> >>>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>>> traffic that congestion would be an issue? If so, should you >>>>>>>>> say rather that any transport that has some way of handling >>>>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>>>> fine. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>> >>> >> From nobody Fri May 29 01:05:48 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02E51B2A93; Fri, 29 May 2015 01:05:46 -0700 (PDT) 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, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 PPMXKC2A8pcB; Fri, 29 May 2015 01:05:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9581B2A8C; Fri, 29 May 2015 01:05:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E0983BF05; Fri, 29 May 2015 09:05:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_Xhl5bpHOQb; Fri, 29 May 2015 09:05:35 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B75DCBF00; Fri, 29 May 2015 09:05:34 +0100 (IST) Message-ID: <55681DCC.2000907@cs.tcd.ie> Date: Fri, 29 May 2015 09:05:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> In-Reply-To: <55678873.3090802@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 08:05:47 -0000 Joel, On 28/05/15 22:28, Joel M. Halpern wrote: > Enjoy the pub. I did, of course:-) > > No, I do not agree. I do not see that the archtiecture needs to mandate > a confidentiality service to protect the meta-data. I'm sorry but that's just unhelpful. I did not speak of mandating and doing so is simply to introduce a distracting negative ambiguity. I am discussing whether the architecture should call for a protocol solution that has a well-defined way to provide confidentiality and data origin authentication. Whether and when that may, should or must be used is not a part of the architecture. It will help the discussion if you are similarly precise. It will IMO prove really hard to resolve the discussion if such ambiguities are constantly introduced. (I have seen the same in response to the secdir review where their suggestion that X be defined is met with an objection to X being forced to be used all the time.) > The data can only > leak across the kind of boundary you describe if the service function > chooses to leak it. Rubbish. If the protocol solution provides no confidentiality service for meta-data then the leakage is inevitable as there will be no possible alternative. Yes a bad actor deploying can always leak, we are here considering how to enable good actors to do the right thing. > Given taht it will have to have access to the meta > data, no confidentiality mechanism will prevent that. > > Note that the encrypted packet produced by the service function is > addressed to some end point. I am failing to see how the problem you > are asking us to address could arise. Frankly, ISTM that you are doing more than that. My impression is that you are opposed to defining a confidentiality service. I would be happy to be corrected in that. I do understand that calling for a confidentiality service does not mean that it will be easy to define a useful confidentiality service. I am quite sure that the IETF could muck that up as we have done in the past (e.g. with SIP & S/MIME) but I am equally sure we could also succeed, and I think we should try and indeed our BCPs call for us to do just that, once we recognise there is a need for such a service. And that last is, I think, entirely clear. S. > > Yours, > Joel > > On 5/28/15 5:24 PM, Stephen Farrell wrote: >> >> Joel, >> >> I'm afraid you've lost me again, but since it's now time for >> me to go to the pub, that's fine:-) >> >> For me the important thing is if meta-data is inserted at A and >> then packets are encrypted by something between B and C, then >> we do not want cleartext meta-data attached to the ciphertext >> sent from B to C to always have to risk making the encryption >> pointless. >> >> To me, that means that this architecture needs to call for the >> existence of a confidentiality service that can be used to >> protect at least the meta-data. (And it could protect more too >> I guess but the details would be for the WG to figure later.) >> >> I think additional scenarios can similarly justify a need for >> the definition of a data origin authentication service. >> >> If we agreed about that and could move on to how that ought be >> expressed in the arch document, that'd be great. (But as I'll >> be in the pub, I won't find out 'till tomorrow:-) >> >> Cheers, >> S. >> >> >> On 28/05/15 22:18, Joel M. Halpern wrote: >>> While SMTP servers are a bad example, service chaining can be use with >>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. Both of >>> those terminate connections and create new packets. As such, the two >>> sides of such devices are on separate service chains. In order for the >>> two sides to be on the same chain, the service function would have to >>> copy the service chaining and related metadata from one side to the >>> other. I can't stop them from doing so, but in most cases it would be >>> misleading. >>> >>> What we have done is to recognize that these are generally different >>> service chains. Because the packets will get different treatments. >>> >>> Yours, >>> Joel >>> >>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>> >>>> Joel, >>>> >>>> If you are asserting that SFC cannot be used in a manner that >>>> has the problem I was trying to exemplify then I have to say, >>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>> is one of the examples cited in the arch draft, and there's >>>> not much difference between that and email from the relevant >>>> perspective. >>>> >>>> I also hope that I've succeeded in explaining the problem as >>>> I see it. If not please ask and I'll try some more to clarify. >>>> (Since you did not ask that, I assume you do get what I mean, >>>> but it would be helpful if you would acknowledge that so we >>>> can communicate more easily.) >>>> >>>> Can you point me at some piece of text in some draft that >>>> ensures that this problem cannot occur? If not, (which I >>>> think is the case), wouldn't we be better off acknowledging >>>> that it is an issue and one that needs to be tackled as >>>> best we can, as indeed Alia's earlier mail seems (to me) >>>> to suggest? >>>> >>>> Thanks, >>>> S. >>>> >>>> >>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>> That case would not occur within a service chain. >>>>> A service chain is about delivery of a packet to a series of >>>>> services to >>>>> which it is not addressed (generally followed by delivery to the >>>>> target >>>>> to which it is addressed.) >>>>> An SMTP server relaying email produces separate packets. The packets >>>>> from the user to the SMTP server are on one chain. The packets from >>>>> that server to another are completely separate, and on a different >>>>> chain. As such, those TLS SMTP packets between the servers would not >>>>> have any metadata from the first transfer. >>>>> >>>>> Mail servers are not SFC service functions. The only time it gets >>>>> close >>>>> is when you are doing port 25 redirection, and then the service chain >>>>> ends at the mail server. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>> >>>>>> >>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>> IF A, B, and C are service function forwarders (SFF), with a TLS >>>>>>> protected link for SFC, then the metadata will be protected. >>>>>>> (Such a >>>>>>> link would be a transport mechanism, which SFC does not describe or >>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>> >>>>>> Ah, no the scenario I was thinking about is where, from >>>>>> the perspective of SFC, the TLS packets are the payload >>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>> servers with starttls only turned on between B and C >>>>>> because that link is "external" (though within the same >>>>>> administrative domain). If some SFC thing at A were to >>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>> data then we wouldn't want that sent in clear from B to C >>>>>> because of the SFC encapsulation, right? >>>>>> >>>>>> S. >>>>>> >>>>>> >>>>>>> >>>>>>> If A, B, and C are service functions used by SFC, then there is no >>>>>>> link >>>>>>> between B and C, so it can't be protected by TLS. >>>>>>> >>>>>>> So I can not see what more needs to be said? >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>> I am not sure what you mean by "Metadata that contains information >>>>>>>>> that >>>>>>>>> is protected in the data plane". Most of what ends up in the >>>>>>>>> metadata >>>>>>>>> is information that is passed on other interfaces directly to >>>>>>>>> relevant >>>>>>>>> functions, or locally determine and locally processed. >>>>>>>> >>>>>>>> So what I had in mind were things like the following. >>>>>>>> >>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>> - B to C link is via say a TLS VPN >>>>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>>>> and not protected by the VPN >>>>>>>> - That seems bad >>>>>>>> >>>>>>>> S. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> The protection used for policy systems (which provide much of the >>>>>>>>> information) is based on the presence of persistent connections >>>>>>>>> and >>>>>>>>> usage which crosses domains. Are you arguing that if AAA is >>>>>>>>> encrypted >>>>>>>>> then policy delivered by AAA resulting in metadata in the packet >>>>>>>>> must be >>>>>>>>> encrypted in the data packets? >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>> >>>>>>>>>> When responding, please keep the subject line intact and reply >>>>>>>>>> to all >>>>>>>>>> email addresses included in the To and CC lines. (Feel free to >>>>>>>>>> cut >>>>>>>>>> this >>>>>>>>>> introductory paragraph, however.) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please refer to >>>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The document, along with other ballot positions, can be found >>>>>>>>>> here: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> DISCUSS: >>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (1) I note the charter calls for this deliverable to "provide >>>>>>>>>> a description of... security models" The charter also >>>>>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>>>>> address the management and security implications when >>>>>>>>>> documenting these deliverables." My conclusion is that this >>>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>>> analysis that the wg are suppoed to have carried out but that >>>>>>>>>> it's currently too vague only saying that solutions need to >>>>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (2) Metadata that contains information that is protected in >>>>>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>>>>> not sure myself if "passed about" ought also include within a >>>>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>>> document needs to say that those services have to be >>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> COMMENT: >>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - It occurs to me that it might really be better for the WG >>>>>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>>>>> result in the eventual RFC being a much more useful document. >>>>>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>>>>> vague and won't be very useful even in the medium term. But >>>>>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>>>>> to push this out, even if that might only give the appearance >>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>> >>>>>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>> >>>>>>>>>> - The charter text describing this deliverable notes that >>>>>>>>>> "The initial scope is restricted to a single administrative >>>>>>>>>> domain, keeping in mind that architectural decisions made for >>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>>> single-domain elements of this architecture might impinge on >>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>>> goals. >>>>>>>>>> >>>>>>>>>> - Chains will require some representation, and re-ordering >>>>>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>>>>> for fun) therefore there must be a requirement for some data >>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>> authorisation decision function and therefore there must >>>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>>> producing entity of some kind that could be authenticated. >>>>>>>>>> That is an example of the missing security analysis that >>>>>>>>>> really is needed before this proceeds. (See my discuss point >>>>>>>>>> 2) >>>>>>>>>> >>>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>>> networks are slightly incongrous. In the case of WiFi when do >>>>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>>>> mobile node transmitter?) I suspect you really mean the wired >>>>>>>>>> bits of a mobile network so it might be better to say that. >>>>>>>>>> >>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>> >>>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>> >>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>>>>> terms need to be defined. >>>>>>>>>> >>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>>> partially ordered? >>>>>>>>>> >>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>>> reviews on the same telechat as this) so I'd also drop that. >>>>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>>>> reference (ideally an RFC). >>>>>>>>>> >>>>>>>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>>>>> the full graphs themselves. >>>>>>>>>> >>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>>>>> the example given imply that all traffic (of what kind?) that >>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>>>> odder to me. >>>>>>>>>> >>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>>>> architecture is to avoid such vagueness? If you mean that an >>>>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>>>> that would be the thing to do. >>>>>>>>>> >>>>>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>>>>> about not making security and privacy worse in general. >>>>>>>>>> >>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>>>> traffic that congestion would be an issue? If so, should you >>>>>>>>>> say rather that any transport that has some way of handling >>>>>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>>>>> fine. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >>> > From nobody Fri May 29 07:23:40 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630551A90BB; Fri, 29 May 2015 07:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 tMrPdeAJh5PL; Fri, 29 May 2015 07:23:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8185F1AC3AD; Fri, 29 May 2015 07:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14283; q=dns/txt; s=iport; t=1432909213; x=1434118813; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=8+i6bRhWDkGZofnUa25JfeTpiG4Cm7NlnwZYqwqIWbY=; b=F2XscHoiodntMafSNN2soIoQw7zcGh+YbT6LsQJVmmPTEF031LIziZ9X aIkIGhB8VhAY1KAfJIRwlCXhJtTDvYNvBR+mCVAyQsZ63PJ+nM+VNDB39 DNGZ+N2fkO65G5vbyTguV02qzuRUk3t6SstBxxHiq24hb9vWllrua+t5P w=; X-IronPort-AV: E=Sophos;i="5.13,517,1427760000"; d="scan'208,217";a="497295299" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 29 May 2015 14:20:10 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4TEKARY024300; Fri, 29 May 2015 14:20:10 GMT Message-ID: <5568759A.4030104@cisco.com> Date: Fri, 29 May 2015 16:20:10 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <20150528144454.10612.14109.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080906020406000504040207" Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Benoit Claise's No Objection on draft-ietf-sfc-architecture-08: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 14:23:34 -0000 This is a multi-part message in MIME format. --------------080906020406000504040207 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Carlos for the detailed answer. I remove all points we agree with. See in line. > Hi Benoit, > > Many thanks again for your review — let me also reply to your COMMENTs > point-by-point below, to make sure we are on the same page. > > >>> >>> >>> - Service Function Path definition: I'm confused. you don't explain what >>> it is, but only explain why you need it. > > The definition of SFP took quite significant crafting and wording, and > WG cycles. It is correct, yet a bit complex. I didn't assert the definition was not correct. I wrote "I'm confused", because, even after reading it multiple times, I can't make the link between the different concepts: SFP, SFC, RSP. > > >>> Later on, I see "As an example of such an intermediate specificity, >>> there >>> may be two >>> SFPs associated with a given SFC". I'm confused. >>> Not too clear on how the SFP and RSP relate to each others. >>> Is the Service Function Path the ordered list of SFs, while the RSP is >>> the ordered list of SFFs? > > The SFC is an ordered set of abstract functions — e.g., “a firewallâ€. > An SFP applies (policy, service function, etc) constrains as e.g., > “this firewallâ€, or “this firewall via this SFF …â€; as detailed in > Section 2.3, SFPs do not have a requirement of full specificity. SFPs > can have varying degrees of specificity (from fully specified SFFs and > SFs to reach that SF and there’s degree of freedom over which SFFs to > use). Lastly, an RSP is the fully specified set of SFFs and SFs > actually visited. In other words, from less specified to fully > specified: SFC -> SFP -> RSP. Ah, now that makes sense (at least to me) With that in mind, I reviewed the definitions and section 2.3, and here are my conclusions. 1. I found the Service Function Path definition in the RSP definition: "The Service Function Path is a constrained specification of where packets assigned to a certain service function path must go. While it may be so constrained as to identify the exact locations, it can also be less specific. These sentences should be the first sentences of the Service Function Path definition. 2. This example below must be mentioned in the draft The SFC is an ordered set of abstract functions — e.g., “a firewallâ€. An SFP applies (policy, service function, etc) constrains as e.g., “this firewallâ€, or “this firewall via this SFF …â€; as detailed in Section 2.3, SFPs do not have a requirement of full specificity. SFPs can have varying degrees of specificity (from fully specified SFFs and SFs to reach that SF and there’s degree of freedom over which SFFs to use). Lastly, an RSP is the fully specified set of SFFs and SFs actually visited. In other words, from less specified to fully specified: SFC -> SFP -> RSP. Potentially in Section 2.3. If yes, section 2.3 should be called "Service Function Paths and RSP" Alternatively in a section 2.4 > > >>> >>> - >>> "Traffic from SFs eventually returns to the same SFF, which is >>> responsible for injecting traffic back onto the network. >>> >>> Am I correct that it only applies in case of a SFC proxy? > > Please note also that SFFs and SFs are architectural functional > blocks, and an IPS might include both functions. I completely missed that from the draft. Where is it explained or how have you improved the draft? I had in mind this use case : SFF = switch, SF = attached appliance. > >>> Related question, along the same lines: >>> >>> 1. SFP forwarding : Traffic arrives at an SFF from the network. >>> The >>> SFF determines the appropriate SF the traffic should be forwarded >>> to via information contained in the SFC encapsulation. Post-SF, >>> the traffic is returned to the SFF, and, if needed, is forwarded >>> to another SF associated with that SFF. If there is another non- >>> local (i.e., different SFF) hop in the SFP, the SFF further >>> encapsulates the traffic in the appropriate network transport >>> protocol and delivers it to the network for delivery to the next >>> SFF along the path. >>> >>> Returned to the initial SFF, or to the next SFF in the RSP? >>> I guess the next SFF in the chain (again, unless we speak about a proxy) > > Not about proxy. Traffic returns from the SF to the SFF that sent it > to that SF. From that SFF, it can go to another SF or to another SFF > -> SF. > > To exemplify (what I believe might be the confusion), if a classifier > sends traffic to a firewall, traffic does not return to the > classifier. After the firewall SF is applied, it returns to the > functional SFF. Understood now. I'll look at the diff. If you have them now, please forward. > > Thanks and regards, Benoit --------------080906020406000504040207 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks Carlos for the detailed answer.
I remove all points we agree with.
See in line.
Hi Benoit,

Many thanks again for your review — let me also reply to your COMMENTs point-by-point below, to make sure we are on the same page.




- Service Function Path definition: I'm confused. you don't explain what
it is, but only explain why you need it.

The definition of SFP took quite significant crafting and wording, and WG cycles. It is correct, yet a bit complex.
I didn't assert the definition was not correct. I wrote "I'm confused", because, even after reading it multiple times, I can't make the link between the different concepts: SFP, SFC, RSP.


Later on, I see "As an example of such an intermediate specificity, there
may be two
SFPs associated with a given SFC". I'm confused.
Not too clear on how the SFP and RSP relate to each others.
Is the Service Function Path the ordered list of SFs, while the RSP is
the ordered list of SFFs?

The SFC is an ordered set of abstract functions — e.g., “a firewallâ€. An SFP applies (policy, service function, etc) constrains as e.g., “this firewallâ€, or “this firewall via this SFF …â€; as detailed in Section 2.3, SFPs do not have a requirement of full specificity. SFPs can have varying degrees of specificity (from fully specified SFFs and SFs to reach that SF and there’s degree of freedom over which SFFs to use). Lastly, an RSP is the fully specified set of SFFs and SFs actually visited. In other words, from less specified to fully specified: SFC -> SFP -> RSP.
Ah, now that makes sense (at least to me)
With that in mind, I reviewed the definitions and section 2.3, and here are my conclusions.

1. I found the Service Function Path definition in the RSP definition:
	"The Service Function Path is a
        constrained specification of where packets assigned to a certain
        service function path must go.  While it may be so constrained
        as to identify the exact locations, it can also be less
        specific.
These sentences should be the first sentences of the Service Function Path definition.

2. This example below must be mentioned in the draft
The SFC is an ordered set of abstract functions — e.g., “a firewallâ€. An SFP applies (policy, service function, etc) constrains as e.g., “this firewallâ€, or “this firewall via this SFF …â€; as detailed in Section 2.3, SFPs do not have a requirement of full specificity. SFPs can have varying degrees of specificity (from fully specified SFFs and SFs to reach that SF and there’s degree of freedom over which SFFs to use). Lastly, an RSP is the fully specified set of SFFs and SFs actually visited. In other words, from less specified to fully specified: SFC -> SFP -> RSP.
Potentially in Section 2.3. If yes, section 2.3 should be called "Service Function Paths and RSP"
Alternatively in a section 2.4




-
"Traffic from SFs eventually returns to the same SFF, which is
responsible for injecting traffic back onto the network.

Am I correct that it only applies in case of a SFC proxy?

Please note also that SFFs and SFs are architectural functional blocks, and an IPS might include both functions.
I completely missed that from the draft. Where is it explained or how have you improved the draft?
I had in mind this use case : SFF = switch, SF = attached appliance.

Related question, along the same lines:

     1.  SFP forwarding : Traffic arrives at an SFF from the network.
The
     SFF determines the appropriate SF the traffic should be forwarded
     to via information contained in the SFC encapsulation.  Post-SF,
     the traffic is returned to the SFF, and, if needed, is forwarded
     to another SF associated with that SFF.  If there is another non-
     local (i.e., different SFF) hop in the SFP, the SFF further
     encapsulates the traffic in the appropriate network transport
     protocol and delivers it to the network for delivery to the next
     SFF along the path.

Returned to the initial SFF, or to the next SFF in the RSP?
I guess the next SFF in the chain (again, unless we speak about a proxy)

Not about proxy. Traffic returns from the SF to the SFF that sent it to that SF. From that SFF, it can go to another SF or to another SFF -> SF.

To exemplify (what I believe might be the confusion), if a classifier sends traffic to a firewall, traffic does not return to the classifier. After the firewall SF is applied, it returns to the functional SFF.
Understood now. I'll look at the diff. If you have them now, please forward.


Thanks and regards, Benoit
--------------080906020406000504040207-- From nobody Fri May 29 07:29:00 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3751A9081; Fri, 29 May 2015 07:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4KEWGdBg9H7; Fri, 29 May 2015 07:28:56 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCA01A9087; Fri, 29 May 2015 07:28:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EBFDF2410FB; Fri, 29 May 2015 07:28:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id B9712240840; Fri, 29 May 2015 07:28:54 -0700 (PDT) Message-ID: <55687798.8050804@joelhalpern.com> Date: Fri, 29 May 2015 10:28:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> <55681DCC.2000907@cs.tcd.ie> In-Reply-To: <55681DCC.2000907@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 14:28:59 -0000 Would you consider the following sentence pair that Carlos and I have been debating to be helpful: “some protocols may optionally include confidentiality provisions for metadata and service function path identity, which may be used in some deployments. The architecture does not mandate such function.“ ? Yours, Joel On 5/29/15 4:05 AM, Stephen Farrell wrote: > > Joel, > > On 28/05/15 22:28, Joel M. Halpern wrote: >> Enjoy the pub. > > I did, of course:-) > >> >> No, I do not agree. I do not see that the archtiecture needs to mandate >> a confidentiality service to protect the meta-data. > > I'm sorry but that's just unhelpful. I did not speak of mandating > and doing so is simply to introduce a distracting negative ambiguity. > > I am discussing whether the architecture should call for a protocol > solution that has a well-defined way to provide confidentiality and > data origin authentication. Whether and when that may, should or > must be used is not a part of the architecture. > > It will help the discussion if you are similarly precise. It will > IMO prove really hard to resolve the discussion if such ambiguities > are constantly introduced. (I have seen the same in response to the > secdir review where their suggestion that X be defined is met with > an objection to X being forced to be used all the time.) > >> The data can only >> leak across the kind of boundary you describe if the service function >> chooses to leak it. > > Rubbish. If the protocol solution provides no confidentiality > service for meta-data then the leakage is inevitable as there > will be no possible alternative. > > Yes a bad actor deploying can always leak, we are here considering > how to enable good actors to do the right thing. > >> Given taht it will have to have access to the meta >> data, no confidentiality mechanism will prevent that. >> >> Note that the encrypted packet produced by the service function is >> addressed to some end point. I am failing to see how the problem you >> are asking us to address could arise. > > Frankly, ISTM that you are doing more than that. My impression is > that you are opposed to defining a confidentiality service. I would > be happy to be corrected in that. > > I do understand that calling for a confidentiality service does > not mean that it will be easy to define a useful confidentiality > service. I am quite sure that the IETF could muck that up as we > have done in the past (e.g. with SIP & S/MIME) but I am equally > sure we could also succeed, and I think we should try and indeed > our BCPs call for us to do just that, once we recognise there is > a need for such a service. And that last is, I think, entirely > clear. > > S. > > >> >> Yours, >> Joel >> >> On 5/28/15 5:24 PM, Stephen Farrell wrote: >>> >>> Joel, >>> >>> I'm afraid you've lost me again, but since it's now time for >>> me to go to the pub, that's fine:-) >>> >>> For me the important thing is if meta-data is inserted at A and >>> then packets are encrypted by something between B and C, then >>> we do not want cleartext meta-data attached to the ciphertext >>> sent from B to C to always have to risk making the encryption >>> pointless. >>> >>> To me, that means that this architecture needs to call for the >>> existence of a confidentiality service that can be used to >>> protect at least the meta-data. (And it could protect more too >>> I guess but the details would be for the WG to figure later.) >>> >>> I think additional scenarios can similarly justify a need for >>> the definition of a data origin authentication service. >>> >>> If we agreed about that and could move on to how that ought be >>> expressed in the arch document, that'd be great. (But as I'll >>> be in the pub, I won't find out 'till tomorrow:-) >>> >>> Cheers, >>> S. >>> >>> >>> On 28/05/15 22:18, Joel M. Halpern wrote: >>>> While SMTP servers are a bad example, service chaining can be use with >>>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. Both of >>>> those terminate connections and create new packets. As such, the two >>>> sides of such devices are on separate service chains. In order for the >>>> two sides to be on the same chain, the service function would have to >>>> copy the service chaining and related metadata from one side to the >>>> other. I can't stop them from doing so, but in most cases it would be >>>> misleading. >>>> >>>> What we have done is to recognize that these are generally different >>>> service chains. Because the packets will get different treatments. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>>> >>>>> Joel, >>>>> >>>>> If you are asserting that SFC cannot be used in a manner that >>>>> has the problem I was trying to exemplify then I have to say, >>>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>>> is one of the examples cited in the arch draft, and there's >>>>> not much difference between that and email from the relevant >>>>> perspective. >>>>> >>>>> I also hope that I've succeeded in explaining the problem as >>>>> I see it. If not please ask and I'll try some more to clarify. >>>>> (Since you did not ask that, I assume you do get what I mean, >>>>> but it would be helpful if you would acknowledge that so we >>>>> can communicate more easily.) >>>>> >>>>> Can you point me at some piece of text in some draft that >>>>> ensures that this problem cannot occur? If not, (which I >>>>> think is the case), wouldn't we be better off acknowledging >>>>> that it is an issue and one that needs to be tackled as >>>>> best we can, as indeed Alia's earlier mail seems (to me) >>>>> to suggest? >>>>> >>>>> Thanks, >>>>> S. >>>>> >>>>> >>>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>>> That case would not occur within a service chain. >>>>>> A service chain is about delivery of a packet to a series of >>>>>> services to >>>>>> which it is not addressed (generally followed by delivery to the >>>>>> target >>>>>> to which it is addressed.) >>>>>> An SMTP server relaying email produces separate packets. The packets >>>>>> from the user to the SMTP server are on one chain. The packets from >>>>>> that server to another are completely separate, and on a different >>>>>> chain. As such, those TLS SMTP packets between the servers would not >>>>>> have any metadata from the first transfer. >>>>>> >>>>>> Mail servers are not SFC service functions. The only time it gets >>>>>> close >>>>>> is when you are doing port 25 redirection, and then the service chain >>>>>> ends at the mail server. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>>> >>>>>>> >>>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>>> IF A, B, and C are service function forwarders (SFF), with a TLS >>>>>>>> protected link for SFC, then the metadata will be protected. >>>>>>>> (Such a >>>>>>>> link would be a transport mechanism, which SFC does not describe or >>>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>>> >>>>>>> Ah, no the scenario I was thinking about is where, from >>>>>>> the perspective of SFC, the TLS packets are the payload >>>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>>> servers with starttls only turned on between B and C >>>>>>> because that link is "external" (though within the same >>>>>>> administrative domain). If some SFC thing at A were to >>>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>>> data then we wouldn't want that sent in clear from B to C >>>>>>> because of the SFC encapsulation, right? >>>>>>> >>>>>>> S. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> If A, B, and C are service functions used by SFC, then there is no >>>>>>>> link >>>>>>>> between B and C, so it can't be protected by TLS. >>>>>>>> >>>>>>>> So I can not see what more needs to be said? >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>>> I am not sure what you mean by "Metadata that contains information >>>>>>>>>> that >>>>>>>>>> is protected in the data plane". Most of what ends up in the >>>>>>>>>> metadata >>>>>>>>>> is information that is passed on other interfaces directly to >>>>>>>>>> relevant >>>>>>>>>> functions, or locally determine and locally processed. >>>>>>>>> >>>>>>>>> So what I had in mind were things like the following. >>>>>>>>> >>>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>>> - B to C link is via say a TLS VPN >>>>>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>>>>> and not protected by the VPN >>>>>>>>> - That seems bad >>>>>>>>> >>>>>>>>> S. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The protection used for policy systems (which provide much of the >>>>>>>>>> information) is based on the presence of persistent connections >>>>>>>>>> and >>>>>>>>>> usage which crosses domains. Are you arguing that if AAA is >>>>>>>>>> encrypted >>>>>>>>>> then policy delivered by AAA resulting in metadata in the packet >>>>>>>>>> must be >>>>>>>>>> encrypted in the data packets? >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>>> >>>>>>>>>>> When responding, please keep the subject line intact and reply >>>>>>>>>>> to all >>>>>>>>>>> email addresses included in the To and CC lines. (Feel free to >>>>>>>>>>> cut >>>>>>>>>>> this >>>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please refer to >>>>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The document, along with other ballot positions, can be found >>>>>>>>>>> here: >>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> DISCUSS: >>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (1) I note the charter calls for this deliverable to "provide >>>>>>>>>>> a description of... security models" The charter also >>>>>>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>>>>>> address the management and security implications when >>>>>>>>>>> documenting these deliverables." My conclusion is that this >>>>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>>>> analysis that the wg are suppoed to have carried out but that >>>>>>>>>>> it's currently too vague only saying that solutions need to >>>>>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (2) Metadata that contains information that is protected in >>>>>>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>>>>>> not sure myself if "passed about" ought also include within a >>>>>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>>>> document needs to say that those services have to be >>>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> COMMENT: >>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - It occurs to me that it might really be better for the WG >>>>>>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>>>>>> result in the eventual RFC being a much more useful document. >>>>>>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>>>>>> vague and won't be very useful even in the medium term. But >>>>>>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>>>>>> to push this out, even if that might only give the appearance >>>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>>> >>>>>>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>>> >>>>>>>>>>> - The charter text describing this deliverable notes that >>>>>>>>>>> "The initial scope is restricted to a single administrative >>>>>>>>>>> domain, keeping in mind that architectural decisions made for >>>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>>>> single-domain elements of this architecture might impinge on >>>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>>>> goals. >>>>>>>>>>> >>>>>>>>>>> - Chains will require some representation, and re-ordering >>>>>>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>>>>>> for fun) therefore there must be a requirement for some data >>>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>>> authorisation decision function and therefore there must >>>>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>>>> producing entity of some kind that could be authenticated. >>>>>>>>>>> That is an example of the missing security analysis that >>>>>>>>>>> really is needed before this proceeds. (See my discuss point >>>>>>>>>>> 2) >>>>>>>>>>> >>>>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>>>> networks are slightly incongrous. In the case of WiFi when do >>>>>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>>>>> mobile node transmitter?) I suspect you really mean the wired >>>>>>>>>>> bits of a mobile network so it might be better to say that. >>>>>>>>>>> >>>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>>> >>>>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>>> >>>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>>>>>> terms need to be defined. >>>>>>>>>>> >>>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>>>> partially ordered? >>>>>>>>>>> >>>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>>>> reviews on the same telechat as this) so I'd also drop that. >>>>>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>>>>> reference (ideally an RFC). >>>>>>>>>>> >>>>>>>>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>>>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>>>>>> the full graphs themselves. >>>>>>>>>>> >>>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>>>>>> the example given imply that all traffic (of what kind?) that >>>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>>>>> odder to me. >>>>>>>>>>> >>>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>>>>> architecture is to avoid such vagueness? If you mean that an >>>>>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>>>>> that would be the thing to do. >>>>>>>>>>> >>>>>>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>>>>>> about not making security and privacy worse in general. >>>>>>>>>>> >>>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>>>>> traffic that congestion would be an issue? If so, should you >>>>>>>>>>> say rather that any transport that has some way of handling >>>>>>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>>>>>> fine. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> From nobody Fri May 29 07:34:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47761A90BB; Fri, 29 May 2015 07:34:37 -0700 (PDT) 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, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 HeAyIrT5TECj; Fri, 29 May 2015 07:34:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5EBE1A909F; Fri, 29 May 2015 07:34:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 49D13BF05; Fri, 29 May 2015 15:34:32 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igo-ry53bAh5; Fri, 29 May 2015 15:34:32 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1FD03BF03; Fri, 29 May 2015 15:34:32 +0100 (IST) Message-ID: <556878F7.6030506@cs.tcd.ie> Date: Fri, 29 May 2015 15:34:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> <55681DCC.2000907@cs.tcd.ie> <55687798.8050804@joelhalpern.com> In-Reply-To: <55687798.8050804@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 14:34:38 -0000 On 29/05/15 15:28, Joel M. Halpern wrote: > Would you consider the following sentence pair that Carlos and I have > been debating to be helpful: > > “some protocols may optionally include confidentiality provisions for > metadata and service function path identity, which may be used in some > deployments. The architecture does not mandate such function.“ Not really no. I think that says nothing at all while at the same time having the ambiguity around the term "mandate" that I pointed out below. I have no clue why the SFC architecture cannot simply say that a confidentiality service needs to be defined. S. > > ? > Yours, > Joel > > On 5/29/15 4:05 AM, Stephen Farrell wrote: >> >> Joel, >> >> On 28/05/15 22:28, Joel M. Halpern wrote: >>> Enjoy the pub. >> >> I did, of course:-) >> >>> >>> No, I do not agree. I do not see that the archtiecture needs to mandate >>> a confidentiality service to protect the meta-data. >> >> I'm sorry but that's just unhelpful. I did not speak of mandating >> and doing so is simply to introduce a distracting negative ambiguity. >> >> I am discussing whether the architecture should call for a protocol >> solution that has a well-defined way to provide confidentiality and >> data origin authentication. Whether and when that may, should or >> must be used is not a part of the architecture. >> >> It will help the discussion if you are similarly precise. It will >> IMO prove really hard to resolve the discussion if such ambiguities >> are constantly introduced. (I have seen the same in response to the >> secdir review where their suggestion that X be defined is met with >> an objection to X being forced to be used all the time.) >> >>> The data can only >>> leak across the kind of boundary you describe if the service function >>> chooses to leak it. >> >> Rubbish. If the protocol solution provides no confidentiality >> service for meta-data then the leakage is inevitable as there >> will be no possible alternative. >> >> Yes a bad actor deploying can always leak, we are here considering >> how to enable good actors to do the right thing. >> >>> Given taht it will have to have access to the meta >>> data, no confidentiality mechanism will prevent that. >>> >>> Note that the encrypted packet produced by the service function is >>> addressed to some end point. I am failing to see how the problem you >>> are asking us to address could arise. >> >> Frankly, ISTM that you are doing more than that. My impression is >> that you are opposed to defining a confidentiality service. I would >> be happy to be corrected in that. >> >> I do understand that calling for a confidentiality service does >> not mean that it will be easy to define a useful confidentiality >> service. I am quite sure that the IETF could muck that up as we >> have done in the past (e.g. with SIP & S/MIME) but I am equally >> sure we could also succeed, and I think we should try and indeed >> our BCPs call for us to do just that, once we recognise there is >> a need for such a service. And that last is, I think, entirely >> clear. >> >> S. >> >> >>> >>> Yours, >>> Joel >>> >>> On 5/28/15 5:24 PM, Stephen Farrell wrote: >>>> >>>> Joel, >>>> >>>> I'm afraid you've lost me again, but since it's now time for >>>> me to go to the pub, that's fine:-) >>>> >>>> For me the important thing is if meta-data is inserted at A and >>>> then packets are encrypted by something between B and C, then >>>> we do not want cleartext meta-data attached to the ciphertext >>>> sent from B to C to always have to risk making the encryption >>>> pointless. >>>> >>>> To me, that means that this architecture needs to call for the >>>> existence of a confidentiality service that can be used to >>>> protect at least the meta-data. (And it could protect more too >>>> I guess but the details would be for the WG to figure later.) >>>> >>>> I think additional scenarios can similarly justify a need for >>>> the definition of a data origin authentication service. >>>> >>>> If we agreed about that and could move on to how that ought be >>>> expressed in the arch document, that'd be great. (But as I'll >>>> be in the pub, I won't find out 'till tomorrow:-) >>>> >>>> Cheers, >>>> S. >>>> >>>> >>>> On 28/05/15 22:18, Joel M. Halpern wrote: >>>>> While SMTP servers are a bad example, service chaining can be use with >>>>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. Both of >>>>> those terminate connections and create new packets. As such, the two >>>>> sides of such devices are on separate service chains. In order for >>>>> the >>>>> two sides to be on the same chain, the service function would have to >>>>> copy the service chaining and related metadata from one side to the >>>>> other. I can't stop them from doing so, but in most cases it would be >>>>> misleading. >>>>> >>>>> What we have done is to recognize that these are generally different >>>>> service chains. Because the packets will get different treatments. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>>>> >>>>>> Joel, >>>>>> >>>>>> If you are asserting that SFC cannot be used in a manner that >>>>>> has the problem I was trying to exemplify then I have to say, >>>>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>>>> is one of the examples cited in the arch draft, and there's >>>>>> not much difference between that and email from the relevant >>>>>> perspective. >>>>>> >>>>>> I also hope that I've succeeded in explaining the problem as >>>>>> I see it. If not please ask and I'll try some more to clarify. >>>>>> (Since you did not ask that, I assume you do get what I mean, >>>>>> but it would be helpful if you would acknowledge that so we >>>>>> can communicate more easily.) >>>>>> >>>>>> Can you point me at some piece of text in some draft that >>>>>> ensures that this problem cannot occur? If not, (which I >>>>>> think is the case), wouldn't we be better off acknowledging >>>>>> that it is an issue and one that needs to be tackled as >>>>>> best we can, as indeed Alia's earlier mail seems (to me) >>>>>> to suggest? >>>>>> >>>>>> Thanks, >>>>>> S. >>>>>> >>>>>> >>>>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>>>> That case would not occur within a service chain. >>>>>>> A service chain is about delivery of a packet to a series of >>>>>>> services to >>>>>>> which it is not addressed (generally followed by delivery to the >>>>>>> target >>>>>>> to which it is addressed.) >>>>>>> An SMTP server relaying email produces separate packets. The >>>>>>> packets >>>>>>> from the user to the SMTP server are on one chain. The packets from >>>>>>> that server to another are completely separate, and on a different >>>>>>> chain. As such, those TLS SMTP packets between the servers would >>>>>>> not >>>>>>> have any metadata from the first transfer. >>>>>>> >>>>>>> Mail servers are not SFC service functions. The only time it gets >>>>>>> close >>>>>>> is when you are doing port 25 redirection, and then the service >>>>>>> chain >>>>>>> ends at the mail server. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>>>> IF A, B, and C are service function forwarders (SFF), with a TLS >>>>>>>>> protected link for SFC, then the metadata will be protected. >>>>>>>>> (Such a >>>>>>>>> link would be a transport mechanism, which SFC does not >>>>>>>>> describe or >>>>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>>>> >>>>>>>> Ah, no the scenario I was thinking about is where, from >>>>>>>> the perspective of SFC, the TLS packets are the payload >>>>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>>>> servers with starttls only turned on between B and C >>>>>>>> because that link is "external" (though within the same >>>>>>>> administrative domain). If some SFC thing at A were to >>>>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>>>> data then we wouldn't want that sent in clear from B to C >>>>>>>> because of the SFC encapsulation, right? >>>>>>>> >>>>>>>> S. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> If A, B, and C are service functions used by SFC, then there is no >>>>>>>>> link >>>>>>>>> between B and C, so it can't be protected by TLS. >>>>>>>>> >>>>>>>>> So I can not see what more needs to be said? >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>>>> I am not sure what you mean by "Metadata that contains >>>>>>>>>>> information >>>>>>>>>>> that >>>>>>>>>>> is protected in the data plane". Most of what ends up in the >>>>>>>>>>> metadata >>>>>>>>>>> is information that is passed on other interfaces directly to >>>>>>>>>>> relevant >>>>>>>>>>> functions, or locally determine and locally processed. >>>>>>>>>> >>>>>>>>>> So what I had in mind were things like the following. >>>>>>>>>> >>>>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>>>> - B to C link is via say a TLS VPN >>>>>>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>>>>>> and not protected by the VPN >>>>>>>>>> - That seems bad >>>>>>>>>> >>>>>>>>>> S. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The protection used for policy systems (which provide much of >>>>>>>>>>> the >>>>>>>>>>> information) is based on the presence of persistent connections >>>>>>>>>>> and >>>>>>>>>>> usage which crosses domains. Are you arguing that if AAA is >>>>>>>>>>> encrypted >>>>>>>>>>> then policy delivered by AAA resulting in metadata in the packet >>>>>>>>>>> must be >>>>>>>>>>> encrypted in the data packets? >>>>>>>>>>> >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>> >>>>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>>>> >>>>>>>>>>>> When responding, please keep the subject line intact and reply >>>>>>>>>>>> to all >>>>>>>>>>>> email addresses included in the To and CC lines. (Feel free to >>>>>>>>>>>> cut >>>>>>>>>>>> this >>>>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Please refer to >>>>>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The document, along with other ballot positions, can be found >>>>>>>>>>>> here: >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> DISCUSS: >>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (1) I note the charter calls for this deliverable to "provide >>>>>>>>>>>> a description of... security models" The charter also >>>>>>>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>>>>>>> address the management and security implications when >>>>>>>>>>>> documenting these deliverables." My conclusion is that this >>>>>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>>>>> analysis that the wg are suppoed to have carried out but that >>>>>>>>>>>> it's currently too vague only saying that solutions need to >>>>>>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (2) Metadata that contains information that is protected in >>>>>>>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>>>>>>> not sure myself if "passed about" ought also include within a >>>>>>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>>>>> document needs to say that those services have to be >>>>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> COMMENT: >>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - It occurs to me that it might really be better for the WG >>>>>>>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>>>>>>> result in the eventual RFC being a much more useful document. >>>>>>>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>>>>>>> vague and won't be very useful even in the medium term. But >>>>>>>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>>>>>>> to push this out, even if that might only give the appearance >>>>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>>>> >>>>>>>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>>>> >>>>>>>>>>>> - The charter text describing this deliverable notes that >>>>>>>>>>>> "The initial scope is restricted to a single administrative >>>>>>>>>>>> domain, keeping in mind that architectural decisions made for >>>>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>>>>> single-domain elements of this architecture might impinge on >>>>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>>>>> goals. >>>>>>>>>>>> >>>>>>>>>>>> - Chains will require some representation, and re-ordering >>>>>>>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>>>>>>> for fun) therefore there must be a requirement for some data >>>>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>>>> authorisation decision function and therefore there must >>>>>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>>>>> producing entity of some kind that could be authenticated. >>>>>>>>>>>> That is an example of the missing security analysis that >>>>>>>>>>>> really is needed before this proceeds. (See my discuss point >>>>>>>>>>>> 2) >>>>>>>>>>>> >>>>>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>>>>> networks are slightly incongrous. In the case of WiFi when do >>>>>>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>>>>>> mobile node transmitter?) I suspect you really mean the wired >>>>>>>>>>>> bits of a mobile network so it might be better to say that. >>>>>>>>>>>> >>>>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>>>> >>>>>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>>>> >>>>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>>>>>>> terms need to be defined. >>>>>>>>>>>> >>>>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>>>>> partially ordered? >>>>>>>>>>>> >>>>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>>>>> reviews on the same telechat as this) so I'd also drop that. >>>>>>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>>>>>> reference (ideally an RFC). >>>>>>>>>>>> >>>>>>>>>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>>>>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>>>>>>> the full graphs themselves. >>>>>>>>>>>> >>>>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>>>>>>> the example given imply that all traffic (of what kind?) that >>>>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>>>>>> odder to me. >>>>>>>>>>>> >>>>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>>>>>> architecture is to avoid such vagueness? If you mean that an >>>>>>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>>>>>> that would be the thing to do. >>>>>>>>>>>> >>>>>>>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>>>>>>> about not making security and privacy worse in general. >>>>>>>>>>>> >>>>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>>>>>> traffic that congestion would be an issue? If so, should you >>>>>>>>>>>> say rather that any transport that has some way of handling >>>>>>>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>>>>>>> fine. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From nobody Fri May 29 08:09:53 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68521AC44B; Fri, 29 May 2015 08:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpHXn-QONPAS; Fri, 29 May 2015 08:09:44 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69AB1AC42C; Fri, 29 May 2015 08:09:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B471124082E; Fri, 29 May 2015 08:09:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 80B0A2401BE; Fri, 29 May 2015 08:09:43 -0700 (PDT) Message-ID: <55688129.4030200@joelhalpern.com> Date: Fri, 29 May 2015 11:09:29 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> <55681DCC.2000907@cs.tcd.ie> <55687798.8050804@joelhalpern.com> <556878F7.6030506@cs.tcd.ie> In-Reply-To: <556878F7.6030506@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 15:09:48 -0000 I am not sure I like the following, but to try to move this forward, would Protocols addressing this architecture need to include definitions for how security services are provided with that solution, although implementation of such mechanisms may be optional. work for you? Yours, Joel On 5/29/15 10:34 AM, Stephen Farrell wrote: > > > On 29/05/15 15:28, Joel M. Halpern wrote: >> Would you consider the following sentence pair that Carlos and I have >> been debating to be helpful: >> >> “some protocols may optionally include confidentiality provisions for >> metadata and service function path identity, which may be used in some >> deployments. The architecture does not mandate such function.“ > > Not really no. I think that says nothing at all while at the same > time having the ambiguity around the term "mandate" that I pointed > out below. > > I have no clue why the SFC architecture cannot simply say that > a confidentiality service needs to be defined. > > S. > >> >> ? >> Yours, >> Joel >> >> On 5/29/15 4:05 AM, Stephen Farrell wrote: >>> >>> Joel, >>> >>> On 28/05/15 22:28, Joel M. Halpern wrote: >>>> Enjoy the pub. >>> >>> I did, of course:-) >>> >>>> >>>> No, I do not agree. I do not see that the archtiecture needs to mandate >>>> a confidentiality service to protect the meta-data. >>> >>> I'm sorry but that's just unhelpful. I did not speak of mandating >>> and doing so is simply to introduce a distracting negative ambiguity. >>> >>> I am discussing whether the architecture should call for a protocol >>> solution that has a well-defined way to provide confidentiality and >>> data origin authentication. Whether and when that may, should or >>> must be used is not a part of the architecture. >>> >>> It will help the discussion if you are similarly precise. It will >>> IMO prove really hard to resolve the discussion if such ambiguities >>> are constantly introduced. (I have seen the same in response to the >>> secdir review where their suggestion that X be defined is met with >>> an objection to X being forced to be used all the time.) >>> >>>> The data can only >>>> leak across the kind of boundary you describe if the service function >>>> chooses to leak it. >>> >>> Rubbish. If the protocol solution provides no confidentiality >>> service for meta-data then the leakage is inevitable as there >>> will be no possible alternative. >>> >>> Yes a bad actor deploying can always leak, we are here considering >>> how to enable good actors to do the right thing. >>> >>>> Given taht it will have to have access to the meta >>>> data, no confidentiality mechanism will prevent that. >>>> >>>> Note that the encrypted packet produced by the service function is >>>> addressed to some end point. I am failing to see how the problem you >>>> are asking us to address could arise. >>> >>> Frankly, ISTM that you are doing more than that. My impression is >>> that you are opposed to defining a confidentiality service. I would >>> be happy to be corrected in that. >>> >>> I do understand that calling for a confidentiality service does >>> not mean that it will be easy to define a useful confidentiality >>> service. I am quite sure that the IETF could muck that up as we >>> have done in the past (e.g. with SIP & S/MIME) but I am equally >>> sure we could also succeed, and I think we should try and indeed >>> our BCPs call for us to do just that, once we recognise there is >>> a need for such a service. And that last is, I think, entirely >>> clear. >>> >>> S. >>> >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/28/15 5:24 PM, Stephen Farrell wrote: >>>>> >>>>> Joel, >>>>> >>>>> I'm afraid you've lost me again, but since it's now time for >>>>> me to go to the pub, that's fine:-) >>>>> >>>>> For me the important thing is if meta-data is inserted at A and >>>>> then packets are encrypted by something between B and C, then >>>>> we do not want cleartext meta-data attached to the ciphertext >>>>> sent from B to C to always have to risk making the encryption >>>>> pointless. >>>>> >>>>> To me, that means that this architecture needs to call for the >>>>> existence of a confidentiality service that can be used to >>>>> protect at least the meta-data. (And it could protect more too >>>>> I guess but the details would be for the WG to figure later.) >>>>> >>>>> I think additional scenarios can similarly justify a need for >>>>> the definition of a data origin authentication service. >>>>> >>>>> If we agreed about that and could move on to how that ought be >>>>> expressed in the arch document, that'd be great. (But as I'll >>>>> be in the pub, I won't find out 'till tomorrow:-) >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> >>>>> On 28/05/15 22:18, Joel M. Halpern wrote: >>>>>> While SMTP servers are a bad example, service chaining can be use with >>>>>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. Both of >>>>>> those terminate connections and create new packets. As such, the two >>>>>> sides of such devices are on separate service chains. In order for >>>>>> the >>>>>> two sides to be on the same chain, the service function would have to >>>>>> copy the service chaining and related metadata from one side to the >>>>>> other. I can't stop them from doing so, but in most cases it would be >>>>>> misleading. >>>>>> >>>>>> What we have done is to recognize that these are generally different >>>>>> service chains. Because the packets will get different treatments. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>>>>> >>>>>>> Joel, >>>>>>> >>>>>>> If you are asserting that SFC cannot be used in a manner that >>>>>>> has the problem I was trying to exemplify then I have to say, >>>>>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>>>>> is one of the examples cited in the arch draft, and there's >>>>>>> not much difference between that and email from the relevant >>>>>>> perspective. >>>>>>> >>>>>>> I also hope that I've succeeded in explaining the problem as >>>>>>> I see it. If not please ask and I'll try some more to clarify. >>>>>>> (Since you did not ask that, I assume you do get what I mean, >>>>>>> but it would be helpful if you would acknowledge that so we >>>>>>> can communicate more easily.) >>>>>>> >>>>>>> Can you point me at some piece of text in some draft that >>>>>>> ensures that this problem cannot occur? If not, (which I >>>>>>> think is the case), wouldn't we be better off acknowledging >>>>>>> that it is an issue and one that needs to be tackled as >>>>>>> best we can, as indeed Alia's earlier mail seems (to me) >>>>>>> to suggest? >>>>>>> >>>>>>> Thanks, >>>>>>> S. >>>>>>> >>>>>>> >>>>>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>>>>> That case would not occur within a service chain. >>>>>>>> A service chain is about delivery of a packet to a series of >>>>>>>> services to >>>>>>>> which it is not addressed (generally followed by delivery to the >>>>>>>> target >>>>>>>> to which it is addressed.) >>>>>>>> An SMTP server relaying email produces separate packets. The >>>>>>>> packets >>>>>>>> from the user to the SMTP server are on one chain. The packets from >>>>>>>> that server to another are completely separate, and on a different >>>>>>>> chain. As such, those TLS SMTP packets between the servers would >>>>>>>> not >>>>>>>> have any metadata from the first transfer. >>>>>>>> >>>>>>>> Mail servers are not SFC service functions. The only time it gets >>>>>>>> close >>>>>>>> is when you are doing port 25 redirection, and then the service >>>>>>>> chain >>>>>>>> ends at the mail server. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>>>>> IF A, B, and C are service function forwarders (SFF), with a TLS >>>>>>>>>> protected link for SFC, then the metadata will be protected. >>>>>>>>>> (Such a >>>>>>>>>> link would be a transport mechanism, which SFC does not >>>>>>>>>> describe or >>>>>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>>>>> >>>>>>>>> Ah, no the scenario I was thinking about is where, from >>>>>>>>> the perspective of SFC, the TLS packets are the payload >>>>>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>>>>> servers with starttls only turned on between B and C >>>>>>>>> because that link is "external" (though within the same >>>>>>>>> administrative domain). If some SFC thing at A were to >>>>>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>>>>> data then we wouldn't want that sent in clear from B to C >>>>>>>>> because of the SFC encapsulation, right? >>>>>>>>> >>>>>>>>> S. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> If A, B, and C are service functions used by SFC, then there is no >>>>>>>>>> link >>>>>>>>>> between B and C, so it can't be protected by TLS. >>>>>>>>>> >>>>>>>>>> So I can not see what more needs to be said? >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>>>>> I am not sure what you mean by "Metadata that contains >>>>>>>>>>>> information >>>>>>>>>>>> that >>>>>>>>>>>> is protected in the data plane". Most of what ends up in the >>>>>>>>>>>> metadata >>>>>>>>>>>> is information that is passed on other interfaces directly to >>>>>>>>>>>> relevant >>>>>>>>>>>> functions, or locally determine and locally processed. >>>>>>>>>>> >>>>>>>>>>> So what I had in mind were things like the following. >>>>>>>>>>> >>>>>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>>>>> - B to C link is via say a TLS VPN >>>>>>>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>>>>>>> and not protected by the VPN >>>>>>>>>>> - That seems bad >>>>>>>>>>> >>>>>>>>>>> S. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The protection used for policy systems (which provide much of >>>>>>>>>>>> the >>>>>>>>>>>> information) is based on the presence of persistent connections >>>>>>>>>>>> and >>>>>>>>>>>> usage which crosses domains. Are you arguing that if AAA is >>>>>>>>>>>> encrypted >>>>>>>>>>>> then policy delivered by AAA resulting in metadata in the packet >>>>>>>>>>>> must be >>>>>>>>>>>> encrypted in the data packets? >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>>>>> >>>>>>>>>>>>> When responding, please keep the subject line intact and reply >>>>>>>>>>>>> to all >>>>>>>>>>>>> email addresses included in the To and CC lines. (Feel free to >>>>>>>>>>>>> cut >>>>>>>>>>>>> this >>>>>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Please refer to >>>>>>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The document, along with other ballot positions, can be found >>>>>>>>>>>>> here: >>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> DISCUSS: >>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (1) I note the charter calls for this deliverable to "provide >>>>>>>>>>>>> a description of... security models" The charter also >>>>>>>>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>>>>>>>> address the management and security implications when >>>>>>>>>>>>> documenting these deliverables." My conclusion is that this >>>>>>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>>>>>> analysis that the wg are suppoed to have carried out but that >>>>>>>>>>>>> it's currently too vague only saying that solutions need to >>>>>>>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (2) Metadata that contains information that is protected in >>>>>>>>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>>>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>>>>>>>> not sure myself if "passed about" ought also include within a >>>>>>>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>>>>>> document needs to say that those services have to be >>>>>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - It occurs to me that it might really be better for the WG >>>>>>>>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>>>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>>>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>>>>>>>> result in the eventual RFC being a much more useful document. >>>>>>>>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>>>>>>>> vague and won't be very useful even in the medium term. But >>>>>>>>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>>>>>>>> to push this out, even if that might only give the appearance >>>>>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>>>>> >>>>>>>>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>>>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>>>>> >>>>>>>>>>>>> - The charter text describing this deliverable notes that >>>>>>>>>>>>> "The initial scope is restricted to a single administrative >>>>>>>>>>>>> domain, keeping in mind that architectural decisions made for >>>>>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>>>>>> single-domain elements of this architecture might impinge on >>>>>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>>>>>> goals. >>>>>>>>>>>>> >>>>>>>>>>>>> - Chains will require some representation, and re-ordering >>>>>>>>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>>>>>>>> for fun) therefore there must be a requirement for some data >>>>>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>>>>> authorisation decision function and therefore there must >>>>>>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>>>>>> producing entity of some kind that could be authenticated. >>>>>>>>>>>>> That is an example of the missing security analysis that >>>>>>>>>>>>> really is needed before this proceeds. (See my discuss point >>>>>>>>>>>>> 2) >>>>>>>>>>>>> >>>>>>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>>>>>> networks are slightly incongrous. In the case of WiFi when do >>>>>>>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>>>>>>> mobile node transmitter?) I suspect you really mean the wired >>>>>>>>>>>>> bits of a mobile network so it might be better to say that. >>>>>>>>>>>>> >>>>>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>>>>> >>>>>>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>>>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>>>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>>>>> >>>>>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>>>>>>>> terms need to be defined. >>>>>>>>>>>>> >>>>>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>>>>>> partially ordered? >>>>>>>>>>>>> >>>>>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>>>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>>>>>> reviews on the same telechat as this) so I'd also drop that. >>>>>>>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>>>>>>> reference (ideally an RFC). >>>>>>>>>>>>> >>>>>>>>>>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>>>>>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>>>>>>>> the full graphs themselves. >>>>>>>>>>>>> >>>>>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>>>>>>>> the example given imply that all traffic (of what kind?) that >>>>>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>>>>>>> odder to me. >>>>>>>>>>>>> >>>>>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>>>>>>> architecture is to avoid such vagueness? If you mean that an >>>>>>>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>>>>>>> that would be the thing to do. >>>>>>>>>>>>> >>>>>>>>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>>>>>>>> about not making security and privacy worse in general. >>>>>>>>>>>>> >>>>>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>>>>>>> traffic that congestion would be an issue? If so, should you >>>>>>>>>>>>> say rather that any transport that has some way of handling >>>>>>>>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>>>>>>>> fine. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From nobody Fri May 29 08:23:08 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D45A1AC3F8; Fri, 29 May 2015 08:23:03 -0700 (PDT) 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, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 rzwxCxNhnJPE; Fri, 29 May 2015 08:22:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244171AC424; Fri, 29 May 2015 08:22:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DFF5CBF12; Fri, 29 May 2015 16:22:56 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWt4zV5ysZG4; Fri, 29 May 2015 16:22:56 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A5E2DBF11; Fri, 29 May 2015 16:22:56 +0100 (IST) Message-ID: <55688450.4060605@cs.tcd.ie> Date: Fri, 29 May 2015 16:22:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Joel Halpern Direct , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> <55681DCC.2000907@cs.tcd.ie> <55687798.8050804@joelhalpern.com> <556878F7.6030506@cs.tcd.ie> <55688129.4030200@joelhalpern.com> In-Reply-To: <55688129.4030200@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 15:23:03 -0000 Hiya, On 29/05/15 16:09, Joel Halpern Direct wrote: > I am not sure I like the following, but to try to move this forward, would > > Protocols addressing this architecture need to include definitions for > how security services are provided with that solution, although > implementation of such mechanisms may be optional. Sorry, I'm really not at all sure that's a good idea as I suspect it has too high a liklihood that those who want to see such work done, and those who don't, both read it and are not unhappy;-) I'm not interested in trying to force the SFC WG to define some mythical security that never gets implemented really so I think maybe we'll be better off if we do enough of the analysis now(ish) to know that the architecture can say "protocols need to define a confidentiality service that can protect meta-data and a data-origin authentication services that can protect the SFC encapsulation." I do think that may need a bit more work though before one would be happy to put it out in the RFC. And one possible outcome of that work could be that it says instead "we know we do really need a confidentiality service but we can't see how that's practical right now" if that is in fact the case. (Which is possible, since these middle to middle confidentiality things are v. hard to do.) BTW - is there a reason to want this document to proceed to be an RFC very quickly? If so, be good to know. If not, then we don't need to rush to a compromise that we might all be sad about later. S. > > work for you? > Yours, > Joel > > On 5/29/15 10:34 AM, Stephen Farrell wrote: >> >> >> On 29/05/15 15:28, Joel M. Halpern wrote: >>> Would you consider the following sentence pair that Carlos and I have >>> been debating to be helpful: >>> >>> “some protocols may optionally include confidentiality provisions for >>> metadata and service function path identity, which may be used in some >>> deployments. The architecture does not mandate such function.“ >> >> Not really no. I think that says nothing at all while at the same >> time having the ambiguity around the term "mandate" that I pointed >> out below. >> >> I have no clue why the SFC architecture cannot simply say that >> a confidentiality service needs to be defined. >> >> S. >> >>> >>> ? >>> Yours, >>> Joel >>> >>> On 5/29/15 4:05 AM, Stephen Farrell wrote: >>>> >>>> Joel, >>>> >>>> On 28/05/15 22:28, Joel M. Halpern wrote: >>>>> Enjoy the pub. >>>> >>>> I did, of course:-) >>>> >>>>> >>>>> No, I do not agree. I do not see that the archtiecture needs to >>>>> mandate >>>>> a confidentiality service to protect the meta-data. >>>> >>>> I'm sorry but that's just unhelpful. I did not speak of mandating >>>> and doing so is simply to introduce a distracting negative ambiguity. >>>> >>>> I am discussing whether the architecture should call for a protocol >>>> solution that has a well-defined way to provide confidentiality and >>>> data origin authentication. Whether and when that may, should or >>>> must be used is not a part of the architecture. >>>> >>>> It will help the discussion if you are similarly precise. It will >>>> IMO prove really hard to resolve the discussion if such ambiguities >>>> are constantly introduced. (I have seen the same in response to the >>>> secdir review where their suggestion that X be defined is met with >>>> an objection to X being forced to be used all the time.) >>>> >>>>> The data can only >>>>> leak across the kind of boundary you describe if the service function >>>>> chooses to leak it. >>>> >>>> Rubbish. If the protocol solution provides no confidentiality >>>> service for meta-data then the leakage is inevitable as there >>>> will be no possible alternative. >>>> >>>> Yes a bad actor deploying can always leak, we are here considering >>>> how to enable good actors to do the right thing. >>>> >>>>> Given taht it will have to have access to the meta >>>>> data, no confidentiality mechanism will prevent that. >>>>> >>>>> Note that the encrypted packet produced by the service function is >>>>> addressed to some end point. I am failing to see how the problem you >>>>> are asking us to address could arise. >>>> >>>> Frankly, ISTM that you are doing more than that. My impression is >>>> that you are opposed to defining a confidentiality service. I would >>>> be happy to be corrected in that. >>>> >>>> I do understand that calling for a confidentiality service does >>>> not mean that it will be easy to define a useful confidentiality >>>> service. I am quite sure that the IETF could muck that up as we >>>> have done in the past (e.g. with SIP & S/MIME) but I am equally >>>> sure we could also succeed, and I think we should try and indeed >>>> our BCPs call for us to do just that, once we recognise there is >>>> a need for such a service. And that last is, I think, entirely >>>> clear. >>>> >>>> S. >>>> >>>> >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 5/28/15 5:24 PM, Stephen Farrell wrote: >>>>>> >>>>>> Joel, >>>>>> >>>>>> I'm afraid you've lost me again, but since it's now time for >>>>>> me to go to the pub, that's fine:-) >>>>>> >>>>>> For me the important thing is if meta-data is inserted at A and >>>>>> then packets are encrypted by something between B and C, then >>>>>> we do not want cleartext meta-data attached to the ciphertext >>>>>> sent from B to C to always have to risk making the encryption >>>>>> pointless. >>>>>> >>>>>> To me, that means that this architecture needs to call for the >>>>>> existence of a confidentiality service that can be used to >>>>>> protect at least the meta-data. (And it could protect more too >>>>>> I guess but the details would be for the WG to figure later.) >>>>>> >>>>>> I think additional scenarios can similarly justify a need for >>>>>> the definition of a data origin authentication service. >>>>>> >>>>>> If we agreed about that and could move on to how that ought be >>>>>> expressed in the arch document, that'd be great. (But as I'll >>>>>> be in the pub, I won't find out 'till tomorrow:-) >>>>>> >>>>>> Cheers, >>>>>> S. >>>>>> >>>>>> >>>>>> On 28/05/15 22:18, Joel M. Halpern wrote: >>>>>>> While SMTP servers are a bad example, service chaining can be use >>>>>>> with >>>>>>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. >>>>>>> Both of >>>>>>> those terminate connections and create new packets. As such, the >>>>>>> two >>>>>>> sides of such devices are on separate service chains. In order for >>>>>>> the >>>>>>> two sides to be on the same chain, the service function would >>>>>>> have to >>>>>>> copy the service chaining and related metadata from one side to the >>>>>>> other. I can't stop them from doing so, but in most cases it >>>>>>> would be >>>>>>> misleading. >>>>>>> >>>>>>> What we have done is to recognize that these are generally different >>>>>>> service chains. Because the packets will get different treatments. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>>>>>> >>>>>>>> Joel, >>>>>>>> >>>>>>>> If you are asserting that SFC cannot be used in a manner that >>>>>>>> has the problem I was trying to exemplify then I have to say, >>>>>>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>>>>>> is one of the examples cited in the arch draft, and there's >>>>>>>> not much difference between that and email from the relevant >>>>>>>> perspective. >>>>>>>> >>>>>>>> I also hope that I've succeeded in explaining the problem as >>>>>>>> I see it. If not please ask and I'll try some more to clarify. >>>>>>>> (Since you did not ask that, I assume you do get what I mean, >>>>>>>> but it would be helpful if you would acknowledge that so we >>>>>>>> can communicate more easily.) >>>>>>>> >>>>>>>> Can you point me at some piece of text in some draft that >>>>>>>> ensures that this problem cannot occur? If not, (which I >>>>>>>> think is the case), wouldn't we be better off acknowledging >>>>>>>> that it is an issue and one that needs to be tackled as >>>>>>>> best we can, as indeed Alia's earlier mail seems (to me) >>>>>>>> to suggest? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> S. >>>>>>>> >>>>>>>> >>>>>>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>>>>>> That case would not occur within a service chain. >>>>>>>>> A service chain is about delivery of a packet to a series of >>>>>>>>> services to >>>>>>>>> which it is not addressed (generally followed by delivery to the >>>>>>>>> target >>>>>>>>> to which it is addressed.) >>>>>>>>> An SMTP server relaying email produces separate packets. The >>>>>>>>> packets >>>>>>>>> from the user to the SMTP server are on one chain. The packets >>>>>>>>> from >>>>>>>>> that server to another are completely separate, and on a different >>>>>>>>> chain. As such, those TLS SMTP packets between the servers would >>>>>>>>> not >>>>>>>>> have any metadata from the first transfer. >>>>>>>>> >>>>>>>>> Mail servers are not SFC service functions. The only time it gets >>>>>>>>> close >>>>>>>>> is when you are doing port 25 redirection, and then the service >>>>>>>>> chain >>>>>>>>> ends at the mail server. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>>>>>> IF A, B, and C are service function forwarders (SFF), with a TLS >>>>>>>>>>> protected link for SFC, then the metadata will be protected. >>>>>>>>>>> (Such a >>>>>>>>>>> link would be a transport mechanism, which SFC does not >>>>>>>>>>> describe or >>>>>>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>>>>>> >>>>>>>>>> Ah, no the scenario I was thinking about is where, from >>>>>>>>>> the perspective of SFC, the TLS packets are the payload >>>>>>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>>>>>> servers with starttls only turned on between B and C >>>>>>>>>> because that link is "external" (though within the same >>>>>>>>>> administrative domain). If some SFC thing at A were to >>>>>>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>>>>>> data then we wouldn't want that sent in clear from B to C >>>>>>>>>> because of the SFC encapsulation, right? >>>>>>>>>> >>>>>>>>>> S. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If A, B, and C are service functions used by SFC, then there >>>>>>>>>>> is no >>>>>>>>>>> link >>>>>>>>>>> between B and C, so it can't be protected by TLS. >>>>>>>>>>> >>>>>>>>>>> So I can not see what more needs to be said? >>>>>>>>>>> >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>> >>>>>>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>>>>>> I am not sure what you mean by "Metadata that contains >>>>>>>>>>>>> information >>>>>>>>>>>>> that >>>>>>>>>>>>> is protected in the data plane". Most of what ends up in the >>>>>>>>>>>>> metadata >>>>>>>>>>>>> is information that is passed on other interfaces directly to >>>>>>>>>>>>> relevant >>>>>>>>>>>>> functions, or locally determine and locally processed. >>>>>>>>>>>> >>>>>>>>>>>> So what I had in mind were things like the following. >>>>>>>>>>>> >>>>>>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>>>>>> - B to C link is via say a TLS VPN >>>>>>>>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>>>>>>>> and not protected by the VPN >>>>>>>>>>>> - That seems bad >>>>>>>>>>>> >>>>>>>>>>>> S. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The protection used for policy systems (which provide much of >>>>>>>>>>>>> the >>>>>>>>>>>>> information) is based on the presence of persistent >>>>>>>>>>>>> connections >>>>>>>>>>>>> and >>>>>>>>>>>>> usage which crosses domains. Are you arguing that if AAA is >>>>>>>>>>>>> encrypted >>>>>>>>>>>>> then policy delivered by AAA resulting in metadata in the >>>>>>>>>>>>> packet >>>>>>>>>>>>> must be >>>>>>>>>>>>> encrypted in the data packets? >>>>>>>>>>>>> >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>> >>>>>>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>>>>>> >>>>>>>>>>>>>> When responding, please keep the subject line intact and >>>>>>>>>>>>>> reply >>>>>>>>>>>>>> to all >>>>>>>>>>>>>> email addresses included in the To and CC lines. (Feel >>>>>>>>>>>>>> free to >>>>>>>>>>>>>> cut >>>>>>>>>>>>>> this >>>>>>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please refer to >>>>>>>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>>>>>> for more information about IESG DISCUSS and COMMENT >>>>>>>>>>>>>> positions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The document, along with other ballot positions, can be found >>>>>>>>>>>>>> here: >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> DISCUSS: >>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> (1) I note the charter calls for this deliverable to "provide >>>>>>>>>>>>>> a description of... security models" The charter also >>>>>>>>>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>>>>>>>>> address the management and security implications when >>>>>>>>>>>>>> documenting these deliverables." My conclusion is that this >>>>>>>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>>>>>>> analysis that the wg are suppoed to have carried out but that >>>>>>>>>>>>>> it's currently too vague only saying that solutions need to >>>>>>>>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>>>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] >>>>>>>>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> (2) Metadata that contains information that is protected in >>>>>>>>>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>>>>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>>>>>>>>> not sure myself if "passed about" ought also include within a >>>>>>>>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>>>>>>> document needs to say that those services have to be >>>>>>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - It occurs to me that it might really be better for the WG >>>>>>>>>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>>>>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>>>>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>>>>>>>>> result in the eventual RFC being a much more useful document. >>>>>>>>>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>>>>>>>>> vague and won't be very useful even in the medium term. But >>>>>>>>>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>>>>>>>>> to push this out, even if that might only give the appearance >>>>>>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>>>>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - The charter text describing this deliverable notes that >>>>>>>>>>>>>> "The initial scope is restricted to a single administrative >>>>>>>>>>>>>> domain, keeping in mind that architectural decisions made for >>>>>>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>>>>>>> single-domain elements of this architecture might impinge on >>>>>>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>>>>>>> goals. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Chains will require some representation, and re-ordering >>>>>>>>>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>>>>>>>>> for fun) therefore there must be a requirement for some data >>>>>>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>>>>>> authorisation decision function and therefore there must >>>>>>>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>>>>>>> producing entity of some kind that could be authenticated. >>>>>>>>>>>>>> That is an example of the missing security analysis that >>>>>>>>>>>>>> really is needed before this proceeds. (See my discuss point >>>>>>>>>>>>>> 2) >>>>>>>>>>>>>> >>>>>>>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>>>>>>> networks are slightly incongrous. In the case of WiFi when do >>>>>>>>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>>>>>>>> mobile node transmitter?) I suspect you really mean the wired >>>>>>>>>>>>>> bits of a mobile network so it might be better to say that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>>>>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>>>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>>>>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>>>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>>>>>>>>> terms need to be defined. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>>>>>>> partially ordered? >>>>>>>>>>>>>> >>>>>>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>>>>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>>>>>>> reviews on the same telechat as this) so I'd also drop that. >>>>>>>>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>>>>>>>> reference (ideally an RFC). >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>>>>>>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>>>>>>>>> the full graphs themselves. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>>>>>>>>> the example given imply that all traffic (of what kind?) that >>>>>>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>>>>>>>> odder to me. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>>>>>>>> architecture is to avoid such vagueness? If you mean that an >>>>>>>>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>>>>>>>> that would be the thing to do. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>>>>>>>>> about not making security and privacy worse in general. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>>>>>>>> traffic that congestion would be an issue? If so, should you >>>>>>>>>>>>>> say rather that any transport that has some way of handling >>>>>>>>>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>>>>>>>>> fine. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From nobody Fri May 29 08:28:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA8C1ACC87; Fri, 29 May 2015 08:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_OFF=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKdYEFG5KXBp; Fri, 29 May 2015 08:28:15 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B851ACD0D; Fri, 29 May 2015 08:27:49 -0700 (PDT) Received: by qgf2 with SMTP id 2so30534021qgf.3; Fri, 29 May 2015 08:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DzG6YHUkMgiZ0e8+myAJew3UcPce5lWP9SsgxsZnYOU=; b=Eyz8hqWMqpp4qSOZISHRl/aRfDPxp/6KogKIl4DZPtaXcLqOjGpu+5eSTJGKB1i0Ec 5QkVjatQSAYPevRj3i9/FU2FQgQUDWEhc+p5FaAp/12GfI3DWYpzPkk0AGEYm51tIf1C oq5I0rcKaF4jJBm7gidfopcq4eRePAj4l34e6w7wGjKeHMjyf0H21SV+xdJxg4JKmimL LAGtklHUUUsxOgsjV8A4BdrFVlCl64paw11cSQkEqVS3k+EwL4Pf6VQxrL9bf01bYV+n KYulicXS78qLgJV2LlvGxZEMNw8uwhu2KNz5geDUnS1/aNMg2g7SoawvZd76/xnkieb1 AerA== X-Received: by 10.140.102.101 with SMTP id v92mr10094186qge.19.1432913268695; Fri, 29 May 2015 08:27:48 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id q7sm2837558qkh.35.2015.05.29.08.27.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 May 2015 08:27:47 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <55688450.4060605@cs.tcd.ie> Date: Fri, 29 May 2015 11:27:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4ABC6138-B19E-4FD0-8A77-713889B0EB90@gmail.com> References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> <55681DCC.2000907@cs.tcd.ie> <55687798.8050804@joelhalpern.com> <556878F7.6030506@cs.tcd.ie> <55688129.4030200@joelhalpern.com> <55688450.4060605@cs.tcd.ie> To: Stephen Farrell Archived-At: Cc: Joel Halpern Direct , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "jguichar@cisco.com" , "draft-ietf-sfc-architecture.ad@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 15:28:19 -0000 Hi, Sent from my iPhone > On May 29, 2015, at 11:22 AM, Stephen Farrell w= rote: >=20 >=20 > Hiya, >=20 >> On 29/05/15 16:09, Joel Halpern Direct wrote: >> I am not sure I like the following, but to try to move this forward, woul= d >>=20 >> Protocols addressing this architecture need to include definitions for >> how security services are provided with that solution, although >> implementation of such mechanisms may be optional. >=20 > Sorry, I'm really not at all sure that's a good idea as I suspect > it has too high a liklihood that those who want to see such work > done, and those who don't, both read it and are not unhappy;-) >=20 > I'm not interested in trying to force the SFC WG to define some > mythical security that never gets implemented really so I think > maybe we'll be better off if we do enough of the analysis now(ish) > to know that the architecture can say "protocols need to > define a confidentiality service that can protect meta-data > and a data-origin authentication services that can protect the > SFC encapsulation." I do think that may need a bit more work > though before one would be happy to put it out in the RFC. > And one possible outcome of that work could be that it says > instead "we know we do really need a confidentiality service > but we can't see how that's practical right now" if that is > in fact the case. (Which is possible, since these middle to > middle confidentiality things are v. hard to do.) I agree with Stephen. His wording is more direct and to the point. Kathleen=20 >=20 > BTW - is there a reason to want this document to proceed to > be an RFC very quickly? If so, be good to know. If not, then > we don't need to rush to a compromise that we might all be > sad about later. >=20 > S. >=20 >>=20 >> work for you? >> Yours, >> Joel >>=20 >>> On 5/29/15 10:34 AM, Stephen Farrell wrote: >>>=20 >>>=20 >>>> On 29/05/15 15:28, Joel M. Halpern wrote: >>>> Would you consider the following sentence pair that Carlos and I have >>>> been debating to be helpful: >>>>=20 >>>> =E2=80=9Csome protocols may optionally include confidentiality provisio= ns for >>>> metadata and service function path identity, which may be used in some >>>> deployments. The architecture does not mandate such function.=E2=80=9C >>>=20 >>> Not really no. I think that says nothing at all while at the same >>> time having the ambiguity around the term "mandate" that I pointed >>> out below. >>>=20 >>> I have no clue why the SFC architecture cannot simply say that >>> a confidentiality service needs to be defined. >>>=20 >>> S. >>>=20 >>>>=20 >>>> ? >>>> Yours, >>>> Joel >>>>=20 >>>>> On 5/29/15 4:05 AM, Stephen Farrell wrote: >>>>>=20 >>>>> Joel, >>>>>=20 >>>>>> On 28/05/15 22:28, Joel M. Halpern wrote: >>>>>> Enjoy the pub. >>>>>=20 >>>>> I did, of course:-) >>>>>=20 >>>>>>=20 >>>>>> No, I do not agree. I do not see that the archtiecture needs to >>>>>> mandate >>>>>> a confidentiality service to protect the meta-data. >>>>>=20 >>>>> I'm sorry but that's just unhelpful. I did not speak of mandating >>>>> and doing so is simply to introduce a distracting negative ambiguity. >>>>>=20 >>>>> I am discussing whether the architecture should call for a protocol >>>>> solution that has a well-defined way to provide confidentiality and >>>>> data origin authentication. Whether and when that may, should or >>>>> must be used is not a part of the architecture. >>>>>=20 >>>>> It will help the discussion if you are similarly precise. It will >>>>> IMO prove really hard to resolve the discussion if such ambiguities >>>>> are constantly introduced. (I have seen the same in response to the >>>>> secdir review where their suggestion that X be defined is met with >>>>> an objection to X being forced to be used all the time.) >>>>>=20 >>>>>> The data can only >>>>>> leak across the kind of boundary you describe if the service function= >>>>>> chooses to leak it. >>>>>=20 >>>>> Rubbish. If the protocol solution provides no confidentiality >>>>> service for meta-data then the leakage is inevitable as there >>>>> will be no possible alternative. >>>>>=20 >>>>> Yes a bad actor deploying can always leak, we are here considering >>>>> how to enable good actors to do the right thing. >>>>>=20 >>>>>> Given taht it will have to have access to the meta >>>>>> data, no confidentiality mechanism will prevent that. >>>>>>=20 >>>>>> Note that the encrypted packet produced by the service function is >>>>>> addressed to some end point. I am failing to see how the problem you= >>>>>> are asking us to address could arise. >>>>>=20 >>>>> Frankly, ISTM that you are doing more than that. My impression is >>>>> that you are opposed to defining a confidentiality service. I would >>>>> be happy to be corrected in that. >>>>>=20 >>>>> I do understand that calling for a confidentiality service does >>>>> not mean that it will be easy to define a useful confidentiality >>>>> service. I am quite sure that the IETF could muck that up as we >>>>> have done in the past (e.g. with SIP & S/MIME) but I am equally >>>>> sure we could also succeed, and I think we should try and indeed >>>>> our BCPs call for us to do just that, once we recognise there is >>>>> a need for such a service. And that last is, I think, entirely >>>>> clear. >>>>>=20 >>>>> S. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>>> On 5/28/15 5:24 PM, Stephen Farrell wrote: >>>>>>>=20 >>>>>>> Joel, >>>>>>>=20 >>>>>>> I'm afraid you've lost me again, but since it's now time for >>>>>>> me to go to the pub, that's fine:-) >>>>>>>=20 >>>>>>> For me the important thing is if meta-data is inserted at A and >>>>>>> then packets are encrypted by something between B and C, then >>>>>>> we do not want cleartext meta-data attached to the ciphertext >>>>>>> sent from B to C to always have to risk making the encryption >>>>>>> pointless. >>>>>>>=20 >>>>>>> To me, that means that this architecture needs to call for the >>>>>>> existence of a confidentiality service that can be used to >>>>>>> protect at least the meta-data. (And it could protect more too >>>>>>> I guess but the details would be for the WG to figure later.) >>>>>>>=20 >>>>>>> I think additional scenarios can similarly justify a need for >>>>>>> the definition of a data origin authentication service. >>>>>>>=20 >>>>>>> If we agreed about that and could move on to how that ought be >>>>>>> expressed in the arch document, that'd be great. (But as I'll >>>>>>> be in the pub, I won't find out 'till tomorrow:-) >>>>>>>=20 >>>>>>> Cheers, >>>>>>> S. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 28/05/15 22:18, Joel M. Halpern wrote: >>>>>>>> While SMTP servers are a bad example, service chaining can be use >>>>>>>> with >>>>>>>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers.=20 >>>>>>>> Both of >>>>>>>> those terminate connections and create new packets. As such, the >>>>>>>> two >>>>>>>> sides of such devices are on separate service chains. In order for= >>>>>>>> the >>>>>>>> two sides to be on the same chain, the service function would >>>>>>>> have to >>>>>>>> copy the service chaining and related metadata from one side to the= >>>>>>>> other. I can't stop them from doing so, but in most cases it >>>>>>>> would be >>>>>>>> misleading. >>>>>>>>=20 >>>>>>>> What we have done is to recognize that these are generally differen= t >>>>>>>> service chains. Because the packets will get different treatments.= >>>>>>>>=20 >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>>=20 >>>>>>>>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>>>>>>>=20 >>>>>>>>> Joel, >>>>>>>>>=20 >>>>>>>>> If you are asserting that SFC cannot be used in a manner that >>>>>>>>> has the problem I was trying to exemplify then I have to say, >>>>>>>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>>>>>>> is one of the examples cited in the arch draft, and there's >>>>>>>>> not much difference between that and email from the relevant >>>>>>>>> perspective. >>>>>>>>>=20 >>>>>>>>> I also hope that I've succeeded in explaining the problem as >>>>>>>>> I see it. If not please ask and I'll try some more to clarify. >>>>>>>>> (Since you did not ask that, I assume you do get what I mean, >>>>>>>>> but it would be helpful if you would acknowledge that so we >>>>>>>>> can communicate more easily.) >>>>>>>>>=20 >>>>>>>>> Can you point me at some piece of text in some draft that >>>>>>>>> ensures that this problem cannot occur? If not, (which I >>>>>>>>> think is the case), wouldn't we be better off acknowledging >>>>>>>>> that it is an issue and one that needs to be tackled as >>>>>>>>> best we can, as indeed Alia's earlier mail seems (to me) >>>>>>>>> to suggest? >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> S. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>>>>>>> That case would not occur within a service chain. >>>>>>>>>> A service chain is about delivery of a packet to a series of >>>>>>>>>> services to >>>>>>>>>> which it is not addressed (generally followed by delivery to the= >>>>>>>>>> target >>>>>>>>>> to which it is addressed.) >>>>>>>>>> An SMTP server relaying email produces separate packets. The >>>>>>>>>> packets >>>>>>>>>> from the user to the SMTP server are on one chain. The packets >>>>>>>>>> from >>>>>>>>>> that server to another are completely separate, and on a differen= t >>>>>>>>>> chain. As such, those TLS SMTP packets between the servers would= >>>>>>>>>> not >>>>>>>>>> have any metadata from the first transfer. >>>>>>>>>>=20 >>>>>>>>>> Mail servers are not SFC service functions. The only time it get= s >>>>>>>>>> close >>>>>>>>>> is when you are doing port 25 redirection, and then the service >>>>>>>>>> chain >>>>>>>>>> ends at the mail server. >>>>>>>>>>=20 >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>>=20 >>>>>>>>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>>>>>>> IF A, B, and C are service function forwarders (SFF), with a TL= S >>>>>>>>>>>> protected link for SFC, then the metadata will be protected. >>>>>>>>>>>> (Such a >>>>>>>>>>>> link would be a transport mechanism, which SFC does not >>>>>>>>>>>> describe or >>>>>>>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>>>>>>>=20 >>>>>>>>>>> Ah, no the scenario I was thinking about is where, from >>>>>>>>>>> the perspective of SFC, the TLS packets are the payload >>>>>>>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>>>>>>> servers with starttls only turned on between B and C >>>>>>>>>>> because that link is "external" (though within the same >>>>>>>>>>> administrative domain). If some SFC thing at A were to >>>>>>>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>>>>>>> data then we wouldn't want that sent in clear from B to C >>>>>>>>>>> because of the SFC encapsulation, right? >>>>>>>>>>>=20 >>>>>>>>>>> S. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> If A, B, and C are service functions used by SFC, then there >>>>>>>>>>>> is no >>>>>>>>>>>> link >>>>>>>>>>>> between B and C, so it can't be protected by TLS. >>>>>>>>>>>>=20 >>>>>>>>>>>> So I can not see what more needs to be said? >>>>>>>>>>>>=20 >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>>>>>>> I am not sure what you mean by "Metadata that contains >>>>>>>>>>>>>> information >>>>>>>>>>>>>> that >>>>>>>>>>>>>> is protected in the data plane". Most of what ends up in the= >>>>>>>>>>>>>> metadata >>>>>>>>>>>>>> is information that is passed on other interfaces directly to= >>>>>>>>>>>>>> relevant >>>>>>>>>>>>>> functions, or locally determine and locally processed. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> So what I had in mind were things like the following. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>>>>>>> - B to C link is via say a TLS VPN >>>>>>>>>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>>>>>>>>> and not protected by the VPN >>>>>>>>>>>>> - That seems bad >>>>>>>>>>>>>=20 >>>>>>>>>>>>> S. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The protection used for policy systems (which provide much of= >>>>>>>>>>>>>> the >>>>>>>>>>>>>> information) is based on the presence of persistent >>>>>>>>>>>>>> connections >>>>>>>>>>>>>> and >>>>>>>>>>>>>> usage which crosses domains. Are you arguing that if AAA is >>>>>>>>>>>>>> encrypted >>>>>>>>>>>>>> then policy delivered by AAA resulting in metadata in the >>>>>>>>>>>>>> packet >>>>>>>>>>>>>> must be >>>>>>>>>>>>>> encrypted in the data packets? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>>>>>>> Stephen Farrell has entered the following ballot position fo= r >>>>>>>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> When responding, please keep the subject line intact and >>>>>>>>>>>>>>> reply >>>>>>>>>>>>>>> to all >>>>>>>>>>>>>>> email addresses included in the To and CC lines. (Feel >>>>>>>>>>>>>>> free to >>>>>>>>>>>>>>> cut >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Please refer to >>>>>>>>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>>>>>>> for more information about IESG DISCUSS and COMMENT >>>>>>>>>>>>>>> positions. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The document, along with other ballot positions, can be foun= d >>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture= / >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> ------------------------------------------------------------= ---------- >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> DISCUSS: >>>>>>>>>>>>>>> ------------------------------------------------------------= ---------- >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> (1) I note the charter calls for this deliverable to "provid= e >>>>>>>>>>>>>>> a description of... security models" The charter also >>>>>>>>>>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>>>>>>>>>> address the management and security implications when >>>>>>>>>>>>>>> documenting these deliverables." My conclusion is that this >>>>>>>>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>>>>>>>> analysis that the wg are suppoed to have carried out but tha= t >>>>>>>>>>>>>>> it's currently too vague only saying that solutions need to >>>>>>>>>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>>>>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg0570= 1.html >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> (2) Metadata that contains information that is protected in >>>>>>>>>>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>>>>>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>>>>>>>>>> not sure myself if "passed about" ought also include within a= >>>>>>>>>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>>>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>>>>>>>> document needs to say that those services have to be >>>>>>>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> ------------------------------------------------------------= ---------- >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>>>> ------------------------------------------------------------= ---------- >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - It occurs to me that it might really be better for the WG >>>>>>>>>>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>>>>>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>>>>>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>>>>>>>>>> result in the eventual RFC being a much more useful document= . >>>>>>>>>>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>>>>>>>>>> vague and won't be very useful even in the medium term. But >>>>>>>>>>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>>>>>>>>>> to push this out, even if that might only give the appearanc= e >>>>>>>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>>>>>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - The charter text describing this deliverable notes that >>>>>>>>>>>>>>> "The initial scope is restricted to a single administrative >>>>>>>>>>>>>>> domain, keeping in mind that architectural decisions made fo= r >>>>>>>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>>>>>>>> single-domain elements of this architecture might impinge on= >>>>>>>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>>>>>>>> goals. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - Chains will require some representation, and re-ordering >>>>>>>>>>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>>>>>>>>>> for fun) therefore there must be a requirement for some data= >>>>>>>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>>>>>>> authorisation decision function and therefore there must >>>>>>>>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>>>>>>>> producing entity of some kind that could be authenticated. >>>>>>>>>>>>>>> That is an example of the missing security analysis that >>>>>>>>>>>>>>> really is needed before this proceeds. (See my discuss point= >>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>>>>>>>> networks are slightly incongrous. In the case of WiFi when d= o >>>>>>>>>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>>>>>>>>> mobile node transmitter?) I suspect you really mean the wire= d >>>>>>>>>>>>>>> bits of a mobile network so it might be better to say that. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>>>>>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>>>>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>>>>>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>>>>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>>>>>>>>>> terms need to be defined. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>>>>>>>> partially ordered? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>>>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any kind o= f >>>>>>>>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>>>>>>>> reviews on the same telechat as this) so I'd also drop that.= >>>>>>>>>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>>>>>>>>> reference (ideally an RFC). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - Figure 1 caption is misleading. That seems to me to show a= >>>>>>>>>>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>>>>>>>>>> the full graphs themselves. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>>>>>>>>>> the example given imply that all traffic (of what kind?) tha= t >>>>>>>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>>>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>>>>>>>>> odder to me. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>>>>>>>>> architecture is to avoid such vagueness? If you mean that an= >>>>>>>>>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>>>>>>>>> that would be the thing to do. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>>>>>>>>>> about not making security and privacy worse in general. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>>>>>>>>> traffic that congestion would be an issue? If so, should yo= u >>>>>>>>>>>>>>> say rather that any transport that has some way of handling >>>>>>>>>>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>>>>>>>>>> fine. >=20 From nobody Fri May 29 08:51:03 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BABE1AC3C8; Fri, 29 May 2015 08:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U81q5lN3vaD; Fri, 29 May 2015 08:50:52 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28B11ACD57; Fri, 29 May 2015 08:50:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DE1852464B7; Fri, 29 May 2015 08:50:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 77E12240865; Fri, 29 May 2015 08:50:50 -0700 (PDT) Message-ID: <55688ACC.6070405@joelhalpern.com> Date: Fri, 29 May 2015 11:50:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> <55681DCC.2000907@cs.tcd.ie> <55687798.8050804@joelhalpern.com> <556878F7.6030506@cs.tcd.ie> <55688129.4030200@joelhalpern.com> <55688450.4060605@cs.tcd.ie> In-Reply-To: <55688450.4060605@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 15:50:55 -0000 The document is a deliverable milestone intended to frame agreements which will then guide the protocol design process. The protocol process is going to try to move quickly. So we want this done, and argument resolved, ASAP. Would: Protocols addressing this architecture must include mechanisms to provide confidentiality and integrity of metadata carried by the protocol, although implementation of such mechanisms may be optional. be any better? I don't want to include data origin authentication because that would require separate protection for each piece of metadata (as they may come from separate sources). We already have size concerns with this whole mechanism. Yours, Joel On 5/29/15 11:22 AM, Stephen Farrell wrote: > > Hiya, > > On 29/05/15 16:09, Joel Halpern Direct wrote: >> I am not sure I like the following, but to try to move this forward, would >> >> Protocols addressing this architecture need to include definitions for >> how security services are provided with that solution, although >> implementation of such mechanisms may be optional. > > Sorry, I'm really not at all sure that's a good idea as I suspect > it has too high a liklihood that those who want to see such work > done, and those who don't, both read it and are not unhappy;-) > > I'm not interested in trying to force the SFC WG to define some > mythical security that never gets implemented really so I think > maybe we'll be better off if we do enough of the analysis now(ish) > to know that the architecture can say "protocols need to > define a confidentiality service that can protect meta-data > and a data-origin authentication services that can protect the > SFC encapsulation." I do think that may need a bit more work > though before one would be happy to put it out in the RFC. > And one possible outcome of that work could be that it says > instead "we know we do really need a confidentiality service > but we can't see how that's practical right now" if that is > in fact the case. (Which is possible, since these middle to > middle confidentiality things are v. hard to do.) > > BTW - is there a reason to want this document to proceed to > be an RFC very quickly? If so, be good to know. If not, then > we don't need to rush to a compromise that we might all be > sad about later. > > S. > >> >> work for you? >> Yours, >> Joel >> >> On 5/29/15 10:34 AM, Stephen Farrell wrote: >>> >>> >>> On 29/05/15 15:28, Joel M. Halpern wrote: >>>> Would you consider the following sentence pair that Carlos and I have >>>> been debating to be helpful: >>>> >>>> “some protocols may optionally include confidentiality provisions for >>>> metadata and service function path identity, which may be used in some >>>> deployments. The architecture does not mandate such function.“ >>> >>> Not really no. I think that says nothing at all while at the same >>> time having the ambiguity around the term "mandate" that I pointed >>> out below. >>> >>> I have no clue why the SFC architecture cannot simply say that >>> a confidentiality service needs to be defined. >>> >>> S. >>> >>>> >>>> ? >>>> Yours, >>>> Joel >>>> >>>> On 5/29/15 4:05 AM, Stephen Farrell wrote: >>>>> >>>>> Joel, >>>>> >>>>> On 28/05/15 22:28, Joel M. Halpern wrote: >>>>>> Enjoy the pub. >>>>> >>>>> I did, of course:-) >>>>> >>>>>> >>>>>> No, I do not agree. I do not see that the archtiecture needs to >>>>>> mandate >>>>>> a confidentiality service to protect the meta-data. >>>>> >>>>> I'm sorry but that's just unhelpful. I did not speak of mandating >>>>> and doing so is simply to introduce a distracting negative ambiguity. >>>>> >>>>> I am discussing whether the architecture should call for a protocol >>>>> solution that has a well-defined way to provide confidentiality and >>>>> data origin authentication. Whether and when that may, should or >>>>> must be used is not a part of the architecture. >>>>> >>>>> It will help the discussion if you are similarly precise. It will >>>>> IMO prove really hard to resolve the discussion if such ambiguities >>>>> are constantly introduced. (I have seen the same in response to the >>>>> secdir review where their suggestion that X be defined is met with >>>>> an objection to X being forced to be used all the time.) >>>>> >>>>>> The data can only >>>>>> leak across the kind of boundary you describe if the service function >>>>>> chooses to leak it. >>>>> >>>>> Rubbish. If the protocol solution provides no confidentiality >>>>> service for meta-data then the leakage is inevitable as there >>>>> will be no possible alternative. >>>>> >>>>> Yes a bad actor deploying can always leak, we are here considering >>>>> how to enable good actors to do the right thing. >>>>> >>>>>> Given taht it will have to have access to the meta >>>>>> data, no confidentiality mechanism will prevent that. >>>>>> >>>>>> Note that the encrypted packet produced by the service function is >>>>>> addressed to some end point. I am failing to see how the problem you >>>>>> are asking us to address could arise. >>>>> >>>>> Frankly, ISTM that you are doing more than that. My impression is >>>>> that you are opposed to defining a confidentiality service. I would >>>>> be happy to be corrected in that. >>>>> >>>>> I do understand that calling for a confidentiality service does >>>>> not mean that it will be easy to define a useful confidentiality >>>>> service. I am quite sure that the IETF could muck that up as we >>>>> have done in the past (e.g. with SIP & S/MIME) but I am equally >>>>> sure we could also succeed, and I think we should try and indeed >>>>> our BCPs call for us to do just that, once we recognise there is >>>>> a need for such a service. And that last is, I think, entirely >>>>> clear. >>>>> >>>>> S. >>>>> >>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 5/28/15 5:24 PM, Stephen Farrell wrote: >>>>>>> >>>>>>> Joel, >>>>>>> >>>>>>> I'm afraid you've lost me again, but since it's now time for >>>>>>> me to go to the pub, that's fine:-) >>>>>>> >>>>>>> For me the important thing is if meta-data is inserted at A and >>>>>>> then packets are encrypted by something between B and C, then >>>>>>> we do not want cleartext meta-data attached to the ciphertext >>>>>>> sent from B to C to always have to risk making the encryption >>>>>>> pointless. >>>>>>> >>>>>>> To me, that means that this architecture needs to call for the >>>>>>> existence of a confidentiality service that can be used to >>>>>>> protect at least the meta-data. (And it could protect more too >>>>>>> I guess but the details would be for the WG to figure later.) >>>>>>> >>>>>>> I think additional scenarios can similarly justify a need for >>>>>>> the definition of a data origin authentication service. >>>>>>> >>>>>>> If we agreed about that and could move on to how that ought be >>>>>>> expressed in the arch document, that'd be great. (But as I'll >>>>>>> be in the pub, I won't find out 'till tomorrow:-) >>>>>>> >>>>>>> Cheers, >>>>>>> S. >>>>>>> >>>>>>> >>>>>>> On 28/05/15 22:18, Joel M. Halpern wrote: >>>>>>>> While SMTP servers are a bad example, service chaining can be use >>>>>>>> with >>>>>>>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. >>>>>>>> Both of >>>>>>>> those terminate connections and create new packets. As such, the >>>>>>>> two >>>>>>>> sides of such devices are on separate service chains. In order for >>>>>>>> the >>>>>>>> two sides to be on the same chain, the service function would >>>>>>>> have to >>>>>>>> copy the service chaining and related metadata from one side to the >>>>>>>> other. I can't stop them from doing so, but in most cases it >>>>>>>> would be >>>>>>>> misleading. >>>>>>>> >>>>>>>> What we have done is to recognize that these are generally different >>>>>>>> service chains. Because the packets will get different treatments. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>>>>>>> >>>>>>>>> Joel, >>>>>>>>> >>>>>>>>> If you are asserting that SFC cannot be used in a manner that >>>>>>>>> has the problem I was trying to exemplify then I have to say, >>>>>>>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>>>>>>> is one of the examples cited in the arch draft, and there's >>>>>>>>> not much difference between that and email from the relevant >>>>>>>>> perspective. >>>>>>>>> >>>>>>>>> I also hope that I've succeeded in explaining the problem as >>>>>>>>> I see it. If not please ask and I'll try some more to clarify. >>>>>>>>> (Since you did not ask that, I assume you do get what I mean, >>>>>>>>> but it would be helpful if you would acknowledge that so we >>>>>>>>> can communicate more easily.) >>>>>>>>> >>>>>>>>> Can you point me at some piece of text in some draft that >>>>>>>>> ensures that this problem cannot occur? If not, (which I >>>>>>>>> think is the case), wouldn't we be better off acknowledging >>>>>>>>> that it is an issue and one that needs to be tackled as >>>>>>>>> best we can, as indeed Alia's earlier mail seems (to me) >>>>>>>>> to suggest? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> S. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>>>>>>> That case would not occur within a service chain. >>>>>>>>>> A service chain is about delivery of a packet to a series of >>>>>>>>>> services to >>>>>>>>>> which it is not addressed (generally followed by delivery to the >>>>>>>>>> target >>>>>>>>>> to which it is addressed.) >>>>>>>>>> An SMTP server relaying email produces separate packets. The >>>>>>>>>> packets >>>>>>>>>> from the user to the SMTP server are on one chain. The packets >>>>>>>>>> from >>>>>>>>>> that server to another are completely separate, and on a different >>>>>>>>>> chain. As such, those TLS SMTP packets between the servers would >>>>>>>>>> not >>>>>>>>>> have any metadata from the first transfer. >>>>>>>>>> >>>>>>>>>> Mail servers are not SFC service functions. The only time it gets >>>>>>>>>> close >>>>>>>>>> is when you are doing port 25 redirection, and then the service >>>>>>>>>> chain >>>>>>>>>> ends at the mail server. >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>>>>>>> IF A, B, and C are service function forwarders (SFF), with a TLS >>>>>>>>>>>> protected link for SFC, then the metadata will be protected. >>>>>>>>>>>> (Such a >>>>>>>>>>>> link would be a transport mechanism, which SFC does not >>>>>>>>>>>> describe or >>>>>>>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>>>>>>> >>>>>>>>>>> Ah, no the scenario I was thinking about is where, from >>>>>>>>>>> the perspective of SFC, the TLS packets are the payload >>>>>>>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>>>>>>> servers with starttls only turned on between B and C >>>>>>>>>>> because that link is "external" (though within the same >>>>>>>>>>> administrative domain). If some SFC thing at A were to >>>>>>>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>>>>>>> data then we wouldn't want that sent in clear from B to C >>>>>>>>>>> because of the SFC encapsulation, right? >>>>>>>>>>> >>>>>>>>>>> S. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If A, B, and C are service functions used by SFC, then there >>>>>>>>>>>> is no >>>>>>>>>>>> link >>>>>>>>>>>> between B and C, so it can't be protected by TLS. >>>>>>>>>>>> >>>>>>>>>>>> So I can not see what more needs to be said? >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>>>>>>> I am not sure what you mean by "Metadata that contains >>>>>>>>>>>>>> information >>>>>>>>>>>>>> that >>>>>>>>>>>>>> is protected in the data plane". Most of what ends up in the >>>>>>>>>>>>>> metadata >>>>>>>>>>>>>> is information that is passed on other interfaces directly to >>>>>>>>>>>>>> relevant >>>>>>>>>>>>>> functions, or locally determine and locally processed. >>>>>>>>>>>>> >>>>>>>>>>>>> So what I had in mind were things like the following. >>>>>>>>>>>>> >>>>>>>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>>>>>>> - B to C link is via say a TLS VPN >>>>>>>>>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>>>>>>>>> and not protected by the VPN >>>>>>>>>>>>> - That seems bad >>>>>>>>>>>>> >>>>>>>>>>>>> S. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The protection used for policy systems (which provide much of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> information) is based on the presence of persistent >>>>>>>>>>>>>> connections >>>>>>>>>>>>>> and >>>>>>>>>>>>>> usage which crosses domains. Are you arguing that if AAA is >>>>>>>>>>>>>> encrypted >>>>>>>>>>>>>> then policy delivered by AAA resulting in metadata in the >>>>>>>>>>>>>> packet >>>>>>>>>>>>>> must be >>>>>>>>>>>>>> encrypted in the data packets? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>> Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> When responding, please keep the subject line intact and >>>>>>>>>>>>>>> reply >>>>>>>>>>>>>>> to all >>>>>>>>>>>>>>> email addresses included in the To and CC lines. (Feel >>>>>>>>>>>>>>> free to >>>>>>>>>>>>>>> cut >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please refer to >>>>>>>>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>>>>>>> for more information about IESG DISCUSS and COMMENT >>>>>>>>>>>>>>> positions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The document, along with other ballot positions, can be found >>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> DISCUSS: >>>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (1) I note the charter calls for this deliverable to "provide >>>>>>>>>>>>>>> a description of... security models" The charter also >>>>>>>>>>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>>>>>>>>>> address the management and security implications when >>>>>>>>>>>>>>> documenting these deliverables." My conclusion is that this >>>>>>>>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>>>>>>>> analysis that the wg are suppoed to have carried out but that >>>>>>>>>>>>>>> it's currently too vague only saying that solutions need to >>>>>>>>>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>>>>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (2) Metadata that contains information that is protected in >>>>>>>>>>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>>>>>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>>>>>>>>>> not sure myself if "passed about" ought also include within a >>>>>>>>>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>>>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>>>>>>>> document needs to say that those services have to be >>>>>>>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - It occurs to me that it might really be better for the WG >>>>>>>>>>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>>>>>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>>>>>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>>>>>>>>>> result in the eventual RFC being a much more useful document. >>>>>>>>>>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>>>>>>>>>> vague and won't be very useful even in the medium term. But >>>>>>>>>>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>>>>>>>>>> to push this out, even if that might only give the appearance >>>>>>>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>>>>>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - The charter text describing this deliverable notes that >>>>>>>>>>>>>>> "The initial scope is restricted to a single administrative >>>>>>>>>>>>>>> domain, keeping in mind that architectural decisions made for >>>>>>>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>>>>>>>> single-domain elements of this architecture might impinge on >>>>>>>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>>>>>>>> goals. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Chains will require some representation, and re-ordering >>>>>>>>>>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>>>>>>>>>> for fun) therefore there must be a requirement for some data >>>>>>>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>>>>>>> authorisation decision function and therefore there must >>>>>>>>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>>>>>>>> producing entity of some kind that could be authenticated. >>>>>>>>>>>>>>> That is an example of the missing security analysis that >>>>>>>>>>>>>>> really is needed before this proceeds. (See my discuss point >>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>>>>>>>> networks are slightly incongrous. In the case of WiFi when do >>>>>>>>>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>>>>>>>>> mobile node transmitter?) I suspect you really mean the wired >>>>>>>>>>>>>>> bits of a mobile network so it might be better to say that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>>>>>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>>>>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>>>>>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>>>>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>>>>>>>>>> terms need to be defined. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>>>>>>>> partially ordered? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>>>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any kind of >>>>>>>>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>>>>>>>> reviews on the same telechat as this) so I'd also drop that. >>>>>>>>>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>>>>>>>>> reference (ideally an RFC). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Figure 1 caption is misleading. That seems to me to show a >>>>>>>>>>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>>>>>>>>>> the full graphs themselves. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>>>>>>>>>> the example given imply that all traffic (of what kind?) that >>>>>>>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>>>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>>>>>>>>> odder to me. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>>>>>>>>> architecture is to avoid such vagueness? If you mean that an >>>>>>>>>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>>>>>>>>> that would be the thing to do. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>>>>>>>>>> about not making security and privacy worse in general. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>>>>>>>>> traffic that congestion would be an issue? If so, should you >>>>>>>>>>>>>>> say rather that any transport that has some way of handling >>>>>>>>>>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>>>>>>>>>> fine. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From nobody Fri May 29 10:31:59 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25551A8798; Fri, 29 May 2015 10:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 801SOIoIOvBW; Fri, 29 May 2015 10:31:45 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0B41B2AD2; Fri, 29 May 2015 10:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=132007; q=dns/txt; s=iport; t=1432920287; x=1434129887; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sMVCZgN4t5IdKpYB2WMvwZlk36Qoc4qMEc3GLUUyz1A=; b=UnNVNu5ljqfPJMqStXWca7dUsdbvNbDY4HpVPvZuwnpF81p5rnk38dtP R4LBl7sND7ayTNZI4e/vHbH8xNwYxQNkThsIbbhdrfs2BYbORcQ5sC8CF kpNWX6CxG6tAy4nU4E2zER95MZrk3Cd+MVJnj6x9KcFumtyRB2yXVX/UJ Q=; X-Files: draft-ietf-sfc-architecture-09-from-8.diff.html, signature.asc : 107888, 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A4BAAHoGhV/5ldJa1SCoMQVFENBoMYuiJmCYFahXMCAgKBRzgUAQEBAQEBAYEKhBkJAQEBAwEaAQgEQBIFCwIBBgIDAQ4GKgICMhcOAgQOBQ4NiAoIDZQUnRmjewEBAQEBAQEBAQEBAQEBAQEBAQEBAReLQ4QhCARZB4JoL4EWAQSGa4wfghKBQ2CESoITgSkTK4Mzgn+LQINZI2GBBSQcFYE9b4EDQ4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,518,1427760000"; d="asc'?html'217?scan'217,208,217";a="154648253" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 29 May 2015 17:24:43 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4THOhGP017637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 17:24:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 29 May 2015 12:24:43 -0500 From: "Carlos Pignataro (cpignata)" To: "Benoit Claise (bclaise)" Thread-Topic: Benoit Claise's No Objection on draft-ietf-sfc-architecture-08: (with COMMENT) Thread-Index: AQHQmVTpxRaqH1qWLkSTH/C2kz7TNJ2R0lAAgAAwjQCAAVNuAIAAM4wA Date: Fri, 29 May 2015 17:24:42 +0000 Message-ID: <301FC39F-1B3E-4D3C-B012-B5EE980F4CE3@cisco.com> References: <20150528144454.10612.14109.idtracker@ietfa.amsl.com> <5568759A.4030104@cisco.com> In-Reply-To: <5568759A.4030104@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/signed; boundary="Apple-Mail=_2B41711D-9F19-4089-A554-54B5EC11D234"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Benoit Claise's No Objection on draft-ietf-sfc-architecture-08: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 17:31:58 -0000 --Apple-Mail=_2B41711D-9F19-4089-A554-54B5EC11D234 Content-Type: multipart/alternative; boundary="Apple-Mail=_814BB666-DF98-49FE-9598-36171F425DF2" --Apple-Mail=_814BB666-DF98-49FE-9598-36171F425DF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Benoit, Thanks for the follow-up and trimming down the set of comments. Please = see inline. > On May 29, 2015, at 10:20 AM, Benoit Claise (bclaise) = wrote: >=20 > Thanks Carlos for the detailed answer. > I remove all points we agree with. > See in line. >> Hi Benoit, >>=20 >> Many thanks again for your review =E2=80=94 let me also reply to your = COMMENTs point-by-point below, to make sure we are on the same page. >>=20 >>=20 >>>>=20 >>>>=20 >>>> - Service Function Path definition: I'm confused. you don't explain = what >>>> it is, but only explain why you need it. >>=20 >> The definition of SFP took quite significant crafting and wording, = and WG cycles. It is correct, yet a bit complex. > I didn't assert the definition was not correct. I wrote "I'm = confused", because, even after reading it multiple times, I can't make = the link between the different concepts: SFP, SFC, RSP. Understood. I did not asset you asserted it was not correct :-) I was = merely acknowledging that it was not an easy read, but stating that it = was correct despite it being complex. Regarding the link between SFC, SFP, and RSP, please see below. >>=20 >>=20 >>>> Later on, I see "As an example of such an intermediate specificity, = there >>>> may be two >>>> SFPs associated with a given SFC". I'm confused. >>>> Not too clear on how the SFP and RSP relate to each others. >>>> Is the Service Function Path the ordered list of SFs, while the RSP = is >>>> the ordered list of SFFs? >>=20 >> The SFC is an ordered set of abstract functions =E2=80=94 e.g., =E2=80=9C= a firewall=E2=80=9D. An SFP applies (policy, service function, etc) = constrains as e.g., =E2=80=9Cthis firewall=E2=80=9D, or =E2=80=9Cthis = firewall via this SFF =E2=80=A6=E2=80=9D; as detailed in Section 2.3, = SFPs do not have a requirement of full specificity. SFPs can have = varying degrees of specificity (from fully specified SFFs and SFs to = reach that SF and there=E2=80=99s degree of freedom over which SFFs to = use). Lastly, an RSP is the fully specified set of SFFs and SFs actually = visited. In other words, from less specified to fully specified: SFC -> = SFP -> RSP. > Ah, now that makes sense (at least to me) > With that in mind, I reviewed the definitions and section 2.3, and = here are my conclusions. >=20 > 1. I found the Service Function Path definition in the RSP definition: > "The Service Function Path is a > constrained specification of where packets assigned to a = certain > service function path must go. While it may be so constrained > as to identify the exact locations, it can also be less > specific. > These sentences should be the first sentences of the Service Function = Path definition. >=20 Sure =E2=80=94 moved text around a bit. > 2. This example below must be mentioned in the draft > The SFC is an ordered set of abstract functions =E2=80=94 e.g., =E2=80=9C= a firewall=E2=80=9D. An SFP applies (policy, service function, etc) = constrains as e.g., =E2=80=9Cthis firewall=E2=80=9D, or =E2=80=9Cthis = firewall via this SFF =E2=80=A6=E2=80=9D; as detailed in Section 2.3, = SFPs do not have a requirement of full specificity. SFPs can have = varying degrees of specificity (from fully specified SFFs and SFs to = reach that SF and there=E2=80=99s degree of freedom over which SFFs to = use). Lastly, an RSP is the fully specified set of SFFs and SFs actually = visited. In other words, from less specified to fully specified: SFC -> = SFP -> RSP. > Potentially in Section 2.3. If yes, section 2.3 should be called = "Service Function Paths and RSP" > Alternatively in a section 2.4 Ack =E2=80=94 instead, we are adding a Section 2.3.1 (since it is = separate, but within context of S2.3). Joel and I crafter some text, here=E2=80=99s the proposal (and see = attached diffs).
As an example of this progressive refinement, consider a service = function chain (SFC) which states that packets using this chain should = be delivered to a firewall and a caching engine.A Service Function Path (SFP) could refine this, considering that this = architecture does not mandate the degree of specificity an SFP has to = have. It might specify that the firewall and caching engine are both to = be in a specific Data Center (e.g., in DC1), or it might specify exactly = which instance of each firewall and chaching engine is to be used.The Rendered Service Path (RSP) is the actual sequence of SFFs and SFs = that the packets will actually visit. So if the SFP picked the DC, the = RSP would be more specific.
>=20 >>=20 >>=20 >>>>=20 >>>> - >>>> "Traffic from SFs eventually returns to the same SFF, which is >>>> responsible for injecting traffic back onto the network. >>>>=20 >>>> Am I correct that it only applies in case of a SFC proxy? >>=20 >> Please note also that SFFs and SFs are architectural functional = blocks, and an IPS might include both functions. > I completely missed that from the draft. Where is it explained or how = have you improved the draft? > I had in mind this use case : SFF =3D switch, SF =3D attached = appliance. OK, clarifying text at the beginning of Section 4 =E2=80=94 please see = attached diffs FYI. >>=20 >>>> Related question, along the same lines: >>>>=20 >>>> 1. SFP forwarding : Traffic arrives at an SFF from the = network. >>>> The >>>> SFF determines the appropriate SF the traffic should be = forwarded >>>> to via information contained in the SFC encapsulation. = Post-SF, >>>> the traffic is returned to the SFF, and, if needed, is = forwarded >>>> to another SF associated with that SFF. If there is another = non- >>>> local (i.e., different SFF) hop in the SFP, the SFF further >>>> encapsulates the traffic in the appropriate network transport >>>> protocol and delivers it to the network for delivery to the = next >>>> SFF along the path. >>>>=20 >>>> Returned to the initial SFF, or to the next SFF in the RSP? >>>> I guess the next SFF in the chain (again, unless we speak about a = proxy) >>=20 >> Not about proxy. Traffic returns from the SF to the SFF that sent it = to that SF. =46rom that SFF, it can go to another SF or to another SFF = -> SF. >>=20 >> To exemplify (what I believe might be the confusion), if a classifier = sends traffic to a firewall, traffic does not return to the classifier. = After the firewall SF is applied, it returns to the functional SFF. > Understood now. I'll look at the diff. If you have them now, please = forward. Sure =E2=80=94 see attached, noting that these include all the edits = thus far since -08, a super-set of the ones from your comments. If you still believe there are issues unadressed, please provide a = specific textual proposal to understand what might be missing. Thanks, =E2=80=94 Carlos. >>=20 >>=20 > Thanks and regards, Benoit --Apple-Mail=_814BB666-DF98-49FE-9598-36171F425DF2 Content-Type: multipart/mixed; boundary="Apple-Mail=_6DEFF6B9-A432-4CCC-931A-FECCFD5E3DED" --Apple-Mail=_6DEFF6B9-A432-4CCC-931A-FECCFD5E3DED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Benoit,

Thanks for the follow-up and trimming down the set of = comments. Please see inline.

On = May 29, 2015, at 10:20 AM, Benoit Claise (bclaise) <bclaise@cisco.com> = wrote:

=20
Thanks Carlos for the detailed = answer.
I remove all points we agree with.
See in line.
=20 Hi Benoit,

Many thanks again for your review =E2=80=94 let me = also reply to your COMMENTs point-by-point below, to make sure we are on the same page.




- Service Function Path definition: I'm confused. you don't explain what
it is, but only explain why you need it.

The definition of SFP took quite significant = crafting and wording, and WG cycles. It is correct, yet a bit = complex.
I didn't assert the definition was not correct. I wrote "I'm confused", because, even after reading it multiple times, I can't make the link between the different concepts: SFP, SFC, RSP.

Understood. I did not asset you asserted it was = not correct :-) I was merely acknowledging that it was not an easy read, = but stating that it was correct despite it being complex.

Regarding the link between SFC, SFP, and RSP, = please see below.



Later on, I see "As = an example of such an intermediate specificity, there
may be two
SFPs associated with a given SFC". I'm confused.
Not too clear on how the SFP and RSP relate to each others.
Is the Service Function Path the ordered list of SFs, while the RSP is
the ordered list of SFFs?

The SFC is an ordered set of abstract = functions =E2=80=94 e.g., =E2=80=9Ca firewall=E2=80=9D. An SFP applies (policy, = service function, etc) constrains as e.g., =E2=80=9Cthis firewall=E2=80=9D, or = =E2=80=9Cthis firewall via this SFF =E2=80=A6=E2=80=9D; as detailed in Section 2.3, = SFPs do not have a requirement of full specificity. SFPs can have varying degrees of specificity (from fully specified SFFs and SFs to reach that SF and there=E2=80=99s degree of freedom over = which SFFs to use). Lastly, an RSP is the fully specified set of SFFs and SFs actually visited. In other words, from less specified to fully specified: SFC -> SFP -> RSP.
Ah, now that makes sense (at least to me)
With that in mind, I reviewed the definitions and section 2.3, and here are my conclusions.

1. I found the Service Function Path definition in the RSP definition:
	"The Service Function Path is a
        constrained specification of where packets assigned to a certain
        service function path must go.  While it may be so constrained
        as to identify the exact locations, it can also be less
        specific.
These sentences should be the first sentences of the Service Function Path definition.


Sure =E2=80=94 moved text around a bit.

2. This example below must be mentioned in the draft
The SFC is an ordered set of abstract = functions =E2=80=94 e.g., =E2=80=9Ca firewall=E2=80=9D. An SFP applies (policy, service = function, etc) constrains as e.g., =E2=80=9Cthis firewall=E2=80=9D, or =E2=80=9Cthi= s firewall via this SFF =E2=80=A6=E2=80=9D; as detailed in Section 2.3, SFPs do not = have a requirement of full specificity. SFPs can have varying degrees of specificity (from fully specified SFFs and SFs to reach that SF and there=E2=80=99= s degree of freedom over which SFFs to use). Lastly, an RSP is the fully specified set of SFFs and SFs actually visited. In other words, from less specified to fully specified: SFC -> SFP -> RSP.
Potentially in Section 2.3. If yes, section 2.3 should be called "Service Function Paths and RSP"
Alternatively in a section 2.4

Ack = =E2=80=94 instead, we are adding a Section 2.3.1 (since it is separate, = but within context of S2.3).

Joel = and I crafter some text, here=E2=80=99s the proposal (and see attached = diffs).

<?xml = version=3D"1.0"?>
<section
title=3D"Service = Function Chains, Service Function Paths, and Rendered Service = Path"
><t
>As an example of this = progressive refinement, consider a service function chain (SFC) which = states that packets using this chain should be delivered to a firewall = and a caching engine.</t
><t
>A Service = Function Path (SFP) could refine this, considering that this = architecture does not mandate the degree of specificity an SFP has to = have. It might specify that the firewall and caching engine are both to = be in a specific Data Center (e.g., in DC1), or it might specify exactly = which instance of each firewall and chaching engine is to be = used.</t
><t
>The Rendered Service Path = (RSP) is the actual sequence of SFFs and SFs that the packets will = actually visit. So if the SFP picked the DC, the RSP would be more = specific.</t
></section
>






-
"Traffic from SFs eventually returns to the same SFF, which is
responsible for injecting traffic back onto the = network.

Am I correct that it only applies in case of a SFC proxy?

Please note also that SFFs and SFs are = architectural functional blocks, and an IPS might include both = functions.
I completely missed that from the draft. Where is it explained or how have you improved the draft?
I had in mind this use case : SFF =3D switch, SF =3D attached = appliance.

OK, clarifying text at the beginning of Section 4 = =E2=80=94 please see attached diffs FYI.


Related question, = along the same lines:

     1.  SFP forwarding : = Traffic arrives at an SFF from the network.
The
     SFF determines the = appropriate SF the traffic should be forwarded
     to via information = contained in the SFC encapsulation.  Post-SF,
     the traffic is returned to = the SFF, and, if needed, is forwarded
     to another SF associated = with that SFF.  If there is another non-
     local (i.e., different = SFF) hop in the SFP, the SFF further
     encapsulates the traffic = in the appropriate network transport
     protocol and delivers it = to the network for delivery to the next
     SFF along the path.

Returned to the initial SFF, or to the next SFF in the RSP?
I guess the next SFF in the chain (again, unless we speak about a proxy)

Not about proxy. Traffic returns from the SF = to the SFF that sent it to that SF. =46rom that SFF, it can go to = another SF or to another SFF -> SF.

To exemplify (what I believe might be the = confusion), if a classifier sends traffic to a firewall, traffic does not return to the classifier. After the firewall SF is applied, it returns to the functional SFF.
Understood now. I'll look at the diff. If you have them now, please forward.

Sure =E2=80=94 see attached, noting that these = include all the edits thus far since -08, a super-set of the ones from = your comments.

If you still believe = there are issues unadressed, please provide a specific textual proposal = to understand what might be missing.

Thanks,

=E2=80=94= Carlos.


= --Apple-Mail=_6DEFF6B9-A432-4CCC-931A-FECCFD5E3DED Content-Disposition: attachment; filename=draft-ietf-sfc-architecture-09-from-8.diff.html Content-Type: text/html; name="draft-ietf-sfc-architecture-09-from-8.diff.html" Content-Transfer-Encoding: 7bit Diff: draft-ietf-sfc-architecture-08.txt - draft-ietf-sfc-architecture-09.txt
 draft-ietf-sfc-architecture-08.txt   draft-ietf-sfc-architecture-09.txt 
Network Working Group J. Halpern, Ed. Network Working Group J. Halpern, Ed.
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational C. Pignataro, Ed. Intended status: Informational C. Pignataro, Ed.
Expires: November 12, 2015 Cisco Expires: November 30, 2015 Cisco
May 11, 2015 May 29, 2015
Service Function Chaining (SFC) Architecture Service Function Chaining (SFC) Architecture
draft-ietf-sfc-architecture-08 draft-ietf-sfc-architecture-09
Abstract Abstract
This document describes an architecture for the specification, This document describes an architecture for the specification,
creation, and ongoing maintenance of Service Function Chains (SFC) in creation, and ongoing maintenance of Service Function Chains (SFC) in
a network. It includes architectural concepts, principles, and a network. It includes architectural concepts, principles, and
components used in the construction of composite services through components used in the construction of composite services through
deployment of SFCs, with a focus on those to be standardized in the deployment of SFCs, with a focus on those to be standardized in the
IETF. This document does not propose solutions, protocols, or IETF. This document does not propose solutions, protocols, or
extensions to existing protocols. extensions to existing protocols.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2015. This Internet-Draft will expire on November 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 1.3. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 6 2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 7
2.1. Service Function Chains . . . . . . . . . . . . . . . . . 7 2.1. Service Function Chains . . . . . . . . . . . . . . . . . 7
2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 8 2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 8
2.3. Service Function Paths . . . . . . . . . . . . . . . . . 9 2.3. Service Function Paths . . . . . . . . . . . . . . . . . 9
3. Architecture Principles . . . . . . . . . . . . . . . . . . . 10 2.3.1. Service Function Chains, Service Function Paths, and
4. Core SFC Architecture Components . . . . . . . . . . . . . . 11 Rendered Service Path . . . . . . . . . . . . . . . . 10
4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 12 3. Architecture Principles . . . . . . . . . . . . . . . . . . . 11
4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 13 4. Core SFC Architecture Components . . . . . . . . . . . . . . 12
4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 13 4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 13
4.3.1. Transport Derived SFF . . . . . . . . . . . . . . . . 15 4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 14
4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 15 4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 14
4.5. Network Overlay and Network Components . . . . . . . . . 15 4.3.1. Transport Derived SFF . . . . . . . . . . . . . . . . 16
4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 16
4.7. Classification . . . . . . . . . . . . . . . . . . . . . 17 4.5. Network Overlay and Network Components . . . . . . . . . 16
4.8. Re-Classification and Branching . . . . . . . . . . . . . 17 4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 17
4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 18 4.7. Classification . . . . . . . . . . . . . . . . . . . . . 18
5. Additional Architectural Concepts . . . . . . . . . . . . . . 18 4.8. Re-Classification and Branching . . . . . . . . . . . . . 18
5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 18 4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 19
5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 19 5. Additional Architectural Concepts . . . . . . . . . . . . . . 19
5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 20 5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 19
5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 20 5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 20
5.5. Load Balancing Considerations . . . . . . . . . . . . . . 21 5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 21
5.6. MTU and Fragmentation Considerations . . . . . . . . . . 22 5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 21
5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.5. Load Balancing Considerations . . . . . . . . . . . . . . 22
5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 24 5.6. MTU and Fragmentation Considerations . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Contributors and Acknowledgments . . . . . . . . . . . . . . 25 5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Informative References . . . . . . . . . . . . . . . . . . . 27 7. Contributors and Acknowledgments . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The delivery of end-to-end services often requires various service The delivery of end-to-end services often requires various service
functions. These include traditional network service functions such functions. These include traditional network service functions such
as firewalls and traditional IP Network Address Translators (NATs), as firewalls and traditional IP Network Address Translators (NATs),
as well as application-specific functions. The definition and as well as application-specific functions. The definition and
instantiation of an ordered set of service functions and subsequent instantiation of an ordered set of service functions and subsequent
'steering' of traffic through them is termed Service Function 'steering' of traffic through them is termed Service Function
Chaining (SFC). Chaining (SFC).
skipping to change at page 3, line 31 skipping to change at page 3, line 33
coupled to network topology and physical resources, greatly reducing coupled to network topology and physical resources, greatly reducing
or eliminating the ability of an operator to introduce new services or eliminating the ability of an operator to introduce new services
or dynamically create service function chains. This architecture or dynamically create service function chains. This architecture
presents a model addressing the problematic aspects of existing presents a model addressing the problematic aspects of existing
service deployments, including topological independence and service deployments, including topological independence and
configuration complexity. configuration complexity.
1.1. Scope 1.1. Scope
This document defines the architecture for Service Function Chaining This document defines the architecture for Service Function Chaining
(SFC) with minimum requirements on the physical topology of the (SFC) as standardized in the IETF. The SFC architecture is
network, as standardized in the IETF. In this architecture packets predicated on topological independence from the underlying forwarding
are classified on ingress for handling by the required set of Service topology.
Functions (SFs) in the SFC-enabled domain and are then forwarded
through that set of functions for processing by each function in In this architecture packets are classified on ingress for handling
turn. Packets may be re-classified as a result of this processing. by the required set of Service Functions (SFs) in the SFC-enabled
domain and are then forwarded through that set of functions for
processing by each function in turn. Packets may be re-classified as
a result of this processing.
The architecture described in this document is independent of the The architecture described in this document is independent of the
planned usage of the network and deployment context and thus, for planned usage of the network and deployment context and thus, for
example, is applicable to both fixed and mobile networks as well as example, is applicable to both fixed and mobile networks as well as
being useful in many Data Center applications. being useful in many Data Center applications.
The architecture described herein is assumed to be applicable to a The architecture described herein is assumed to be applicable to a
single network administrative domain. While it is possible for the single network administrative domain. While it is possible for the
architectural principles and components to be applied to inter-domain architectural principles and components to be applied to inter-domain
SFCs, these are left for future study. SFCs, these are left for future study.
skipping to change at page 4, line 29 skipping to change at page 4, line 29
of SFs that needs to be applied to deliver a given service is of SFs that needs to be applied to deliver a given service is
specific to each administrative entity. specific to each administrative entity.
o The chaining of SFs and the criteria to invoke them are specific o The chaining of SFs and the criteria to invoke them are specific
to each administrative entity that operates an SF-enabled domain. to each administrative entity that operates an SF-enabled domain.
o Several SF chaining policies can be simultaneously applied within o Several SF chaining policies can be simultaneously applied within
an administrative domain to meet various business requirements. an administrative domain to meet various business requirements.
o The underlay is assumed to provide the necessary connectivity to o The underlay is assumed to provide the necessary connectivity to
interconnect the SFFs, but the architecture places no constraints interconnect the Service Function Forwarders (SFFs, see
on how that connectivity is realized other than it have the Section 1.3), but the architecture places no constraints on how
required bandwidth, latency, and jitter to support the SFC. that connectivity is realized other than it have the required
bandwidth, latency, and jitter to support the SFC.
o No assumption is made on how FIBs and RIBs of involved nodes are o No assumption is made on how Forwarding Information Bases (FIBs)
and Routing Information Bases (RIBs) of involved nodes are
populated. populated.
o How to bind traffic to a given SF chain is policy-based. o How to bind traffic to a given SF chain is policy-based.
1.3. Definition of Terms 1.3. Definition of Terms
Network Service: An offering provided by an operator that is Network Service: An offering provided by an operator that is
delivered using one or more service functions. This may also be delivered using one or more service functions. This may also be
referred to as a composite service. The term "service" is used referred to as a composite service. The term "service" is used
to denote a "network service" in the context of this document. to denote a "network service" in the context of this document.
skipping to change at page 6, line 10 skipping to change at page 6, line 12
service functions according to information carried in the SFC service functions according to information carried in the SFC
encapsulation, as well as handling traffic coming back from the encapsulation, as well as handling traffic coming back from the
SF. Additionally, a service function forwarder is responsible SF. Additionally, a service function forwarder is responsible
for delivering traffic to a classifier when needed and for delivering traffic to a classifier when needed and
supported, transporting traffic to another SFF (in the same or supported, transporting traffic to another SFF (in the same or
different type of overlay), and terminating the SFP. different type of overlay), and terminating the SFP.
Metadata: provides the ability to exchange context information Metadata: provides the ability to exchange context information
between classifiers and SFs and among SFs. between classifiers and SFs and among SFs.
Service Function Path (SFP): The SFP provides a level of indirection Service Function Path (SFP): The Service Function Path is a
between the fully abstract notion of service chain as a sequence constrained specification of where packets assigned to a certain
of abstract service functions to be delivered, and the fully service function path must go. While it may be so constrained
specified notion of exactly which SFF/SFs the packet will visit as to identify the exact locations, it can also be less
when it actually traverses the network. By allowing the control specific. The SFP provides a level of indirection between the
fully abstract notion of service chain as a sequence of abstract
service functions to be delivered, and the fully specified
notion of exactly which SFF/SFs the packet will visit when it
actually traverses the network. By allowing the control
components to specify this level of indirection, the operator components to specify this level of indirection, the operator
may control the degree of SFF/SF selection authority that is may control the degree of SFF/SF selection authority that is
delegated to the network. delegated to the network.
SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP
identification, and is used by the SFC-aware functions, such as identification, and is used by the SFC-aware functions, such as
the SFF and SFC-aware SFs. The SFC Encapsulation is not used the SFF and SFC-aware SFs. The SFC Encapsulation is not used
for network packet forwarding. In addition to SFP for network packet forwarding. In addition to SFP
identification, the SFC encapsulation carries metadata including identification, the SFC encapsulation carries metadata including
data plane context information. data plane context information.
Rendered Service Path (RSP): The Service Function Path is a Rendered Service Path (RSP): WIthin an SFP, packets themselves are
constrained specification of where packets assigned to a certain of course transmitted from and to specific places in the
service function path must go. While it may be so constrained network, visiting a specific sequence of SFFs and SFs. This
as to identify the exact locations, it can also be less sequence of actual visits by a packet to specific SFFs and SFs
specific. Packets themselves are of course transmitted from and in the network is known as the Rendered Service Path (RSP).
to specific places in the network, visiting a specific sequence This definition is included here for use by later documents,
of SFFs and SFs. This sequence of actual visits by a packet to such as when solutions may need to discuss the actual sequence
specific SFFs and SFs in the network is known as the Rendered of locations the packets visit.
Service Path (RSP). This definition is included here for use by
later documents, such as when solutions may need to discuss the
actual sequence of locations the packets visit.
SFC-enabled Domain: A network or region of a network that implements SFC-enabled Domain: A network or region of a network that implements
SFC. An SFC-enabled Domain is limited to a single network SFC. An SFC-enabled Domain is limited to a single network
administrative domain. administrative domain.
SFC Proxy: Removes and inserts SFC encapsulation on behalf of an SFC Proxy: Removes and inserts SFC Encapsulation on behalf of an
SFC-unaware service function. SFC proxies are logical elements. SFC-unaware service function. SFC proxies are logical elements.
2. Architectural Concepts 2. Architectural Concepts
The following sections describe the foundational concepts of service The following sections describe the foundational concepts of service
function chaining and the SFC architecture. function chaining and the SFC architecture.
Service Function Chaining enables the creation of composite (network) Service Function Chaining enables the creation of composite (network)
services that consist of an ordered set of Service Functions (SF) services that consist of an ordered set of Service Functions (SF)
that must be applied to packets and/or frames and/or flows selected that must be applied to packets and/or frames and/or flows selected
skipping to change at page 7, line 32 skipping to change at page 7, line 40
(SFs) can be part of zero, one, or many SFCs. A given graph node (SFs) can be part of zero, one, or many SFCs. A given graph node
(SF) can appear one time or multiple times in a given SFC. (SF) can appear one time or multiple times in a given SFC.
SFCs can start from the origination point of the service function SFCs can start from the origination point of the service function
graph (i.e., node 1 in Figure 1), or from any subsequent node in the graph (i.e., node 1 in Figure 1), or from any subsequent node in the
graph. As shown, SFs may therefore become branching nodes in the graph. As shown, SFs may therefore become branching nodes in the
graph, with those SFs selecting edges that move traffic to one or graph, with those SFs selecting edges that move traffic to one or
more branches. The top and middle graphs depict such a case, where a more branches. The top and middle graphs depict such a case, where a
second classification event occurs after node 2, and a new graph is second classification event occurs after node 2, and a new graph is
selected (i.e., node 3 instead of node 6). The bottom graph selected (i.e., node 3 instead of node 6). The bottom graph
highlights the the concept of a cycle, in which a given SF (e.g., highlights the concept of a cycle, in which a given SF (e.g., node 7
node 7 in the depiction) can be visited more than once within a given in the depiction) can be visited more than once within a given
service chain. An SFC can have more than one terminus. service chain. An SFC can have more than one terminus.
,-+-. ,---. ,---. ,---. ,-+-. ,---. ,---. ,---.
/ \ / \ / \ / \ / \ / \ / \ / \
( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) ( 1 )+--->( 2 )+---->( 6 )+---->( 8 )
\ / \ / \ / \ / \ / \ / \ / \ /
`---' `---' `---' `---' `---' `---' `---' `---'
,-+-. ,---. ,---. ,---. ,---. ,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \ / \ / \ / \ / \ / \
skipping to change at page 10, line 33 skipping to change at page 10, line 33
properly perform its job. Implementation details of such mechanisms properly perform its job. Implementation details of such mechanisms
are considered out of scope for this document, and can include a are considered out of scope for this document, and can include a
spectrum of methods: for example situations including all next-hops spectrum of methods: for example situations including all next-hops
explicitly, others where a list of possible next-hops is provided and explicitly, others where a list of possible next-hops is provided and
the selection is local, or cases with just an identifier, where all the selection is local, or cases with just an identifier, where all
resolution is local. resolution is local.
This architecture also allows the same SF to be part of multiple This architecture also allows the same SF to be part of multiple
SFPs. SFPs.
2.3.1. Service Function Chains, Service Function Paths, and Rendered
Service Path
As an example of this progressive refinement, consider a service
function chain (SFC) which states that packets using this chain
should be delivered to a firewall and a caching engine.
A Service Function Path (SFP) could refine this, considering that
this architecture does not mandate the degree of specificity an SFP
has to have. It might specify that the firewall and caching engine
are both to be in a specific Data Center (e.g., in DC1), or it might
specify exactly which instance of each firewall and chaching engine
is to be used.
The Rendered Service Path (RSP) is the actual sequence of SFFs and
SFs that the packets will actually visit. So if the SFP picked the
DC, the RSP would be more specific.
3. Architecture Principles 3. Architecture Principles
Service function chaining is predicated on several key architectural Service function chaining is predicated on several key architectural
principles: principles:
1. Topological independence: no changes to the underlay network 1. Topological independence: no changes to the underlay network
forwarding topology - implicit, or explicit - are needed to forwarding topology - implicit, or explicit - are needed to
deploy and invoke SFs or SFCs. deploy and invoke SFs or SFCs.
2. Plane separation: dynamic realization of SFPs is separated from 2. Plane separation: dynamic realization of SFPs is separated from
skipping to change at page 11, line 38 skipping to change at page 12, line 9
or deletion of an SFC has no impact on other SFCs. The same is or deletion of an SFC has no impact on other SFCs. The same is
true for SFPs. true for SFPs.
7. Heterogeneous control/policy points: The architecture allows SFs 7. Heterogeneous control/policy points: The architecture allows SFs
to use independent mechanisms (out of scope for this document) to to use independent mechanisms (out of scope for this document) to
populate and resolve local policy and (if needed) local populate and resolve local policy and (if needed) local
classification criteria. classification criteria.
4. Core SFC Architecture Components 4. Core SFC Architecture Components
At a very high level, the logical architecture of an SFC-enabled The SFC Architecture is built out of architectural building blocks
Domain comprises: which are logical components; these logical components are
classifiers, service function forwarders (SFF), the service functions
themselves (SF), and SFC-proxies. They are interconnected using the
SFC Encapsulation. This results in a high level logical architecture
of an SFC-enabled Domain which comprises:
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. +--------------+ +------------------~~~ . +--------------+ +------------------~~~
. | Service | SFC | Service +---+ +---+ . | Service | SFC | Service +---+ +---+
. |Classification| Encapsulation | Function |sf1|...|sfn| . |Classification| Encapsulation | Function |sf1|...|sfn|
+---->| Function |+---------------->| Path +---+ +---+ +---->| Function |+---------------->| Path +---+ +---+
. +--------------+ +------------------~~~ . +--------------+ +------------------~~~
. SFC-enabled Domain . SFC-enabled Domain
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
skipping to change at page 15, line 47 skipping to change at page 16, line 43
required to remove any information specific to the SFC Domain, required to remove any information specific to the SFC Domain,
typically the SFC Encapsulation. Further, from a privacy typically the SFC Encapsulation. Further, from a privacy
perspective, an SFC Egress Node is required to ensure that any perspective, an SFC Egress Node is required to ensure that any
sensitive information added as part of SFC gets removed. In this sensitive information added as part of SFC gets removed. In this
context, information may be sensitive due to network concerns or end- context, information may be sensitive due to network concerns or end-
customer concerns. An SFC Ingress Node denotes an SFC Boundary Node customer concerns. An SFC Ingress Node denotes an SFC Boundary Node
that handles traffic entering the SFC-enabled domain. In most that handles traffic entering the SFC-enabled domain. In most
solutions and deployments this will need to include a classifier, and solutions and deployments this will need to include a classifier, and
will be responsible for adding the SFC encapsulation to the packet. will be responsible for adding the SFC encapsulation to the packet.
An SFC Proxy and corresponding SFC-unaware Service Function (see
Figure 3) are inside the SFC-enabled domain.
4.5. Network Overlay and Network Components 4.5. Network Overlay and Network Components
Underneath the SFF there are components responsible for performing Underneath the SFF there are components responsible for performing
the transport (overlay) forwarding. They do not consult the SFC the transport (overlay) forwarding. They do not consult the SFC
encapsulation or inner payload for performing this forwarding. They encapsulation or inner payload for performing this forwarding. They
only consult the outer-transport encapsulation for the transport only consult the outer-transport encapsulation for the transport
(overlay) forwarding. (overlay) forwarding.
4.6. SFC Proxy 4.6. SFC Proxy
skipping to change at page 19, line 27 skipping to change at page 20, line 24
The offering of service chains to customers, and the selection of The offering of service chains to customers, and the selection of
which service chain a customer wishes to use, are driven by a which service chain a customer wishes to use, are driven by a
combination of operator and customer policies using appropriate combination of operator and customer policies using appropriate
portals in conjunction with the OSS and BSS tools. These selections portals in conjunction with the OSS and BSS tools. These selections
then drive the service chaining control logic, which in turn then drive the service chaining control logic, which in turn
establishes the appropriate packet classification rules. establishes the appropriate packet classification rules.
5.2. SFC Control Plane 5.2. SFC Control Plane
This is part of the overall architecture but outside the scope of The SFC Control Plane is part of the overall SFC architecture, and
this section describes its high-level functions. However, the
detailed definition of the SFC Control Plane is outside the scope of
this document. this document.
The SFC control plane is responsible for constructing SFPs, The SFC control plane is responsible for constructing SFPs,
translating SFCs to forwarding paths and propagating path information translating SFCs to forwarding paths and propagating path information
to participating nodes to achieve requisite forwarding behavior to to participating nodes to achieve requisite forwarding behavior to
construct the service overlay. For instance, an SFC construction may construct the service overlay. For instance, an SFC construction may
be static; selecting exactly which SFFs and which SFs from those SFFs be static; selecting exactly which SFFs and which SFs from those SFFs
are to be used, or it may be dynamic, allowing the network to perform are to be used, or it may be dynamic, allowing the network to perform
some or all of the choices of SFF or SF to use to deliver the some or all of the choices of SFF or SF to use to deliver the
selected service chain within the constraints represented by the selected service chain within the constraints represented by the
skipping to change at page 24, line 39 skipping to change at page 25, line 39
Similarly, operational requirements imply resilience in the face of Similarly, operational requirements imply resilience in the face of
load changes. While mechanisms for managing (e.g., monitoring, load changes. While mechanisms for managing (e.g., monitoring,
instantiating, loading images, providing configuration to service instantiating, loading images, providing configuration to service
function chaining control, deleting, etc.) virtual machines are out function chaining control, deleting, etc.) virtual machines are out
of scope for this architecture, solutions can and are aided by of scope for this architecture, solutions can and are aided by
describing how they can make use of scaling mechanisms. describing how they can make use of scaling mechanisms.
6. Security Considerations 6. Security Considerations
The architecture described here is different from the current model,
and moving to the new model could lead to different security
arrangements and modeling. In the SFC architecture, a relatively
static topologically-dependent deployment model is replaced with the
chaining of sets of service functions. This can change the flow of
data through the network, and the security and privacy considerations
of the protocol and deployment will need to be reevaluated in light
of the new model.
Security considerations apply to the realization of this Security considerations apply to the realization of this
architecture, in particular to the documents that will define architecture, in particular to the documents that will define
protocols. Such realization ought to provide means to protect protocols. Such realization ought to provide means to protect
against security and privacy attacks in the areas hereby described. against security and privacy attacks in the areas hereby described.
Following the categorization of [RFC7498], we can largely divide the Building from the categorization of [RFC7498], we can largely divide
security consdierations in three areas: the security considerations in four areas:
Service Overlay: Underneath the Service Function Forwarders, the Service Overlay: Underneath the Service Function Forwarders, the
components that are responsible for performing the transport components that are responsible for performing the transport
forwarding consult the outer-transport encapsulation for forwarding consult the outer-transport encapsulation for
underlay forwarding. Used transport mechanisms should satisfy underlay forwarding. Used transport mechanisms should satisfy
the security requirements of the specific SFC deployment. These the security requirements of the specific SFC deployment. These
requirements typically include varying degrees of traffic requirements typically include varying degrees of traffic
separation, protection against different attacks (e.g., separation, protection against different attacks (e.g.,
spoofing, man-in-the-middle, brute-force, or insertion attacks), spoofing, man-in-the-middle, brute-force, or insertion attacks),
and can also include authenticity and integrity checking, and/or and can also include authenticity and integrity checking, and/or
confidentiality provisions. confidentiality provisions, for both the network overlay
transport and traffic it encapsulates.
Classification: Specific requirements may need to be enforced at the Boundaries: Specific requirements may need to be enforced at the
boundaries of an SFC-enabled domain. These include, for boundaries of an SFC-enabled domain. These include, for
example, to avoid leaking SFC information, and to protect its example, to avoid leaking SFC information, and to protect its
borders against various forms of attacks, including DDoS borders against various forms of attacks, including DDoS
attacks. Classification is used at the ingress edge of an SFC- attacks.
enabled domain. Policy for this classification is done using a
plurality of methods. Whatever method is used needs to consider Classification: Classification is used at the ingress edge of an
a range of security issues. These include appropriate SFC-enabled domain. Policy for this classification is done
using a plurality of methods. Whatever method is used needs to
consider a range of security issues. These include appropriate
authentication and authorization of classification policy, authentication and authorization of classification policy,
potential confidentiality issues of that policy, protection potential confidentiality issues of that policy, protection
against corruption, and proper application of policy with needed against corruption, and proper application of policy with needed
segregation of application. This includes proper controls on segregation of application. This includes proper controls on
the policies which drive the application of the SFC the policies which drive the application of the SFC
Encapsulation and associated metadata to packets. Similar Encapsulation and associated metadata to packets. Similar
issues need to be addressed if classification is performed issues need to be addressed if classification is performed
within a service chaining domain, i.e., re-classification. within a service chaining domain, i.e., re-classification.
SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP
 End of changes. 21 change blocks. 
71 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/
--Apple-Mail=_6DEFF6B9-A432-4CCC-931A-FECCFD5E3DED Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii



Thanks and regards, Benoit

--Apple-Mail=_6DEFF6B9-A432-4CCC-931A-FECCFD5E3DED-- --Apple-Mail=_814BB666-DF98-49FE-9598-36171F425DF2-- --Apple-Mail=_2B41711D-9F19-4089-A554-54B5EC11D234 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVaKDYAAoJEIXgpQGOZny9mfsQAIjMKO8N32gqD1sV0eqcu8t5 Is95pEFniERQD4jEx1CSIdfmqReTdceO2pFbenVY5TQs+76rWKms7Ivlka612V1L 30sHLd1ic7Bo/Oqf7F71c5fvL2VtJo4jh17MIuJPhiSdDdMnrg6IQjBlU6vuoN4A +stGfUrllOg69DjK1nSpNIkKcHvvTCGs5CbgBqFNTxoXP7Oi5Iws65GlHOJGvlxm 4XmkTp2qUgY7cgLtDYgZgnVGONchBA++dvrx7nitSgijzK0fuLQCd7WfjqJ/DCba 5+eLUjExzj0WlTfRP/Llm+cLuqnUcxjtYB2HUAuKYBOly94q5TxtnQDtEKIKgzb7 NLJruYa6PYAcY7gH+Zk4AwGshEgDLDyFx1jAa9lR2BP44CXDOAswPM2rY/qZHyfv eEg6OoNg0sRFheoU94WRla6D5H6Kthv0cZiV5NqHwdQO+J8yAg7/try1Rkepguws xNnK43MX9jARSPhbLYHQao7OYJTYN4Dw/t9aTYTTLkE+w7mALYeWuAxgp+pLN07l 7gufoD+hSBz8KX5l/o+ohk3OwWJ7KgE0MU4we2GR7WZqQ8zW/IYauj3tWMDTakQO Z/pnRvnD0dl9JUARj9I45AJki49+g7LeS3biCAg2Ujwo8w9ZrhodruqksX6pU1Pb G8s7Q2TA5jyw4OHPm3XO =fVrp -----END PGP SIGNATURE----- --Apple-Mail=_2B41711D-9F19-4089-A554-54B5EC11D234-- From nobody Fri May 29 10:48:00 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A676E1B2B3E; Fri, 29 May 2015 10:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 YMAe3wArdAEd; Fri, 29 May 2015 10:45:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B681ACE8E; Fri, 29 May 2015 10:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26240; q=dns/txt; s=iport; t=1432921122; x=1434130722; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JwwVmzF9vrRY4XCVBJEBkhk/HxShrhG2ZgrBZ/h1mM0=; b=QvAMGbPvNoRd34bElywzQsIO/WLU+g+kaiAKKrtX6eewhs1HzCJOWXLu 63++kvLkPNQpXj/E88ochIBV85zMkO1Un+dnq+INaqqZ6aXrjHNZRD1kx Q8qlYJ2w5cF1jBU0vgWY4iESOR2yPh/9Z4UmmzSRrAJoCRptXXp29MPcV E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A3BABYo2hV/4UNJK1TCYMQVF4Ggxi6ImYJgVqFLUoCgUc4FAEBAQEBAQGBCoQiAQEBAwEaAwYEQAkJBQsCAQgSBioCAjIXDgIEAQkEBQ4NiAoIDbE2o30BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpBgQKEIwcJAgEFRgUCBYJoL4EWBYZrjB+CEoFDYIJShAuBKYNxgn+LQINZI2GBKQUXFYE9bwGBRYEBAQEB X-IronPort-AV: E=Sophos; i="5.13,518,1427760000"; d="asc'?scan'208"; a="2911290" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 29 May 2015 17:38:40 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4THcelv018673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 17:38:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Fri, 29 May 2015 12:38:38 -0500 From: "Carlos Pignataro (cpignata)" To: Stephen Farrell , Kathleen Moriarty Thread-Topic: Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmUU9UNzRkq1wJU2Wvlf+qhp5bp2Rv2+AgAAI/ICAAADkAIAAY4uAgAACqICAAANkgIAABgaAgAAB1ICAAAD1gIAAsgkAgABrDACAAAGjgIAACcWAgAADwgCAAAe7AIAAHjKA Date: Fri, 29 May 2015 17:38:38 +0000 Message-ID: References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> <55681DCC.2000907@cs.tcd.ie> <55687798.8050804@joelhalpern.com> <556878F7.6030506@cs.tcd.ie> <55688129.4030200@joelhalpern.com> <55688450.4060605@cs.tcd.ie> <55688ACC.6070405@joelhalpern.com> In-Reply-To: <55688ACC.6070405@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/signed; boundary="Apple-Mail=_A2032C13-8032-4026-AEC9-BE7F3DCE9ED4"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 29 May 2015 10:47:58 -0700 Cc: "Joel M. Halpern" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "Jim Guichard \(jguichar\)" , The IESG , "draft-ietf-sfc-architecture@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 17:45:52 -0000 --Apple-Mail=_A2032C13-8032-4026-AEC9-BE7F3DCE9ED4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephen, (and Kathleen, as this relates to the heart of your concern as = well), Would that proposal below be the actionable middle-ground satisfying = your concerns? I would actually tweak a bit to say: =E2=80=9CProtocols addressing this architecture must include adjunct = mechanisms to provide confidentiality and integrity of metadata carried = by the protocol, although implementation of such mechanisms may be = optional.=E2=80=9D Please let us know =E2=80=94 thanks, =E2=80=94 Carlos. > On May 29, 2015, at 11:50 AM, Joel M. Halpern = wrote: >=20 > The document is a deliverable milestone intended to frame agreements = which will then guide the protocol design process. The protocol process = is going to try to move quickly. So we want this done, and argument = resolved, ASAP. >=20 > Would: >=20 > Protocols addressing this architecture must include mechanisms to = provide confidentiality and integrity of metadata carried by the = protocol, although implementation of such mechanisms may be optional. >=20 > be any better? I don't want to include data origin authentication = because that would require separate protection for each piece of = metadata (as they may come from separate sources). We already have size = concerns with this whole mechanism. >=20 > Yours, > Joel >=20 > On 5/29/15 11:22 AM, Stephen Farrell wrote: >>=20 >> Hiya, >>=20 >> On 29/05/15 16:09, Joel Halpern Direct wrote: >>> I am not sure I like the following, but to try to move this forward, = would >>>=20 >>> Protocols addressing this architecture need to include definitions = for >>> how security services are provided with that solution, although >>> implementation of such mechanisms may be optional. >>=20 >> Sorry, I'm really not at all sure that's a good idea as I suspect >> it has too high a liklihood that those who want to see such work >> done, and those who don't, both read it and are not unhappy;-) >>=20 >> I'm not interested in trying to force the SFC WG to define some >> mythical security that never gets implemented really so I think >> maybe we'll be better off if we do enough of the analysis now(ish) >> to know that the architecture can say "protocols need to >> define a confidentiality service that can protect meta-data >> and a data-origin authentication services that can protect the >> SFC encapsulation." I do think that may need a bit more work >> though before one would be happy to put it out in the RFC. >> And one possible outcome of that work could be that it says >> instead "we know we do really need a confidentiality service >> but we can't see how that's practical right now" if that is >> in fact the case. (Which is possible, since these middle to >> middle confidentiality things are v. hard to do.) >>=20 >> BTW - is there a reason to want this document to proceed to >> be an RFC very quickly? If so, be good to know. If not, then >> we don't need to rush to a compromise that we might all be >> sad about later. >>=20 >> S. >>=20 >>>=20 >>> work for you? >>> Yours, >>> Joel >>>=20 >>> On 5/29/15 10:34 AM, Stephen Farrell wrote: >>>>=20 >>>>=20 >>>> On 29/05/15 15:28, Joel M. Halpern wrote: >>>>> Would you consider the following sentence pair that Carlos and I = have >>>>> been debating to be helpful: >>>>>=20 >>>>> =E2=80=9Csome protocols may optionally include confidentiality = provisions for >>>>> metadata and service function path identity, which may be used in = some >>>>> deployments. The architecture does not mandate such function.=E2=80=9C= >>>>=20 >>>> Not really no. I think that says nothing at all while at the same >>>> time having the ambiguity around the term "mandate" that I pointed >>>> out below. >>>>=20 >>>> I have no clue why the SFC architecture cannot simply say that >>>> a confidentiality service needs to be defined. >>>>=20 >>>> S. >>>>=20 >>>>>=20 >>>>> ? >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 5/29/15 4:05 AM, Stephen Farrell wrote: >>>>>>=20 >>>>>> Joel, >>>>>>=20 >>>>>> On 28/05/15 22:28, Joel M. Halpern wrote: >>>>>>> Enjoy the pub. >>>>>>=20 >>>>>> I did, of course:-) >>>>>>=20 >>>>>>>=20 >>>>>>> No, I do not agree. I do not see that the archtiecture needs to >>>>>>> mandate >>>>>>> a confidentiality service to protect the meta-data. >>>>>>=20 >>>>>> I'm sorry but that's just unhelpful. I did not speak of mandating >>>>>> and doing so is simply to introduce a distracting negative = ambiguity. >>>>>>=20 >>>>>> I am discussing whether the architecture should call for a = protocol >>>>>> solution that has a well-defined way to provide confidentiality = and >>>>>> data origin authentication. Whether and when that may, should or >>>>>> must be used is not a part of the architecture. >>>>>>=20 >>>>>> It will help the discussion if you are similarly precise. It will >>>>>> IMO prove really hard to resolve the discussion if such = ambiguities >>>>>> are constantly introduced. (I have seen the same in response to = the >>>>>> secdir review where their suggestion that X be defined is met = with >>>>>> an objection to X being forced to be used all the time.) >>>>>>=20 >>>>>>> The data can only >>>>>>> leak across the kind of boundary you describe if the service = function >>>>>>> chooses to leak it. >>>>>>=20 >>>>>> Rubbish. If the protocol solution provides no confidentiality >>>>>> service for meta-data then the leakage is inevitable as there >>>>>> will be no possible alternative. >>>>>>=20 >>>>>> Yes a bad actor deploying can always leak, we are here = considering >>>>>> how to enable good actors to do the right thing. >>>>>>=20 >>>>>>> Given taht it will have to have access to the meta >>>>>>> data, no confidentiality mechanism will prevent that. >>>>>>>=20 >>>>>>> Note that the encrypted packet produced by the service function = is >>>>>>> addressed to some end point. I am failing to see how the = problem you >>>>>>> are asking us to address could arise. >>>>>>=20 >>>>>> Frankly, ISTM that you are doing more than that. My impression is >>>>>> that you are opposed to defining a confidentiality service. I = would >>>>>> be happy to be corrected in that. >>>>>>=20 >>>>>> I do understand that calling for a confidentiality service does >>>>>> not mean that it will be easy to define a useful confidentiality >>>>>> service. I am quite sure that the IETF could muck that up as we >>>>>> have done in the past (e.g. with SIP & S/MIME) but I am equally >>>>>> sure we could also succeed, and I think we should try and indeed >>>>>> our BCPs call for us to do just that, once we recognise there is >>>>>> a need for such a service. And that last is, I think, entirely >>>>>> clear. >>>>>>=20 >>>>>> S. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 5/28/15 5:24 PM, Stephen Farrell wrote: >>>>>>>>=20 >>>>>>>> Joel, >>>>>>>>=20 >>>>>>>> I'm afraid you've lost me again, but since it's now time for >>>>>>>> me to go to the pub, that's fine:-) >>>>>>>>=20 >>>>>>>> For me the important thing is if meta-data is inserted at A and >>>>>>>> then packets are encrypted by something between B and C, then >>>>>>>> we do not want cleartext meta-data attached to the ciphertext >>>>>>>> sent from B to C to always have to risk making the encryption >>>>>>>> pointless. >>>>>>>>=20 >>>>>>>> To me, that means that this architecture needs to call for the >>>>>>>> existence of a confidentiality service that can be used to >>>>>>>> protect at least the meta-data. (And it could protect more too >>>>>>>> I guess but the details would be for the WG to figure later.) >>>>>>>>=20 >>>>>>>> I think additional scenarios can similarly justify a need for >>>>>>>> the definition of a data origin authentication service. >>>>>>>>=20 >>>>>>>> If we agreed about that and could move on to how that ought be >>>>>>>> expressed in the arch document, that'd be great. (But as I'll >>>>>>>> be in the pub, I won't find out 'till tomorrow:-) >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> S. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 28/05/15 22:18, Joel M. Halpern wrote: >>>>>>>>> While SMTP servers are a bad example, service chaining can be = use >>>>>>>>> with >>>>>>>>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. >>>>>>>>> Both of >>>>>>>>> those terminate connections and create new packets. As such, = the >>>>>>>>> two >>>>>>>>> sides of such devices are on separate service chains. In = order for >>>>>>>>> the >>>>>>>>> two sides to be on the same chain, the service function would >>>>>>>>> have to >>>>>>>>> copy the service chaining and related metadata from one side = to the >>>>>>>>> other. I can't stop them from doing so, but in most cases it >>>>>>>>> would be >>>>>>>>> misleading. >>>>>>>>>=20 >>>>>>>>> What we have done is to recognize that these are generally = different >>>>>>>>> service chains. Because the packets will get different = treatments. >>>>>>>>>=20 >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>>=20 >>>>>>>>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>>>>>>>>=20 >>>>>>>>>> Joel, >>>>>>>>>>=20 >>>>>>>>>> If you are asserting that SFC cannot be used in a manner that >>>>>>>>>> has the problem I was trying to exemplify then I have to say, >>>>>>>>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>>>>>>>> is one of the examples cited in the arch draft, and there's >>>>>>>>>> not much difference between that and email from the relevant >>>>>>>>>> perspective. >>>>>>>>>>=20 >>>>>>>>>> I also hope that I've succeeded in explaining the problem as >>>>>>>>>> I see it. If not please ask and I'll try some more to = clarify. >>>>>>>>>> (Since you did not ask that, I assume you do get what I mean, >>>>>>>>>> but it would be helpful if you would acknowledge that so we >>>>>>>>>> can communicate more easily.) >>>>>>>>>>=20 >>>>>>>>>> Can you point me at some piece of text in some draft that >>>>>>>>>> ensures that this problem cannot occur? If not, (which I >>>>>>>>>> think is the case), wouldn't we be better off acknowledging >>>>>>>>>> that it is an issue and one that needs to be tackled as >>>>>>>>>> best we can, as indeed Alia's earlier mail seems (to me) >>>>>>>>>> to suggest? >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> S. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>>>>>>>> That case would not occur within a service chain. >>>>>>>>>>> A service chain is about delivery of a packet to a series of >>>>>>>>>>> services to >>>>>>>>>>> which it is not addressed (generally followed by delivery = to the >>>>>>>>>>> target >>>>>>>>>>> to which it is addressed.) >>>>>>>>>>> An SMTP server relaying email produces separate packets. = The >>>>>>>>>>> packets >>>>>>>>>>> from the user to the SMTP server are on one chain. The = packets >>>>>>>>>>> from >>>>>>>>>>> that server to another are completely separate, and on a = different >>>>>>>>>>> chain. As such, those TLS SMTP packets between the servers = would >>>>>>>>>>> not >>>>>>>>>>> have any metadata from the first transfer. >>>>>>>>>>>=20 >>>>>>>>>>> Mail servers are not SFC service functions. The only time = it gets >>>>>>>>>>> close >>>>>>>>>>> is when you are doing port 25 redirection, and then the = service >>>>>>>>>>> chain >>>>>>>>>>> ends at the mail server. >>>>>>>>>>>=20 >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>>=20 >>>>>>>>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>>>>>>>> IF A, B, and C are service function forwarders (SFF), with = a TLS >>>>>>>>>>>>> protected link for SFC, then the metadata will be = protected. >>>>>>>>>>>>> (Such a >>>>>>>>>>>>> link would be a transport mechanism, which SFC does not >>>>>>>>>>>>> describe or >>>>>>>>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>>>>>>>>=20 >>>>>>>>>>>> Ah, no the scenario I was thinking about is where, from >>>>>>>>>>>> the perspective of SFC, the TLS packets are the payload >>>>>>>>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>>>>>>>> servers with starttls only turned on between B and C >>>>>>>>>>>> because that link is "external" (though within the same >>>>>>>>>>>> administrative domain). If some SFC thing at A were to >>>>>>>>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>>>>>>>> data then we wouldn't want that sent in clear from B to C >>>>>>>>>>>> because of the SFC encapsulation, right? >>>>>>>>>>>>=20 >>>>>>>>>>>> S. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If A, B, and C are service functions used by SFC, then = there >>>>>>>>>>>>> is no >>>>>>>>>>>>> link >>>>>>>>>>>>> between B and C, so it can't be protected by TLS. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> So I can not see what more needs to be said? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>>>>>>>> I am not sure what you mean by "Metadata that contains >>>>>>>>>>>>>>> information >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> is protected in the data plane". Most of what ends up = in the >>>>>>>>>>>>>>> metadata >>>>>>>>>>>>>>> is information that is passed on other interfaces = directly to >>>>>>>>>>>>>>> relevant >>>>>>>>>>>>>>> functions, or locally determine and locally processed. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> So what I had in mind were things like the following. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>>>>>>>> - B to C link is via say a TLS VPN >>>>>>>>>>>>>> - Metadata is created at A and is in the SFC = encapsulation >>>>>>>>>>>>>> and not protected by the VPN >>>>>>>>>>>>>> - That seems bad >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> S. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The protection used for policy systems (which provide = much of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> information) is based on the presence of persistent >>>>>>>>>>>>>>> connections >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> usage which crosses domains. Are you arguing that if = AAA is >>>>>>>>>>>>>>> encrypted >>>>>>>>>>>>>>> then policy delivered by AAA resulting in metadata in = the >>>>>>>>>>>>>>> packet >>>>>>>>>>>>>>> must be >>>>>>>>>>>>>>> encrypted in the data packets? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>>>>>>>> Stephen Farrell has entered the following ballot = position for >>>>>>>>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> When responding, please keep the subject line intact = and >>>>>>>>>>>>>>>> reply >>>>>>>>>>>>>>>> to all >>>>>>>>>>>>>>>> email addresses included in the To and CC lines. (Feel >>>>>>>>>>>>>>>> free to >>>>>>>>>>>>>>>> cut >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Please refer to >>>>>>>>>>>>>>>> = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>>>>>>>> for more information about IESG DISCUSS and COMMENT >>>>>>>>>>>>>>>> positions. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The document, along with other ballot positions, can be = found >>>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>>> = https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> DISCUSS: >>>>>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> (1) I note the charter calls for this deliverable to = "provide >>>>>>>>>>>>>>>> a description of... security models" The charter also >>>>>>>>>>>>>>>> generally notes that "The SFC WG will closely consider = and >>>>>>>>>>>>>>>> address the management and security implications when >>>>>>>>>>>>>>>> documenting these deliverables." My conclusion is that = this >>>>>>>>>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>>>>>>>>> analysis that the wg are suppoed to have carried out = but that >>>>>>>>>>>>>>>> it's currently too vague only saying that solutions = need to >>>>>>>>>>>>>>>> consider this. (Essentially this is a continuation of = the >>>>>>>>>>>>>>>> mail threads from the secdir review [1] and a = satisfactory >>>>>>>>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>> = https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> (2) Metadata that contains information that is = protected in >>>>>>>>>>>>>>>> the data plane SHOULD be equally well protected when = passed >>>>>>>>>>>>>>>> about by SFC. I hope that's acceptable and documented. = I'm >>>>>>>>>>>>>>>> not sure myself if "passed about" ought also include = within a >>>>>>>>>>>>>>>> device but maybe it should really. But at minimum, I = do >>>>>>>>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>>>>>>>> authentication services for SFC metadata and/or for the = SFC >>>>>>>>>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>>>>>>>>> document needs to say that those services have to be >>>>>>>>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>>>>>>>> saying that this draft needs to define how to do = those.) >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - It occurs to me that it might really be better for = the WG >>>>>>>>>>>>>>>> to not publish this as an RFC now, but rather to put it = on >>>>>>>>>>>>>>>> hold until they've made progress on the solutions. = Perhaps >>>>>>>>>>>>>>>> revistiting this when the solutions are just at WGLC = would >>>>>>>>>>>>>>>> result in the eventual RFC being a much more useful = document. >>>>>>>>>>>>>>>> I think this one has to hedge so many bets that it's = quite >>>>>>>>>>>>>>>> vague and won't be very useful even in the medium term. = But >>>>>>>>>>>>>>>> that's just a suggestion, I can see why the WG might = prefer >>>>>>>>>>>>>>>> to push this out, even if that might only give the = appearance >>>>>>>>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - While IPR on an architecture document is sad to see, = esp >>>>>>>>>>>>>>>> with what seems like it may be restrictive licensing, I = do >>>>>>>>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - The charter text describing this deliverable notes = that >>>>>>>>>>>>>>>> "The initial scope is restricted to a single = administrative >>>>>>>>>>>>>>>> domain, keeping in mind that architectural decisions = made for >>>>>>>>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>>>>>>>> inter-domain case." So I think there is also a = currently >>>>>>>>>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>>>>>>>>> single-domain elements of this architecture might = impinge on >>>>>>>>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>>>>>>>>> goals. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - Chains will require some representation, and = re-ordering >>>>>>>>>>>>>>>> that is security sensitive (e.g. swap order of f/w and = nat >>>>>>>>>>>>>>>> for fun) therefore there must be a requirement for some = data >>>>>>>>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>>>>>>>> authorisation decision function and therefore there = must >>>>>>>>>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>>>>>>>>> producing entity of some kind that could be = authenticated. >>>>>>>>>>>>>>>> That is an example of the missing security analysis = that >>>>>>>>>>>>>>>> really is needed before this proceeds. (See my discuss = point >>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>>>>>>>>> networks are slightly incongrous. In the case of WiFi = when do >>>>>>>>>>>>>>>> the packet ingress? (When it gets to the AP or leaves = the >>>>>>>>>>>>>>>> mobile node transmitter?) I suspect you really mean the = wired >>>>>>>>>>>>>>>> bits of a mobile network so it might be better to say = that. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's = no >>>>>>>>>>>>>>>> standard chaining logic, which is maybe right, but then = you >>>>>>>>>>>>>>>> imply that a fully ordered set of SF's is a well = defined >>>>>>>>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you = want >>>>>>>>>>>>>>>> to say is that the architecture doesn't determine if an = SFC >>>>>>>>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that = later >>>>>>>>>>>>>>>> protocol work will have to do that. (In fact, I think = you >>>>>>>>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where = those >>>>>>>>>>>>>>>> terms need to be defined. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>>>>>>>>> partially ordered? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising = that >>>>>>>>>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any = kind of >>>>>>>>>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>>>>>>>>> reviews on the same telechat as this) so I'd also drop = that. >>>>>>>>>>>>>>>> And I think all of the exemplar SF's should really have = a >>>>>>>>>>>>>>>> reference (ideally an RFC). >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - Figure 1 caption is misleading. That seems to me to = show a >>>>>>>>>>>>>>>> set of paths through (one or more) graphs but doesn't = show >>>>>>>>>>>>>>>> the full graphs themselves. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. = Does >>>>>>>>>>>>>>>> the example given imply that all traffic (of what = kind?) that >>>>>>>>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think = more >>>>>>>>>>>>>>>> precision is needed really. The hybrid concept seems = even >>>>>>>>>>>>>>>> odder to me. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of = an >>>>>>>>>>>>>>>> architecture is to avoid such vagueness? If you mean = that an >>>>>>>>>>>>>>>> SFP representation can embody an if-statement then = saying >>>>>>>>>>>>>>>> that would be the thing to do. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - Section 3: I think there's maybe a missing principle = here >>>>>>>>>>>>>>>> about not making security and privacy worse in general. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC = control >>>>>>>>>>>>>>>> traffic that congestion would be an issue? If so, = should you >>>>>>>>>>>>>>>> say rather that any transport that has some way of = handling >>>>>>>>>>>>>>>> congestion is ok. If not, then I guess the current text = is >>>>>>>>>>>>>>>> fine. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>=20 >>=20 --Apple-Mail=_A2032C13-8032-4026-AEC9-BE7F3DCE9ED4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVaKQhAAoJEIXgpQGOZny9X40QAKAwWrSGALIRTzKoA/wNOL2t lWFXPk2wjofSeNOIa4D//0iqddkmBUuJPeK/3ihXFfnTWcl55j3TN30PUsX13YiH nS/Z6BW0MODeL4OIZTcFw4zZHrE6Idxm3r3nLNidXmtLcZgfK2oV2g8xN2R8XkE2 4m1xFH7NsuTNhNH4XgJGTL8haFN11tm9ZrmSfBppNWWxbhXpT8myVx9A4xIu+0Vy VrBzTIvcO9A+ZZni1Xrw+f0jqGhdNLIqkMgbFOd6tu67N9fG1BhQBOoPnPXC77d3 RwLLz92Kykz+hXDD92COilHDTU4TD1c+eJWy9dn7Lkvc531V2DQN2BZ7leFaGdtZ c4kdyIB7AMLvA2LRs4Ep+6VIqI39e2ppoq9tH9wc/A/MpQKxMpdVIHXtNw9O/wHe 3B+5UJW1TjBxqLnXjUfuKuPmPWxXmt6SE6A8bNGfHxnr49FRjl+nV67+s/Ui50PG o2wrXnlwNcaIwIWwteFm+MKeB24lawUC2f9etrZlPYQLNyzSBTKrv+NpMBRAl0Pz SC7NEeGFVbX0VOs3Dfwdc7g5musaAV3Y9/+Ae+GIqFptdBIuoBcRV3mSqNr+wkHU NAJKsyUB+Y+OeVpkR4lMSnJyLAULl/Y0vIf4i88W/jKmi0j+l5RqPVNemPOHkzdW LU8im0hUFuRH6KS/F7l6 =j/Nn -----END PGP SIGNATURE----- --Apple-Mail=_A2032C13-8032-4026-AEC9-BE7F3DCE9ED4-- From nobody Fri May 29 10:48:02 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12701ACE39; Fri, 29 May 2015 10:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_OFF=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oAgR8kbiR8D; Fri, 29 May 2015 10:46:36 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76AF31ACEED; Fri, 29 May 2015 10:41:17 -0700 (PDT) Received: by qgfa63 with SMTP id a63so32086136qgf.0; Fri, 29 May 2015 10:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9aU1r7POsUl/CZHpITi61fxgkN8bTKCqxZDZLM2FZnk=; b=Y8iuf0TNjif9AJuQurM+UH20j7cryRvyL3bmWhKwpxzkK66psgmdvl0MXNVj5hPn3Q /kthU5FN8l6GdOp3uAHFo6iQ3O/CvcXDsFn5WvqsAQMLjEmJegDIgau+i3pBqMR75Mg2 COIcR+vG6LfB2JnqvQRl0yzAzcg7Vm3JJifR4wHqYaRBeK3nhk0FofDe+VYdcGb13XwU Wfd+8BSEzMrso0dSR2kDilne3Fx9aCz92dpb882PH5zIG4ucl7BWLzzuzdQ8VFWKHE6Z nQeQYK4MQidTaiM45kBcpfLZDGAOvjK0hXD8bsQCAfNmTGvcOGTSrOFQsGNeDQzyO4uh lCkA== X-Received: by 10.229.17.70 with SMTP id r6mr11495969qca.11.1432921276706; Fri, 29 May 2015 10:41:16 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id c20sm3006922qka.21.2015.05.29.10.41.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 May 2015 10:41:15 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Fri, 29 May 2015 13:41:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F471674-BC7F-41BA-92C0-B3C2F207E481@gmail.com> References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> <55681DCC.2000907@cs.tcd.ie> <55687798.8050804@joelhalpern.com> <556878F7.6030506@cs.tcd.ie> <55688129.4030200@joelhalpern.com> <55688450.4060605@cs.tcd.ie> <55688ACC.6070405@joelhalpern.com> To: "Carlos Pignataro (cpignata)" Archived-At: X-Mailman-Approved-At: Fri, 29 May 2015 10:47:58 -0700 Cc: "draft-ietf-sfc-architecture@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , "draft-ietf-sfc-architecture.ad@ietf.org" , Stephen Farrell , The IESG Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 17:46:40 -0000 Alia's text helps with my concern. Let's keep this to Stephen's discuss poi= nts that I support. Thank you, Kathleen=20 Sent from my iPhone > On May 29, 2015, at 1:38 PM, "Carlos Pignataro (cpignata)" wrote: >=20 > Stephen, (and Kathleen, as this relates to the heart of your concern as we= ll), >=20 > Would that proposal below be the actionable middle-ground satisfying your c= oncerns? I would actually tweak a bit to say: >=20 > =E2=80=9CProtocols addressing this architecture must include adjunct mecha= nisms to provide confidentiality and integrity of metadata carried by the pr= otocol, although implementation of such mechanisms may be optional.=E2=80=9D= >=20 > Please let us know =E2=80=94 thanks, >=20 > =E2=80=94 Carlos. >=20 >> On May 29, 2015, at 11:50 AM, Joel M. Halpern wrote= : >>=20 >> The document is a deliverable milestone intended to frame agreements whic= h will then guide the protocol design process. The protocol process is goin= g to try to move quickly. So we want this done, and argument resolved, ASAP= . >>=20 >> Would: >>=20 >> Protocols addressing this architecture must include mechanisms to provide= confidentiality and integrity of metadata carried by the protocol, although= implementation of such mechanisms may be optional. >>=20 >> be any better? I don't want to include data origin authentication becaus= e that would require separate protection for each piece of metadata (as they= may come from separate sources). We already have size concerns with this w= hole mechanism. >>=20 >> Yours, >> Joel >>=20 >>> On 5/29/15 11:22 AM, Stephen Farrell wrote: >>>=20 >>> Hiya, >>>=20 >>>> On 29/05/15 16:09, Joel Halpern Direct wrote: >>>> I am not sure I like the following, but to try to move this forward, wo= uld >>>>=20 >>>> Protocols addressing this architecture need to include definitions for >>>> how security services are provided with that solution, although >>>> implementation of such mechanisms may be optional. >>>=20 >>> Sorry, I'm really not at all sure that's a good idea as I suspect >>> it has too high a liklihood that those who want to see such work >>> done, and those who don't, both read it and are not unhappy;-) >>>=20 >>> I'm not interested in trying to force the SFC WG to define some >>> mythical security that never gets implemented really so I think >>> maybe we'll be better off if we do enough of the analysis now(ish) >>> to know that the architecture can say "protocols need to >>> define a confidentiality service that can protect meta-data >>> and a data-origin authentication services that can protect the >>> SFC encapsulation." I do think that may need a bit more work >>> though before one would be happy to put it out in the RFC. >>> And one possible outcome of that work could be that it says >>> instead "we know we do really need a confidentiality service >>> but we can't see how that's practical right now" if that is >>> in fact the case. (Which is possible, since these middle to >>> middle confidentiality things are v. hard to do.) >>>=20 >>> BTW - is there a reason to want this document to proceed to >>> be an RFC very quickly? If so, be good to know. If not, then >>> we don't need to rush to a compromise that we might all be >>> sad about later. >>>=20 >>> S. >>>=20 >>>>=20 >>>> work for you? >>>> Yours, >>>> Joel >>>>=20 >>>>> On 5/29/15 10:34 AM, Stephen Farrell wrote: >>>>>=20 >>>>>=20 >>>>>> On 29/05/15 15:28, Joel M. Halpern wrote: >>>>>> Would you consider the following sentence pair that Carlos and I have= >>>>>> been debating to be helpful: >>>>>>=20 >>>>>> =E2=80=9Csome protocols may optionally include confidentiality provis= ions for >>>>>> metadata and service function path identity, which may be used in som= e >>>>>> deployments. The architecture does not mandate such function.=E2=80=9C= >>>>>=20 >>>>> Not really no. I think that says nothing at all while at the same >>>>> time having the ambiguity around the term "mandate" that I pointed >>>>> out below. >>>>>=20 >>>>> I have no clue why the SFC architecture cannot simply say that >>>>> a confidentiality service needs to be defined. >>>>>=20 >>>>> S. >>>>>=20 >>>>>>=20 >>>>>> ? >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>>> On 5/29/15 4:05 AM, Stephen Farrell wrote: >>>>>>>=20 >>>>>>> Joel, >>>>>>>=20 >>>>>>>> On 28/05/15 22:28, Joel M. Halpern wrote: >>>>>>>> Enjoy the pub. >>>>>>>=20 >>>>>>> I did, of course:-) >>>>>>>=20 >>>>>>>>=20 >>>>>>>> No, I do not agree. I do not see that the archtiecture needs to >>>>>>>> mandate >>>>>>>> a confidentiality service to protect the meta-data. >>>>>>>=20 >>>>>>> I'm sorry but that's just unhelpful. I did not speak of mandating >>>>>>> and doing so is simply to introduce a distracting negative ambiguity= . >>>>>>>=20 >>>>>>> I am discussing whether the architecture should call for a protocol >>>>>>> solution that has a well-defined way to provide confidentiality and >>>>>>> data origin authentication. Whether and when that may, should or >>>>>>> must be used is not a part of the architecture. >>>>>>>=20 >>>>>>> It will help the discussion if you are similarly precise. It will >>>>>>> IMO prove really hard to resolve the discussion if such ambiguities >>>>>>> are constantly introduced. (I have seen the same in response to the >>>>>>> secdir review where their suggestion that X be defined is met with >>>>>>> an objection to X being forced to be used all the time.) >>>>>>>=20 >>>>>>>> The data can only >>>>>>>> leak across the kind of boundary you describe if the service functi= on >>>>>>>> chooses to leak it. >>>>>>>=20 >>>>>>> Rubbish. If the protocol solution provides no confidentiality >>>>>>> service for meta-data then the leakage is inevitable as there >>>>>>> will be no possible alternative. >>>>>>>=20 >>>>>>> Yes a bad actor deploying can always leak, we are here considering >>>>>>> how to enable good actors to do the right thing. >>>>>>>=20 >>>>>>>> Given taht it will have to have access to the meta >>>>>>>> data, no confidentiality mechanism will prevent that. >>>>>>>>=20 >>>>>>>> Note that the encrypted packet produced by the service function is >>>>>>>> addressed to some end point. I am failing to see how the problem y= ou >>>>>>>> are asking us to address could arise. >>>>>>>=20 >>>>>>> Frankly, ISTM that you are doing more than that. My impression is >>>>>>> that you are opposed to defining a confidentiality service. I would >>>>>>> be happy to be corrected in that. >>>>>>>=20 >>>>>>> I do understand that calling for a confidentiality service does >>>>>>> not mean that it will be easy to define a useful confidentiality >>>>>>> service. I am quite sure that the IETF could muck that up as we >>>>>>> have done in the past (e.g. with SIP & S/MIME) but I am equally >>>>>>> sure we could also succeed, and I think we should try and indeed >>>>>>> our BCPs call for us to do just that, once we recognise there is >>>>>>> a need for such a service. And that last is, I think, entirely >>>>>>> clear. >>>>>>>=20 >>>>>>> S. >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>>=20 >>>>>>>>> On 5/28/15 5:24 PM, Stephen Farrell wrote: >>>>>>>>>=20 >>>>>>>>> Joel, >>>>>>>>>=20 >>>>>>>>> I'm afraid you've lost me again, but since it's now time for >>>>>>>>> me to go to the pub, that's fine:-) >>>>>>>>>=20 >>>>>>>>> For me the important thing is if meta-data is inserted at A and >>>>>>>>> then packets are encrypted by something between B and C, then >>>>>>>>> we do not want cleartext meta-data attached to the ciphertext >>>>>>>>> sent from B to C to always have to risk making the encryption >>>>>>>>> pointless. >>>>>>>>>=20 >>>>>>>>> To me, that means that this architecture needs to call for the >>>>>>>>> existence of a confidentiality service that can be used to >>>>>>>>> protect at least the meta-data. (And it could protect more too >>>>>>>>> I guess but the details would be for the WG to figure later.) >>>>>>>>>=20 >>>>>>>>> I think additional scenarios can similarly justify a need for >>>>>>>>> the definition of a data origin authentication service. >>>>>>>>>=20 >>>>>>>>> If we agreed about that and could move on to how that ought be >>>>>>>>> expressed in the arch document, that'd be great. (But as I'll >>>>>>>>> be in the pub, I won't find out 'till tomorrow:-) >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>> S. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 28/05/15 22:18, Joel M. Halpern wrote: >>>>>>>>>> While SMTP servers are a bad example, service chaining can be use= >>>>>>>>>> with >>>>>>>>>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. >>>>>>>>>> Both of >>>>>>>>>> those terminate connections and create new packets. As such, the= >>>>>>>>>> two >>>>>>>>>> sides of such devices are on separate service chains. In order f= or >>>>>>>>>> the >>>>>>>>>> two sides to be on the same chain, the service function would >>>>>>>>>> have to >>>>>>>>>> copy the service chaining and related metadata from one side to t= he >>>>>>>>>> other. I can't stop them from doing so, but in most cases it >>>>>>>>>> would be >>>>>>>>>> misleading. >>>>>>>>>>=20 >>>>>>>>>> What we have done is to recognize that these are generally differ= ent >>>>>>>>>> service chains. Because the packets will get different treatment= s. >>>>>>>>>>=20 >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>>=20 >>>>>>>>>>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Joel, >>>>>>>>>>>=20 >>>>>>>>>>> If you are asserting that SFC cannot be used in a manner that >>>>>>>>>>> has the problem I was trying to exemplify then I have to say, >>>>>>>>>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>>>>>>>>> is one of the examples cited in the arch draft, and there's >>>>>>>>>>> not much difference between that and email from the relevant >>>>>>>>>>> perspective. >>>>>>>>>>>=20 >>>>>>>>>>> I also hope that I've succeeded in explaining the problem as >>>>>>>>>>> I see it. If not please ask and I'll try some more to clarify. >>>>>>>>>>> (Since you did not ask that, I assume you do get what I mean, >>>>>>>>>>> but it would be helpful if you would acknowledge that so we >>>>>>>>>>> can communicate more easily.) >>>>>>>>>>>=20 >>>>>>>>>>> Can you point me at some piece of text in some draft that >>>>>>>>>>> ensures that this problem cannot occur? If not, (which I >>>>>>>>>>> think is the case), wouldn't we be better off acknowledging >>>>>>>>>>> that it is an issue and one that needs to be tackled as >>>>>>>>>>> best we can, as indeed Alia's earlier mail seems (to me) >>>>>>>>>>> to suggest? >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>> S. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>>>>>>>>> That case would not occur within a service chain. >>>>>>>>>>>> A service chain is about delivery of a packet to a series of >>>>>>>>>>>> services to >>>>>>>>>>>> which it is not addressed (generally followed by delivery to t= he >>>>>>>>>>>> target >>>>>>>>>>>> to which it is addressed.) >>>>>>>>>>>> An SMTP server relaying email produces separate packets. The >>>>>>>>>>>> packets >>>>>>>>>>>> from the user to the SMTP server are on one chain. The packets= >>>>>>>>>>>> from >>>>>>>>>>>> that server to another are completely separate, and on a differ= ent >>>>>>>>>>>> chain. As such, those TLS SMTP packets between the servers wou= ld >>>>>>>>>>>> not >>>>>>>>>>>> have any metadata from the first transfer. >>>>>>>>>>>>=20 >>>>>>>>>>>> Mail servers are not SFC service functions. The only time it g= ets >>>>>>>>>>>> close >>>>>>>>>>>> is when you are doing port 25 redirection, and then the service= >>>>>>>>>>>> chain >>>>>>>>>>>> ends at the mail server. >>>>>>>>>>>>=20 >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>>>>>>>>> IF A, B, and C are service function forwarders (SFF), with a T= LS >>>>>>>>>>>>>> protected link for SFC, then the metadata will be protected. >>>>>>>>>>>>>> (Such a >>>>>>>>>>>>>> link would be a transport mechanism, which SFC does not >>>>>>>>>>>>>> describe or >>>>>>>>>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Ah, no the scenario I was thinking about is where, from >>>>>>>>>>>>> the perspective of SFC, the TLS packets are the payload >>>>>>>>>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>>>>>>>>> servers with starttls only turned on between B and C >>>>>>>>>>>>> because that link is "external" (though within the same >>>>>>>>>>>>> administrative domain). If some SFC thing at A were to >>>>>>>>>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>>>>>>>>> data then we wouldn't want that sent in clear from B to C >>>>>>>>>>>>> because of the SFC encapsulation, right? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> S. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> If A, B, and C are service functions used by SFC, then there >>>>>>>>>>>>>> is no >>>>>>>>>>>>>> link >>>>>>>>>>>>>> between B and C, so it can't be protected by TLS. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> So I can not see what more needs to be said? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>>>>>>>>> I am not sure what you mean by "Metadata that contains >>>>>>>>>>>>>>>> information >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> is protected in the data plane". Most of what ends up in t= he >>>>>>>>>>>>>>>> metadata >>>>>>>>>>>>>>>> is information that is passed on other interfaces directly t= o >>>>>>>>>>>>>>>> relevant >>>>>>>>>>>>>>>> functions, or locally determine and locally processed. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> So what I had in mind were things like the following. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>>>>>>>>> - B to C link is via say a TLS VPN >>>>>>>>>>>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>>>>>>>>>>> and not protected by the VPN >>>>>>>>>>>>>>> - That seems bad >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> S. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The protection used for policy systems (which provide much o= f >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> information) is based on the presence of persistent >>>>>>>>>>>>>>>> connections >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> usage which crosses domains. Are you arguing that if AAA i= s >>>>>>>>>>>>>>>> encrypted >>>>>>>>>>>>>>>> then policy delivered by AAA resulting in metadata in the >>>>>>>>>>>>>>>> packet >>>>>>>>>>>>>>>> must be >>>>>>>>>>>>>>>> encrypted in the data packets? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>>>>>>>>> Stephen Farrell has entered the following ballot position f= or >>>>>>>>>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> When responding, please keep the subject line intact and >>>>>>>>>>>>>>>>> reply >>>>>>>>>>>>>>>>> to all >>>>>>>>>>>>>>>>> email addresses included in the To and CC lines. (Feel >>>>>>>>>>>>>>>>> free to >>>>>>>>>>>>>>>>> cut >>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Please refer to >>>>>>>>>>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>>>>>>>>> for more information about IESG DISCUSS and COMMENT >>>>>>>>>>>>>>>>> positions. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The document, along with other ballot positions, can be fo= und >>>>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architectu= re/ >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> ----------------------------------------------------------= ------------ >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> DISCUSS: >>>>>>>>>>>>>>>>> ----------------------------------------------------------= ------------ >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> (1) I note the charter calls for this deliverable to "prov= ide >>>>>>>>>>>>>>>>> a description of... security models" The charter also >>>>>>>>>>>>>>>>> generally notes that "The SFC WG will closely consider and= >>>>>>>>>>>>>>>>> address the management and security implications when >>>>>>>>>>>>>>>>> documenting these deliverables." My conclusion is that thi= s >>>>>>>>>>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>>>>>>>>>> analysis that the wg are suppoed to have carried out but t= hat >>>>>>>>>>>>>>>>> it's currently too vague only saying that solutions need t= o >>>>>>>>>>>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>>>>>>>>>>> mail threads from the secdir review [1] and a satisfactory= >>>>>>>>>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05= 701.html >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> (2) Metadata that contains information that is protected i= n >>>>>>>>>>>>>>>>> the data plane SHOULD be equally well protected when passe= d >>>>>>>>>>>>>>>>> about by SFC. I hope that's acceptable and documented. I'm= >>>>>>>>>>>>>>>>> not sure myself if "passed about" ought also include withi= n a >>>>>>>>>>>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>>>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>>>>>>>>> authentication services for SFC metadata and/or for the SFC= >>>>>>>>>>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>>>>>>>>>> document needs to say that those services have to be >>>>>>>>>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>>>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> ----------------------------------------------------------= ------------ >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>>>>>> ----------------------------------------------------------= ------------ >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - It occurs to me that it might really be better for the W= G >>>>>>>>>>>>>>>>> to not publish this as an RFC now, but rather to put it on= >>>>>>>>>>>>>>>>> hold until they've made progress on the solutions. Perhaps= >>>>>>>>>>>>>>>>> revistiting this when the solutions are just at WGLC would= >>>>>>>>>>>>>>>>> result in the eventual RFC being a much more useful docume= nt. >>>>>>>>>>>>>>>>> I think this one has to hedge so many bets that it's quite= >>>>>>>>>>>>>>>>> vague and won't be very useful even in the medium term. Bu= t >>>>>>>>>>>>>>>>> that's just a suggestion, I can see why the WG might prefe= r >>>>>>>>>>>>>>>>> to push this out, even if that might only give the appeara= nce >>>>>>>>>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - While IPR on an architecture document is sad to see, esp= >>>>>>>>>>>>>>>>> with what seems like it may be restrictive licensing, I do= >>>>>>>>>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - The charter text describing this deliverable notes that >>>>>>>>>>>>>>>>> "The initial scope is restricted to a single administrativ= e >>>>>>>>>>>>>>>>> domain, keeping in mind that architectural decisions made f= or >>>>>>>>>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>>>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>>>>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>>>>>>>>>> single-domain elements of this architecture might impinge o= n >>>>>>>>>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>>>>>>>>>> goals. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - Chains will require some representation, and re-ordering= >>>>>>>>>>>>>>>>> that is security sensitive (e.g. swap order of f/w and nat= >>>>>>>>>>>>>>>>> for fun) therefore there must be a requirement for some da= ta >>>>>>>>>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>>>>>>>>> authorisation decision function and therefore there must >>>>>>>>>>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>>>>>>>>>> producing entity of some kind that could be authenticated.= >>>>>>>>>>>>>>>>> That is an example of the missing security analysis that >>>>>>>>>>>>>>>>> really is needed before this proceeds. (See my discuss poi= nt >>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>>>>>>>>>> networks are slightly incongrous. In the case of WiFi when= do >>>>>>>>>>>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>>>>>>>>>>> mobile node transmitter?) I suspect you really mean the wi= red >>>>>>>>>>>>>>>>> bits of a mobile network so it might be better to say that= . >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no= >>>>>>>>>>>>>>>>> standard chaining logic, which is maybe right, but then yo= u >>>>>>>>>>>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>>>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you wan= t >>>>>>>>>>>>>>>>> to say is that the architecture doesn't determine if an SFC= >>>>>>>>>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that late= r >>>>>>>>>>>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>>>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those= >>>>>>>>>>>>>>>>> terms need to be defined. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>>>>>>>>>> partially ordered? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising tha= t >>>>>>>>>>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any kind= of >>>>>>>>>>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>>>>>>>>>> reviews on the same telechat as this) so I'd also drop tha= t. >>>>>>>>>>>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>>>>>>>>>>> reference (ideally an RFC). >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - Figure 1 caption is misleading. That seems to me to show= a >>>>>>>>>>>>>>>>> set of paths through (one or more) graphs but doesn't show= >>>>>>>>>>>>>>>>> the full graphs themselves. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Doe= s >>>>>>>>>>>>>>>>> the example given imply that all traffic (of what kind?) t= hat >>>>>>>>>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>>>>>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>>>>>>>>>>> odder to me. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>>>>>>>>>>> architecture is to avoid such vagueness? If you mean that a= n >>>>>>>>>>>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>>>>>>>>>>> that would be the thing to do. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - Section 3: I think there's maybe a missing principle her= e >>>>>>>>>>>>>>>>> about not making security and privacy worse in general. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>>>>>>>>>>> traffic that congestion would be an issue? If so, should y= ou >>>>>>>>>>>>>>>>> say rather that any transport that has some way of handlin= g >>>>>>>>>>>>>>>>> congestion is ok. If not, then I guess the current text is= >>>>>>>>>>>>>>>>> fine. >=20 From nobody Fri May 29 10:52:25 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2041ACE77; Fri, 29 May 2015 10:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Y-wY6WdX5B5T; Fri, 29 May 2015 10:51:14 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C65E1AD379; Fri, 29 May 2015 10:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28933; q=dns/txt; s=iport; t=1432921666; x=1434131266; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vDfm6jEWbyFb+E9Z9roJKmbxHTCQwQjMGwjlpAVBJO8=; b=f6an3j4bSJv4t0o3TOAFfMzbI5maY9+7eu2o2dCwZ6IREL/oRTn6+v9v N2R0O7BcrDOnBMelbXVpmZTR6SrNVKQUN0RHhhb8DjbcOea6cC4k8vKQZ lTjepPpqNEOxZV2bHGjx70bxd7RCRXlQ7KZSN5wuFh73B7XBU3wwQ+glA Y=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWBQCwpWhV/5JdJa1TCYMQVF4Ggxi6IoJJhS1KAoFHTAEBAQEBAYELhCIBAQEDARoDBgRACQkFCwIBCBIGKgICIREXDgIECgQFDg2HfQMKCA2xJ553DYR2AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKQYECgk2BVgcJAgEFRgUCBYJoL4EWBYZrjB+CEoFDYIJSgjKBWYEpg3GCf4gVgyuDWSNhgSkFFxWBPW8BgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,518,1427760000"; d="asc'?scan'208";a="420615531" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP; 29 May 2015 17:47:43 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4THlhwd032688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 17:47:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 29 May 2015 12:47:43 -0500 From: "Carlos Pignataro (cpignata)" To: Kathleen Moriarty Thread-Topic: Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmUU9UNzRkq1wJU2Wvlf+qhp5bp2Rv2+AgAAI/ICAAADkAIAAY4uAgAACqICAAANkgIAABgaAgAAB1ICAAAD1gIAAsgkAgABrDACAAAGjgIAACcWAgAADwgCAAAe7AIAAHjKAgAAAuICAAAHRgA== Date: Fri, 29 May 2015 17:47:42 +0000 Message-ID: <5DAF7D96-6665-487A-B86D-51734AF5D972@cisco.com> References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> <55681DCC.2000907@cs.tcd.ie> <55687798.8050804@joelhalpern.com> <556878F7.6030506@cs.tcd.ie> <55688129.4030200@joelhalpern.com> <55688450.4060605@cs.tcd.ie> <55688ACC.6070405@joelhalpern.com> <3F471674-BC7F-41BA-92C0-B3C2F207E481@gmail.com> In-Reply-To: <3F471674-BC7F-41BA-92C0-B3C2F207E481@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/signed; boundary="Apple-Mail=_229FDCC9-E23E-487F-813D-6E63B3D4C5A5"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 29 May 2015 10:52:23 -0700 Cc: "draft-ietf-sfc-architecture@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , "draft-ietf-sfc-architecture.ad@ietf.org" , Stephen Farrell , The IESG Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 17:51:19 -0000 --Apple-Mail=_229FDCC9-E23E-487F-813D-6E63B3D4C5A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 29, 2015, at 1:41 PM, Kathleen Moriarty = wrote: >=20 > Alia's text helps with my concern. We believe Alia=E2=80=99s text is mostly redundant and too verbose, = resulting in a low SNR. Let=E2=80=99s go back to your DISCUSS to understand your concern = again=E2=80=A6 although I feel we are starting to go in circles... =E2=80=9C1. The Security Considerations section only talks about privacy = of the SFC information for classification. The more important point may be the = privacy of any data gathered from a payload used for the classification and this = needs to be mentioned.=E2=80=9D The text that Alia provided seems to be covered by the second sentence = of the existing text here, and so does the information derived from = classification into metadata: SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP identification, and carries metadata. An operator may consider the SFC Metadata as sensitive. =46rom a privacy perspective, a user may be concerned about the operator revealing data about (and not belonging to) the customer. Therefore, solutions should consider whether there is a risk of sensitive information slipping out of the operators control. Issues of information exposure should also consider flow analysis. What=E2=80=99s missing again? Thank you, =E2=80=94 Carlos. > Let's keep this to Stephen's discuss points that I support. >=20 > Thank you, > Kathleen >=20 > Sent from my iPhone >=20 >> On May 29, 2015, at 1:38 PM, "Carlos Pignataro (cpignata)" = wrote: >>=20 >> Stephen, (and Kathleen, as this relates to the heart of your concern = as well), >>=20 >> Would that proposal below be the actionable middle-ground satisfying = your concerns? I would actually tweak a bit to say: >>=20 >> =E2=80=9CProtocols addressing this architecture must include adjunct = mechanisms to provide confidentiality and integrity of metadata carried = by the protocol, although implementation of such mechanisms may be = optional.=E2=80=9D >>=20 >> Please let us know =E2=80=94 thanks, >>=20 >> =E2=80=94 Carlos. >>=20 >>> On May 29, 2015, at 11:50 AM, Joel M. Halpern = wrote: >>>=20 >>> The document is a deliverable milestone intended to frame agreements = which will then guide the protocol design process. The protocol process = is going to try to move quickly. So we want this done, and argument = resolved, ASAP. >>>=20 >>> Would: >>>=20 >>> Protocols addressing this architecture must include mechanisms to = provide confidentiality and integrity of metadata carried by the = protocol, although implementation of such mechanisms may be optional. >>>=20 >>> be any better? I don't want to include data origin authentication = because that would require separate protection for each piece of = metadata (as they may come from separate sources). We already have size = concerns with this whole mechanism. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 5/29/15 11:22 AM, Stephen Farrell wrote: >>>>=20 >>>> Hiya, >>>>=20 >>>>> On 29/05/15 16:09, Joel Halpern Direct wrote: >>>>> I am not sure I like the following, but to try to move this = forward, would >>>>>=20 >>>>> Protocols addressing this architecture need to include definitions = for >>>>> how security services are provided with that solution, although >>>>> implementation of such mechanisms may be optional. >>>>=20 >>>> Sorry, I'm really not at all sure that's a good idea as I suspect >>>> it has too high a liklihood that those who want to see such work >>>> done, and those who don't, both read it and are not unhappy;-) >>>>=20 >>>> I'm not interested in trying to force the SFC WG to define some >>>> mythical security that never gets implemented really so I think >>>> maybe we'll be better off if we do enough of the analysis now(ish) >>>> to know that the architecture can say "protocols need to >>>> define a confidentiality service that can protect meta-data >>>> and a data-origin authentication services that can protect the >>>> SFC encapsulation." I do think that may need a bit more work >>>> though before one would be happy to put it out in the RFC. >>>> And one possible outcome of that work could be that it says >>>> instead "we know we do really need a confidentiality service >>>> but we can't see how that's practical right now" if that is >>>> in fact the case. (Which is possible, since these middle to >>>> middle confidentiality things are v. hard to do.) >>>>=20 >>>> BTW - is there a reason to want this document to proceed to >>>> be an RFC very quickly? If so, be good to know. If not, then >>>> we don't need to rush to a compromise that we might all be >>>> sad about later. >>>>=20 >>>> S. >>>>=20 >>>>>=20 >>>>> work for you? >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>> On 5/29/15 10:34 AM, Stephen Farrell wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On 29/05/15 15:28, Joel M. Halpern wrote: >>>>>>> Would you consider the following sentence pair that Carlos and I = have >>>>>>> been debating to be helpful: >>>>>>>=20 >>>>>>> =E2=80=9Csome protocols may optionally include confidentiality = provisions for >>>>>>> metadata and service function path identity, which may be used = in some >>>>>>> deployments. The architecture does not mandate such function.=E2=80= =9C >>>>>>=20 >>>>>> Not really no. I think that says nothing at all while at the same >>>>>> time having the ambiguity around the term "mandate" that I = pointed >>>>>> out below. >>>>>>=20 >>>>>> I have no clue why the SFC architecture cannot simply say that >>>>>> a confidentiality service needs to be defined. >>>>>>=20 >>>>>> S. >>>>>>=20 >>>>>>>=20 >>>>>>> ? >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>>> On 5/29/15 4:05 AM, Stephen Farrell wrote: >>>>>>>>=20 >>>>>>>> Joel, >>>>>>>>=20 >>>>>>>>> On 28/05/15 22:28, Joel M. Halpern wrote: >>>>>>>>> Enjoy the pub. >>>>>>>>=20 >>>>>>>> I did, of course:-) >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> No, I do not agree. I do not see that the archtiecture needs = to >>>>>>>>> mandate >>>>>>>>> a confidentiality service to protect the meta-data. >>>>>>>>=20 >>>>>>>> I'm sorry but that's just unhelpful. I did not speak of = mandating >>>>>>>> and doing so is simply to introduce a distracting negative = ambiguity. >>>>>>>>=20 >>>>>>>> I am discussing whether the architecture should call for a = protocol >>>>>>>> solution that has a well-defined way to provide confidentiality = and >>>>>>>> data origin authentication. Whether and when that may, should = or >>>>>>>> must be used is not a part of the architecture. >>>>>>>>=20 >>>>>>>> It will help the discussion if you are similarly precise. It = will >>>>>>>> IMO prove really hard to resolve the discussion if such = ambiguities >>>>>>>> are constantly introduced. (I have seen the same in response to = the >>>>>>>> secdir review where their suggestion that X be defined is met = with >>>>>>>> an objection to X being forced to be used all the time.) >>>>>>>>=20 >>>>>>>>> The data can only >>>>>>>>> leak across the kind of boundary you describe if the service = function >>>>>>>>> chooses to leak it. >>>>>>>>=20 >>>>>>>> Rubbish. If the protocol solution provides no confidentiality >>>>>>>> service for meta-data then the leakage is inevitable as there >>>>>>>> will be no possible alternative. >>>>>>>>=20 >>>>>>>> Yes a bad actor deploying can always leak, we are here = considering >>>>>>>> how to enable good actors to do the right thing. >>>>>>>>=20 >>>>>>>>> Given taht it will have to have access to the meta >>>>>>>>> data, no confidentiality mechanism will prevent that. >>>>>>>>>=20 >>>>>>>>> Note that the encrypted packet produced by the service = function is >>>>>>>>> addressed to some end point. I am failing to see how the = problem you >>>>>>>>> are asking us to address could arise. >>>>>>>>=20 >>>>>>>> Frankly, ISTM that you are doing more than that. My impression = is >>>>>>>> that you are opposed to defining a confidentiality service. I = would >>>>>>>> be happy to be corrected in that. >>>>>>>>=20 >>>>>>>> I do understand that calling for a confidentiality service does >>>>>>>> not mean that it will be easy to define a useful = confidentiality >>>>>>>> service. I am quite sure that the IETF could muck that up as we >>>>>>>> have done in the past (e.g. with SIP & S/MIME) but I am equally >>>>>>>> sure we could also succeed, and I think we should try and = indeed >>>>>>>> our BCPs call for us to do just that, once we recognise there = is >>>>>>>> a need for such a service. And that last is, I think, entirely >>>>>>>> clear. >>>>>>>>=20 >>>>>>>> S. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>>=20 >>>>>>>>>> On 5/28/15 5:24 PM, Stephen Farrell wrote: >>>>>>>>>>=20 >>>>>>>>>> Joel, >>>>>>>>>>=20 >>>>>>>>>> I'm afraid you've lost me again, but since it's now time for >>>>>>>>>> me to go to the pub, that's fine:-) >>>>>>>>>>=20 >>>>>>>>>> For me the important thing is if meta-data is inserted at A = and >>>>>>>>>> then packets are encrypted by something between B and C, then >>>>>>>>>> we do not want cleartext meta-data attached to the ciphertext >>>>>>>>>> sent from B to C to always have to risk making the encryption >>>>>>>>>> pointless. >>>>>>>>>>=20 >>>>>>>>>> To me, that means that this architecture needs to call for = the >>>>>>>>>> existence of a confidentiality service that can be used to >>>>>>>>>> protect at least the meta-data. (And it could protect more = too >>>>>>>>>> I guess but the details would be for the WG to figure later.) >>>>>>>>>>=20 >>>>>>>>>> I think additional scenarios can similarly justify a need for >>>>>>>>>> the definition of a data origin authentication service. >>>>>>>>>>=20 >>>>>>>>>> If we agreed about that and could move on to how that ought = be >>>>>>>>>> expressed in the arch document, that'd be great. (But as I'll >>>>>>>>>> be in the pub, I won't find out 'till tomorrow:-) >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>> S. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On 28/05/15 22:18, Joel M. Halpern wrote: >>>>>>>>>>> While SMTP servers are a bad example, service chaining can = be use >>>>>>>>>>> with >>>>>>>>>>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. >>>>>>>>>>> Both of >>>>>>>>>>> those terminate connections and create new packets. As = such, the >>>>>>>>>>> two >>>>>>>>>>> sides of such devices are on separate service chains. In = order for >>>>>>>>>>> the >>>>>>>>>>> two sides to be on the same chain, the service function = would >>>>>>>>>>> have to >>>>>>>>>>> copy the service chaining and related metadata from one side = to the >>>>>>>>>>> other. I can't stop them from doing so, but in most cases = it >>>>>>>>>>> would be >>>>>>>>>>> misleading. >>>>>>>>>>>=20 >>>>>>>>>>> What we have done is to recognize that these are generally = different >>>>>>>>>>> service chains. Because the packets will get different = treatments. >>>>>>>>>>>=20 >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>>=20 >>>>>>>>>>>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Joel, >>>>>>>>>>>>=20 >>>>>>>>>>>> If you are asserting that SFC cannot be used in a manner = that >>>>>>>>>>>> has the problem I was trying to exemplify then I have to = say, >>>>>>>>>>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>>>>>>>>>> is one of the examples cited in the arch draft, and there's >>>>>>>>>>>> not much difference between that and email from the = relevant >>>>>>>>>>>> perspective. >>>>>>>>>>>>=20 >>>>>>>>>>>> I also hope that I've succeeded in explaining the problem = as >>>>>>>>>>>> I see it. If not please ask and I'll try some more to = clarify. >>>>>>>>>>>> (Since you did not ask that, I assume you do get what I = mean, >>>>>>>>>>>> but it would be helpful if you would acknowledge that so we >>>>>>>>>>>> can communicate more easily.) >>>>>>>>>>>>=20 >>>>>>>>>>>> Can you point me at some piece of text in some draft that >>>>>>>>>>>> ensures that this problem cannot occur? If not, (which I >>>>>>>>>>>> think is the case), wouldn't we be better off acknowledging >>>>>>>>>>>> that it is an issue and one that needs to be tackled as >>>>>>>>>>>> best we can, as indeed Alia's earlier mail seems (to me) >>>>>>>>>>>> to suggest? >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> S. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>>>>>>>>>> That case would not occur within a service chain. >>>>>>>>>>>>> A service chain is about delivery of a packet to a series = of >>>>>>>>>>>>> services to >>>>>>>>>>>>> which it is not addressed (generally followed by delivery = to the >>>>>>>>>>>>> target >>>>>>>>>>>>> to which it is addressed.) >>>>>>>>>>>>> An SMTP server relaying email produces separate packets. = The >>>>>>>>>>>>> packets >>>>>>>>>>>>> from the user to the SMTP server are on one chain. The = packets >>>>>>>>>>>>> from >>>>>>>>>>>>> that server to another are completely separate, and on a = different >>>>>>>>>>>>> chain. As such, those TLS SMTP packets between the = servers would >>>>>>>>>>>>> not >>>>>>>>>>>>> have any metadata from the first transfer. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Mail servers are not SFC service functions. The only time = it gets >>>>>>>>>>>>> close >>>>>>>>>>>>> is when you are doing port 25 redirection, and then the = service >>>>>>>>>>>>> chain >>>>>>>>>>>>> ends at the mail server. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>>>>>>>>>> IF A, B, and C are service function forwarders (SFF), = with a TLS >>>>>>>>>>>>>>> protected link for SFC, then the metadata will be = protected. >>>>>>>>>>>>>>> (Such a >>>>>>>>>>>>>>> link would be a transport mechanism, which SFC does not >>>>>>>>>>>>>>> describe or >>>>>>>>>>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ah, no the scenario I was thinking about is where, from >>>>>>>>>>>>>> the perspective of SFC, the TLS packets are the payload >>>>>>>>>>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>>>>>>>>>> servers with starttls only turned on between B and C >>>>>>>>>>>>>> because that link is "external" (though within the same >>>>>>>>>>>>>> administrative domain). If some SFC thing at A were to >>>>>>>>>>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>>>>>>>>>> data then we wouldn't want that sent in clear from B to C >>>>>>>>>>>>>> because of the SFC encapsulation, right? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> S. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> If A, B, and C are service functions used by SFC, then = there >>>>>>>>>>>>>>> is no >>>>>>>>>>>>>>> link >>>>>>>>>>>>>>> between B and C, so it can't be protected by TLS. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> So I can not see what more needs to be said? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>>>>>>>>>> I am not sure what you mean by "Metadata that contains >>>>>>>>>>>>>>>>> information >>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> is protected in the data plane". Most of what ends up = in the >>>>>>>>>>>>>>>>> metadata >>>>>>>>>>>>>>>>> is information that is passed on other interfaces = directly to >>>>>>>>>>>>>>>>> relevant >>>>>>>>>>>>>>>>> functions, or locally determine and locally processed. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> So what I had in mind were things like the following. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>>>>>>>>>> - B to C link is via say a TLS VPN >>>>>>>>>>>>>>>> - Metadata is created at A and is in the SFC = encapsulation >>>>>>>>>>>>>>>> and not protected by the VPN >>>>>>>>>>>>>>>> - That seems bad >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> S. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The protection used for policy systems (which provide = much of >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> information) is based on the presence of persistent >>>>>>>>>>>>>>>>> connections >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> usage which crosses domains. Are you arguing that if = AAA is >>>>>>>>>>>>>>>>> encrypted >>>>>>>>>>>>>>>>> then policy delivered by AAA resulting in metadata in = the >>>>>>>>>>>>>>>>> packet >>>>>>>>>>>>>>>>> must be >>>>>>>>>>>>>>>>> encrypted in the data packets? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>>>>>>>>>> Stephen Farrell has entered the following ballot = position for >>>>>>>>>>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> When responding, please keep the subject line intact = and >>>>>>>>>>>>>>>>>> reply >>>>>>>>>>>>>>>>>> to all >>>>>>>>>>>>>>>>>> email addresses included in the To and CC lines. = (Feel >>>>>>>>>>>>>>>>>> free to >>>>>>>>>>>>>>>>>> cut >>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Please refer to >>>>>>>>>>>>>>>>>> = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>>>>>>>>>> for more information about IESG DISCUSS and COMMENT >>>>>>>>>>>>>>>>>> positions. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> The document, along with other ballot positions, can = be found >>>>>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>>>>> = https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> DISCUSS: >>>>>>>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> (1) I note the charter calls for this deliverable to = "provide >>>>>>>>>>>>>>>>>> a description of... security models" The charter also >>>>>>>>>>>>>>>>>> generally notes that "The SFC WG will closely = consider and >>>>>>>>>>>>>>>>>> address the management and security implications when >>>>>>>>>>>>>>>>>> documenting these deliverables." My conclusion is = that this >>>>>>>>>>>>>>>>>> deliverable needs to reflect the results of a = security >>>>>>>>>>>>>>>>>> analysis that the wg are suppoed to have carried out = but that >>>>>>>>>>>>>>>>>> it's currently too vague only saying that solutions = need to >>>>>>>>>>>>>>>>>> consider this. (Essentially this is a continuation of = the >>>>>>>>>>>>>>>>>> mail threads from the secdir review [1] and a = satisfactory >>>>>>>>>>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>> = https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> (2) Metadata that contains information that is = protected in >>>>>>>>>>>>>>>>>> the data plane SHOULD be equally well protected when = passed >>>>>>>>>>>>>>>>>> about by SFC. I hope that's acceptable and = documented. I'm >>>>>>>>>>>>>>>>>> not sure myself if "passed about" ought also include = within a >>>>>>>>>>>>>>>>>> device but maybe it should really. But at minimum, I = do >>>>>>>>>>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>>>>>>>>>> authentication services for SFC metadata and/or for = the SFC >>>>>>>>>>>>>>>>>> encapsulation as a whole. And I think this = architecture >>>>>>>>>>>>>>>>>> document needs to say that those services have to be >>>>>>>>>>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>>>>>>>>>> saying that this draft needs to define how to do = those.) >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - It occurs to me that it might really be better for = the WG >>>>>>>>>>>>>>>>>> to not publish this as an RFC now, but rather to put = it on >>>>>>>>>>>>>>>>>> hold until they've made progress on the solutions. = Perhaps >>>>>>>>>>>>>>>>>> revistiting this when the solutions are just at WGLC = would >>>>>>>>>>>>>>>>>> result in the eventual RFC being a much more useful = document. >>>>>>>>>>>>>>>>>> I think this one has to hedge so many bets that it's = quite >>>>>>>>>>>>>>>>>> vague and won't be very useful even in the medium = term. But >>>>>>>>>>>>>>>>>> that's just a suggestion, I can see why the WG might = prefer >>>>>>>>>>>>>>>>>> to push this out, even if that might only give the = appearance >>>>>>>>>>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - While IPR on an architecture document is sad to = see, esp >>>>>>>>>>>>>>>>>> with what seems like it may be restrictive licensing, = I do >>>>>>>>>>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - The charter text describing this deliverable notes = that >>>>>>>>>>>>>>>>>> "The initial scope is restricted to a single = administrative >>>>>>>>>>>>>>>>>> domain, keeping in mind that architectural decisions = made for >>>>>>>>>>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>>>>>>>>>> inter-domain case." So I think there is also a = currently >>>>>>>>>>>>>>>>>> missing analysis (or the results of that) as to how = the >>>>>>>>>>>>>>>>>> single-domain elements of this architecture might = impinge on >>>>>>>>>>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>>>>>>>>>> end of section 1.1 appears to contradict the = chartered >>>>>>>>>>>>>>>>>> goals. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - Chains will require some representation, and = re-ordering >>>>>>>>>>>>>>>>>> that is security sensitive (e.g. swap order of f/w = and nat >>>>>>>>>>>>>>>>>> for fun) therefore there must be a requirement for = some data >>>>>>>>>>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>>>>>>>>>> authorisation decision function and therefore there = must >>>>>>>>>>>>>>>>>> (istm) be a need for the architecture to define a = chain >>>>>>>>>>>>>>>>>> producing entity of some kind that could be = authenticated. >>>>>>>>>>>>>>>>>> That is an example of the missing security analysis = that >>>>>>>>>>>>>>>>>> really is needed before this proceeds. (See my = discuss point >>>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - 1.1: "classified on ingress" and applicable to = mobile >>>>>>>>>>>>>>>>>> networks are slightly incongrous. In the case of WiFi = when do >>>>>>>>>>>>>>>>>> the packet ingress? (When it gets to the AP or leaves = the >>>>>>>>>>>>>>>>>> mobile node transmitter?) I suspect you really mean = the wired >>>>>>>>>>>>>>>>>> bits of a mobile network so it might be better to say = that. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - 1.2: What does "chaining logic" mean? You say = there's no >>>>>>>>>>>>>>>>>> standard chaining logic, which is maybe right, but = then you >>>>>>>>>>>>>>>>>> imply that a fully ordered set of SF's is a well = defined >>>>>>>>>>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what = you want >>>>>>>>>>>>>>>>>> to say is that the architecture doesn't determine if = an SFC >>>>>>>>>>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that = later >>>>>>>>>>>>>>>>>> protocol work will have to do that. (In fact, I think = you >>>>>>>>>>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where = those >>>>>>>>>>>>>>>>>> terms need to be defined. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully = or >>>>>>>>>>>>>>>>>> partially ordered? >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be = standardising that >>>>>>>>>>>>>>>>>> (cf. RFC2804) so better to not drag in the = controversy >>>>>>>>>>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any = kind of >>>>>>>>>>>>>>>>>> standard and perhaps not likely to be (cf. some = confict >>>>>>>>>>>>>>>>>> reviews on the same telechat as this) so I'd also = drop that. >>>>>>>>>>>>>>>>>> And I think all of the exemplar SF's should really = have a >>>>>>>>>>>>>>>>>> reference (ideally an RFC). >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - Figure 1 caption is misleading. That seems to me to = show a >>>>>>>>>>>>>>>>>> set of paths through (one or more) graphs but doesn't = show >>>>>>>>>>>>>>>>>> the full graphs themselves. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. = Does >>>>>>>>>>>>>>>>>> the example given imply that all traffic (of what = kind?) that >>>>>>>>>>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think = more >>>>>>>>>>>>>>>>>> precision is needed really. The hybrid concept seems = even >>>>>>>>>>>>>>>>>> odder to me. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point = of an >>>>>>>>>>>>>>>>>> architecture is to avoid such vagueness? If you mean = that an >>>>>>>>>>>>>>>>>> SFP representation can embody an if-statement then = saying >>>>>>>>>>>>>>>>>> that would be the thing to do. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - Section 3: I think there's maybe a missing = principle here >>>>>>>>>>>>>>>>>> about not making security and privacy worse in = general. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC = control >>>>>>>>>>>>>>>>>> traffic that congestion would be an issue? If so, = should you >>>>>>>>>>>>>>>>>> say rather that any transport that has some way of = handling >>>>>>>>>>>>>>>>>> congestion is ok. If not, then I guess the current = text is >>>>>>>>>>>>>>>>>> fine. >>=20 --Apple-Mail=_229FDCC9-E23E-487F-813D-6E63B3D4C5A5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVaKZAAAoJEIXgpQGOZny9cXMP/1gYhG3tO9QCN5x+aQS57hvl NtwzUf3E0WWo+IdEA0DY38klgWXkDfUEVBzwT/FXz5valh2JOtbLRH7bLeG3QK6e CU/wU9POZBzE3+H30xKQiIsBNEfUNIbLUFblZolHtQD1JV7hmlLnro40+VxCTe1N pM3PNAfqrHk63zGCcNAewRjuVchohercRsT4NbLcVBH0HxUwnWrGsW8ni4ESWdCB k7/3XaZQhallAwpRcpTK/teBmwn2+aUtw/4pbpv7hUbb0zrBmjjnxEKB9dn3/Q8v ihBzVuepdMVwTY3KXRBo+hkX5XtAjdsQAzQCecmtpc6CmlZd02znCGtCT3ufUy6k ZpoZRVrzpPXlroEXYgw5CwbsgfUv/p32+iGzIrGRhzPyKB1mwLAFUTt1dupK3f8a Ix2peLUeCm0baDWUFmZnPiSdFf8Zd8JOUtQIKmNv/alZCfGVrOyS0Nd606LCuN5K 8CqqI/LJadVrNj8B3pYrItppdK7XWx4OacbKpoH6f0B/7qShkBrfme+7TvTshMeH s5cZ6Ep5DfHf1/CUtz+QsIRLdYHq1ldxXwTr35li7DhYgyX68mN9XzrlV+KYXoXL CbYHy9u+tWXSpPanwlUFUGhHmomiyWCmrACDw6Plet9mKfpFLXamC/W5aPQDPZpc 1mbDg5+KSBwMJObgdzCC =apo5 -----END PGP SIGNATURE----- --Apple-Mail=_229FDCC9-E23E-487F-813D-6E63B3D4C5A5-- From nobody Fri May 29 10:53:02 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8171A7009; Fri, 29 May 2015 10:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 bJOE3Qv5TTKi; Fri, 29 May 2015 10:52:55 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77DA71B2BBF; Fri, 29 May 2015 10:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9532; q=dns/txt; s=iport; t=1432921805; x=1434131405; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VDnbeS8n9DHsJlF9noWb2Jtz07XMgqsIHhPY1GaNU/U=; b=CUeHBwOiDVibh7VQ72lALcqdaDbg4T49fUvf8ttGU84sAddH8XqRRdn1 Rbfad/HhL7H0gMe+dnXHmEWyQzD1sJ2OgutWZVrEddweGK+bhySyn1DBb F6gtig80Qj2sHVInxfWbvIJNiUa2xwuqxHdtcTdMcV48CYK/GZcLxytk4 g=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A1BACwpWhV/4gNJK1cgkVLgSUNBoMYuiJmCYdRAoFHOBQBAQEBAQEBgQqEIgEBAQMBI1YFCwIBCBIGKgICMhcOAgQOBQ6IFwixNKN6AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tDhQYHgmgvgRYFhmuJY4I8ghKBQ4c9gSmDcZIYI2GBKRwVgT1vgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,518,1427760000"; d="asc'?scan'208,217";a="154670578" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 29 May 2015 17:50:04 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4THo3kh003973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 17:50:03 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Fri, 29 May 2015 12:50:03 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" Thread-Topic: Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmOrEEsv6EGLzPU647i5P9hxl1Z2TkccA Date: Fri, 29 May 2015 17:50:02 +0000 Message-ID: <14577D29-8E3F-4F82-BA93-964D1D9D5DC3@cisco.com> References: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> In-Reply-To: <20150528020523.4847.77039.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/signed; boundary="Apple-Mail=_9BA2D448-EB64-404E-90FB-A5ACF469C1DE"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 17:52:57 -0000 --Apple-Mail=_9BA2D448-EB64-404E-90FB-A5ACF469C1DE Content-Type: multipart/alternative; boundary="Apple-Mail=_9B7D5798-A3F0-4B3A-AB6E-EF8E396EF4FE" --Apple-Mail=_9B7D5798-A3F0-4B3A-AB6E-EF8E396EF4FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alvaro, Alia, Happy Friday! > On May 27, 2015, at 10:05 PM, Alvaro Retana (aretana) = wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I want to talk about the intended status of this document: right now > (-08) it is marked as Informational, but up to -06 it was intended to = be > on the Standards Track. Why did this change? [I looked at the = archives, > but couldn=E2=80=99t find a specific reason or discussion.] Are there any conclusions from the teletext that would guide the = intended status of this architecture? Please let us know =E2=80=94 thanks! =E2=80=94 Carlos. --Apple-Mail=_9B7D5798-A3F0-4B3A-AB6E-EF8E396EF4FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Alvaro, Alia,

Happy Friday!

On = May 27, 2015, at 10:05 PM, Alvaro Retana (aretana) <aretana@cisco.com> = wrote:

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

I want to talk about the = intended status of this document: right now
(-08) it is marked as Informational, but up to = -06 it was intended to be
on the Standards Track. =  Why did this change?  [I looked at the archives,
but couldn=E2=80=99t find a specific reason or = discussion.]

Are there any conclusions from the teletext = that would guide the intended status of this architecture?

Please let us know =E2=80=94= thanks!

=E2=80=94= Carlos.

= --Apple-Mail=_9B7D5798-A3F0-4B3A-AB6E-EF8E396EF4FE-- --Apple-Mail=_9BA2D448-EB64-404E-90FB-A5ACF469C1DE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVaKbNAAoJEIXgpQGOZny9X6cP/1bpJs9huELMJlIffwJ6OHZk rpbZadhVWcmQeX/NLE3P/ahC4E6xJwdBYjk2o4rHLU3KAceyjP6QAA9avMRdqgyv bvCf5Jz5/eUmCn7R498cRFIANi+StOv8n6KGEJEw6ij48ic/uj4Z9ZXVDSHZwRwj 7WH9gmjFF8XjdrSUHajfI+bq0pH1ov4JxOZw+ead71hgsiqVbF2sAyXp9xZIqJSi n0mf1G8IBjlWWqI4cBR8dcojCuj5POtUwaMmIxeZW/DpI7+vppBzeSJeiZ0n8o2L xwMKcfzTDmVcVnTBiEfrmHCVQX8hWjfXYKJa706RjTaXNCVDtU5zC7jCmpxfzZ/3 fVtjE2MsECgsp8r48FmDkqwrtQ3fZmeqWZ/imR1H6DlOUC0nyP1EHunxLfQ7w8u5 GBtL2pwE2VRaANEfzFIMqWJogSUf5wCdtXlHipBMLq9UWXM4CMs215+nxoClc4ZO WwMF5U2m/raqQI4hCgwuOXqHaUJHmohdu3RRvgKAYb/RRIAFyWJkcTU5QkXLdgp3 C5NE1BfFaoiMnEIN8ccCO25jjn+AtY/Ds1PCpyaLL7QHV7mvc/LEDXmbWEbb/MFL DvpqmmCkyqkFiF8/VoG2OMYSY1dpt5u1yHT0yDRd+Xtu0CAb5geUoQal1NDdjYQ0 niLyU9Jy/U9QlNxsrSAC =zMSa -----END PGP SIGNATURE----- --Apple-Mail=_9BA2D448-EB64-404E-90FB-A5ACF469C1DE-- From nobody Fri May 29 13:42:39 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0991B2D15 for ; Fri, 29 May 2015 13:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 aTb_9CK0pZK5 for ; Fri, 29 May 2015 13:42:30 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05D1B2D0C for ; Fri, 29 May 2015 13:42:30 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.178) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 29 May 2015 16:42:29 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Fri, 29 May 2015 16:42:29 -0400 From: Dave Dolson To: "sfc@ietf.org" , "hongyu.li@huawei.com" , "bill.wu@huawei.com" , "oliver.huang@huawei.com" , "mohamed.boucadair@orange.com" , "christian.jacquenet@orange.com" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "ron_parker@affirmednetworks.com" Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eA== Date: Fri, 29 May 2015 20:42:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830C1CB3Ewtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 20:42:33 -0000 --_000_E8355113905631478EFF04F5AA706E9830C1CB3Ewtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors of draft-ww-sfc-control-plane, I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control-pla= ne-04 I have some very high-level suggestions: 1. I believe the "F" interface should be split into two interfaces. O= ne for performance monitoring (availability and workload were cited), and o= ne for updating classification information. Call these F1 and F2, I suppose. My reasons are that (a) as a general princ= iple, interfaces should not have multiple purposes and (b) F1 and F2 could = be communicating to different control-plane managers. 2. A control interface is required to SF components. Call it C3. This= interface is required to (a) inform the SF about bidirectional chains (i.e= ., which Path IDs are paired) and (b) inform the SF about semantics of type= s of meta-data. C3 should also be connected to the SFC Proxy. I propose: 4.5 C3 Interface A service function may need information about the service paths passing through it, and may need information about specific meta-data types attached to packets on the paths. Some types of SF might be agnostic about the paths traversing them, but most transport-layer-flow-aware devices will require this configuration. When bidirectional chains are deployed, the C3 interface provisions each SF with each path identifier/path index pair that will pass through= . Each such pair is associated with an opposite-direction pair of identifier/index. Meta-data is for the benefit of SFs. The C3 interface informs the SF about the semantics of the meta-data, which would otherwise have opaque meaning. Meta-data attributes include "scope" (per-packet, per-fl= ow or per host), "mandatory" (must be understood), "bidirectional" (same value may be used in both directions), "is_qualifier" (indicates a distinct routing domain). I think there is quite a bit to explore, but I believe this starts the disc= ussion. Thoughts? David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830C1CB3Ewtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors of draft-ww-sfc-control-plane,

 

I’ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04

 

I have some very high-level suggestions:<= /p>

 

1.     &= nbsp; I believe the “F” interface should be s= plit into two interfaces. One for performance monitoring (availability and = workload were cited), and one for updating classification information.=

Call these F1 and F2, I suppose. My reasons a= re that (a) as a general principle, interfaces should not have multiple pur= poses and (b) F1 and F2 could be communicating to different control-plane m= anagers.

 

2.     &= nbsp; A control interface is required to SF components. C= all it C3. This interface is required to (a) inform the SF about bidirectio= nal chains (i.e., which Path IDs are paired) and (b) inform the SF about se= mantics of types of meta-data. C3 should also be connected to the SFC Proxy.

 

I propose:

 

= 4.5  C3 Interface

=  

=    A service function may need information about the service path= s

=    passing through it, and may need information about specific me= ta-data

=    types attached to packets on the paths.

=  

=    Some types of SF might be agnostic about the paths traversing = them, but

=    most transport-layer-flow-aware devices will require this conf= iguration.

=  

=    When bidirectional chains are deployed, the C3 interface provi= sions

=    each SF with each path identifier/path index pair that will pa= ss through.

=    Each such pair is associated with an opposite-direction pair o= f

=    identifier/index.

=  

=    Meta-data is for the benefit of SFs. The C3 interface informs = the SF

=    about the semantics of the meta-data, which would otherwise ha= ve

=    opaque meaning. Meta-data attributes include "scope"= (per-packet, per-flow

=    or per host), "mandatory" (must be understood), &quo= t;bidirectional" (same

=    value may be used in both directions), "is_qualifier"= ; (indicates a

=    distinct routing domain).

=  

 

I think there is quite a bit to explore, but I belie= ve this starts the discussion.

Thoughts?

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_E8355113905631478EFF04F5AA706E9830C1CB3Ewtlexchp2sandvi_-- From nobody Fri May 29 14:20:35 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF7B1B2D99; Fri, 29 May 2015 14:20:30 -0700 (PDT) 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, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 DJk7DjDEGSJC; Fri, 29 May 2015 14:20:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A211B2D91; Fri, 29 May 2015 14:20:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B57C3BF19; Fri, 29 May 2015 22:20:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ802fJq_D85; Fri, 29 May 2015 22:20:19 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB28EBF0F; Fri, 29 May 2015 22:20:18 +0100 (IST) Message-ID: <5568D812.8040701@cs.tcd.ie> Date: Fri, 29 May 2015 22:20:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , The IESG References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <55672033.4000201@joelhalpern.com> <556727BD.3080309@cs.tcd.ie> <5567287C.6080905@joelhalpern.com> <55677BFD.5030808@cs.tcd.ie> <55677E37.1070203@joelhalpern.com> <5567810F.9020207@cs.tcd.ie> <5567861D.9020301@joelhalpern.com> <556787A5.9050808@cs.tcd.ie> <55678873.3090802@joelhalpern.com> <55681DCC.2000907@cs.tcd.ie> <55687798.8050804@joelhalpern.com> <556878F7.6030506@cs.tcd.ie> <55688129.4030200@joelhalpern.com> <55688450.4060605@cs.tcd.ie> <55688ACC.6070405@joelhalpern.com> In-Reply-To: <55688ACC.6070405@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 21:20:30 -0000 On 29/05/15 16:50, Joel M. Halpern wrote: > The document is a deliverable milestone intended to frame agreements > which will then guide the protocol design process. The protocol process > is going to try to move quickly. So we want this done, and argument > resolved, ASAP. > > Would: > > Protocols addressing this architecture must include mechanisms to > provide confidentiality and integrity of metadata carried by the > protocol, although implementation of such mechanisms may be optional. > > be any better? I don't want to include data origin authentication > because that would require separate protection for each piece of > metadata (as they may come from separate sources). We already have size > concerns with this whole mechanism. I'd need to think a bit about origin-auth vs. (presumably) hob-by-hop integrity (maybe via AEAD), but it's a good question. Has someone done an analysis on the relevant threats? S. > > Yours, > Joel > > On 5/29/15 11:22 AM, Stephen Farrell wrote: >> >> Hiya, >> >> On 29/05/15 16:09, Joel Halpern Direct wrote: >>> I am not sure I like the following, but to try to move this forward, >>> would >>> >>> Protocols addressing this architecture need to include definitions for >>> how security services are provided with that solution, although >>> implementation of such mechanisms may be optional. >> >> Sorry, I'm really not at all sure that's a good idea as I suspect >> it has too high a liklihood that those who want to see such work >> done, and those who don't, both read it and are not unhappy;-) >> >> I'm not interested in trying to force the SFC WG to define some >> mythical security that never gets implemented really so I think >> maybe we'll be better off if we do enough of the analysis now(ish) >> to know that the architecture can say "protocols need to >> define a confidentiality service that can protect meta-data >> and a data-origin authentication services that can protect the >> SFC encapsulation." I do think that may need a bit more work >> though before one would be happy to put it out in the RFC. >> And one possible outcome of that work could be that it says >> instead "we know we do really need a confidentiality service >> but we can't see how that's practical right now" if that is >> in fact the case. (Which is possible, since these middle to >> middle confidentiality things are v. hard to do.) >> >> BTW - is there a reason to want this document to proceed to >> be an RFC very quickly? If so, be good to know. If not, then >> we don't need to rush to a compromise that we might all be >> sad about later. >> >> S. >> >>> >>> work for you? >>> Yours, >>> Joel >>> >>> On 5/29/15 10:34 AM, Stephen Farrell wrote: >>>> >>>> >>>> On 29/05/15 15:28, Joel M. Halpern wrote: >>>>> Would you consider the following sentence pair that Carlos and I have >>>>> been debating to be helpful: >>>>> >>>>> “some protocols may optionally include confidentiality provisions for >>>>> metadata and service function path identity, which may be used in some >>>>> deployments. The architecture does not mandate such function.“ >>>> >>>> Not really no. I think that says nothing at all while at the same >>>> time having the ambiguity around the term "mandate" that I pointed >>>> out below. >>>> >>>> I have no clue why the SFC architecture cannot simply say that >>>> a confidentiality service needs to be defined. >>>> >>>> S. >>>> >>>>> >>>>> ? >>>>> Yours, >>>>> Joel >>>>> >>>>> On 5/29/15 4:05 AM, Stephen Farrell wrote: >>>>>> >>>>>> Joel, >>>>>> >>>>>> On 28/05/15 22:28, Joel M. Halpern wrote: >>>>>>> Enjoy the pub. >>>>>> >>>>>> I did, of course:-) >>>>>> >>>>>>> >>>>>>> No, I do not agree. I do not see that the archtiecture needs to >>>>>>> mandate >>>>>>> a confidentiality service to protect the meta-data. >>>>>> >>>>>> I'm sorry but that's just unhelpful. I did not speak of mandating >>>>>> and doing so is simply to introduce a distracting negative ambiguity. >>>>>> >>>>>> I am discussing whether the architecture should call for a protocol >>>>>> solution that has a well-defined way to provide confidentiality and >>>>>> data origin authentication. Whether and when that may, should or >>>>>> must be used is not a part of the architecture. >>>>>> >>>>>> It will help the discussion if you are similarly precise. It will >>>>>> IMO prove really hard to resolve the discussion if such ambiguities >>>>>> are constantly introduced. (I have seen the same in response to the >>>>>> secdir review where their suggestion that X be defined is met with >>>>>> an objection to X being forced to be used all the time.) >>>>>> >>>>>>> The data can only >>>>>>> leak across the kind of boundary you describe if the service >>>>>>> function >>>>>>> chooses to leak it. >>>>>> >>>>>> Rubbish. If the protocol solution provides no confidentiality >>>>>> service for meta-data then the leakage is inevitable as there >>>>>> will be no possible alternative. >>>>>> >>>>>> Yes a bad actor deploying can always leak, we are here considering >>>>>> how to enable good actors to do the right thing. >>>>>> >>>>>>> Given taht it will have to have access to the meta >>>>>>> data, no confidentiality mechanism will prevent that. >>>>>>> >>>>>>> Note that the encrypted packet produced by the service function is >>>>>>> addressed to some end point. I am failing to see how the problem >>>>>>> you >>>>>>> are asking us to address could arise. >>>>>> >>>>>> Frankly, ISTM that you are doing more than that. My impression is >>>>>> that you are opposed to defining a confidentiality service. I would >>>>>> be happy to be corrected in that. >>>>>> >>>>>> I do understand that calling for a confidentiality service does >>>>>> not mean that it will be easy to define a useful confidentiality >>>>>> service. I am quite sure that the IETF could muck that up as we >>>>>> have done in the past (e.g. with SIP & S/MIME) but I am equally >>>>>> sure we could also succeed, and I think we should try and indeed >>>>>> our BCPs call for us to do just that, once we recognise there is >>>>>> a need for such a service. And that last is, I think, entirely >>>>>> clear. >>>>>> >>>>>> S. >>>>>> >>>>>> >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 5/28/15 5:24 PM, Stephen Farrell wrote: >>>>>>>> >>>>>>>> Joel, >>>>>>>> >>>>>>>> I'm afraid you've lost me again, but since it's now time for >>>>>>>> me to go to the pub, that's fine:-) >>>>>>>> >>>>>>>> For me the important thing is if meta-data is inserted at A and >>>>>>>> then packets are encrypted by something between B and C, then >>>>>>>> we do not want cleartext meta-data attached to the ciphertext >>>>>>>> sent from B to C to always have to risk making the encryption >>>>>>>> pointless. >>>>>>>> >>>>>>>> To me, that means that this architecture needs to call for the >>>>>>>> existence of a confidentiality service that can be used to >>>>>>>> protect at least the meta-data. (And it could protect more too >>>>>>>> I guess but the details would be for the WG to figure later.) >>>>>>>> >>>>>>>> I think additional scenarios can similarly justify a need for >>>>>>>> the definition of a data origin authentication service. >>>>>>>> >>>>>>>> If we agreed about that and could move on to how that ought be >>>>>>>> expressed in the arch document, that'd be great. (But as I'll >>>>>>>> be in the pub, I won't find out 'till tomorrow:-) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> S. >>>>>>>> >>>>>>>> >>>>>>>> On 28/05/15 22:18, Joel M. Halpern wrote: >>>>>>>>> While SMTP servers are a bad example, service chaining can be use >>>>>>>>> with >>>>>>>>> HTTP inserted (quasi-trasnparent) proxies or TCP optimizers. >>>>>>>>> Both of >>>>>>>>> those terminate connections and create new packets. As such, the >>>>>>>>> two >>>>>>>>> sides of such devices are on separate service chains. In order >>>>>>>>> for >>>>>>>>> the >>>>>>>>> two sides to be on the same chain, the service function would >>>>>>>>> have to >>>>>>>>> copy the service chaining and related metadata from one side to >>>>>>>>> the >>>>>>>>> other. I can't stop them from doing so, but in most cases it >>>>>>>>> would be >>>>>>>>> misleading. >>>>>>>>> >>>>>>>>> What we have done is to recognize that these are generally >>>>>>>>> different >>>>>>>>> service chains. Because the packets will get different >>>>>>>>> treatments. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 5/28/15 4:56 PM, Stephen Farrell wrote: >>>>>>>>>> >>>>>>>>>> Joel, >>>>>>>>>> >>>>>>>>>> If you are asserting that SFC cannot be used in a manner that >>>>>>>>>> has the problem I was trying to exemplify then I have to say, >>>>>>>>>> I'm skeptical. I also note that so-called HTTP "enrichment" >>>>>>>>>> is one of the examples cited in the arch draft, and there's >>>>>>>>>> not much difference between that and email from the relevant >>>>>>>>>> perspective. >>>>>>>>>> >>>>>>>>>> I also hope that I've succeeded in explaining the problem as >>>>>>>>>> I see it. If not please ask and I'll try some more to clarify. >>>>>>>>>> (Since you did not ask that, I assume you do get what I mean, >>>>>>>>>> but it would be helpful if you would acknowledge that so we >>>>>>>>>> can communicate more easily.) >>>>>>>>>> >>>>>>>>>> Can you point me at some piece of text in some draft that >>>>>>>>>> ensures that this problem cannot occur? If not, (which I >>>>>>>>>> think is the case), wouldn't we be better off acknowledging >>>>>>>>>> that it is an issue and one that needs to be tackled as >>>>>>>>>> best we can, as indeed Alia's earlier mail seems (to me) >>>>>>>>>> to suggest? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> S. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 28/05/15 21:44, Joel Halpern Direct wrote: >>>>>>>>>>> That case would not occur within a service chain. >>>>>>>>>>> A service chain is about delivery of a packet to a series of >>>>>>>>>>> services to >>>>>>>>>>> which it is not addressed (generally followed by delivery to >>>>>>>>>>> the >>>>>>>>>>> target >>>>>>>>>>> to which it is addressed.) >>>>>>>>>>> An SMTP server relaying email produces separate packets. The >>>>>>>>>>> packets >>>>>>>>>>> from the user to the SMTP server are on one chain. The packets >>>>>>>>>>> from >>>>>>>>>>> that server to another are completely separate, and on a >>>>>>>>>>> different >>>>>>>>>>> chain. As such, those TLS SMTP packets between the servers >>>>>>>>>>> would >>>>>>>>>>> not >>>>>>>>>>> have any metadata from the first transfer. >>>>>>>>>>> >>>>>>>>>>> Mail servers are not SFC service functions. The only time it >>>>>>>>>>> gets >>>>>>>>>>> close >>>>>>>>>>> is when you are doing port 25 redirection, and then the service >>>>>>>>>>> chain >>>>>>>>>>> ends at the mail server. >>>>>>>>>>> >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>> >>>>>>>>>>> On 5/28/15 4:35 PM, Stephen Farrell wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 28/05/15 15:38, Joel M. Halpern wrote: >>>>>>>>>>>>> IF A, B, and C are service function forwarders (SFF), with >>>>>>>>>>>>> a TLS >>>>>>>>>>>>> protected link for SFC, then the metadata will be protected. >>>>>>>>>>>>> (Such a >>>>>>>>>>>>> link would be a transport mechanism, which SFC does not >>>>>>>>>>>>> describe or >>>>>>>>>>>>> mandate. The SFC architecture is transport agnostic.) >>>>>>>>>>>> >>>>>>>>>>>> Ah, no the scenario I was thinking about is where, from >>>>>>>>>>>> the perspective of SFC, the TLS packets are the payload >>>>>>>>>>>> that is encapsulated. I guess A, B and C could be mail >>>>>>>>>>>> servers with starttls only turned on between B and C >>>>>>>>>>>> because that link is "external" (though within the same >>>>>>>>>>>> administrative domain). If some SFC thing at A were to >>>>>>>>>>>> dive into the SMTP traffic and pull out sensitive meta0 >>>>>>>>>>>> data then we wouldn't want that sent in clear from B to C >>>>>>>>>>>> because of the SFC encapsulation, right? >>>>>>>>>>>> >>>>>>>>>>>> S. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If A, B, and C are service functions used by SFC, then there >>>>>>>>>>>>> is no >>>>>>>>>>>>> link >>>>>>>>>>>>> between B and C, so it can't be protected by TLS. >>>>>>>>>>>>> >>>>>>>>>>>>> So I can not see what more needs to be said? >>>>>>>>>>>>> >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>> >>>>>>>>>>>>> On 5/28/15 10:35 AM, Stephen Farrell wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 28/05/15 15:03, Joel M. Halpern wrote: >>>>>>>>>>>>>>> I am not sure what you mean by "Metadata that contains >>>>>>>>>>>>>>> information >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> is protected in the data plane". Most of what ends up in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> metadata >>>>>>>>>>>>>>> is information that is passed on other interfaces >>>>>>>>>>>>>>> directly to >>>>>>>>>>>>>>> relevant >>>>>>>>>>>>>>> functions, or locally determine and locally processed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So what I had in mind were things like the following. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Packet is sent along a SFP A,B,C >>>>>>>>>>>>>> - B to C link is via say a TLS VPN >>>>>>>>>>>>>> - Metadata is created at A and is in the SFC encapsulation >>>>>>>>>>>>>> and not protected by the VPN >>>>>>>>>>>>>> - That seems bad >>>>>>>>>>>>>> >>>>>>>>>>>>>> S. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The protection used for policy systems (which provide >>>>>>>>>>>>>>> much of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> information) is based on the presence of persistent >>>>>>>>>>>>>>> connections >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> usage which crosses domains. Are you arguing that if AAA is >>>>>>>>>>>>>>> encrypted >>>>>>>>>>>>>>> then policy delivered by AAA resulting in metadata in the >>>>>>>>>>>>>>> packet >>>>>>>>>>>>>>> must be >>>>>>>>>>>>>>> encrypted in the data packets? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 5/28/15 8:52 AM, Stephen Farrell wrote: >>>>>>>>>>>>>>>> Stephen Farrell has entered the following ballot >>>>>>>>>>>>>>>> position for >>>>>>>>>>>>>>>> draft-ietf-sfc-architecture-08: Discuss >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> When responding, please keep the subject line intact and >>>>>>>>>>>>>>>> reply >>>>>>>>>>>>>>>> to all >>>>>>>>>>>>>>>> email addresses included in the To and CC lines. (Feel >>>>>>>>>>>>>>>> free to >>>>>>>>>>>>>>>> cut >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please refer to >>>>>>>>>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>>>>>>>> for more information about IESG DISCUSS and COMMENT >>>>>>>>>>>>>>>> positions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The document, along with other ballot positions, can be >>>>>>>>>>>>>>>> found >>>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> DISCUSS: >>>>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (1) I note the charter calls for this deliverable to >>>>>>>>>>>>>>>> "provide >>>>>>>>>>>>>>>> a description of... security models" The charter also >>>>>>>>>>>>>>>> generally notes that "The SFC WG will closely consider and >>>>>>>>>>>>>>>> address the management and security implications when >>>>>>>>>>>>>>>> documenting these deliverables." My conclusion is that this >>>>>>>>>>>>>>>> deliverable needs to reflect the results of a security >>>>>>>>>>>>>>>> analysis that the wg are suppoed to have carried out but >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> it's currently too vague only saying that solutions need to >>>>>>>>>>>>>>>> consider this. (Essentially this is a continuation of the >>>>>>>>>>>>>>>> mail threads from the secdir review [1] and a satisfactory >>>>>>>>>>>>>>>> resolution of that will probably resolve this.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (2) Metadata that contains information that is protected in >>>>>>>>>>>>>>>> the data plane SHOULD be equally well protected when passed >>>>>>>>>>>>>>>> about by SFC. I hope that's acceptable and documented. I'm >>>>>>>>>>>>>>>> not sure myself if "passed about" ought also include >>>>>>>>>>>>>>>> within a >>>>>>>>>>>>>>>> device but maybe it should really. But at minimum, I do >>>>>>>>>>>>>>>> think you need to define confidentiality and origin >>>>>>>>>>>>>>>> authentication services for SFC metadata and/or for the SFC >>>>>>>>>>>>>>>> encapsulation as a whole. And I think this architecture >>>>>>>>>>>>>>>> document needs to say that those services have to be >>>>>>>>>>>>>>>> well-defined as part of any solution. (And I am not >>>>>>>>>>>>>>>> saying that this draft needs to define how to do those.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - It occurs to me that it might really be better for the WG >>>>>>>>>>>>>>>> to not publish this as an RFC now, but rather to put it on >>>>>>>>>>>>>>>> hold until they've made progress on the solutions. Perhaps >>>>>>>>>>>>>>>> revistiting this when the solutions are just at WGLC would >>>>>>>>>>>>>>>> result in the eventual RFC being a much more useful >>>>>>>>>>>>>>>> document. >>>>>>>>>>>>>>>> I think this one has to hedge so many bets that it's quite >>>>>>>>>>>>>>>> vague and won't be very useful even in the medium term. But >>>>>>>>>>>>>>>> that's just a suggestion, I can see why the WG might prefer >>>>>>>>>>>>>>>> to push this out, even if that might only give the >>>>>>>>>>>>>>>> appearance >>>>>>>>>>>>>>>> of progress and not reflect real progress. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - While IPR on an architecture document is sad to see, esp >>>>>>>>>>>>>>>> with what seems like it may be restrictive licensing, I do >>>>>>>>>>>>>>>> see the wg debated that and decided to move on. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - The charter text describing this deliverable notes that >>>>>>>>>>>>>>>> "The initial scope is restricted to a single administrative >>>>>>>>>>>>>>>> domain, keeping in mind that architectural decisions >>>>>>>>>>>>>>>> made for >>>>>>>>>>>>>>>> the intra-domain case may have implications for the >>>>>>>>>>>>>>>> inter-domain case." So I think there is also a currently >>>>>>>>>>>>>>>> missing analysis (or the results of that) as to how the >>>>>>>>>>>>>>>> single-domain elements of this architecture might >>>>>>>>>>>>>>>> impinge on >>>>>>>>>>>>>>>> a later inter-domain architecture. So the text at the >>>>>>>>>>>>>>>> end of section 1.1 appears to contradict the chartered >>>>>>>>>>>>>>>> goals. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Chains will require some representation, and re-ordering >>>>>>>>>>>>>>>> that is security sensitive (e.g. swap order of f/w and nat >>>>>>>>>>>>>>>> for fun) therefore there must be a requirement for some >>>>>>>>>>>>>>>> data >>>>>>>>>>>>>>>> integrity service and origin authentication and an >>>>>>>>>>>>>>>> authorisation decision function and therefore there must >>>>>>>>>>>>>>>> (istm) be a need for the architecture to define a chain >>>>>>>>>>>>>>>> producing entity of some kind that could be authenticated. >>>>>>>>>>>>>>>> That is an example of the missing security analysis that >>>>>>>>>>>>>>>> really is needed before this proceeds. (See my discuss >>>>>>>>>>>>>>>> point >>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 1.1: "classified on ingress" and applicable to mobile >>>>>>>>>>>>>>>> networks are slightly incongrous. In the case of WiFi >>>>>>>>>>>>>>>> when do >>>>>>>>>>>>>>>> the packet ingress? (When it gets to the AP or leaves the >>>>>>>>>>>>>>>> mobile node transmitter?) I suspect you really mean the >>>>>>>>>>>>>>>> wired >>>>>>>>>>>>>>>> bits of a mobile network so it might be better to say that. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 1.2 should follow 1.3 I think. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 1.2: What does "chaining logic" mean? You say there's no >>>>>>>>>>>>>>>> standard chaining logic, which is maybe right, but then you >>>>>>>>>>>>>>>> imply that a fully ordered set of SF's is a well defined >>>>>>>>>>>>>>>> thing. I'm not sure that makes sense. Perhaps what you want >>>>>>>>>>>>>>>> to say is that the architecture doesn't determine if an SFC >>>>>>>>>>>>>>>> {{A,B},C} is or is not the same as {{B,A},C} but that later >>>>>>>>>>>>>>>> protocol work will have to do that. (In fact, I think you >>>>>>>>>>>>>>>> could say a lot more here and probably should.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 1.2: what is a "chaining policy"? Isn't here where those >>>>>>>>>>>>>>>> terms need to be defined. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 1.3: SFC definition: by ordered do you mean fully or >>>>>>>>>>>>>>>> partially ordered? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 1.3: I'd omit LI as a SF - we won't be standardising that >>>>>>>>>>>>>>>> (cf. RFC2804) so better to not drag in the controversy >>>>>>>>>>>>>>>> really. Similarly, HOST_ID injection is not afaik any >>>>>>>>>>>>>>>> kind of >>>>>>>>>>>>>>>> standard and perhaps not likely to be (cf. some confict >>>>>>>>>>>>>>>> reviews on the same telechat as this) so I'd also drop >>>>>>>>>>>>>>>> that. >>>>>>>>>>>>>>>> And I think all of the exemplar SF's should really have a >>>>>>>>>>>>>>>> reference (ideally an RFC). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Figure 1 caption is misleading. That seems to me to >>>>>>>>>>>>>>>> show a >>>>>>>>>>>>>>>> set of paths through (one or more) graphs but doesn't show >>>>>>>>>>>>>>>> the full graphs themselves. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 2.2: The concept of a bi-directional SFC seems odd. Does >>>>>>>>>>>>>>>> the example given imply that all traffic (of what kind?) >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> followed SF1->SF2->SF3 on the way "in" must follow >>>>>>>>>>>>>>>> SF3->SF2->SF1 on the way "out"? If so, then I think more >>>>>>>>>>>>>>>> precision is needed really. The hybrid concept seems even >>>>>>>>>>>>>>>> odder to me. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 2.3: How can an SFP "be vague" - surely the point of an >>>>>>>>>>>>>>>> architecture is to avoid such vagueness? If you mean >>>>>>>>>>>>>>>> that an >>>>>>>>>>>>>>>> SFP representation can embody an if-statement then saying >>>>>>>>>>>>>>>> that would be the thing to do. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Section 3: I think there's maybe a missing principle here >>>>>>>>>>>>>>>> about not making security and privacy worse in general. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 4.1: I wonder if one could ever get enough SFC control >>>>>>>>>>>>>>>> traffic that congestion would be an issue? If so, >>>>>>>>>>>>>>>> should you >>>>>>>>>>>>>>>> say rather that any transport that has some way of handling >>>>>>>>>>>>>>>> congestion is ok. If not, then I guess the current text is >>>>>>>>>>>>>>>> fine. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> > From nobody Sat May 30 10:30:45 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBE11ACE50 for ; Fri, 29 May 2015 18:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 2GaXCMW41raD for ; Fri, 29 May 2015 18:08:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D801ACE4E for ; Fri, 29 May 2015 18:08:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWR17519; Sat, 30 May 2015 01:08:48 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 May 2015 02:08:44 +0100 Received: from SZXEMA506-MBX.china.huawei.com ([169.254.3.98]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Sat, 30 May 2015 09:06:23 +0800 From: "Huangyong (Oliver)" To: Dave Dolson , "sfc@ietf.org" , "Hongyu Li (Julio)" , Qin Wu , "mohamed.boucadair@orange.com" , "christian.jacquenet@orange.com" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "ron_parker@affirmednetworks.com" , "Huangjing (A)" , Linda Dunbar Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XA Date: Sat, 30 May 2015 01:06:21 +0000 Message-ID: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.108.172] Content-Type: multipart/mixed; boundary="_004_8172B566C79A4A4C8EB6C7B1F6529EFC61E28160szxema506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Sat, 30 May 2015 10:30:44 -0700 Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 01:09:09 -0000 --_004_8172B566C79A4A4C8EB6C7B1F6529EFC61E28160szxema506mbxchi_ Content-Type: multipart/alternative; boundary="_000_8172B566C79A4A4C8EB6C7B1F6529EFC61E28160szxema506mbxchi_" --_000_8172B566C79A4A4C8EB6C7B1F6529EFC61E28160szxema506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Dave, Thank you for your detailed consideration on the draft. I agree th= at the SF should support the capability of bidirectional chains. For exampl= e, the NAT SF may provide the new allocated address/port to the controller.= You mentioned the control plane should inform SF bidirectional chain (whi= ch path id are paired). I have question why not the SFC forwarding system = handle the paired chain itself? Performance mornitoring is a basic capability which should exist in= all interfaces C1,C2,C3. Mohamed have developed a new version of this draft and made a big p= romotion. In the new draft, C3,C4 are introduced for SF and SF proxy separa= tely. I think it may cover the related scenario. I attached it in this em= ail, please check it. Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are = representative of Huawei on this draft. Please contact more detail to them.= Thank you very much! BR Oliver --------------------------- Huangyong (Oliver) Network research, Huawei From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Saturday, May 30, 2015 4:42 AM To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); mohamed.bo= ucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafon= e.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com Subject: Comments on draft-ww-sfc-control-plane-04 Authors of draft-ww-sfc-control-plane, I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control-pla= ne-04 I have some very high-level suggestions: 1. I believe the "F" interface should be split into two interfaces. On= e for performance monitoring (availability and workload were cited), and on= e for updating classification information. Call these F1 and F2, I suppose. My reasons are that (a) as a general princ= iple, interfaces should not have multiple purposes and (b) F1 and F2 could = be communicating to different control-plane managers. 2. A control interface is required to SF components. Call it C3. This = interface is required to (a) inform the SF about bidirectional chains (i.e.= , which Path IDs are paired) and (b) inform the SF about semantics of types= of meta-data. C3 should also be connected to the SFC Proxy. I propose: 4.5 C3 Interface A service function may need information about the service paths passing through it, and may need information about specific meta-data types attached to packets on the paths. Some types of SF might be agnostic about the paths traversing them, but most transport-layer-flow-aware devices will require this configuration. When bidirectional chains are deployed, the C3 interface provisions each SF with each path identifier/path index pair that will pass through= . Each such pair is associated with an opposite-direction pair of identifier/index. Meta-data is for the benefit of SFs. The C3 interface informs the SF about the semantics of the meta-data, which would otherwise have opaque meaning. Meta-data attributes include "scope" (per-packet, per-fl= ow or per host), "mandatory" (must be understood), "bidirectional" (same value may be used in both directions), "is_qualifier" (indicates a distinct routing domain). I think there is quite a bit to explore, but I believe this starts the disc= ussion. Thoughts? David Dolson Senior Software Architect, Sandvine Inc. --_000_8172B566C79A4A4C8EB6C7B1F6529EFC61E28160szxema506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Dave,

 

        Thank you for your det= ailed consideration on the draft.  I agree that the SF should support = the capability of bidirectional chains. For example, the NAT SF may provide= the new allocated address/port to the controller.  You mentioned the cont= rol plane should inform SF bidirectional chain (which path id are paired).&= nbsp; I have question why not the SFC forwarding system handle the paired c= hain itself?

 

        Performance mornitorin= g is a basic capability which should exist in all interfaces C1,C2,C3.=

 

        Mohamed have developed= a new version of this draft and made a big promotion. In the new draft, C3= ,C4 are introduced for SF and SF proxy separately.  I think it may cov= er the related scenario.  I attached it in this email,  please chec= k it.

 

        Now James.Huang(I add = in this email), Qin.Wu and Linda. Dunbar= are representative of Huawei on this draft. Please contact more detail to = them.   Thank you very much!

 

BR

Oliver

 

---------------------------

Huangyong = (Oliver)

Network re= search, Huawei

 

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Saturday, May 30, 2015 4:42 AM
To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); moh= amed.boucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@= vodafone.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com
Subject: Comments on draft-ww-sfc-control-plane-04=

 

Authors of draft-ww-sfc-control= -plane,

 

I’ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04

 

I have some very high-level sug= gestions:

 

1. &nbs= p;    I believe the “F&= #8221; interface should be split into two interfaces. One for performance m= onitoring (availability and workload were cited), and one for updating clas= sification information.

Call these F1 and F2, I = suppose. My reasons are that (a) as a general principle, interfaces should = not have multiple purposes and (b) F1 and F2 could be communicating to diff= erent control-plane managers.

 =

2. &nbs= p;    A control interface is = required to SF components. Call it C3. This interface is required to (a) in= form the SF about bidirectional chains (i.e., which Path IDs are paired) an= d (b) inform the SF about semantics of types of meta-data. C3 should also be connected to the SFC Proxy.<= /o:p>

 

I propose:

 

4.5  C3 Interface

 

   A service function may need information about t= he service paths

   passing through it, and may need information ab= out specific meta-data

   types attached to packets on the paths.

 

   Some types of SF might be agnostic about the pa= ths traversing them, but

   most transport-layer-flow-aware devices will re= quire this configuration.

 

   When bidirectional chains are deployed, the C3 = interface provisions

   each SF with each path identifier/path index pa= ir that will pass through.

   Each such pair is associated with an opposite-d= irection pair of

   identifier/index.

 

   Meta-data is for the benefit of SFs. The C3 int= erface informs the SF

   about the semantics of the meta-data, which wou= ld otherwise have

   opaque meaning. Meta-data attributes include &q= uot;scope" (per-packet, per-flow

   or per host), "mandatory" (must be un= derstood), "bidirectional" (same

   value may be used in both directions), "is= _qualifier" (indicates a

   distinct routing domain).

 

 

I think there is quite a bit to= explore, but I believe this starts the discussion.

Thoughts?

 

 

David Dolson<= /p>

Senior Software Architect, Sand= vine Inc.

 

--_000_8172B566C79A4A4C8EB6C7B1F6529EFC61E28160szxema506mbxchi_-- --_004_8172B566C79A4A4C8EB6C7B1F6529EFC61E28160szxema506mbxchi_ Content-Type: text/plain; name="draft-ww-sfc-control-plane-05.txt" Content-Description: draft-ww-sfc-control-plane-05.txt Content-Disposition: attachment; filename="draft-ww-sfc-control-plane-05.txt"; size=50701; creation-date="Mon, 27 Apr 2015 11:20:44 GMT"; modification-date="Tue, 28 Apr 2015 14:53:30 GMT" Content-Transfer-Encoding: base64 CgoKClNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKHNmYykgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBILiBMaQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUS4gV3UKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE8uIEh1YW5nCkV4cGly ZXM6IE9jdG9iZXIgMzAsIDIwMTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEh1YXdlaQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBNLiBCb3VjYWRhaXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQy4gSmFjcXVlbmV0CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGcmFuY2UgVGVsZWNv bQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgVy4gSGFlZmZuZXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFZvZGFmb25lCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFMuIExlZQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEVUUkkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUi4gUGFya2VyCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBZmZpcm1lZCBOZXR3b3JrcwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBEdW5iYXIK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEEuIE1hbGlzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSHVhd2VpIFRlY2hub2xvZ2llcwogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjgsIDIwMTUKCgpTZXJ2aWNl IEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIENvbnRyb2wgUGxhbmUgQ29tcG9uZW50cyAmIFJlcXVp cmVtZW50cwogICAgICAgICAgICAgICAgICAgICBkcmFmdC13dy1zZmMtY29udHJvbC1wbGFuZS0w NQoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHJlcXVpcmVtZW50cyBmb3Ig Y29udmV5aW5nIGluZm9ybWF0aW9uCiAgIGJldHdlZW4gU2VydmljZSBGdW5jdGlvbiBDaGFpbmlu ZyAoU0ZDKSBjb250cm9sIGVsZW1lbnRzIChpbmNsdWRpbmcKICAgbWFuYWdlbWVudCBjb21wb25l bnRzKSBhbmQgU0ZDIGZ1bmN0aW9uYWwgZWxlbWVudHMuICBBbHNvLCB0aGlzCiAgIGRvY3VtZW50 IGlkZW50aWZpZXMgYSBzZXQgb2YgY29udHJvbCBpbnRlcmZhY2VzIHRvIGludGVyYWN0IHdpdGgg U0ZDLQogICBhd2FyZSBlbGVtZW50cyB0byBlc3RhYmxpc2gsIG1haW50YWluIG9yIHJlY292ZXIg c2VydmljZSBmdW5jdGlvbgogICBjaGFpbnMuICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHNwZWNp ZnkgcHJvdG9jb2xzIG5vciBleHRlbnNpb25zIHRvCiAgIGV4aXN0aW5nIHByb3RvY29scy4KCiAg IFRoaXMgZG9jdW1lbnQgZXhjbHVzaXZlbHkgZm9jdXNlcyBvbiBTRkMgZGVwbG95bWVudHMgdGhh dCBhcmUgdW5kZXIKICAgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGEgc2luZ2xlIGFkbWluaXN0cmF0 aXZlIGVudGl0eS4gIEludGVyLWRvbWFpbgogICBjb25zaWRlcmF0aW9ucyBhcmUgb3V0IG9mIHNj b3BlLgoKUmVxdWlyZW1lbnRzIExhbmd1YWdlCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlz CiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIx MTkgW1JGQzIxMTldLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFm dCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25z IG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKCgoKCkxpLCBldCBhbC4gICAgICAgICAgICAgIEV4cGly ZXMgT2N0b2JlciAzMCwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURy YWZ0ICAgQ29udHJvbCBQbGFuZSBDb21wb25lbnRzICYgUmVxdWlyZW1lbnRzICAgICAgQXByaWwg MjAxNQoKCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIElu dGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVy bmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBh dCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv dGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhl bSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgd2lsbCBleHBpcmUgb24gT2N0b2JlciAzMCwgMjAxNS4KCkNvcHlyaWdodCBOb3RpY2UKCiAg IENvcHlyaWdodCAoYykgMjAxNSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVk IGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVn YWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3Ry dXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAg cHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1l bnRzCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJp Y3Rpb25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRz IGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRy dXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFz CiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KClRhYmxlIG9mIENv bnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgICAxLjEuICBTY29wZSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAgMS4yLiAgVGVybWlu b2xvZ3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQog ICAgIDEuMy4gIEFzc3VtcHRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDUKICAgMi4gIEdlbmVyaWMgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgICAgMi4xLiAgR2VuZXJpYyBSZXF1aXJl bWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICAgIDIuMi4g IFNGQyBDb250cm9sIFBsYW5lIEJvb3RzdHJhcHBpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDYKICAgICAyLjMuICBDb2hlcmVudCBTZXR1cCBvZiBhbiBTRkMtZW5hYmxlZCBEb21haW4g LiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgIDMuICBTRkMgQ29udHJvbCBQbGFuZSBDb21wb25lbnRz ICYgSW50ZXJmYWNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICAgIDMuMS4gIFJlZmVyZW5j ZSBBcmNoaXRlY3R1cmUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAg ICAzLjIuICBDZW50cmFsaXplZCB2cy4gRGlzdHJpYnV0ZWQgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA5CiAgICAgMy4zLiAgSW50ZXJmYWNlIFJlZmVyZW5jZSBQb2ludHMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMAogICAgICAgMy4zLjEuICBDMTogSW50ZXJmYWNl IGJldHdlZW4gU0ZDIENvbnRyb2wgUGxhbmUgJiBTRkMKICAgICAgICAgICAgICAgQ2xhc3NpZmll ciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwCiAgICAgICAz LjMuMi4gIEMyOiBJbnRlcmZhY2UgYmV0d2VlbiBTRkMgQ29udHJvbCBQbGFuZSAmIFNGRiAuIC4g LiAuICAxMgogICAgICAgMy4zLjMuICBDMzogSW50ZXJmYWNlIGJldHdlZW4gU0ZDIENvbnRyb2wg UGxhbmUgJiBTRkMtYXdhcmUKICAgICAgICAgICAgICAgU0ZzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgICAzLjMuNC4gIEM0OiBJbnRl cmZhY2UgYmV0d2VlbiBTRkMgQ29udHJvbCBQbGFuZSAmIFNGQyBQcm94eSAuICAxMwogICA0LiAg U0ZDIENvbnRyb2wgSW5mb3JtYXRpb24gRXhjaGFuZ2UgKFdhbHRlcikgLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTMKCgoKTGksIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMwLCAy MDE1ICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICBDb250cm9sIFBs YW5lIENvbXBvbmVudHMgJiBSZXF1aXJlbWVudHMgICAgICBBcHJpbCAyMDE1CgoKICAgICA0LjEu ICB0aXRsZSAxIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDEzCiAgICAgNC4yLiAgdGl0bGUgMSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAxMwogICA1LiAgQWR2YW5jZWQgRmVhdHVyZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMKICAgICA1LjEuICBEaXNjb3Zl cnkgb2YgdGhlIFNGQyBDb250cm9sIEVsZW1lbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzCiAg ICAgNS4yLiAgU0YgU3ltbWV0cnkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxNAogICAgIDUuMy4gIFByZS1kZXBsb3lpbmcgU0ZDcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQKICAgICA1LjQuICBXaXRocmF3IGEgU2Vydmlj ZSBGdW5jdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0CiAgICAgNS41LiAg U0ZDIE9wZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxNAogICAgIDUuNi4gIFVuc29saWNpdGVkIE1lc3NhZ2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTQKICAgICA1LjcuICBTRiBMaXZlbmVzcyBEZXRlY3Rpb24gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1CiAgICAgNS44LiAgTW9uaXRvcmlu ZyAmIENvdW50ZXJzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNQogICAg IDUuOS4gIFNGQyBEaWFnbm9zaXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTUKICAgICA1LjEwLiBDb25zaWRlcmF0aW9ucyBTcGVjaWZpYyB0byB0aGUgQ2Vu dHJhbGl6ZWQgUGF0aAogICAgICAgICAgIENvbXB1dGF0aW9uIE1vZGVsIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYKICAgICAgIDUuMTAuMS4gIFNlcnZpY2UgRnVu Y3Rpb24gUGF0aCBBZGp1c3RtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2CiAgICAgICA1LjEw LjIuICBIZWFkIEVuZCBJbml0aWF0ZWQgU0ZQIEVzdGFibGlzaG1lbnQgLiAuIC4gLiAuIC4gLiAu ICAxNwogICAgICAgNS4xMC4zLiAgKFJlZ2lvbmFsKSBSZXN0b3JhdGlvbiBvZiBTZXJ2aWNlIEZ1 bmN0aW9ucyAgLiAuIC4gLiAgMTcKICAgNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4CiAgIDcuICBJQU5BIENvbnNpZGVy YXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOQogICA4 LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTkKICAgOS4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5CiAgICAgOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOQogICAgIDkuMi4gIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MjAKICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDIxCgoxLiAgSW50cm9kdWN0aW9uCgogICBUaGUgZHluYW1pYyBlbmZv cmNlbWVudCBvZiBhIHNlcnZpY2UtZGVyaXZlZCBmb3J3YXJkaW5nIHBvbGljeSBmb3IKICAgcGFj a2V0cyBlbnRlcmluZyBhIG5ldHdvcmsgdGhhdCBzdXBwb3J0cyBhZHZhbmNlZCBTZXJ2aWNlIEZ1 bmN0aW9ucwogICAoU0ZzKSBoYXMgYmVjb21lIGEga2V5IGNoYWxsZW5nZSBmb3Igb3BlcmF0b3Jz LiAgVHlwaWNhbGx5LCBtYW55CiAgIGFkdmFuY2VkIFNlcnZpY2UgRnVuY3Rpb25zIChlLmcuLCBQ ZXJmb3JtYW5jZSBFbmhhbmNlbWVudCBQcm94aWVzCiAgIChbUkZDMzEzNV0pLCBOQVRzIFtSRkMz MDIyXVtSRkM2MzMzXVtSRkM2MTQ2XSwgZmlyZXdhbGxzCiAgIFtJLUQuaWV0Zi1vcHNhd2ctZmly ZXdhbGxzXSwgZXRjLikgYXJlIHNvbGljaXRlZCBmb3IgdGhlIGRlbGl2ZXJ5IG9mCiAgIHZhbHVl LWFkZGVkIHNlcnZpY2VzLCBwYXJ0aWN1bGFybHkgdG8gbWVldCB2YXJpb3VzIHNlcnZpY2Ugb2Jq ZWN0aXZlcwogICBzdWNoIGFzIElQIGFkZHJlc3Mgc2hhcmluZywgYXZvaWRpbmcgY292ZXJ0IGNo YW5uZWxzLCBkZXRlY3RpbmcgYW5kCiAgIHByb3RlY3RpbmcgYWdhaW5zdCBldmVyIGluY3JlYXNp bmcgRERvUyBhdHRhY2tzLCBpbnNlcnRpbmcgY29udGVudCwKICAgZXRjLgoKICAgQmVjYXVzZSBv ZiB0aGUgcHJvbGlmZXJhdGlvbiBvZiBzdWNoIGFkdmFuY2VkIHNlcnZpY2UgZnVuY3Rpb25zCiAg IHRvZ2V0aGVyIHdpdGggY29tcGxleCBzZXJ2aWNlIGRlcGxveW1lbnQgY29uc3RyYWludHMgdGhh dCBkZW1hbmQgbW9yZQogICBhZ2lsZSBzZXJ2aWNlIGRlbGl2ZXJ5IHByb2NlZHVyZXMsIG9wZXJh dG9ycyBuZWVkIHRvIHJhdGlvbmFsaXplCiAgIHRoZWlyIHNlcnZpY2UgZGVsaXZlcnkgbG9naWNz IGFuZCBtYXN0ZXIgdGhlaXIgY29tcGxleGl0eSB3aGlsZQogICBvcHRpbWlzaW5nIHNlcnZpY2Ug YWN0aXZhdGlvbiB0aW1lIGN5Y2xlcy4gIFRoZSBvdmVyYWxsIHByb2JsZW0gc3BhY2UKICAgaXMg ZGVzY3JpYmVkIGluIFtSRkM3NDk4XS4gIEEgbW9yZSBpbi1kZXB0aCBkaXNjdXNzaW9uIG9uIHVz ZSBjYXNlcwogICBjYW4gYmUgZm91bmQgaW4gW0ktRC5pZXRmLXNmYy11c2UtY2FzZS1tb2JpbGl0 eV0gYW5kCiAgIFtJLUQuaWV0Zi1zZmMtZGMtdXNlLWNhc2VzXS4KCgoKCgpMaSwgZXQgYWwuICAg ICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2Ug M10KDApJbnRlcm5ldC1EcmFmdCAgIENvbnRyb2wgUGxhbmUgQ29tcG9uZW50cyAmIFJlcXVpcmVt ZW50cyAgICAgIEFwcmlsIDIwMTUKCgogICBbSS1ELmlldGYtc2ZjLWFyY2hpdGVjdHVyZV0gcHJl c2VudHMgYSBtb2RlbCBhZGRyZXNzaW5nIHRoZQogICBwcm9ibGVtYXRpYyBhc3BlY3RzIG9mIGV4 aXN0aW5nIHNlcnZpY2UgZGVwbG95bWVudHMsIGluY2x1ZGluZwogICB0b3BvbG9naWNhbCBkZXBl bmRlbmNlIGFuZCBjb25maWd1cmF0aW9uIGNvbXBsZXhpdHkuICBJdCBhbHNvCiAgIGRlc2NyaWJl cyBhbiBhcmNoaXRlY3R1cmUgZm9yIHRoZSBzcGVjaWZpY2F0aW9uLCBjcmVhdGlvbiwgYW5kCiAg IG9uZ29pbmcgbWFpbnRlbmFuY2Ugb2YgU2VydmljZSBGdW5jdGlvbiBDaGFpbnMgKFNGQykgd2l0 aGluIGEKICAgbmV0d29yay4gIFRoYXQgaXMsIGhvdyB0byBkZWZpbmUgYW4gb3JkZXJlZCBzZXQg b2YgU2VydmljZSBGdW5jdGlvbnMKICAgYW5kIG9yZGVyaW5nIGNvbnN0cmFpbnRzIHRoYXQgbXVz dCBiZSBhcHBsaWVkIHRvIHBhY2tldHMgYW5kL29yCiAgIGZyYW1lcyBhbmQvb3IgZmxvd3Mgc2Vs ZWN0ZWQgYXMgYSByZXN1bHQgb2YgY2xhc3NpZmljYXRpb24uCgoxLjEuICBTY29wZQoKICAgV2hp bGUgW0ktRC5pZXRmLXNmYy1hcmNoaXRlY3R1cmVdIGZvY3VzZXMgb24gZGF0YSBwbGFuZQogICBj b25zaWRlcmF0aW9ucywgdGhpcyBkb2N1bWVudCBkZXNjcmliZXMgcmVxdWlyZW1lbnRzIGZvciBj b252ZXlpbmcKICAgaW5mb3JtYXRpb24gYmV0d2VlbiBTRkMgY29udHJvbCBlbGVtZW50cyAoaW5j bHVkaW5nIG1hbmFnZW1lbnQKICAgY29tcG9uZW50cykgYW5kIFNGQyBmdW5jdGlvbmFsIGVsZW1l bnRzLiAgQWxzbywgdGhpcyBkb2N1bWVudAogICBpZGVudGlmaWVzIGEgc2V0IG9mIGNvbnRyb2wg aW50ZXJmYWNlcyB0byBpbnRlcmFjdCB3aXRoIFNGQy1hd2FyZQogICBlbGVtZW50cyB0byBlc3Rh Ymxpc2gsIG1haW50YWluIG9yIHJlY292ZXIgc2VydmljZSBmdW5jdGlvbiBjaGFpbnMuCiAgIEZ1 cnRoZXJtb3JlLCB0aGlzIGRvY3VtZW50IGRpc2N1c3NlcyBvdGhlciBjb25zaWRlcmF0aW9ucywg aW5jbHVkaW5nCiAgIFNGQyBjb250cm9sbGVyIGRpc2NvdmVyeSwgZGV0ZWN0aW9uIG9mIFNGIGxp dmVsaW5lc3MsIGluZm9ybWF0aW9uCiAgIGV4Y2hhbmdlIGJldHdlZW4gU2VydmljZSBGdW5jdGlv biBQYXRoIChTRlApIGNvbXB1dGF0aW9uIGVuZ2luZXMgYW5kCiAgIFNGQyBlbmZvcmNlbWVudCBw b2ludHMsIGV0Yy4KCiAgIEJvdGggZGlzdHJpYnV0ZWQgYW5kIGNlbnRyYWxpemVkIGNvbnRyb2wg cGxhbmUgc2NoZW1lcyB0byBpbnN0YWxsCiAgIFNGQy1yZWxhdGVkIHN0YXRlIGFuZCBpbmZsdWVu Y2UgZm9yd2FyZGluZyBwb2xpY2llcyBhcmUgZGlzY3Vzc2VkLgoKICAgVGhpcyBkb2N1bWVudCBk b2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIG9uIHRoZSBkZXBsb3ltZW50IHVzZQogICBjYXNl cy4gIEluIHBhcnRpY3VsYXIsIHRoZSBkb2N1bWVudCBpbXBsaWNpdGx5IGNvdmVycyBmaXhlZCwg bW9iaWxlLAogICBkYXRhIGNlbnRlciBuZXR3b3JrcyBhbmQgYW55IGNvbWJpbmF0aW9uIHRoZXJl b2YuCgogICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQg d2hpY2ggY29udHJvbAogICBwcm90b2NvbCB0byB1c2UsIHdoZXRoZXIgb25lIG9yIG11bHRpcGxl IGNvbnRyb2wgcHJvdG9jb2xzIGFyZQogICByZXF1aXJlZCwgb3Igd2hldGhlciB0aGUgc2FtZSBv ciBkaXN0aW5jdCBjb250cm9sIHByb3RvY29scyB3aWxsIGJlCiAgIGludm9rZWQgZm9yIGVhY2gg b2YgdGhlIGNvbnRyb2wgaW50ZXJmYWNlcy4gIEl0IGlzIG91dCBvZiBzY29wZSBvZgogICB0aGlz IGRvY3VtZW50IHRvIHNwZWNpZnkgYSBwcm9maWxlIGZvciBhbiBleGlzdGluZyBwcm90b2NvbCwg dG8KICAgZGVmaW5lIHByb3RvY29sIGV4dGVuc2lvbnMsIG9yIHRvIHNlbGVjdCBhIHByb3RvY29s LgoKICAgQ29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byB0aGUgY2hhaW5pbmcgb2YgU2VydmljZSBG dW5jdGlvbnMgdGhhdCBzcGFuCiAgIGRvbWFpbnMgb3duZWQgYnkgbXVsdGlwbGUgYWRtaW5pc3Ry YXRpdmUgZW50aXRpZXMgYXJlIG91dCBvZiBzY29wZS4KCiAgIEl0IGlzIG91dCBvZiBzY29wZSBv ZiB0aGlzIGRvY3VtZW50IHRvIGRpc2N1c3MgU0Ytc3BlY2lmaWMgY29udHJvbAogICBhbmQgcG9s aWN5IGVuZm9yY2VtZW50IHNjaGVtZXM7IG9ubHkgU0ZDIGNvbnNpZGVyYXRpb25zIGFyZQogICBl bGFib3JhdGVkLCByZWdhcmRsZXNzIG9mIHRoZSB2YXJpb3VzIGNvbm5lY3Rpdml0eSBzZXJ2aWNl cyB0aGF0IG1heQogICBiZSBzdXBwb3J0ZWQgaW4gdGhlIFNGQyBkb21haW4uICBMaWtld2lzZSwg b25seSB0aGUgY29udHJvbCBvZiBTRkMtCiAgIGF3YXJlIGVsZW1lbnRzIGlzIGRpc2N1c3NlZC4K CiAgIFNlcnZpY2UgY2F0YWxvZ3VlIChpbmNsdWRpbmcgZ3VpZGVsaW5lcyBmb3IgZGVyaXZpbmcg c2VydmljZSBmdW5jdGlvbgogICBjaGFpbnMpIGlzIG91dCBvZiBzY29wZS4KCgoKCkxpLCBldCBh bC4gICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxNSAgICAgICAgICAgICAgICBb UGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgQ29udHJvbCBQbGFuZSBDb21wb25lbnRzICYgUmVx dWlyZW1lbnRzICAgICAgQXByaWwgMjAxNQoKCjEuMi4gIFRlcm1pbm9sb2d5CgogICBUaGUgcmVh ZGVyIHNob3VsZCBiZSBmYW1pbGlhciB3aXRoIHRoZSB0ZXJtcyBkZWZpbmVkIGluIFtSRkM3NDk4 XSBhbmQKICAgW0ktRC5pZXRmLXNmYy1hcmNoaXRlY3R1cmVdLgoKICAgVGhlIGRvY3VtZW50IG1h a2VzIHVzZSBvZiB0aGUgZm9sbG93aW5nIHRlcm1zOgoKICAgbyAgU0ZDIGRhdGEgcGxhbmUgZnVu Y3Rpb25hbCBlbGVtZW50OiBSZWZlcnMgdG8gU0ZDLWF3YXJlIFNlcnZpY2UKICAgICAgRnVuY3Rp b24sIFNlcnZpY2UgRnVuY3Rpb24gRm9yd2FyZGVyIChTRkYpLCBTRkMgUHJveHksIG9yIFNGQwog ICAgICBDbGFzc2lmaWVyIGFzIGRlZmluZWQgaW4gdGhlIFNGQyBkYXRhIHBsYW5lIGFyY2hpdGVj dHVyZQogICAgICBbSS1ELmlldGYtc2ZjLWFyY2hpdGVjdHVyZV0uCgogICBvICBTRkMgQ29udHJv bCBFbGVtZW50OiBBIGxvZ2ljYWwgZW50aXR5IHRoYXQgaW5zdHJ1Y3RzIG9uZSBvciBtb3JlCiAg ICAgIFNGQyBkYXRhIHBsYW5lIGZ1bmN0aW9uYWwgZWxlbWVudHMgb24gaG93IHRvIHByb2Nlc3Mg cGFja2V0cwogICAgICB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluLgoKICAgbyAgU0ZDIENs YXNzaWZpY2F0aW9uIGVudHJ5OiBSZWZlcnMgdG8gYW4gZW50cnkgbWFpbnRhaW5lZCBieSBhbiBT RkMKICAgICAgQ2xhc3NpZmllciB0aGF0IHJlZmxlY3RzIHRoZSBwb2xpY2llcyBmb3IgYmluZGlu ZyBhbiBpbmNvbWluZwogICAgICBmbG93L3BhY2tldCB0byBhIGdpdmVuIFNGQy4gIEFjdGlvbnMg YXJlIGFzc29jaWF0ZWQgd2l0aCBtYXRjaGluZwogICAgICBjcml0ZXJpYS4gIEZvciBleGFtcGxl LCBwYWNrZXRzIGNhbiBiZSBtYXJrZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUKICAgICAgU0ZDLXJl bGF0ZWQgaW5mb3JtYXRpb24gdG8gZGlmZmVyZW50aWF0ZSBmbG93cyBzbyB0aGF0IHN1YnNlcXVl bnQKICAgICAgU0ZGcyBjYW4gZm9yd2FyZCB0aGUgZmxvd3MgdG8gYSBzZXF1ZW5jZSBvZiBTRnMg aW4gYSBnaXZlbiBvcmRlci4KICAgICAgVGhlIHNldCBvZiBjbGFzc2lmaWNhdGlvbiBlbnRyaWVz IG1haW50YWluZWQgYnkgYSBDbGFzc2lmaWVyIGFyZQogICAgICByZWZlcnJlZCB0byBhcyBpbiB0 aGUgY2xhc3NpZmljYXRpb24gcG9saWN5IHRhYmxlLgoKICAgbyAgU0ZDIEZvcndhcmRpbmcgUG9s aWN5IFRhYmxlOiB0aGlzIHRhYmxlIHJlZmxlY3RzIHRoZSBTRkMtc3BlY2lmaWMKICAgICAgdHJh ZmZpYyBmb3J3YXJkaW5nIHBvbGljeSBlbmZvcmNlZCBieSBTRkYgY29tcG9uZW50cyBmb3IgZXZl cnkKICAgICAgcmVsZXZhbnQgaW5jb21pbmcgcGFja2V0IHRoYXQgaXMgYXNzb2NpYXRlZCB0byBv bmUgb2YgdGhlIGV4aXN0aW5nCiAgICAgIFNGQ3MuCgoxLjMuICBBc3N1bXB0aW9ucwoKICAgVGhp cyBkb2N1bWVudCBhZGhlcmVzIHRvIHRoZSBhc3N1bXB0aW9ucyBsaXN0ZWQgaW4gU2VjdGlvbiAx LjIgb2YKICAgW0ktRC5pZXRmLXNmYy1hcmNoaXRlY3R1cmVdLgoKICAgVGhpcyBkb2N1bWVudCBk b2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9ucyBhYm91dCB0aGUgY28tbG9jYXRpb24gb2YKICAg U0ZDIGRhdGEgcGxhbmUgZnVuY3Rpb25hbCBlbGVtZW50czsgdGhpcyBpcyBkZXBsb3ltZW50LXNw ZWNpZmljLgogICBUaGlzIGRvY3VtZW50IGNhbiBhY2NvbW1vZGF0ZSBhIHZhcmlldHkgb2YgZGVw bG95bWVudCBjb250ZXh0cyBzdWNoCiAgIGFzIChidXQgbm90IGxpbWl0ZWQgdG8pOgoKICAgbyAg QSBTZXJ2aWNlIEZ1bmN0aW9uIEZvcndhcmRlciAoU0ZGKSBjYW4gY29ubmVjdCBpbnN0YW5jZXMg b2YgdGhlCiAgICAgIHNhbWUgb3IgZGlzdGluY3QgU0ZzLgogICBvICBBIFNGIGluc3RhbmNlIGNh biBiZSBzZXJ2aWNlZCBieSBvbmUgb3IgbXVsdGlwbGUgU0ZGcy4KICAgbyAgT25lIG9yIG11bHRp cGxlIFNGcyBjYW4gYmUgY29sbG9jYXRlZCB3aXRoIGEgU0ZGLgogICBvICBBIGJvdW5kYXJ5IG5v ZGUgKHRoYXQgY29ubmVjdHMgb25lIFNGQy1lbmFibGVkIGRvbWFpbiB0byBhIG5vZGUKICAgICAg ZWl0aGVyIGxvY2F0ZWQgaW4gYW5vdGhlciBTRkMtZW5hYmxlZCBkb21haW4gb3IgaW4gYSBkb21h aW4gdGhhdAogICAgICBpcyBTRkMtdW5hd2FyZSkgY2FuIGFjdCBhcyBhbiBlZ3Jlc3Mgbm9kZSBh bmQgYW4gaW5ncmVzcyBub2RlIGZvcgogICAgICB0aGUgc2FtZSBmbG93LgoKCgpMaSwgZXQgYWwu ICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIwMTUgICAgICAgICAgICAgICAgW1Bh Z2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnRyb2wgUGxhbmUgQ29tcG9uZW50cyAmIFJlcXVp cmVtZW50cyAgICAgIEFwcmlsIDIwMTUKCgogICBvICBEaXN0aW5jdCBpbmdyZXNzIGFuZCBlZ3Jl c3Mgbm9kZXMgbWF5IGJlIGNyb3NzZWQgYnkgYSBwYWNrZXQgd2hlbgogICAgICBmb3J3YXJkZWQg aW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluLgogICBvICBEaXN0aW5jdCBpbmdyZXNzIG5vZGVzIG1h eSBiZSBzb2xpY2l0ZWQgZm9yIGVhY2ggdHJhZmZpYyBkaXJlY3Rpb24KICAgICAgKGUuZy4sIHVw c3RyZWFtIGFuZCBkb3duc3RyZWFtKS4KICAgbyAgQW4gaW5ncmVzcyBub2RlIGNhbiBlbWJlZCBh IENsYXNzaWZpZXIuCiAgIG8gIEFuIGluZ3Jlc3Mgbm9kZSBtYXkgbm90IGVtYmVkIGEgQ2xhc3Np ZmllciwgYnV0IGl0IGNhbiBiZQogICAgICByZXNwb25zaWJsZSBmb3IgZGlzcGF0Y2hpbmcgZmxv d3MgYW1vbmcgYSBzZXQgb2YgQ2xhc3NpZmllcnMuCiAgIG8gIFRoZSBzYW1lIGJvdW5kYXJ5IG5v ZGUgbWF5IGFjdCBhcyBhbiBpbmdyZXNzIG5vZGUsIGFuIGVncmVzcyBub2RlLAogICAgICBhbmQg YWxzbyBlbWJlZCBhIENsYXNzaWZpZXIuCiAgIG8gIEEgQ2xhc3NpZmllciBjYW4gYmUgaG9zdGVk IGluIGEgbm9kZSB0aGF0IGVtYmVkcyBvbmUgb3IgbW9yZSBTRnMuCiAgIG8gIE1hbnkgbmV0d29y ayBlbGVtZW50cyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIG1heSBiZWhhdmUgYXMKICAg ICAgZWdyZXNzL2luZ3Jlc3Mgbm9kZXMuCgogICBGdXJ0aGVybW9yZSwgdGhlIGZvbGxvd2luZyBh c3N1bXB0aW9ucyBhcmUgbWFkZToKCiAgIG8gIEEgQ29udHJvbCBFbGVtZW50IGNhbiBiZSBjby1s b2NhdGVkIHdpdGggYSBDbGFzc2lmaWVyLCBTRkYgb3IgU0YuCiAgIG8gIE9uZSBvciBtdWx0aXBs ZSBDb250cm9sIEVsZW1lbnRzIGNhbiBiZSBkZXBsb3llZCBpbiBhbiBTRkMtZW5hYmxlZAogICAg ICBkb21haW4uCiAgIG8gIFN0YXRlIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIENvbnRyb2wgRWxl bWVudHMgaXMgb3V0IG9mIHNjb3BlLgoKMi4gIEdlbmVyaWMgQ29uc2lkZXJhdGlvbnMKCjIuMS4g IEdlbmVyaWMgUmVxdWlyZW1lbnRzCgogICBGb3IgZGVwbG95bWVudHMgdGhhdCB3b3VsZCByZXF1 aXJlIHNvLCBTRkMgZm9yd2FyZGluZyBtdXN0IGJlIGFsbG93ZWQKICAgZXZlbiBpZiBubyBjb250 cm9sIHByb3RvY29scyBhcmUgZW5hYmxlZC4gIFN0YXRpYyBjb25maWd1cmF0aW9uIG11c3QKICAg YmUgYWxsb3dlZC4KCiAgIEEgcGVybWFuZW50IGFzc29jaWF0aW9uIGJldHdlZW4gYW4gU0ZDIGRh dGEgcGxhbmUgZWxlbWVudCB3aXRoIGEKICAgQ29udHJvbCBFbGVtZW50IG11c3Qgbm90IGJlIHJl cXVpcmVkOyBzcGVjaWZpY2FsbHksIHRoZSBTRkMtZW5hYmxlZAogICBkb21haW4gbXVzdCBrZWVw IG9uIHByb2Nlc3NpbmcgaW5jb21pbmcgcGFja2V0cyBhY2NvcmRpbmcgdG8gdGhlIFNGQwogICBp bnN0cnVjdGlvbnMsIGV2ZW4gd2hlbiBjb250cm9sIHBsYW5lIGNvbXBvbmVudHMgYXJlIHVuYXZh aWxhYmxlIG9yCiAgIHVucmVhY2hhYmxlIGZvciBzb21lIHJlYXNvbi4KCjIuMi4gIFNGQyBDb250 cm9sIFBsYW5lIEJvb3RzdHJhcHBpbmcKCiAgIFRoZSBpbnRlcmZhY2UgdGhhdCBpcyB1c2VkIHRv IGZlZWQgdGhlIFNGQyBjb250cm9sIHBsYW5lIHdpdGggc2VydmljZQogICBvYmplY3RpdmVzIGFu ZCBndWlkZWxpbmVzIGlzIG5vdCBwYXJ0IG9mIHRoZSBTRkMgY29udHJvbCBwbGFuZQogICBpdHNl bGYuICBUaGVyZWZvcmUsIHRoaXMgZG9jdW1lbnQgYXNzdW1lcyB0aGUgU0ZDIGNvbnRyb2wgcGxh bmUgaXMKICAgcHJvdmlkZWQgd2l0aCBhIHNldCBvZiBpbmZvcm1hdGlvbiB0aGF0IGlzIHJlcXVp cmVkIGZvciBwcm9wZXIgU0ZDCiAgIG9wZXJhdGlvbiB3aXRoIG5vIHNwZWNpZmljIGFzc3VtcHRp b24gYWJvdXQgaG93IHRoaXMgaW5mb3JtYXRpb24gaXMKICAgY29sbGVjdGVkL3Byb3Zpc2lvbmVk LCBub3IgYWJvdXQgdGhlIHN0cnVjdHVyZSBvZiBzdWNoIGluZm9ybWF0aW9uLgogICBUaGUgZm9s bG93aW5nIGluZm9ybWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8gdGhlIFNGQwog ICBjb250cm9sIHBsYW5lIGF0IGJvb3RzdHJhcHBpbmcgaW5jbHVkZXMgKG5vbi1leGhhdXN0aXZl IGxpc3QpOgoKICAgbyAgTG9jYXRvcnMgZm9yIENsYXNzaWZpZXJzL1NGRi9TRnMvUHJveGllcywg ZXRjLgogICBvICBTRnMgc2VydmljZWQgYnkgZWFjaCBTRkYuCgoKCgpMaSwgZXQgYWwuICAgICAg ICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgNl0K DApJbnRlcm5ldC1EcmFmdCAgIENvbnRyb2wgUGxhbmUgQ29tcG9uZW50cyAmIFJlcXVpcmVtZW50 cyAgICAgIEFwcmlsIDIwMTUKCgogICBvICBBIGxpc3Qgb2YgU0ZDcywgaW5jbHVkaW5nIGhvdyB0 aGV5IGFyZSBzdHJ1Y3R1cmVkIGFuZAogICAgICB1bmFtYmlndW91c2x5IGlkZW50aWZpZWQuCiAg IG8gIFN0YXR1cyBvZiBlYWNoIFNGQzogYWN0aXZlL3ByZS1kZXBsb3ltZW50IHBoYXNlL2V0Yy4g IEEgU0ZDIGNhbiBiZQogICAgICBkZWZpbmVkIGF0IHRoZSBtYW5hZ2VtZW50IGxldmVsIGFuZCBp bnN0YW50aWF0ZWQgaW4gYW4gU0ZDLQogICAgICBlbmFibGVkIGRvbWFpbiBmb3IgcHJlLWRlcGxv eW1lbnQgcHVycG9zZXMgKGUuZy4sIHRlc3RpbmcpLgogICAgICBBY3Rpb25zIHRvIGFjdGl2YXRl LCBtb2RpZnkgb3Igd2l0aGRyYXcgYW4gU0ZDIGFyZSB0cmlnZ2VyZWQgYnkKICAgICAgdGhlIGNv bnRyb2wgcGxhbmUuICBOZXZlcnRoZWxlc3MsIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbWFrZSBh bnkKICAgICAgYXNzdW1wdGlvbiBhYm91dCBob3cgYW4gb3BlcmF0b3IgaW5zdHJ1Y3RzIHRoZSBj b250cm9sIHBsYW5lLgogICBvICBBIGxpc3Qgb2YgY2xhc3NpZmljYXRpb24gZ3VpZGVsaW5lcyBh bmQgcnVsZXMgdG8gYmluZCBmbG93cyB0bwogICAgICBTRkNzLgogICBvICBPcHRpb25hbGx5LCAo dHJhZmZpYy9DUFUvbWVtb3J5KSBsb2FkIGJhbGFuY2luZyBvYmplY3RpdmVzIGF0IHRoZQogICAg ICBTRkMgbGV2ZWwgb3Igb24gYSBwZXIgbm9kZSAoZS5nLiwgcGVyLVNGL1NGRi9Qcm94eSkgYmFz aXMuCiAgIG8gIFNlY3VyaXR5IGNyZWRlbnRpYWxzLgogICBvICBDb250ZXh0IGluZm9ybWF0aW9u IHRoYXQgbmVlZHMgdG8gYmUgc2hhcmVkIG9uIGEgcGVyIFNGQyBiYXNpcy4KCiAgIEFsc28sIHRo ZSBTRkMgY29udHJvbCBwbGFuZSBtYXkgZ2F0aGVyIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24g ZnJvbQogICBhbiBTRkMtZW5hYmxlZCBkb21haW4gYXQgYm9vdHN0cmFwcGluZyAobm9uLWV4aGF1 c3RpdmUgbGlzdCkuICBIb3cKICAgdGhpcyBpbmZvcm1hdGlvbiBpcyBjb2xsZWN0ZWQgaXMgbGVm dCB1bnNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50OgoKICAgbyAgVGhlIGxpc3Qgb2YgYWN0aXZl IFNGQy1hd2FyZSBTRnMgKGluY2x1ZGluZyB0aGVpciBsb2NhdGlvbikuCiAgIG8gIFRoZSBsaXN0 IG9mIFNGRnMgYW5kIHRoZSBTRnMgdGhhdCBhcmUgYXR0YWNoZWQgdG8uCiAgIG8gIFRoZSBsaXN0 IG9mIGVuYWJsZWQgU0ZDIFByb3hpZXMsIGFuZCB0aGUgbGlzdCBvZiBTRkMtdW53YXJlIFNGcwog ICAgICBhdHRhY2hlZCB0by4KICAgbyAgVGhlIGxpc3Qgb2YgYWN0aXZlIFNlcnZpY2UgRnVuY3Rp b24gQ2hhaW5zIGFzIGVuYWJsZWQgaW4gYW4gU0ZDLQogICAgICBlbmFibGVkIGRvbWFpbi4KICAg byAgVGhlIGxpc3Qgb2YgQ2xhc3NpZmllcnMgYW5kIHRoZWlyIGxvY2F0aW9uLCBzbyBhcyB0byBy ZXRyaWV2ZSB0aGUKICAgICAgY2xhc3NpZmljYXRpb24gcG9saWN5IHRhYmxlIGZvciBlYWNoIENs YXNzaWZpZXIsIGluIHBhcnRpY3VsYXIuCiAgIG8gIFRoZSBTRkMgZm9yd2FyZGluZyBwb2xpY3kg dGFibGVzIG1haW50YWluZWQgYnkgU0ZGcy4KCiAgIER1cmluZyB0aGUgYm9vdHN0cmFwcGluZyBw aGFzZSwgYSBDb250cm9sIEVsZW1lbnQgbWF5IGRldGVjdCBhCiAgIGNvbmZsaWN0IGJldHdlZW4g dGhlIHJ1bm5pbmcgY29uZmlndXJhdGlvbiBpbiBhbiBTRkMgZGF0YSBwbGFuZQogICBlbGVtZW50 IGFuZCB0aGUgbG9jYWwgaW5mb3JtYXRpb24gbWFpbnRhaW5lZCBieSB0aGUgY29udHJvbCBwbGFu ZS4KICAgQ29uc2VxdWVudGx5LCB0aGUgY29udHJvbCBwbGFuZSB1bmRlcnRha2VzIGFwcHJvcHJp YXRlIGFjdGlvbnMgdG8gZml4CiAgIHRob3NlIGNvbmZsaWN0cy4gIFRoaXMgaXMgdHlwaWNhbGx5 IGFjaGlldmVkIGJ5IGludm9raW5nIG9uZSBvZiB0aGUKICAgaW50ZXJmYWNlcyBkZWZpbmVkIGlu IFNlY3Rpb24gMy4zLgoKMi4zLiAgQ29oZXJlbnQgU2V0dXAgb2YgYW4gU0ZDLWVuYWJsZWQgRG9t YWluCgogICBWYXJpb3VzIHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9uIHNjaGVtZXMgYW5kL29yIHZh cmlhdGlvbnMgb2YgU0ZDCiAgIGhlYWRlciBpbXBsZW1lbnRhdGlvbnMgbWF5IGJlIHN1cHBvcnRl ZCBieSBvbmUgb3Igc2V2ZXJhbCBub2RlcyBvZiBhbgogICBTRkMtZW5hYmxlZCBkb21haW4uICBG b3IgdGhlIHNha2Ugb2YgY29oZXJlbnQgY29uZmlndXJhdGlvbiwgdGhlIFNGQwogICBjb250cm9s IHBsYW5lIGlzIHJlc3BvbnNpYmxlIGZvciBpbnN0cnVjdGluZyBhbGwgdGhlIGludm9sdmVkIFNG QwogICBkYXRhIHBsYW5lIGZ1bmN0aW9uYWwgZWxlbWVudHMgYWJvdXQgdGhlIGJlaGF2aW9yIHRv IGFkb3B0IHRvIHNlbGVjdAogICB0aGUgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24gc2NoZW1lLCB0 aGUgdmVyc2lvbiBvZiB0aGUgU0ZDIGhlYWRlciB0bwogICBlbmFibGUsIGV0YyAuCgoKCgoKCkxp LCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxNSAgICAgICAgICAg ICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgQ29udHJvbCBQbGFuZSBDb21wb25lbnRz ICYgUmVxdWlyZW1lbnRzICAgICAgQXByaWwgMjAxNQoKCjMuICBTRkMgQ29udHJvbCBQbGFuZSBD b21wb25lbnRzICYgSW50ZXJmYWNlcwoKMy4xLiAgUmVmZXJlbmNlIEFyY2hpdGVjdHVyZQoKICAg VGhlIFNGQyBjb250cm9sIHBsYW5lIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgZm9sbG93aW5nOgoK ICAgbyAgQnVpbGQgYW5kIG1vbml0b3JzIHRoZSBzZXJ2aWNlLWF3YXJlIHRvcG9sb2d5LiAgRm9y IGV4YW1wbGUsIHRoaXMKICAgICAgY2FuIGJlIGFjaGlldmVkIGJ5IG1lYW5zIG9mIGR5bmFtaWMg U0YgZGlzY292ZXJ5IHRlY2huaXF1ZXMuCiAgICAgIFRob3NlIG1lYW5zIGFyZSBvdXQgb2Ygc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC4KICAgbyAgTWFpbnRhaW4gYSByZXBvc2l0b3J5IG9mIFNGQ3Ms IFNGQyBtYXRjaGluZyBjcml0ZXJpYSB0byBiaW5kIGZsb3dzCiAgICAgIHRvIGEgZ2l2ZW4gU0ZD LCBhbmQgbWFwcGluZyBiZXR3ZWVuIFNGQyBhbmQgU2VydmljZSBGdW5jdGlvbgogICAgICBQYXRo cy4KICAgbyAgR3VhcmFudGVlIHRoZSBjb2hlcmVuY3kgb2YgdGhlIGNvbmZpZ3VyYXRpb24gYW5k IHRoZSBvcGVyYXRpb24gb2YKICAgICAgYW4gU0ZDLWVuYWJsZWQgZG9tYWluLgogICBvICBEeW5h bWljYWxseSBjb21wdXRlIGEgc2VydmljZS1hd2FyZSBmb3J3YXJkaW5nIHBhdGggKGRpc3RyaWJ1 dGVkCiAgICAgIG1vZGVsLCBzZWUgU2VjdGlvbiAzLjIpCiAgIG8gIERldGVybWluZSBhIGZvcndh cmRpbmcgcGF0aCBpbiB0aGUgY29udGV4dCBvZiBhIGNlbnRyYWxpemVkCiAgICAgIGRlcGxveW1l bnQgbW9kZWwgKHNlZSBTZWN0aW9uIDMuMikuCiAgIG8gIEFkanVzdCBTRkNzIG9yIFNGUHMgKGUu Zy4sIGZvciByZXN0b3JhdGlvbiBwdXJwb3NlcykgYmFzZWQgb24KICAgICAgdmFyaW91cyBpbnB1 dHMgKGUuZy4sIGV4dGVybmFsIHBvbGljeSBjb250ZXh0LCBwYXRoIGFsdGVyYXRpb24sIFNGCiAg ICAgIHVuYXZhaWxhYmlsaXR5LCBldGMuKS4KICAgbyAgUG9wdWxhdGUgU0ZDIGZvcndhcmRpbmcg cG9saWN5IHRhYmxlcyBvZiBpbnZvbHZlZCBTRkMgZGF0YSBwbGFuZQogICAgICBlbGVtZW50cyBh bmQgcHJvdmlkZXMgQ2xhc3NpZmllcnMgd2l0aCB0cmFmZmljIGNsYXNzaWZpY2F0aW9uCiAgICAg IHJ1bGVzLgoKICAgRmlndXJlIDEgc2hvd3MgdGhlIG92ZXJhbGwgU0ZDIGNvbnRyb2wgcGxhbmUg YXJjaGl0ZWN0dXJlLCBpbmNsdWRpbmcKICAgaW50ZXJmYWNlIHJlZmVyZW5jZSBwb2ludHMuCgog ICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGVsYWJvcmF0ZSBvbiB0aGUgaW50ZXJuYWwgZGVjb21w b3NpdGlvbiBvZiB0aGUKICAgU0ZDIENvbnRyb2wgJiBNYW5hZ2VtZW50IFBsYW5lIGZ1bmN0aW9u YWwgYmxvY2tzLiAgVGhlIGNvbXBvbmVudHMKICAgd2l0aGluIHRoZSBTRkMgQ29udHJvbCAmIE1h bmFnZW1lbnQgUGxhbmVzIGFuZCB0aGVpciBpbnRlcmFjdGlvbnMgYXJlCiAgIG91dCBvZiBzY29w ZS4KCiAgIEFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDMuMiwgdGhlIFNGQyBjb250cm9sIHBsYW5l IGNhbiBiZSBpbXBsZW1lbnRlZAogICBpbiBhIChsb2dpY2FsbHkpIGNlbnRyYWxpemVkIG9yIGRp c3RyaWJ1dGVkIGZhc2hpb24uCgoKCgoKCgoKCgoKCgoKCgpMaSwgZXQgYWwuICAgICAgICAgICAg ICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRl cm5ldC1EcmFmdCAgIENvbnRyb2wgUGxhbmUgQ29tcG9uZW50cyAmIFJlcXVpcmVtZW50cyAgICAg IEFwcmlsIDIwMTUKCgogICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgIHwgICAg ICAgU0ZDICBDb250cm9sICYgTWFuYWdlbWVudCBQbGFuZXMgICAgICAgfAogICAgICAgICAgKy0t LS0tLS18ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgICAgICBDMSAgICAgICstLS0tLS1eLS0tLS0tLS0tLS1eLS0tLS0tLS0tLS0t LV4tLS0tLS0tLS0tLS0tKwogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tfEMzLS0tLS0tLS0tfC0t LS0tLS0tLS0tLS18LS0tLS0tLS0tLS0tLSsKICAgfCAgICAgIHwgICAgICAgICAgICArLS0tLSsg ICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8CiAgIHwgICAgICB8ICAgICAgICAg ICAgfCBTRiB8ICAgICAgICB8QzIgICAgICAgICAgIHxDMiAgICAgICAgICAgfAogICB8ICAgICAg fCAgICAgICAgICAgICstLS0tKyAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwK ICAgfCArLS0tLVYtLS0gLS0rICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8CiAgIHwgfCAgIFNGQyAgICAgfCAgICAgKy0tLS0rICAgICAgKy18LS0rICAgICAg ICArLS0tLSsgICAgICAgICAgfAogICB8IHxDbGFzc2lmaWVyIHwtLS0tPnxTRkYgfC0tLS0tPnxT RkYgfC0tLS0tLS0+fFNGRiB8ICAgICAgICAgIHwKICAgfCB8ICAgTm9kZSAgICB8PC0tLS18ICAg IHw8LS0tLS18ICAgIHw8LS0tLS0tLXwgICAgfCAgICAgICAgICB8CiAgIHwgKy0tLS0tLS0tLS0t KyAgICAgKy0tLS0rICAgICAgKy0tLS0rICAgICAgICArLS0tLSsgICAgICAgICAgfAogICB8ICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg IHwKICAgfCAgICAgICAgICAgICAgICAgICAgIHxDMiAgICAgIC0tLS0tLS0gICAgICAgICAgIHwg ICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgfCAg ICAgKy0tLS0tLS0tLS0tKyBDNCAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgViAgICAgKy0t LS0rICstLS0tKyAgIHwgU0ZDIFByb3h5IHwtLT4gIHwKICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgU0YgfCB8U0YgIHwgICArLS0tLS0tLS0tLS0rICAgICB8CiAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLSsgKy0tLS0rICAgICAgICAgICAgICAgICAgICAgfAogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8QzMgICAgfEMzICAgICAgICAgICAgICAgICAg ICAgIHwKICAgfCAgU0ZDIERhdGEgUGxhbmUgQ29tcG9uZW50cyAgViAgICAgIFYgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBT RkMgQ29udHJvbCBQbGFuZTogT3ZlcnZpZXcKCjMuMi4gIENlbnRyYWxpemVkIHZzLiBEaXN0cmli dXRlZAoKICAgVGhlIFNGQyBjb250cm9sIHBsYW5lIGNhbiBiZSAobG9naWNhbGx5KSBjZW50cmFs aXplZCwgZGlzdHJpYnV0ZWQgb3IKICAgYSBjb21iaW5hdGlvbiB0aGVyZW9mLiAgV2hldGhlciBv bmUgb3IgbXVsdGlwbGUgU0ZDIENvbnRyb2wgRWxlbWVudHMKICAgYXJlIGVuYWJsZWQgaXMgZGVw bG95bWVudC1zcGVjaWZpYy4gIE5ldmVydGhlbGVzcywgdGhlIGZvbGxvd2luZwogICBjb21tZW50 cyBjYW4gYmUgbWFkZToKCiAgIFNGQyBtYW5hZ2VtZW50IChpbmNsdWRpbmcgU0ZDIG1vbml0b3Jp bmcgYW5kIHN1cGVydmlzaW9uKTogIGlzIGxpa2VseQogICAgICB0byBiZSBjZW50cmFsaXplZC4K CiAgIFNGQyBNYXBwaW5nIFJ1bGVzOiAgaS5lLiwgc2VydmljZSBpbnN0cnVjdGlvbnMgdG8gYmlu ZCBhIGZsb3cgdG8gYQogICAgICBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGFyZSBsaWtlbHkgdG8g YmUgbWFuYWdlZCBieSBhIGNlbnRyYWwgU0ZDCiAgICAgIENvbnRyb2wgRWxlbWVudCwgYnV0IHRo ZSByZXN1bHRpbmcgcG9saWNpZXMgY2FuIGJlIHNoYXJlZCBhbW9uZwogICAgICBzZXZlcmFsIENv bnRyb2wgRWxlbWVudHMuICBOb3RlLCB0aGVzZSBwb2xpY2llcyBjYW4gYmUKICAgICAgY29tcGxl bWVudGVkIHdpdGggbG9jYWwgaW5mb3JtYXRpb24gKGUuZy4sIGFuIElQdjQgYWRkcmVzcy9JUHY2 CiAgICAgIHByZWZpeCBhc3NpZ25lZCB0byBhIGN1c3RvbWVyKSBiZWNhdXNlIHN1Y2ggaW5mb3Jt YXRpb24gbWF5IG5vdCBiZQogICAgICBhdmFpbGFibGUgdG8gdGhlIGNlbnRyYWwgZW50aXR5IGJ1 dCBrbm93biBvbmx5IGR1cmluZyBuZXR3b3JrCiAgICAgIGF0dGFjaG1lbnQgcGhhc2UuCgogICBQ YXRoIGNvbXB1dGF0aW9uOiAgY2FuIGJlIGVpdGhlciBkaXN0cmlidXRlZCBvciBjZW50cmFsaXpl ZC4KICAgICAgRGlzdHJpYnV0ZWQgcGF0aCBjb21wdXRhdGlvbiBtZWFucyB0aGF0IHRoZSBzZWxl Y3Rpb24gb2YgdGhlIGV4YWN0CgoKCkxpLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgT2N0 b2JlciAzMCwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAg Q29udHJvbCBQbGFuZSBDb21wb25lbnRzICYgUmVxdWlyZW1lbnRzICAgICAgQXByaWwgMjAxNQoK CiAgICAgIHNlcXVlbmNlIG9mIFNGIGZ1bmN0aW9ucyB0aGF0IGEgcGFja2V0IG5lZWRzIHRvIGlu dm9rZSAoYWxvbmcgd2l0aAogICAgICBpbnN0YW5jZXMgYW5kL29yIFNGRiBsb2NhdG9yIGluZm9y bWF0aW9uKSBpcyBhIHJlc3VsdCBvZiBhCiAgICAgIGRpc3RyaWJ1dGVkIHBhdGggc2VsZWN0aW9u IGFsZ29yaXRobSBleGVjdXRlZCBieSBpbnZvbHZlZCBub2Rlcy4KICAgICAgRm9yIHNvbWUgdHJh ZmZpYyBlbmdpbmVlcmluZyBwcm9wb3NlcywgdGhlIFNGUCBtYXkgYmUgY29uc3RyYWluZWQKICAg ICAgYnkgdGhlIGNvbnRyb2wgcGxhbmU7IGFzIHN1Y2gsIHNvbWUgU0ZQcyBjYW4gYmUgZnVsbHkg c3BlY2lmaWVkCiAgICAgIChpLmUuLCBsaXN0IGFsbCB0aGUgU0ZGL1NGcyB0aGF0IG5lZWQgdG8g YmUgc29saWNpdGVkKSBvcgogICAgICBwYXJ0aWFsbHkgc3BlY2lmaWVkIChlLmcuLCBleGNsdWRl IHNvbWUgbm9kZXMsIGV4cGxpY2l0bHkgc2VsZWN0CiAgICAgIHdoaWNoIGluc3RhbmNlIG9mIGEg Z2l2ZW4gU0YgbmVlZHMgdG8gYmUgaW52b2tlZCwgZXRjLikuCgogICBTRkMgUmVzaWxpZW5jeSAo aW5jbHVkaW5nIHJlc3RvcmF0aW9uKSAgcmVmZXJzIHRvIG1lY2hhbmlzbXMgdG8KICAgICAgZW5z dXJlIGhpZ2ggYXZhaWxhYmxlIFNGQ3MuICBJdCBpbmNsdWRlcyBtZWFucyB0byBkZXRlY3QKICAg ICAgbm9kZS9saW5rL3BhdGggZmFpbHVyZXMuICBCb3RoIGNlbnRyYWxpemVkIGFuZCBkaXN0cmli dXRlZAogICAgICBtZWNoYW5pc20gdG8gZW5zdXJlIFNGQyByZXNpbGllbmN5IGNhbiBiZSBlbnZp c2FnZWQuCgogICBJbXBsZW1lbnRpbmcgYSAobG9naWNhbGx5KSBjZW50cmFsaXplZCBwYXRoIGNv bXB1dGF0aW9uIGVuZ2luZQogICByZXF1aXJlcyBpbmZvcm1hdGlvbiB0byBiZSBkeW5hbWljYWxs eSBjb21tdW5pY2F0ZWQgdG8gdGhlIGNlbnRyYWwKICAgU0ZDIENvbnRyb2wgRWxlbWVudCwgc3Vj aCBhcyB0aGUgbGlzdCBvZiBhdmFpbGFibGUgU0YgaW5zdGFuY2VzLCBTRkYKICAgbG9jYXRvcnMs IGxvYWQgc3RhdHVzLCBTRlAgYXZhaWxhYmlsaXR5LCBldGMuCgozLjMuICBJbnRlcmZhY2UgUmVm ZXJlbmNlIFBvaW50cwoKICAgVGhlIGZvbGxvd2luZyBzdWItc2VjdGlvbnMgZGVzY3JpYmUgdGhl IGludGVyZmFjZXMgYmV0d2VlbiB0aGUgU0ZDCiAgIENvbnRyb2wgJiBNYW5hZ2VtZW50IFBsYW5l cywgYXMgd2VsbCBhcyB2YXJpb3VzIFNGQyBkYXRhIHBsYW5lCiAgIGVsZW1lbnRzCgozLjMuMS4g IEMxOiBJbnRlcmZhY2UgYmV0d2VlbiBTRkMgQ29udHJvbCBQbGFuZSAmIFNGQyBDbGFzc2lmaWVy CgogICBBcyBhIHJlbWluZGVyLCBhIENsYXNzaWZpZXIgaXMgYSBmdW5jdGlvbiB0aGF0IGlzIHJl c3BvbnNpYmxlIGZvcgogICBjbGFzc2lmeWluZyB0cmFmZmljIGJhc2VkIG9uIChwcmUtZGVmaW5l ZCkgcnVsZXMuCgogICBUaGlzIGludGVyZmFjZSBpcyB1c2VkIHRvIGluc3RhbGwgU0ZDIGNsYXNz aWZpY2F0aW9uIHJ1bGVzIGluCiAgIENsYXNzaWZpZXJzLiAgT25jZSBjbGFzc2lmaWNhdGlvbiBy dWxlcyBhcmUgcG9wdWxhdGVkLCBTRkMKICAgQ2xhc3NpZmllcnMgYXJlIHJlc3BvbnNpYmxlIGZv ciBiaW5kaW5nIGluY29taW5nIHRyYWZmaWMgdG8gU0ZDcwogICBhY2NvcmRpbmcgdG8gdGhlc2Ug Y2xhc3NpZmljYXRpb24gcnVsZXMuICBOb3RlLCB0aGUgU0ZDIGNvbnRyb2wgcGxhbmUKICAgbXVz dCBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBvbiBob3cgdGhlIHRyYWZmaWMgaXMgdG8gYmUgYm91 bmQgdG8gYQogICBnaXZlbiBTRkMuICBJbiBvdGhlciB3b3JkcywgY2xhc3NpZmljYXRpb24gcnVs ZXMgYXJlIGRlcGxveW1lbnQtCiAgIHNwZWNpZmljLiAgRm9yIGluc3RhbmNlLCBjbGFzc2lmaWNh dGlvbiBjYW4gcmVseSBvbiBhIHN1YnNldCBvZiB0aGUKICAgaW5mb3JtYXRpb24gY2FycmllZCBp biBhIHJlY2VpdmVkIHBhY2tldCBzdWNoIGFzIDUtdHVwbGUKICAgY2xhc3NpZmljYXRpb24sIGJl IHN1YnNjcmliZXItYXdhcmUsIGJlIGRyaXZlbiBieSB0cmFmZmljIGVuZ2luZWVyaW5nCiAgIGNv bnNpZGVyYXRpb25zLCBvciBhbnkgY29tYmluYXRpb24gdGhlcmVvZi4KCiAgIFRoZSBTRkMgY29u dHJvbCBwbGFuZSBzaG91bGQgYmUgcmVzcG9uc2libGUgZm9yIHJlbW92aW5nIGludmFsaWQgKGFu ZAogICBzdGFsZSkgbWFwcGluZ3MgZnJvbSB0aGUgY2xhc3NpZmljYXRpb24gdGFibGVzIG1haW50 YWluZWQgYnkgdGhlCiAgIGNsYXNzaWZpZXJzLiAgQWxzbywgbG9jYWwgc2FuaXR5IGNoZWNrcyBt ZWNoYW5pc21zIG1heSBiZSBzdXBwb3J0ZWQKICAgbG9jYWxseSBieSB0aGUgQ2xhc3NpZmllcnMs IGJ1dCB0aG9zZSBhcmUgb3V0IG9mIHNjb3BlLgoKCgoKCgpMaSwgZXQgYWwuICAgICAgICAgICAg ICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRl cm5ldC1EcmFmdCAgIENvbnRyb2wgUGxhbmUgQ29tcG9uZW50cyAmIFJlcXVpcmVtZW50cyAgICAg IEFwcmlsIDIwMTUKCgogICBDbGFzc2lmaWNhdGlvbiBydWxlcyBtYXkgYmUgdXBkYXRlZCwgZGVs ZXRlZCBvciBkaXNhYmxlZCBieSB0aGUKICAgY29udHJvbCBwbGFuZS4gIENyaXRlcmlhIHRoYXQg d291bGQgdHJpZ2dlciB0aG9zZSBvcGVyYXRpb25zIGFyZQogICBkZXBsb3ltZW50LXNwZWNpZmlj LgoKICAgQmVjYXVzZSBhIGxhcmdlIG51bWJlciAoZS5nLiwgMTAwMHMpIG9mIGNsYXNzaWZpY2F0 aW9uIGVudHJpZXMgbWF5IGJlCiAgIGNvbmZpZ3VyZWQgdG8gYSBjbGFzc2lmaWVyLCBtZWFucyB0 byByZWR1Y2UgY2xhc3NpZmljYXRpb24gbG9vay11cAogICB0aW1lIHN1Y2ggYXMgb3B0aW1pemlu ZyB0aGUgc2l6ZSBvZiB0aGUgY2xhc3NpZmljYXRpb24gdGFibGUgKGUuZy4sCiAgIGJ5IG1lYW5z IG9mIGFnZ3JlZ2F0aW9uIGNhcGFiaWxpdGllcykgc2hvdWxkIGJlIHN1cHBvcnRlZCBieSB0aGUg U0ZDCiAgIGNvbnRyb2wgcGxhbmUgKGFuZC9vciB0aGUgY2xhc3NpZmllcikuCgogICBCZWxvdyBh cmUgbGlzdGVkIHNvbWUgZnVuY3Rpb25hbCBvYmplY3RpdmVzIGZvciB0aGlzIGludGVyZmFjZToK CiAgIG8gIFJhdGlvbmFsaXplIHRoZSBtYW5hZ2VtZW50IG9mIGNsYXNzaWZpY2F0aW9uIHJ1bGVz LgogICBvICBNYWludGFpbiBhIGdsb2JhbCB2aWV3IG9mIGluc3RhbnRpYXRlZCBydWxlcyBpbiBh bGwgQ2xhc3NpZmllcnMgaW4KICAgICAgYW4gU0ZDLWVuYWJsZWQgZG9tYWluLgogICBvICBDaGVj ayB0aGUgY29uc2lzdGVuY3kgb2YgaW5zdGFudGlhdGVkIGNsYXNzaWZpY2F0aW9uIHJ1bGVzIHdp dGhpbgogICAgICB0aGUgc2FtZSBDbGFzc2lmaWVyIG9yIGFtb25nIG11bHRpcGxlIENsYXNzaWZp ZXIuCiAgIG8gIEFzc2VzcyB0aGUgaW1wYWN0IG9mIHJlbW92aW5nIG9yIG1vZGlmeWluZyBhIGNs YXNzaWZpY2F0aW9uIGVudHJ5CiAgICAgIG9uIHBhY2tldHMgZW50ZXJpbmcgYW4gU0ZDLWVuYWJs ZWQgZG9tYWluLgogICBvICBBZ2dyZWdhdGUgY2xhc3NpZmljYXRpb24gcnVsZXMgZm9yIHRoZSBz YWtlIG9mIHBlcmZvcm1hbmNlCiAgICAgIG9wdGltaXphdGlvbiAobWFpbmx5IHJlZHVjZSBsb29r dXAgZGVsYXlzKS4KICAgbyAgQWRqdXN0IGNsYXNzaWZpY2F0aW9uIHJ1bGVzIHdoZW4gcnVsZXMg YXJlIGJhc2VkIG9uIHZvbGF0aWxlCiAgICAgIGlkZW50aWZpZXJzIChlLmcuLCBhbiBJUHY0IGFk ZHJlc3MsIElQdjYgcHJlZml4KS4KICAgbyAgQWxsb3cgdG8gcmFwaWRseSByZXN0b3JlIFNGQyBz dGF0ZXMgZHVyaW5nIGZhaWx1cmUgZXZlbnRzIHRoYXQKICAgICAgb2NjdXJyZWQgYXQgYSBDbGFz c2lmaWVyIChvciBhIENvbnRyb2wgRWxlbWVudCkuCgogICBUaGUgY29udHJvbCBwbGFuZSBtdXN0 IGluc3RydWN0IHRoZSBDbGFzc2lmaWVyIHdoZXRoZXIgaXQgY2FuIHRydXN0CiAgIGFuIGV4aXN0 aW5nIFNGQyBtYXJraW5nIG9mIGFuIGluY29taW5nIHBhY2tldCBvciB3aGV0aGVyIGl0IG11c3Qg YmUKICAgaWdub3JlZC4KCiAgIEZvciBiaWRpcmVjdGlvbmFsIHBhY2tldCBwcm9jZXNzaW5nIHB1 cnBvc2VzIChlLmcuLCBmdWxsIG9yIHBhcnRpYWwKICAgcGF0aCBzeW1tZXRyeSksIHRoZSBjb250 cm9sIHBsYW5lIGludm9rZXMgdGhpcyBpbnRlcmZhY2UgdG8gY29uZmlndXJlCiAgIHRoZSBhcHBy b3ByaWF0ZSBjbGFzc2lmaWNhdGlvbiBlbnRyaWVzLgoKICAgQSBDbGFzc2lmaWVyIGNhbiBzZW5k IHVuc29saWNpdGVkIG1lc3NhZ2VzIHRocm91Z2ggdGhpcyBpbnRlcmZhY2UgdG8KICAgbm90aWZ5 IHRoZSBTRkMgQ29udHJvbCAmIE1hbmFnZW1lbnQgUGxhbmVzIGFib3V0IHNwZWNpZmljIGV2ZW50 cy4KCiAgIFJlLWNsYXNzaWZpY2F0aW9uIHJ1bGVzIG1heSBiZSBjb250cm9sbGVkIHdoZW4gYWxs b3dlZCBpbiBvdGhlcgogICBlbGVtZW50cyAoZS5nLiwgU0ZDLWF3YXJlIFNGIG9yIFNGQyBQcm94 eSkuICBUaGlzIGludGVyZmFjZSBjYW4gYmUKICAgdXNlZCBmb3Igc3VjaCBwdXJwb3Nlcy4KCiAg IFNGQyBDbGFzc2lmaWNhdGlvbiBwb2xpY3kgZW50cnkgc2hvdWxkIGJlIGJvdW5kIHRvIG9uZSBz aW5nbGUgU0ZDOwogICB3aGVuIGFuIGluY29taW5nIHBhY2tldCBtYXRjaGVzIG1vcmUgdGhhbiBv bmUgY2xhc3NpZmljYXRpb24gZW50cnksCiAgIHRpZS1icmVha2luZyBjcml0ZXJpYSBzaG91bGQg YmUgc3BlY2lmaWVkIChlLmcuLCBwcmlvcml0eSkuICBTdWNoCiAgIHRpZS1icmVha2luZyBjcml0 ZXJpYSBzaG91bGQgYmUgaW5zdHJ1Y3RlZCBieSB0aGUgY29udHJvbCBwbGFuZS4KCiAgIFRoZSBp ZGVudGlmaWNhdGlvbiBvZiBpbnN0YW50aWF0ZWQgU0ZDcyBpcyBsb2NhbCB0byBlYWNoCiAgIGFk bWluaXN0cmF0aXZlIGRvbWFpbjsgaXQgaXMgcG9saWN5LWJhc2VkIGFuZCBkZXBsb3ltZW50LXNw ZWNpZmljLgoKCgpMaSwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIw MTUgICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnRyb2wgUGxh bmUgQ29tcG9uZW50cyAmIFJlcXVpcmVtZW50cyAgICAgIEFwcmlsIDIwMTUKCgozLjMuMi4gIEMy OiBJbnRlcmZhY2UgYmV0d2VlbiBTRkMgQ29udHJvbCBQbGFuZSAmIFNGRgoKICAgU0ZGcyBtYWtl IHRyYWZmaWMgZm9yd2FyZGluZyBkZWNpc2lvbnMgYWNjb3JkaW5nIHRvIHRoZSBlbnRyaWVzCiAg IG1haW50YWluZWQgaW4gdGhlaXIgU0ZDIGZvcndhcmRpbmcgcG9saWN5IHRhYmxlLiAgU3VjaCB0 YWJsZSBpcwogICBwb3B1bGF0ZWQgYnkgdGhlIFNGQyBjb250cm9sIHBsYW5lIHRocm91Z2ggdGhl IEMyIGludGVyZmFjZS4KCiAgIFRoaXMgaW50ZXJmYWNlIGlzIGFsc28gdXNlZCB0byBpbnN0cnVj dCBhIFNGRiBhYm91dCB0aGUgU0ZDLWF3YXJlIFNGcwogICB0aGF0IGl0IGNhbiBzZXJ2aWNlLiAg TG9jYWwgbWVhbnMgbWF5IGJlIGVuYWJsZWQgYmV0d2VlbiB0aGUgU0ZDLQogICBhd2FyZSBTRnMg YW5kIFNGRnMgdG8gYWxsb3cgZm9yIHRoZSBkeW5hbWljIGF0dGFjaG1lbnQgb2YgU0ZzIHRvIGEK ICAgU0ZGIGJ1dCB0aG9zZSBtZWFucyBhcmUgdW5zcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudC4K CiAgIFRoZSBDMiBpbnRlcmZhY2UgaXMgYWxzbyB1c2VkIGZvciBjb2xsZWN0aW5nIHN0YXRlcyBv ZiBhdHRyaWJ1dGVzCiAgIChlLmcuLCBhdmFpbGFiaWxpdHksIHdvcmtsb2FkLCBsYXRlbmN5KSwg Zm9yIGV4YW1wbGUsIHRvIGR5bmFtaWNhbGx5CiAgIGFkanVzdCBTZXJ2aWNlIEZ1bmN0aW9uIFBh dGhzLgoKMy4zLjMuICBDMzogSW50ZXJmYWNlIGJldHdlZW4gU0ZDIENvbnRyb2wgUGxhbmUgJiBT RkMtYXdhcmUgU0ZzCgogICBUaGUgU0ZDIGNvbnRyb2wgcGxhbmUgdXNlcyB0aGlzIGludGVyZmFj ZSB0byBpbnRlcmFjdCB3aXRoIFNGQy1hd2FyZQogICBTRnMuCgogICBTRnMgbWF5IG5lZWQgdG8g b3V0cHV0IHNvbWUgcHJvY2Vzc2luZyByZXN1bHRzIG9mIHBhY2tldHMgdG8gdGhlIFNGQwogICBj b250cm9sIHBsYW5lLiAgVGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUgdXNlZCBieSB0aGUgU0ZDIGNv bnRyb2wgcGxhbmUKICAgdG8gdXBkYXRlIHRoZSBTRkMgY2xhc3NpZmljYXRpb24gcnVsZXMgYW5k IHRoZSBTRkMgZm9yd2FyZGluZyBwb2xpY3kKICAgdGFibGUgZW50cmllcy4KCiAgIFRoaXMgSW50 ZXJmYWNlIGlzIHVzZWQgdG8gY29sbGVjdCBzdWNoIGtpbmQgb2YgZmVlZGJhY2sgaW5mb3JtYXRp b24KICAgZnJvbSBTRnMuICBGb3IgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBj YW4gYmUgZXhjaGFuZ2VkCiAgIGJldHdlZW4gYSBTRiBhbmQgdGhlIFNGQyBjb250cm9sIHBsYW5l OgoKICAgbyAgU0YgZXhlY3V0aW9uIHN0YXR1czogU29tZSBTRnMgbWF5IG5lZWQgdG8gc2VuZCBp bmZvcm1hdGlvbiB0byB0aGUKICAgICAgY29udHJvbCBwbGFuZSB0byBmaW5lIHR1bmUgU0ZQcy4g IEZvciBleGFtcGxlLCBhIHRocmVhdC1kZXRlY3RpbmcKICAgICAgU0YgY2FuIHBlcmlvZGljYWxs eSBzZW5kIHRoZSB0aHJlYXQgY2hhcmFjdGVyaXN0aWNzIHZpYSB0aGlzCiAgICAgIGludGVyZmFj ZSwgc3VjaCBhcyBoaWdoIHByb2JhYmlsaXR5IG9mIHRocmVhdCB3aXRoIHBhY2tldCBzaXplCiAg ICAgIGVxdWFsIHRvIDQ3LiAgVGhlIGNvbnRyb2wgcGxhbmUgY2FuIHRoZW4gYWRkICJwYWNrZXQt c2l6ZT00NyIKICAgICAgbWF0Y2hpbmcgY3JpdGVyaWEgdG8gU0ZGIHRvIHN0ZWVyIHRyYWZmaWMg d2l0aCBwYWNrZXQgc2l6ZSBlcXVhbAogICAgICB0byA0NyB0byBhIHNjcnViYmluZyBjZW50ZXIu CgogICBvICBTRiBMaXZlbGluZXNzIHVwZGF0ZTogV2hlbiBTRnMgYXJlIHVuZGVyIHN0cmVzcyB0 aGF0IHlpZWxkZWQgdGhlCiAgICAgIGNyb3NzaW5nIG9mIHNvbWUgcGVyZm9ybWFuY2UgdGhyZXNo b2xkcywgdGhlIFNGQyBjb250cm9sIHBsYW5lCiAgICAgIG5lZWRzIHRvIGJlIG5vdGlmaWVkIHRv IGFkanVzdCBTRlBzIGFjY29yZGluZ2x5IChlc3BlY2lhbGx5IHdoZW4KICAgICAgdGhlIGNlbnRy YWxpemVkIHBhdGggY29tcHV0YXRpb24gbW9kZSBpcyBlbmFibGVkKSAuCgogICBUaGlzIGludGVy ZmFjZSBpcyBhbHNvIHVzZWQgdG8gaW5zdHJ1Y3QgYW4gU0ZDLWF3YXJlIFNGIGFib3V0IGFueQog ICBjb250ZXh0IGluZm9ybWF0aW9uIGl0IG5lZWQgdG8gc3VwcGx5IGluIHRoZSBjb250ZXh0IG9m IGEgZ2l2ZW4gU0ZDLgoKICAgQSBTRkMtYXdhcmUgU0YgY2FuIGFsc28gYmUgaW5zdHJ1Y3RlZCBh Ym91dCB0aGUgYmVoYXZpb3IgaXMgc2hvdWxkCiAgIGFkb3B0IGFmdGVyIGNvbnN1bWluZyBhIGNv bnRleHQgaW5mb3JtYXRpb24gdGhhdCB3YXMgc3VwcGxpZWQgaW4gdGhlCiAgIFNGQyBoZWFkZXIu ICBGb3IgZXhhbXBsZSwgdGhlIGNvbnRleHQgY2FuIGJlIG1haW50YWluZWQgb3Igc3RyaXBwZWQu CgoKCkxpLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxNSAgICAg ICAgICAgICAgIFtQYWdlIDEyXQoMCkludGVybmV0LURyYWZ0ICAgQ29udHJvbCBQbGFuZSBDb21w b25lbnRzICYgUmVxdWlyZW1lbnRzICAgICAgQXByaWwgMjAxNQoKCiAgIFRoZSBTRkMtYXdhcmUg U0YgY2FuIGJlIGluc3RydWN0ZWQgdG8gaW5qZWN0IGEgbmV3IGNvbnRleHQgaGVhZGVyCiAgIGlu dG8gdGhlIFNGQyBoZWFkZXIuCgogICBNdWx0aXBsZSBTRnMgbWF5IGJlIGxvY2F0ZWQgd2l0aGlu IHRoZSBzYW1lIHBoeXNpY2FsIG5vZGUsIGFuZCBubyBTRkYKICAgaXMgZW5hYmxlZCBpbiB0aGF0 IHNhbWUgbm9kZSwgbWVhbnMgdG8gdW5hbWJpZ3VvdXNseSBmb3J3YXJkIHRoZQogICB0cmFmZmlj IHRvIHRoZSBhcHByb3ByaWF0ZSBTRiBtdXN0IGJlIHN1cHBvcnRlZC4KCiAgIENvLWxvY2F0ZWQg U0ZDLWF3YXJlIFNGcyBtYXkgYmUgYWRqYWNlbnQgaW4gdGhlIGNvbnRleHQgb2YgYSBTRkMsCiAg IHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGlzY3VzcyBhYm91dCBob3cgZm9yd2FyZGluZyBpcyBv cHRpbWl6ZWQgc28KICAgdGhhdCB0cmFmZmljIHRoYXQgaXMgYXNzb2NpYXRlZCB0byB0aGF0IFNG QyBpcyBoYW5kbGVkIGxvY2FsbHkgdGlsbAogICBhbGwgYWRqYWNlbnQgU0ZzIGFyZSBjb25zdW1l ZCAuCgogICBBbiBTRiBjYW4gYmUgaW5zdHJ1Y3RlZCB0byBzdHJpcCB0aGUgU0ZDIGluZm9ybWF0 aW9uIGZvciB0aGUgY2hhaW5zCiAgIGl0IHRlcm1pbmF0ZXMuCgozLjMuNC4gIEM0OiBJbnRlcmZh Y2UgYmV0d2VlbiBTRkMgQ29udHJvbCBQbGFuZSAmIFNGQyBQcm94eQoKICAgVGhlIFNGQyBjb250 cm9sIHBsYW5lIHVzZXMgdGhpcyBpbnRlcmZhY2UgdG8gaW50ZXJhY3Qgd2l0aCBhbiBTRkMKICAg UHJveHkuCgogICBUaGUgU0ZDIHByb3h5IGNhbiBiZSBpbnN0cnVjdGVkIGFib3V0IGF1dGhvcml6 ZWQgU0ZDLXVud2FyZSBTRnMgaXQKICAgY2FuIHNlcnZpY2UuICBBIFNGQyBQcm94eSBjYW4gYmUg aW5zdHJ1Y3RlZCBhYm91dCB0aGUgYmVoYXZpb3IgaXQKICAgc2hvdWxkIGFkb3B0IHRvIHByb2Nl c3MgdGhlIGNvbnRleHQgaW5mb3JtYXRpb24gdGhhdCB3YXMgc3VwcGxpZWQgaW4KICAgdGhlIFNG QyBoZWFkZXIgb24gYmVoYWxmIG9mIGEgU0ZDLXVud2FyZSBTRiwgZS5nLiwgdGhlIGNvbnRleHQg Y2FuIGJlCiAgIG1haW50YWluZWQgb3Igc3RyaXBwZWQuCgogICBUaGUgU0ZDIFByb3h5IGNhbiBh bHNvIGJlIGluc3RydWN0ZWQgdG8gYWRkIFNGIHNvbWUgbmV3IGNvbnRleHQKICAgaW5mb3JtYXRp b24gaW50byB0aGUgU0ZDIGhlYWRlciBvbiBiZWhhbGYgb2YgYSBTRkMtdW5hd2FyZSBTRi4KCiAg IFRoZSBDNCBpbnRlcmZhY2UgaXMgYWxzbyB1c2VkIGZvciBjb2xsZWN0aW5nIGF0dHJpYnV0ZSBz dGF0ZXMgKGUuZy4sCiAgIGF2YWlsYWJpbGl0eSwgd29ya2xvYWQsIGxhdGVuY3kpLCBmb3IgZXhh bXBsZSwgdG8gZHluYW1pY2FsbHkgYWRqdXN0CiAgIFNlcnZpY2UgRnVuY3Rpb24gUGF0aHMuCgo0 LiAgU0ZDIENvbnRyb2wgSW5mb3JtYXRpb24gRXhjaGFuZ2UgKFdhbHRlcikKCiAgIFhYWFggRGVz Y3JpYmUgd2hhdCBraW5kcyBvZiBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBleGNoYW5nZWQgWFhY WFhYCgo0LjEuICB0aXRsZSAxCgo0LjIuICB0aXRsZSAxCgo1LiAgQWR2YW5jZWQgRmVhdHVyZXMK CjUuMS4gIERpc2NvdmVyeSBvZiB0aGUgU0ZDIENvbnRyb2wgRWxlbWVudAoKICAgVGhpcyBkb2N1 bWVudCBhc3N1bWVzIFNGQyBkYXRhIHBsYW5lIGZ1bmN0aW9uYWwgZWxlbWVudHMgc3VwcG9ydHMK ICAgbWVhbnMgdG8gZGlzY292ZXIgQ29udHJvbCBFbGVtZW50cy4gIFRoaXMgY2FuIGJlIGFjaGll dmVkIHVzaW5nIGEKICAgdmFyaWV0eSBpZiBtZWNoYW5pc206IGluY2x1ZGluZyBzdGF0aWMgY29u ZmlndXJhdGlvbiBvciB0aGUKCgoKTGksIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBPY3Rv YmVyIDMwLCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICBD b250cm9sIFBsYW5lIENvbXBvbmVudHMgJiBSZXF1aXJlbWVudHMgICAgICBBcHJpbCAyMDE1CgoK ICAgYWN0aXZhdGlvbiBvZiBhIHNlcnZpY2UgZGlzY292ZXJ5IG1lY2hhbmlzbS4gIFRoZSBleGFj dCBzcGVjaWZpY2F0aW9uCiAgIG9mIHRoZSBDb250cm9sIEVsZW1lbnQgZGlzY292ZXJ5IGFyZSBv dXQgb2Ygc2NvcGUuCgo1LjIuICBTRiBTeW1tZXRyeQoKICAgU29tZSBTRnMgcmVxdWlyZSBib3Ro IGRpcmVjdGlvbnMgb2YgYSBmbG93IHRvIHRyYXZlcnNlLiAgU29tZSBTRkNzCiAgIHJlcXVpcmUg ZnVsbCBzeW1tZXRyeS4gIElmIGEgU0YgKGUuZy4sIHN0YXRlZnVsIGZpcmV3YWxsIG9yIE5BVCkK ICAgbmVlZHMgYm90aCBkaXJlY3Rpb24gb2YgYSBmbG93LCBpdCBpcyB0aGUgU0YgaW5zdGFudGlh dGlvbiB0aGF0IG5lZWRzCiAgIGJvdGggZGlyZWN0aW9uIG9mIGEgZmxvdyB0byB0cmF2ZXJzZSwg bm90IHRoZSBhYnN0cmFjdCBTRiAod2hpY2ggY2FuCiAgIGhhdmUgbWFueSBpbnN0YW50aWF0aW9u cyBzcHJlYWQgYWNyb3NzIHRoZSBuZXR3b3JrKS4KCjUuMy4gIFByZS1kZXBsb3lpbmcgU0ZDcwoK ICAgRW5hYmxpbmcgU0ZDcyBzaG91bGQgcHJlc2VydmUgc29tZSBkZXBsb3ltZW50IHByYWN0aWNl cyBhZG9wdGVkIGJ5CiAgIE9wZXJhdG9ycy4gIFBhcnRpY3VsYXJseSwgaW5zdGFsbGluZyBhIFNG QyBzaG91bGQgYWxsb3cgZm9yIHByZS0KICAgZGVwbG95bWVudCB0ZXN0aW5nIGFuZCB2YWxpZGF0 aW9uIHB1cnBvc2VzICh0aGF0IGlzIGEgcmVzdHJpY3RlZCBhbmQKICAgY29udHJvbGxlZCB1c2Fn ZSBvZiBzdWNoIFNGQykuCgo1LjQuICBXaXRocmF3IGEgU2VydmljZSBGdW5jdGlvbgoKICAgRHVy aW5nIHRoZSBsaWZldGltZSBvZiBhIFNGQywgYSBnaXZlbiBTRiBjYW4gYmUgZGVjb21taXNzaW9u ZWQuICBUbwogICBhY2NvbW1vZGF0ZSBzdWNoIGNvbnRleHQgYW5kIGFueSBvdGhlciBjYXNlIHdo ZXJlIGEgU0YgaXMgdG8gYmUKICAgd2l0aGRyYXduLCB0aGUgY29udHJvbCBwbGFuZSBzaG91bGQg aW5zdHJ1Y3QgdGhlIFNGQyBkYXRhIHBsYW5lCiAgIGZ1bmN0aW9uYWwgZWxlbWVudCBhYm91dCB0 aGUgYmVoYXZpb3IgdG8gYWRvcHQuICBQYXJ0aWN1bGFybHksIGEKICAgZmlyc3QgYXBwcm9hY2gg d291bGQgYmUgdG8gdXBkYXRlIHRoZSBTRkNzIHdoZXJlIHRoYXQgU0YgaXMgcHJlc2VudAogICBi eSByZW1vdmluZyBhbnkgcmVmZXJlbmNlIHRvIHRoYXQgU0YuICBEb2luZyBzbyBhdm9pZHMgdG8g aW5kdWNlCiAgIHNlcnZpY2UgZmFpbHVyZXMgZm9yIGVuZCB1c2Vycy4gIEEgc2Vjb25kIGFwcHJv YWNoIHdvdWxkIGJlIHRvCiAgIGRlbGV0ZS9kZWFjdGl2YXRlIGFueSBTRkMgdGhhdCBpbnZvbHZl cyB0aGF0IFNGIGJ1dCBpbnN0YWxsIG5ldyBTRkNzLgoKNS41LiAgU0ZDIE9wZXJhdGlvbnMKCiAg IFZhcmlvdXMgYWN0aW9ucyBjYW4gYmUgZXhlY3V0ZWQgb24gYW4gU0ZDIHRoYXQgaXMgc3RydWN0 dXJlZCBieSB0aGUKICAgU0ZDIENvbnRyb2wgJiBNYW5hZ2VtZW50IHBsYW5lcy4gIEluZGVlZCwg YW4gU0ZDIGNhbiBiZSBlbmFibGVkLAogICBkaXNhYmxlZCwgaXRzIHN0cnVjdHVyZSBtb2RpZmll ZCBieSBhZGRpbmcgYSBuZXcgU0YgaG9wIG9yIHJlbW92ZSBhbgogICBTRiBmcm9tIHRoZSBzZXF1 ZW5jZSBvZiBTRnMgdG8gYmUgaW52b2tlZCwgaXRzIGNsYXNzaWZpY2F0aW9uIHJ1bGVzCiAgIG1v ZGlmaWVkLCBldGMuCgogICBBIG1vZGlmaWNhdGlvbiBvZiBhIFNGQyBjYW4gdHJpZ2dlciBjb250 cm9sIG1lc3NhZ2VzIHdpdGggdGhlCiAgIGFwcHJvcHJpYXRlIFNGQy1hd2FyZSBub2RlcyBhY2Nv cmRpbmdseS4KCjUuNi4gIFVuc29saWNpdGVkIE1lc3NhZ2VzCgogICBJbnZvbHZlZCBTRkMgZGF0 YSBwbGFuZSBmdW5jdGlvbmFsIGVsZW1lbnQgbXVzdCBiZSBpbnN0cnVjdGVkIHRvIHNlbmQKICAg dW5zb2xpY2l0ZWQgbm90aWZpY2F0aW9ucyB3aGVuIGxvb3BzIGFyZSBkZXRlY3RlZCwgYSBwcm9i bGVtIGluIHRoZQogICBzdHJ1Y3R1cmUgb2YgYSBTRkMgaXMgZW5jb3VudGVyZWQsIGEgbG9uZyB1 bmF2YWlsYWJsZSBmb3J3YXJkaW5nIHBhdGgKICAgdGltZSBpcyBvYnNlcnZlZCwgZXRjLiAgU3Bl Y2lmaWMgY3JpdGVyaWEgdG8gc2VuZCB1bnNvbGljaXRlZAogICBub3RpZmljYXRpb25zIHRvIGEg Q29udHJvbCBFbGVtZW50IHNob3VsZCBiZSBmaW5lIHR1bmVkIGJ5IHRoZQogICBjb250cm9sIHBs YW5lIHVzaW5nIHRoZSBpbnRlcmZhY2UgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMy4KCgoKTGksIGV0 IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMwLCAyMDE1ICAgICAgICAgICAgICAg W1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQgICBDb250cm9sIFBsYW5lIENvbXBvbmVudHMgJiBS ZXF1aXJlbWVudHMgICAgICBBcHJpbCAyMDE1CgoKNS43LiAgU0YgTGl2ZW5lc3MgRGV0ZWN0aW9u CgogICBUaGUgY29udHJvbCBwbGFuZSBtdXN0IGFsbG93IHRvIGRldGVjdCB0aGUgbGl2ZWxpbmVz cyBvZiBTRnMgb2YgYW4KICAgU0ZDLWVuYWJsZWQgZG9tYWluLiAgSW4gcGFydGljdWxhciwgaXQg bXVzdCBhbGxvdyB0byBkeW5hbWljYWxseQogICBkZXRlY3QgdGhhdCBhIFNGIGluc3RhbmNlIGlz IG91dCBvZiBzZXJ2aWNlIGFuZCBub3RpZnkgdGhlIHJlbGV2YW50CiAgIENvbnRyb2wgRWxlbWVu dCBlbGVtZW50cyBhY2NvcmRpbmdseS4gIFRoZSBDbGFzc2lmaWVyIG1heSBiZSBub3RpZmllZAog ICBieSB0aGUgY29udHJvbCBwbGFuZSBvciBiZSBwYXJ0IG9mIHRoZSBsaXZlbmVzcyBkZXRlY3Rp b24gcHJvY2VkdXJlLgoKICAgTGl2ZW5lc3Mgc3RhdHVzIHJlY29yZHMgZm9yIGFsbCBTRiBpbnN0 YW5jZXMsIGFuZCBTRkNzIChpbmNsdWRpbmcgdGhlCiAgIFNGUHMgYm91bmQgdG8gYSBnaXZlbiBj aGFpbikgbXVzdCBiZSBtYWludGFpbmVkIGJ5IHRoZSBTRkMgQ29udHJvbCAmCiAgIE1hbmFnZW1l bnQuCgogICBUaGUgYWJpbGl0eSBvZiBhIFNGQyBDb250cm9sIEVsZW1lbnQgdG8gY2hlY2sgdGhl IGxpdmVuZXNzIG9mIGVhY2ggU0YKICAgcHJlc2VudCBpbiBTRkMgY2hhaW4gaGFzIHNldmVyYWwg YWR2YW50YWdlcywgaW5jbHVkaW5nOgoKICAgbyAgRW5oYW5jZWQgc3RhdHVzIHJlcG9ydGluZyBi eSB0aGUgY29udHJvbCAmIG1hbmFnZW1lbnQgcGxhbmVzCiAgICAgIChpLmUuLCBhbiBvcGVyYXRp b25hbCBzdGF0dXMgZm9yIGFueSBnaXZlbiBzZXJ2aWNlIGNoYWluIGRlcml2ZWQKICAgICAgZnJv bSBsaXZlbmVzcyBzdGF0ZSBvZiBpdHMgU0ZzKS4KICAgbyAgQWJpbGl0eSB0byBzdXBwb3J0IHZh cmlvdXMgcmVzaWxpZW5jeSBwb2xpY2llcyAoaS5lLiwgYnlwYXNzIGEKICAgICAgTm9kZSBlbWJl ZGRpbmcgYW4gU0YsIHVzZSBhbHRlcm5hdGUgbm9kZSwgdXNlIGFsdGVybmF0ZSBjaGFpbiwKICAg ICAgZHJvcCB0cmFmZmljLCBldGMuKSAuCiAgIG8gIEFiaWxpdHkgdG8gc3VwcG9ydCBsb2FkIGJh bGFuY2luZyBjYXBhYmlsaXRpZXMgdG8gc29saWNpdCBtdWx0aXBsZQogICAgICBTRiBpbnN0YW5j ZXMgdGhhdCBwcm92aWRlIGVxdWl2YWxlbnQgZnVuY3Rpb25zLgoKICAgQmVjYXVzZSBhIG5vZGUg ZW1iZWRkaW5nIGFuIFNGIGNhbiBiZSByZXNwb25zaXZlIGZyb20gYSByZWFjaGFiaWxpdHkKICAg c3RhbmRwb2ludCAoZS5nLiwgSVAgbGV2ZWwpIHdoaWxlIHRoZSBmdW5jdGlvbiBpdHMgcHJvdmlk ZXMgbWF5IGJlCiAgIGJyb2tlbiAoZS5nLiwgYSBOQVQgbW9kdWxlIG1heSBiZSBkb3duKSwgYWRk aXRpb25hbCBtZWFucyB0byBhc3Nlc3MKICAgd2hldGhlciBhbiBTRiBpcyB1cCBhbmQgcnVubmlu ZyBhcmUgcmVxdWlyZWQuICBUaGVzZSBtZWFucyBtYXkgYmUKICAgc2VydmljZS1zcGVjaWZpYy4K CjUuOC4gIE1vbml0b3JpbmcgJiBDb3VudGVycwoKICAgU0ZDLXNwZWNpZmljIGNvdW50ZXJzIGFu ZCBzdGF0aXN0aWNzIG11c3QgYmUgcHJvdmlkZWQgdXNpbmcgb2YgdGhlCiAgIGludGVyZmFjZXMg ZGVmaW5lZCBpbiBTZWN0aW9uIDMuMy4gIFRoZXNlIGRhdGEgaW5jbHVkZSAoYnV0IG5vdAogICBs aW1pdGVkIHRvKToKCiAgIG8gIE51bWJlciBvZiBmbG93cyBldmVyIGFuZCBjdXJyZW50bHkgYXNz aWduZWQgdG8gYSBnaXZlbiBTRkMgYW5kIGEKICAgICAgZ2l2ZW4gU0ZQLgogICBvICBOdW1iZXIg b2YgZmxvd3MsIHBhY2tldHMsIGJ5dGVzIGRyb3BwZWQgZHVlIHRvIHBvbGljeS4KICAgbyAgTnVt YmVyIG9mIHBhY2tldHMgYW5kIGJ5dGVzIGluL291dCBwZXIgU0ZDLgogICBvICBOdW1iZXIgb2Yg Zmxvd3MsIHBhY2tldHMsIGJ5dGVzIGRyb3BwZWQgZHVlIHRvIHVua25vd24gU0ZDICh0aGlzCiAg ICAgIGlzIHZhbGlkIGluIHBhcnRpY3VsYXIgZm9yIGEgU0Ygbm9kZSkuCgo1LjkuICBTRkMgRGlh Z25vc2lzCgogICBUaGUgQ29udHJvbCAmIE1hbmFnZW1lbnQgcGxhbmVzIHNob3VsZCBhbGxvdyBm b3IgdGhlIGZvbGxvd2luZzoKCgoKCgpMaSwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE9j dG9iZXIgMzAsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAg IENvbnRyb2wgUGxhbmUgQ29tcG9uZW50cyAmIFJlcXVpcmVtZW50cyAgICAgIEFwcmlsIDIwMTUK CgogICBvICBBc3Nlc3MgdGhlIHN0YXR1cyBvZiB0aGUgc2VydmljZWFiaWxpdHkgb2YgYSBTRiAo aS5lLiwgdGhlIFNGCiAgICAgIHByb3ZpZGVzIHRoZSBzZXJ2aWNlKHMpIGl0IGlzIGNvbmZpZ3Vy ZWQgZm9yKS4gIE9idmlvdXNseSwgdGhpcwogICAgICBhc3Nlc3NtZW50IG11c3Qgbm90IHJlbHkg b25seSBvbiBJUCByZWFjaGFiaWxpdHkgdG8gZGVjaWRlIHdoZXRoZXIKICAgICAgYSBTRiBpcyB1 cCBhbmQgcnVubmluZy4KICAgbyAgRGlhZ25vc2UgdGhlIGF2YWlsYWJpbGl0eSBvZiBhIFNGQyAo aW5jbHVkaW5nIHRoZSBhdmFpbGFiaWxpdHkgb2YKICAgICAgYSBwYXJ0aWN1bGFyIFNGUCBib3Vu ZCB0byBhIGdpdmVuIFNGQykuCiAgIG8gIFJldHJpZXZlIHRoZSBzZXQgb2YgU0ZDcyB0aGF0IGFy ZSBlbmFibGVkIHdpdGhpbiBhIGRvbWFpbi4KICAgbyAgQXNzZXNzIHdoZXRoZXIgYW4gU0ZDLWVu YWJsZWQgZG9tYWluIGlzIGFwcHJvcHJpYXRlbHkgY29uZmlndXJlZAogICAgICAoaW5jbHVkaW5n LCBjaGVjayB0aGUgY29uZmlndXJlZCBjaGFpbnMgYXJlIG1hdGNoaW5nIHdoYXQgc2hvdWxkCiAg ICAgIGJlIGNvbmZpZ3VyZWQgaW4gdGhhdCBkb21haW4sIGFuZCBlbnN1cmUgY29oZXJlbnQgY2xh c3NpZmljYXRpb24KICAgICAgcnVsZXMgYXJlIGluc3RhbGxlZCBpbiBhbmQgZW5mb3JjZWQgYnkg YWxsIHRoZSBDbGFzc2lmaWVycyBvZiB0aGUKICAgICAgU0ZDLWVuYWJsZWQgZG9tYWluKS4KICAg byAgQ29ycmVsYXRlIGNsYXNzaWZpY2F0aW9uIHBvbGljaWVzIHdpdGggb2JzZXJ2ZWQgZm9yd2Fy ZGluZyBhY3Rpb25zCiAgICAgIChpbmNsdWRpbmcsIGFzc2VzcyB0aGUgb3V0cHV0IG9mIHRoZSBj bGFzc2lmaWNhdGlvbiBydWxlIGFwcGxpZWQKICAgICAgb24gYSBwYWNrZXQgcHJlc2VudGVkIHRv IGEgQ2xhc3NpZmllciBvZiBhbiBTRkMtZW5hYmxlZCBkb21haW4pLgogICBvICBTdXBwb3J0IHRo ZSBjb3JyZWxhdGlvbiBiZXR3ZWVuIGEgU0ZDIGFuZCB0aGUgYWN0dWFsIGZvcndhcmRpbmcKICAg ICAgcGF0aCBmb2xsb3dlZCBieSBhIHBhY2tldCBtYXRjaGluZyB0aGF0IFNGQy4KICAgbyAgTm90 aWZ5IHRoZSBTRkMgQ29udHJvbCBFbGVtZW50IHdoZW5ldmVyIHNvbWUgKGNyaXRpY2FsKSBldmVu dHMKICAgICAgb2NjdXIgKGZvciBleGFtcGxlLCBhIG1hbGZ1bmN0aW9uaW5nIFNGIGluc3RhbmNl KS4KICAgbyAgUmUtdXNlIFNGIGJ1aWx0LWluIGRpYWdub3N0aWMgcHJvY2VkdXJlcyBzcGVjaWZp YyB0byBlYWNoIFNGLgoKNS4xMC4gIENvbnNpZGVyYXRpb25zIFNwZWNpZmljIHRvIHRoZSBDZW50 cmFsaXplZCBQYXRoIENvbXB1dGF0aW9uIE1vZGVsCgogICBUaGlzIHNlY3Rpb24gZm9jdXNlcyBv biBpc3N1ZXMgdGhhdCBhcmUgc3BlY2lmaWMgdG8gdGhlIGNlbnRyYWxpemVkCiAgIGRlcGxveW1l bnQgbW9kZWwgKFNlY3Rpb24gMy4yKS4KCjUuMTAuMS4gIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCBB ZGp1c3RtZW50CgogICBBIFNGUCBpcyBkZXRlcm1pbmVkIGJ5IGNvbXBvc2luZyBTRiBpbnN0YW5j ZXMgYW5kIG92ZXJsYXkgbGlua3MgYW1vbmcKICAgU0ZGcy4gIFRodXMsIHRoZSBzdGF0dXMgb2Yg YSBTRlAgZGVwZW5kcyBvbiB0aGUgc3RhdGVzIG9yIGF0dHJpYnV0ZXMKICAgKGUuZy4sIGF2YWls YWJpbGl0eSwgdG9wb2xvZ2ljYWwgbG9jYXRpb24sIGxhdGVuY3ksIHdvcmtsb2FkLCBldGMuKQog ICBvZiBpdHMgY29tcG9uZW50cy4gIEZvciBleGFtcGxlLCBmYWlsdXJlIG9mIGEgc2luZ2xlIFNG IGluc3RhbmNlCiAgIHJlc3VsdHMgaW4gZmFpbHVyZSBvZiB0aGUgd2hvbGUgU0ZQLiAgU2luY2Ug dGhlc2Ugc3RhdGVzIG9yCiAgIGF0dHJpYnV0ZXMgb2YgU0ZQIGNvbXBvbmVudHMgbWF5IHZhcnkg aW4gdGltZSwgdGhlaXIgY2hhbmdlcyBzaG91bGQKICAgbW9uaXRvcmVkIGFuZCBTRlBzIHNob3Vs ZCBiZSBkeW5hbWljYWxseSBhZGp1c3RlZC4KCiAgIEV4YW1wbGVzIG9mIHVzZSBjYXNlcyBmb3Ig U0ZQIGFkanVzdG1lbnQgYXJlIGxpc3RlZCBiZWxvdzoKCiAgIFNGUCBmYWlsLW92ZXI6ICAgcmUt Y29uc3RydWN0IGEgU0ZQIHdpdGggcmVwbGFjaW5nIHRoZSBmYWlsZWQgU0YKICAgICAgaW5zdGFu Y2Ugd2l0aCBhbm90aGVyIGluc3RhbmNlIG9mIHRoZSBzYW1lIFNGLgogICBTRlAgd2l0aCBiZXR0 ZXIgbGF0ZW5jeSBleHBlcmllbmNlOiAgcmUtY29uc3RydWN0IGEgU0ZQIHdpdGggYSBsb3cKICAg ICAgcGF0aCBzdHJldGNoIGNvbnNpZGVyaW5nIHRoZSBjaGFuZ2VzIGluIHRvcG9sb2dpY2FsIGxv Y2F0aW9ucyBvZgogICAgICBTRiBpbnN0YW5jZXMgYW5kIHRoZSBsYXRlbmN5IGluZHVjZWQgYnkg dGhlIChvdmVybGF5KSBjb25uZWN0aXZpdHkKICAgICAgYW1vbmcgU0ZGcy4KICAgVHJhZmZpYyBl bmdpbmVlcmVkIFNGQzogIDogcmUtY29uc3RydWN0IFNGUHMgdG8gbG9jYWxpemUgdGhlIHRyYWZm aWMKICAgICAgaW4gdGhlIG5ldHdvcmsgY29uc2lkZXJpbmcgdmFyaW91cyBURSBnb2FscyBzdWNo IGFzIGJ5cGFzcyBhIG5vZGUsCiAgICAgIGJ5cGFzcyBhIGxpbmssIGV0Yy4gIFRoZXNlIHRlY2hu aXF1ZXMgbWF5IGJlIHVzZWQgZm9yIHBsYW5uZWQKICAgICAgbWFpbnRlbmFuY2Ugb3BlcmF0aW9u cyBvbiBhIFNGQy1lbmFibGVkIGRvbWFpbi4KCgoKTGksIGV0IGFsLiAgICAgICAgICAgICAgRXhw aXJlcyBPY3RvYmVyIDMwLCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQt RHJhZnQgICBDb250cm9sIFBsYW5lIENvbXBvbmVudHMgJiBSZXF1aXJlbWVudHMgICAgICBBcHJp bCAyMDE1CgoKICAgU0YvU0ZDIExvYWQgYmFsYW5jaW5nOiAgIHJlLWNvbnN0cnVjdCBTRlBzIHRv IGRpc3RyaWJ1dGUgdGhlIHdvcmtsb2FkCiAgICAgIGFtb25nIHZhcmlvdXMgU0YgaW5zdGFuY2Vz LgoKICAgRm9yIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgdXNlIGNhc2VzLCByZWZlciB0bwogICBb SS1ELmxlZS1uZnZyZy1yZXNvdXJjZS1tYW5hZ2VtZW50LXNlcnZpY2UtY2hhaW5dLgoKICAgVGhl IHByb2NlZHVyZXMgZm9yIFNGUCBhZGp1c3RtZW50IG1heSBiZSBoYW5kbGVkIGJ5IHRoZSBTRkMg Y29udHJvbAogICBwbGFuZSBhcyBmb2xsb3dzOgoKICAgbyAgQ29sbGVjdCBhbmQgbW9uaXRvciBz dGF0ZXMgYW5kIGF0dHJpYnV0ZXMgb2YgU0YgaW5zdGFuY2VzIGFuZAogICAgICBvdmVybGF5IGxp bmtzIHZpYSB0aGUgQzIgaW50ZXJmYWNlIChTZWN0aW9uIDMuMy4yKSBhbmQgdGhlIEMzCiAgICAg IGludGVyZmFjZSAoU2VjdGlvbiAzLjMuMykuCiAgIG8gIEV2YWx1YXRlIFNGIGluc3RhbmNlcyBh bmQgb3ZlcmxheSBsaW5rcyBiYXNlZCBvbiB0aGUgbW9uaXRvcmluZwogICAgICByZXN1bHRzLgog ICBvICBTZWxlY3QgU0YgaW5zdGFuY2VzIHRvIHJlLWRldGVybWluZSBhIFNGUCBhY2NvcmRpbmcg dG8gdGhlCiAgICAgIGV2YWx1YXRpb24gcmVzdWx0cy4KICAgbyAgUmVwbGFjZSB0YXJnZXQgU0Yg aW5zdGFuY2VzIChlLmcuLCBpbiBhIGZhaWx1cmUgb3Igb3ZlcmxhZGVkKSB3aXRoCiAgICAgIG5l d2x5IHNlbGVjdGVkIG9uZXMuCiAgIG8gIEVuZm9yY2UgdGhlIHVwZGF0ZWQgU0ZQIGZvciB1cGNv bWluZyBTRkMgdHJhdmVyc2FsIHRvIFNGRnMgdmlhIHRoZQogICAgICBDMSBpbnRlcmZhY2UgKFNl Y3Rpb24gMy4zLjEpIG9yIHRoZSBDMiBpbnRlcmZhY2UgKFNlY3Rpb24gMy4zLjIpLgoKNS4xMC4y LiAgSGVhZCBFbmQgSW5pdGlhdGVkIFNGUCBFc3RhYmxpc2htZW50CgogICBJbiBzb21lIHNjZW5h cmlvcyB3aGVyZSBhIFNGQyBDb250cm9sIEVsZW1lbnQgaXMgbm90IGNvbm5lY3RlZCB0byBhbGwK ICAgU0ZGcyBpbiBhIFNGQy1lbmFibGVkIGRvbWFpbiwgdGhlIFNGQyBjb250cm9sIHBsYW5lIGNh biBzZW5kIHRoZQogICBleHBsaWNpdCBTRkYtU0Ytc2VxdWVuY2Ugb3IgU0Ytc2VxdWVuY2UgdG8g dGhlIFNGQyBoZWFkLWVuZCwgZS5nLiwKICAgdGhlIFNGQyBDbGFzc2lmaWVyIHZpYSB0aGUgQzEg aW50ZXJmYWNlIChTZWN0aW9uIDMuMy4xKS4gIFNGQyBoZWFkLQogICBlbmQgY2FuIHVzZSBhIHNp Z25hbGluZyBwcm90b2NvbCB0byBlc3RhYmxpc2ggdGhlIFNGRi1TRi1zZXF1ZW5jZQogICBiYXNl ZCBvbiB0aGUgU0Ytc2VxdWVuY2UuCgo1LjEwLjMuICAoUmVnaW9uYWwpIFJlc3RvcmF0aW9uIG9m IFNlcnZpY2UgRnVuY3Rpb25zCgogICBUaGVyZSBhcmUgc2l0dWF0aW9ucyB0aGF0IGl0IG1pZ2h0 IG5vdCBiZSBmZWFzaWJsZSBmb3IgdGhlIENsYXNzaWZpZXIKICAgdG8gYmUgbm90aWZpZWQgb2Yg dGhlIGNoYW5nZXMgb2YgU0ZGLXNlcXVlbmNlIG9yIFNGRi1TRi1TZXF1ZW5jZSBmb3IKICAgYSBn aXZlbiBTRlAgYmVjYXVzZSBvZiB0aGUgdGltZSB0YWtlbiBmb3IgdGhlIG5vdGlmaWNhdGlvbiBh bmQgdGhlCiAgIGxpbWl0ZWQgY2FwYWJpbGl0eSBvZiB0aGUgQ2xhc3NpZmllcnMuCgogICBJZiBh IFNGIGhhcyBhIGxhcmdlIG51bWJlciBvZiBpbnN0YW50aWF0aW9ucywgaXQgc2NhbGVzIGJldHRl ciBpZiB0aGUKICAgQ2xhc3NpZmllciBkb2Vzbid0IG5lZWQgdG8gYmUgbm90aWZpZWQgd2l0aCBz dGF0dXMgb2YgdmlzaWJsZQogICBpbnN0YW50aWF0aW9ucyBvZiBTRnMgb24gYSBTRlAuCgogICBJ dCBtaWdodCBub3QgYmUgYWx3YXlzIGJlIGZlYXNpYmxlIGZvciB0aGUgQ2xhc3NpZmllciB0byBi ZSBhd2FyZSBvZgogICB0aGUgZXhhY3QgU0YgaW5zdGFuY2VzIHNlbGVjdGVkIGZvciBhIGdpdmVu IFNGUCBkdWUgdG8gdG9vIG1hbnkKICAgaW5zdGFuY2VzIGZvciBlYWNoIFNGLCBub3RpZmljYXRp b25zIG5vdCBiZWluZyBwcm9tcHRseSBzZW50IHRvIHRoZQogICBDbGFzc2lmaWVyLCBvciBvdGhl ciByZWFzb25zLiAgVGhpcyBpcyBub3QgYWJvdXQgbXVsdGlwbGUgaW5zdGFuY2VzCiAgIG9mIHRo ZSBzYW1lIFNGIGF0dGFjaGVkIHRvIG9uZSBTRkYgbm9kZTsgdGhvc2UgaW5zdGFuY2VzIGNhbiBi ZQogICBoYW5kbGVkIGJ5IHRoZSBTRkYgdmlhIGxvY2FsIGxvYWQgYmFsYW5jaW5nIHNjaGVtZXMu CgoKCgpMaSwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIwMTUgICAg ICAgICAgICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFmdCAgIENvbnRyb2wgUGxhbmUgQ29t cG9uZW50cyAmIFJlcXVpcmVtZW50cyAgICAgIEFwcmlsIDIwMTUKCgogICBSZWdpb25hbCByZXN0 b3JhdGlvbiBjYW4gdGFrZSB0aGUgc2ltaWxhciBhcHByb2FjaCBhcyB0aGUgZ2xvYmFsCiAgIHJl c3RvcmF0aW9uOiBjaG9vc2luZyBhIHJlZ2lvbmFsIGluZ3Jlc3Mgbm9kZSB0aGF0IGNhbiB0YWtl IG92ZXIgdGhlCiAgIHJlc3BvbnNpYmlsaXR5IG9mIGluc3RhbGxpbmcgdGhlIG5ldyBzdGVlcmlu ZyBwb2xpY2llcyB0byB0aGUKICAgaW52b2x2ZWQgU0ZGcyBvciBuZXR3b3JrIG5vZGVzLiAgVHlw aWNhbGx5LCB0aGUgcmVnaW9uYWwgaW5ncmVzcyBub2RlCiAgIHNob3VsZCBiZToKCiAgIG8gIG9u IHRoZSBkYXRhIHBhdGggb2YgdGhlIGZsb3cgb2YgdGhlIGdpdmVuIFNGQzsKICAgbyAgaW4gZnJv bnQgb2YgdGhlIHJlbGV2YW50IFNGRnMgb3IgbmV0d29yayBub2RlcyB0aGF0IGFyZSBpbXBhY3Rl ZAogICAgICBieSB0aGUgY2hhbmdlIG9mIHRoZSBTRlA7CiAgIG8gIGNhcGFibGUgb2YgZW5jb2Rp bmcgdGhlIGRldGFpbGVkIFNGUCB0byB0aGUgU2VydmljZSBDaGFpbiBIZWFkZXIKICAgICAgb2Yg ZGF0YSBwYWNrZXRzIG9mIHRoZSBpZGVudGlmaWVkIGZsb3c7IGFuZAogICBvICBjYXBhYmxlIG9m IHJlbW92aW5nIHRoZSBkZXRhaWxlZCBTRlAgZW5jb2RpbmcgaW4gZGF0YSBwYWNrZXRzCiAgICAg IGFmdGVyIGFsbCB0aGUgaW1wYWN0ZWQgU0ZGcyBhbmQgbmV0d29yayBub2RlcyBjb21wbGV0ZWQg dGhlIHBvbGljeQogICAgICBpbnN0YWxsYXRpb24uCgo2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMKCiAgIFRoZSBTRkMgQ29udHJvbCBFbGVtZW50cyBhbmQgdGhlIHBhcnRpY2lwYXRpbmcgU0ZD IGRhdGEgcGxhbmUKICAgZWxlbWVudHMgbXVzdCBtdXR1YWxseSBhdXRoZW50aWNhdGUuICBTRkMg ZGF0YSBwbGFuZSBlbGVtZW50cyBtdXN0CiAgIGlnbm9yZSBpbnN0cnVjdGlvbnMgcmVjZWl2ZWQg ZnJvbSB1bmF1dGhlbnRpY2F0ZWQgU0ZDIENvbnRyb2wKICAgRWxlbWVudHMuICBUaGUgY3JlZGVu dGlhbHMgZGV0YWlscyB1c2VkIGR1cmluZyBhdXRoZW50aWNhdGlvbiBjYW4gYmUKICAgdXNlZCBi eSB0aGUgU0ZDIGNvbnRyb2wgcGxhbmUgdG8gZGVjaWRlIHdoZXRoZXIgc3BlY2lmaWMKICAgYXV0 aG9yaXphdGlvbiBtYXkgYmUgZ3JhbnRlZCB0byBhIFNlcnZpY2UgRnVuY3Rpb24gd2l0aCByZWdh cmRzIHRvCiAgIHNvbWUgc3BlY2lmaWMgb3BlcmF0aW9ucyAoZS5nLiwgZ2VuZXJhdGUgYW5kIHN1 cHBseSBhIHNlY3VyaXR5IHRva2VuCiAgIGluIHRoZSBTRkMgaGVhZGVyKS4KCiAgIEluIGNhc2Ug bXVsdGlwbGUgU0ZDIGRhdGEgcGxhbmUgZWxlbWVudHMgYXJlIGVtYmVkZGVkIGluIHRoZSBzYW1l CiAgIG5vZGUsIHRoZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gc2hvdWxkIGJlIGV4ZWN1dGVk IGFzIGEgd2hvbGU7IG5vdAogICBmb3IgZWFjaCBpbnN0YW5jZS4KCiAgIEEgU0ZDIGRhdGEgcGxh bmUgZWxlbWVudCBtdXN0IGJlIGFibGUgdG8gc2VuZCBhdXRoZW50aWNhdGVkCiAgIHVuc29saWNp dGVkIG5vdGlmaWNhdGlvbnMgdG8gYSBTRkMgQ29udHJvbCBFbGVtZW50LgoKICAgVGhlIGF1dGhl bnRpY2F0aW9uIG1lY2hhbmlzbSBzaG91bGQgYmUgaW1tdW5lIHRvIHBlcnZhc2l2ZSBtb25pdG9y aW5nCiAgIFtSRkM3MjU4XS4gIEFuIGF0dGFja2VyIGNhbiBpbnRlcmNlcHQgdHJhZmZpYyBieSBp bnN0YWxsaW5nCiAgIGNsYXNzaWZpY2F0aW9uIHJ1bGVzIHRoYXQgd291bGQgbGVhZCB0byByZWRp cmVjdCBhbGwgb3IgcGFydCBvZiB0aGUKICAgdHJhZmZpYyB0byBhbiBpbGxlZ2l0aW1hdGUgbmV0 d29yayBub2RlLiAgTWVhbnMgdG8gcHJvdGVjdCBhZ2FpbnN0CiAgIGF0dGFja3MgdGhhdCB3b3Vs ZCBsZWFkIHRvIGluc3RhbGwsIHJlbW92ZSwgb3IgbW9kaWZ5IGNsYXNzaWZpY2F0aW9uCiAgIHJ1 bGVzIG11c3QgYmUgc3VwcG9ydGVkLgoKICAgTWVhbnMgdG8gZGVmZW5kIGFnYWluc3Qgc29saWNp dGluZyBpbGxlZ2l0aW1hdGUgU0ZzL1NGRnMgdGhhdCBkbyBub3QKICAgYmVsb25nIHRvIHRoZSBT RkMtZW5hYmxlZCBkb21haW4uICBTdWNoIG1lYW5zIG11c3QgYmUgZGVmaW5lZCBpbgogICBzZXJ2 aWNlIGZ1bmN0aW9uIGRpc2NvdmVyeSBhbmQgU0ZDIENvbnRyb2wgRWxlbWVudCBkaXNjb3ZlcnkK ICAgc3BlY2lmaWNhdGlvbiBkb2N1bWVudHMuCgogICBUaGUgU0ZDIGNvbnRyb2wgcGxhbmUgbXVz dCBiZSBhYmxlIHRvIGNvbnRyb2wgdGhlIGluZm9ybWF0aW9uIHRoYXQgaXMKICAgbGVha2VkIG91 dHNpZGUgYW4gU0ZDLWVuYWJsZWQgZG9tYWluLiAgUGFydGljdWxhcmx5LCB0aGUgU0ZDIGNvbnRy b2wKICAgcGxhbmUgbXVzdCBzdXBwb3J0IG1lYW5zIHRvIHByZXNlcnZlIHByaXZhY3kgW1JGQzY5 NzNdLiAgQ29udGV4dAoKCgpMaSwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIg MzAsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnRy b2wgUGxhbmUgQ29tcG9uZW50cyAmIFJlcXVpcmVtZW50cyAgICAgIEFwcmlsIDIwMTUKCgogICBo ZWFkZXJzIG1heSBpbmRlZWQgcmV2ZWFsIHByaXZhY3kgaW5mb3JtYXRpb24gKGUuZy4sIElNU0ks IHVzZXIgbmFtZSwKICAgdXNlciBwcm9maWxlLCBsb2NhdGlvbiwgZXRjLikuICBUaG9zZSBoZWFk ZXJzIG11c3Qgbm90IGJlIGV4cG9zZWQKICAgb3V0c2lkZSB0aGUgb3BlcmF0b3IncyBkb21haW4u CgogICBBbiBTRkMgQ29udHJvbCBFbGVtZW50IG1heSBpbnN0cnVjdCBhIFNlcnZpY2UgRnVuY3Rp b24gdG8gaW5jbHVkZQogICBzcGVjaWZpYyBzZWN1cml0eSB0b2tlbihzKSB0aGF0IG1heSBiZSB1 c2VkIHRvIGRlY3J5cHQgdHJhZmZpYwogICB1cHN0cmVhbS4gIFRoZSBzZWN1cml0eSB0b2tlbiBt YXkgYmUgc3VwcGxpZWQgYnkgdGhlIFNGQyBjb250cm9sCiAgIHBsYW5lIG9yIGJ5IGFuIGF1dGhv cml6ZWQgU2VydmljZSBGdW5jdGlvbiAoZS5nLiwgYW4gU1NMIHJlbGF5KS4gIFRoZQogICBleGFj dCBkZXRhaWxzIG9uIGhvdyBhdXRob3JpemF0aW9uIGlzIGdyYW50ZWQgdG8gYSBzcGVjaWZpYyBT RiwKICAgaW5jbHVkaW5nIHZpYSBhIGNvbnRyb2wgcGxhbmUgaW50ZXJmYWNlLCBzaG91bGQgYmUg c3BlY2lmaWVkLgoKICAgVGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBhIENvbnRyb2wgRWxlbWVu dCBhbmQgU0ZDIGRhdGEgcGxhbmUKICAgZWxlbWVudHMgbXVzdCBwcm92aWRlIGludGVncml0eSBw cm90ZWN0aW9uLgoKICAgQSBTZXJ2aWNlIEZ1bmN0aW9uIG11c3QgYnkgZGVmYXVsdCBkaXNjYXJk IGFueSBhY3Rpb24gZnJvbSBhIFNGQwogICBDb250cm9sIEVsZW1lbnQgdGhhdCByZXF1aXJlcyBz cGVjaWZpYyByaWdodCBwcml2aWxlZ2VzIChlLmcuLCBhY2Nlc3MKICAgdG8gYSBsZWdhbCBpbnRl cmNlcHQgbG9nLCBtaXJyb3IgdGhlIHRyYWZmaWMsIGV0Yy4pLgoKICAgSW4gb3JkZXIgdG8gcHJv dGVjdCBhZ2FpbnN0IGRlbmlhbCBvZiBzZXJ2aWNlIHRoYXQgd291bGQgYmUgY2F1c2VkIGJ5CiAg IGEgbWlzYmVoYXZpbmcgdHJ1c3RlZCBTRkMgQ29udHJvbCBFbGVtZW50LCBTRkMgZGF0YSBwbGFu ZSBlbGVtZW50cwogICBzaG91bGQgcmF0ZSBsaW1pdCB0aGUgbWVzc2FnZXMgcmVjZWl2ZWQgZnJv bSBhbiBTRkMgQ29udHJvbCBFbGVtZW50LgoKNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRo aXMgZG9jdW1lbnQgZG9lcyBub3QgcmVxdWlyZSBhbnkgSUFOQSBhY3Rpb25zLgoKOC4gIEFja25v d2xlZGdlbWVudHMKCiAgIFRoaXMgZG9jdW1lbnQgaXMgdGhlIHJlc3VsdCBvZiBtZXJnaW5nIHdp dGgKICAgW0ktRC5sZWUtc2ZjLWR5bmFtaWMtaW5zdGFudGlhdGlvbl0uCgogICBUaGUgYXV0aG9y cyB3b3VsZCBsaWtlIHRvIHRoYW5rIFNoaWJpIEh1YW5nIGZvciBwcm92aWRpbmcgaW5wdXQgYW5k CiAgIExBQyBDaGlkdW5nIGZvciBoaXMgcmV2aWV3IGFuZCBjb21tZW50cyB0aGF0IGhlbHBlZCBp bXByb3ZlIHRoaXMKICAgZG9jdW1lbnQuCgo5LiAgUmVmZXJlbmNlcwoKOS4xLiAgTm9ybWF0aXZl IFJlZmVyZW5jZXMKCiAgIFtJLUQuaWV0Zi1zZmMtYXJjaGl0ZWN0dXJlXQogICAgICAgICAgICAg IEhhbHBlcm4sIEouIGFuZCBDLiBQaWduYXRhcm8sICJTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5n CiAgICAgICAgICAgICAgKFNGQykgQXJjaGl0ZWN0dXJlIiwgZHJhZnQtaWV0Zi1zZmMtYXJjaGl0 ZWN0dXJlLTA3ICh3b3JrCiAgICAgICAgICAgICAgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDE1LgoK ICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8g SW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAy MTE5LCBNYXJjaCAxOTk3LgoKCgoKCkxpLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgT2N0 b2JlciAzMCwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDE5XQoMCkludGVybmV0LURyYWZ0ICAg Q29udHJvbCBQbGFuZSBDb21wb25lbnRzICYgUmVxdWlyZW1lbnRzICAgICAgQXByaWwgMjAxNQoK CjkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJLUQuaWV0Zi1vcHNhd2ctZmlyZXdh bGxzXQogICAgICAgICAgICAgIEJha2VyLCBGLiBhbmQgUC4gSG9mZm1hbiwgIk9uIEZpcmV3YWxs cyBpbiBJbnRlcm5ldAogICAgICAgICAgICAgIFNlY3VyaXR5IiwgZHJhZnQtaWV0Zi1vcHNhd2ct ZmlyZXdhbGxzLTAxICh3b3JrIGluCiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBPY3RvYmVyIDIw MTIuCgogICBbSS1ELmlldGYtc2ZjLWRjLXVzZS1jYXNlc10KICAgICAgICAgICAgICBTdXJlbmRy YSwgUy4sIFR1ZmFpbCwgTS4sIE1hamVlLCBTLiwgQ2FwdGFyaSwgQy4sIGFuZCBTLgogICAgICAg ICAgICAgIEhvbW1hLCAiU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBVc2UgQ2FzZXMgSW4gRGF0 YQogICAgICAgICAgICAgIENlbnRlcnMiLCBkcmFmdC1pZXRmLXNmYy1kYy11c2UtY2FzZXMtMDIg KHdvcmsgaW4KICAgICAgICAgICAgICBwcm9ncmVzcyksIEphbnVhcnkgMjAxNS4KCiAgIFtJLUQu aWV0Zi1zZmMtdXNlLWNhc2UtbW9iaWxpdHldCiAgICAgICAgICAgICAgSGFlZmZuZXIsIFcuLCBO YXBwZXIsIEouLCBTdGllbWVybGluZywgTS4sIExvcGV6LCBELiwgYW5kCiAgICAgICAgICAgICAg Si4gVXR0YXJvLCAiU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBVc2UgQ2FzZXMgaW4gTW9iaWxl CiAgICAgICAgICAgICAgTmV0d29ya3MiLCBkcmFmdC1pZXRmLXNmYy11c2UtY2FzZS1tb2JpbGl0 eS0wMyAod29yayBpbgogICAgICAgICAgICAgIHByb2dyZXNzKSwgSmFudWFyeSAyMDE1LgoKICAg W0ktRC5sZWUtbmZ2cmctcmVzb3VyY2UtbWFuYWdlbWVudC1zZXJ2aWNlLWNoYWluXQogICAgICAg ICAgICAgIExlZSwgUy4sIFBhY2ssIFMuLCBTaGluLCBNLiwgYW5kIEUuIFBhaWssICJSZXNvdXJj ZQogICAgICAgICAgICAgIE1hbmFnZW1lbnQgaW4gU2VydmljZSBDaGFpbmluZyIsIGRyYWZ0LWxl ZS1uZnZyZy1yZXNvdXJjZS0KICAgICAgICAgICAgICBtYW5hZ2VtZW50LXNlcnZpY2UtY2hhaW4t MDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaAogICAgICAgICAgICAgIDIwMTUuCgogICBbSS1E LmxlZS1zZmMtZHluYW1pYy1pbnN0YW50aWF0aW9uXQogICAgICAgICAgICAgIExlZSwgUy4sIFBh Y2ssIFMuLCBTaGluLCBNLiwgYW5kIEUuIFBhaWssICJTRkMgZHluYW1pYwogICAgICAgICAgICAg IGluc3RhbnRpYXRpb24iLCBkcmFmdC1sZWUtc2ZjLWR5bmFtaWMtaW5zdGFudGlhdGlvbi0wMQog ICAgICAgICAgICAgICh3b3JrIGluIHByb2dyZXNzKSwgT2N0b2JlciAyMDE0LgoKICAgW1JGQzMw MjJdICBTcmlzdXJlc2gsIFAuIGFuZCBLLiBFZ2V2YW5nLCAiVHJhZGl0aW9uYWwgSVAgTmV0d29y awogICAgICAgICAgICAgIEFkZHJlc3MgVHJhbnNsYXRvciAoVHJhZGl0aW9uYWwgTkFUKSIsIFJG QyAzMDIyLCBKYW51YXJ5CiAgICAgICAgICAgICAgMjAwMS4KCiAgIFtSRkMzMTM1XSAgQm9yZGVy LCBKLiwgS29qbywgTS4sIEdyaW5lciwgSi4sIE1vbnRlbmVncm8sIEcuLCBhbmQgWi4KICAgICAg ICAgICAgICBTaGVsYnksICJQZXJmb3JtYW5jZSBFbmhhbmNpbmcgUHJveGllcyBJbnRlbmRlZCB0 bwogICAgICAgICAgICAgIE1pdGlnYXRlIExpbmstUmVsYXRlZCBEZWdyYWRhdGlvbnMiLCBSRkMg MzEzNSwgSnVuZSAyMDAxLgoKICAgW1JGQzYxNDZdICBCYWdudWxvLCBNLiwgTWF0dGhld3MsIFAu LCBhbmQgSS4gdmFuIEJlaWpudW0sICJTdGF0ZWZ1bAogICAgICAgICAgICAgIE5BVDY0OiBOZXR3 b3JrIEFkZHJlc3MgYW5kIFByb3RvY29sIFRyYW5zbGF0aW9uIGZyb20gSVB2NgogICAgICAgICAg ICAgIENsaWVudHMgdG8gSVB2NCBTZXJ2ZXJzIiwgUkZDIDYxNDYsIEFwcmlsIDIwMTEuCgogICBb UkZDNjMzM10gIER1cmFuZCwgQS4sIERyb21zLCBSLiwgV29vZHlhdHQsIEouLCBhbmQgWS4gTGVl LCAiRHVhbC0KICAgICAgICAgICAgICBTdGFjayBMaXRlIEJyb2FkYmFuZCBEZXBsb3ltZW50cyBG b2xsb3dpbmcgSVB2NAogICAgICAgICAgICAgIEV4aGF1c3Rpb24iLCBSRkMgNjMzMywgQXVndXN0 IDIwMTEuCgoKCgoKCkxpLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwg MjAxNSAgICAgICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgQ29udHJvbCBQ bGFuZSBDb21wb25lbnRzICYgUmVxdWlyZW1lbnRzICAgICAgQXByaWwgMjAxNQoKCiAgIFtSRkM2 OTczXSAgQ29vcGVyLCBBLiwgVHNjaG9mZW5pZywgSC4sIEFib2JhLCBCLiwgUGV0ZXJzb24sIEou LAogICAgICAgICAgICAgIE1vcnJpcywgSi4sIEhhbnNlbiwgTS4sIGFuZCBSLiBTbWl0aCwgIlBy aXZhY3kKICAgICAgICAgICAgICBDb25zaWRlcmF0aW9ucyBmb3IgSW50ZXJuZXQgUHJvdG9jb2xz IiwgUkZDIDY5NzMsIEp1bHkKICAgICAgICAgICAgICAyMDEzLgoKICAgW1JGQzcyNThdICBGYXJy ZWxsLCBTLiBhbmQgSC4gVHNjaG9mZW5pZywgIlBlcnZhc2l2ZSBNb25pdG9yaW5nIElzIGFuCiAg ICAgICAgICAgICAgQXR0YWNrIiwgQkNQIDE4OCwgUkZDIDcyNTgsIE1heSAyMDE0LgoKICAgW1JG Qzc0OThdICBRdWlubiwgUC4gYW5kIFQuIE5hZGVhdSwgIlByb2JsZW0gU3RhdGVtZW50IGZvciBT ZXJ2aWNlCiAgICAgICAgICAgICAgRnVuY3Rpb24gQ2hhaW5pbmciLCBSRkMgNzQ5OCwgQXByaWwg MjAxNS4KCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgSG9uZ3l1IExpCiAgIEh1YXdlaQogICBIdWF3 ZWkgSW5kdXN0cmlhbCBCYXNlLEJhbnRpYW4sTG9uZ2dhbmcKICAgU2hlbnpoZW4KICAgQ2hpbmEK CiAgIEVNYWlsOiBob25neXUubGlAaHVhd2VpLmNvbQoKCiAgIFFpbiBXdQogICBIdWF3ZWkKICAg MTAxIFNvZnR3YXJlIEF2ZW51ZSwgWXVodWEgRGlzdHJpY3QKICAgTmFuamluZywgSmlhbmdzdSAg MjEwMDEyCiAgIENoaW5hCgogICBFTWFpbDogYmlsbC53dUBodWF3ZWkuY29tCgoKICAgWW9uZyhP bGl2ZXIpIEh1YW5nCiAgIEh1YXdlaQogICBIdWF3ZWkgSW5kdXN0cmlhbCBCYXNlLEJhbnRpYW4s TG9uZ2dhbmcKICAgU2hlbnpoZW4KICAgQ2hpbmEKCiAgIEVNYWlsOiBvbGl2ZXIuaHVhbmdAaHVh d2VpLmNvbQoKCiAgIE1vaGFtZWQgQm91Y2FkYWlyCiAgIEZyYW5jZSBUZWxlY29tCiAgIFJlbm5l cyAzNTAwMAogICBGcmFuY2UKCiAgIEVNYWlsOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t CgoKCgoKTGksIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMwLCAyMDE1ICAg ICAgICAgICAgICAgW1BhZ2UgMjFdCgwKSW50ZXJuZXQtRHJhZnQgICBDb250cm9sIFBsYW5lIENv bXBvbmVudHMgJiBSZXF1aXJlbWVudHMgICAgICBBcHJpbCAyMDE1CgoKICAgQ2hyaXN0aWFuIEph Y3F1ZW5ldAogICBGcmFuY2UgVGVsZWNvbQogICBSZW5uZXMgMzUwMDAKICAgRnJhbmNlCgogICBF TWFpbDogY2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFuZ2UuY29tCgoKICAgV2FsdGVyIEhhZWZmbmVy CiAgIFZvZGFmb25lIEQyIEdtYkgKICAgRmVyZGluYW5kLUJyYXVuLVBsYXR6IDEKICAgRHVlc3Nl bGRvcmYgIDQwNTQ5CiAgIERFCgogICBFTWFpbDogd2FsdGVyLmhhZWZmbmVyQHZvZGFmb25lLmNv bQoKCiAgIFNldW5naWsgTGVlCiAgIEVUUkkKICAgMjE4IEdhamVvbmctcm8gWXVzZXVuZy1HdQog ICBEYWVqZW9uICAzMDUtNzAwCiAgIEtvcmVhCgogICBQaG9uZTogKzgyIDQyIDg2MCAxNDgzCiAg IEVNYWlsOiBzZXVuZ2lrbGVlQGV0cmkucmUua3IKCgogICBSb24gUGFya2VyCiAgIEFmZmlybWVk IE5ldHdvcmtzCiAgIEFjdG9uCiAgIE1BICAwMTcyMAogICBVU0EKCiAgIEVNYWlsOiByb25fcGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tCgoKICAgTGluZGEgRHVuYmFyCiAgIEh1YXdlaSBUZWNo bm9sb2dpZXMKICAgVVNBCgogICBFTWFpbDogbGR1bmJhckBodWF3ZWkuY29tCgoKICAgQW5kcmV3 IE1hbGlzCiAgIEh1YXdlaSBUZWNobm9sb2dpZXMKICAgVVNBCgogICBFTWFpbDogYWdtYWxpc0Bn bWFpbC5jb20KCgoKTGksIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMwLCAy MDE1ICAgICAgICAgICAgICAgW1BhZ2UgMjJdCg== --_004_8172B566C79A4A4C8EB6C7B1F6529EFC61E28160szxema506mbxchi_-- From nobody Sat May 30 10:30:47 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD231A8752 for ; Sat, 30 May 2015 05:14:03 -0700 (PDT) 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 gCW9rZSpwLmP for ; Sat, 30 May 2015 05:14:01 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5631A874F for ; Sat, 30 May 2015 05:14:01 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 30 May 2015 08:14:00 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Sat, 30 May 2015 08:14:00 -0400 From: Dave Dolson To: "Huangyong (Oliver)" , "sfc@ietf.org" , "Hongyu Li (Julio)" , Qin Wu , "mohamed.boucadair@orange.com" , "christian.jacquenet@orange.com" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "ron_parker@affirmednetworks.com" , "Huangjing (A)" , Linda Dunbar Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAABf9ORQ= Date: Sat, 30 May 2015 12:13:59 +0000 Message-ID: References: , <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> In-Reply-To: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.203.184.252] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 30 May 2015 10:30:44 -0700 Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 12:14:03 -0000 I will review the document later, but I can quickly answer your question. > I have question why not the SFC forwarding system handle the paired chain= itself? Here is the very simple example that indicates the problem: - An SF firewall has a policy to respond to not-permitted incoming connect= ions with TCP RST (rather than allowing the connection to reach the protected host). - Therefore when a TCP SYN packet arrives at the SF firewall with NSH enca= psulation having path ID x and Path Index y, it must be able to insert the response i= nto the path that is the bidirectional complement, an NSH encapsulation having path ID x' and pa= th index y' to send the packet back to the source, following the reverse path. I hope that shows why the paths need to be paired? I believe that most flow-stateful devices will require the pairing informat= ion. -Dave ________________________________ From: Huangyong (Oliver) [oliver.huang@huawei.com] Sent: Friday, May 29, 2015 9:06 PM To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.boucadair= @orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; = seungiklee@etri.re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Lind= a Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hello Dave, Thank you for your detailed consideration on the draft. I agree th= at the SF should support the capability of bidirectional chains. For exampl= e, the NAT SF may provide the new allocated address/port to the controller.= You mentioned the control plane should inform SF bidirectional chain (whi= ch path id are paired). I have question why not the SFC forwarding system = handle the paired chain itself? Performance mornitoring is a basic capability which should exist in= all interfaces C1,C2,C3. Mohamed have developed a new version of this draft and made a big p= romotion. In the new draft, C3,C4 are introduced for SF and SF proxy separa= tely. I think it may cover the related scenario. I attached it in this em= ail, please check it. Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are = representative of Huawei on this draft. Please contact more detail to them.= Thank you very much! BR Oliver --------------------------- Huangyong (Oliver) Network research, Huawei From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Saturday, May 30, 2015 4:42 AM To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); mohamed.bo= ucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafon= e.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com Subject: Comments on draft-ww-sfc-control-plane-04 Authors of draft-ww-sfc-control-plane, I=92ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-p= lane-04 I have some very high-level suggestions: 1. I believe the =93F=94 interface should be split into two interfaces= . One for performance monitoring (availability and workload were cited), an= d one for updating classification information. Call these F1 and F2, I suppose. My reasons are that (a) as a general princ= iple, interfaces should not have multiple purposes and (b) F1 and F2 could = be communicating to different control-plane managers. 2. A control interface is required to SF components. Call it C3. This = interface is required to (a) inform the SF about bidirectional chains (i.e.= , which Path IDs are paired) and (b) inform the SF about semantics of types= of meta-data. C3 should also be connected to the SFC Proxy. I propose: 4.5 C3 Interface A service function may need information about the service paths passing through it, and may need information about specific meta-data types attached to packets on the paths. Some types of SF might be agnostic about the paths traversing them, but most transport-layer-flow-aware devices will require this configuration. When bidirectional chains are deployed, the C3 interface provisions each SF with each path identifier/path index pair that will pass through= . Each such pair is associated with an opposite-direction pair of identifier/index. Meta-data is for the benefit of SFs. The C3 interface informs the SF about the semantics of the meta-data, which would otherwise have opaque meaning. Meta-data attributes include "scope" (per-packet, per-fl= ow or per host), "mandatory" (must be understood), "bidirectional" (same value may be used in both directions), "is_qualifier" (indicates a distinct routing domain). I think there is quite a bit to explore, but I believe this starts the disc= ussion. Thoughts? David Dolson Senior Software Architect, Sandvine Inc. From nobody Sat May 30 11:33:30 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFCF1A916A for ; Sat, 30 May 2015 11:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 9ZrBL7zoV-az for ; Sat, 30 May 2015 11:33:27 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0D31A9166 for ; Sat, 30 May 2015 11:33:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4D63724096D for ; Sat, 30 May 2015 11:33:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D7EF4240362 for ; Sat, 30 May 2015 11:33:26 -0700 (PDT) Message-ID: <556A0261.3040305@joelhalpern.com> Date: Sat, 30 May 2015 14:33:05 -0400 From: Joel Halpern User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "sfc@ietf.org" References: , <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 18:33:29 -0000 Clearly, there are cases where a service funtion will originate packets. I would strongly hope that the service function is not required to know the details of the service function path identification inorder to do so. My assumption has been that to support this need (both for bidirectional cases, and for others), there would be a classifier in place to apply the necessary headers. That classifier could be colocated with the SFF, or could be colocated with the service function itself. Thus, if one wants to deploy a service function and the ability to add path information, I would expect a service funciton with colocated classifier. Arguably this is only a descriptive difference. But that description keeps much clearer what functionality we are discussing, and where it may exist. Yours, Joel On 5/30/15 8:13 AM, Dave Dolson wrote: > I will review the document later, but I can quickly answer your question. >> I have question why not the SFC forwarding system handle the paired chain itself? > > Here is the very simple example that indicates the problem: > - An SF firewall has a policy to respond to not-permitted incoming connections with TCP RST > (rather than allowing the connection to reach the protected host). > - Therefore when a TCP SYN packet arrives at the SF firewall with NSH encapsulation > having path ID x and Path Index y, it must be able to insert the response into the path that is > the bidirectional complement, an NSH encapsulation having path ID x' and path index y' to send > the packet back to the source, following the reverse path. > > I hope that shows why the paths need to be paired? > > I believe that most flow-stateful devices will require the pairing information. > > -Dave > > > ________________________________ > From: Huangyong (Oliver) [oliver.huang@huawei.com] > Sent: Friday, May 29, 2015 9:06 PM > To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Linda Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 > > Hello Dave, > > Thank you for your detailed consideration on the draft. I agree that the SF should support the capability of bidirectional chains. For example, the NAT SF may provide the new allocated address/port to the controller. You mentioned the control plane should inform SF bidirectional chain (which path id are paired). I have question why not the SFC forwarding system handle the paired chain itself? > > Performance mornitoring is a basic capability which should exist in all interfaces C1,C2,C3. > > Mohamed have developed a new version of this draft and made a big promotion. In the new draft, C3,C4 are introduced for SF and SF proxy separately. I think it may cover the related scenario. I attached it in this email, please check it. > > Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are representative of Huawei on this draft. Please contact more detail to them. Thank you very much! > > BR > Oliver > > --------------------------- > Huangyong (Oliver) > Network research, Huawei > > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Saturday, May 30, 2015 4:42 AM > To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com > Subject: Comments on draft-ww-sfc-control-plane-04 > > Authors of draft-ww-sfc-control-plane, > > I’ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04 > > I have some very high-level suggestions: > > > 1. I believe the “F” interface should be split into two interfaces. One for performance monitoring (availability and workload were cited), and one for updating classification information. > > Call these F1 and F2, I suppose. My reasons are that (a) as a general principle, interfaces should not have multiple purposes and (b) F1 and F2 could be communicating to different control-plane managers. > > > > 2. A control interface is required to SF components. Call it C3. This interface is required to (a) inform the SF about bidirectional chains (i.e., which Path IDs are paired) and (b) inform the SF about semantics of types of meta-data. C3 should also be connected to the SFC Proxy. > > I propose: > > 4.5 C3 Interface > > A service function may need information about the service paths > passing through it, and may need information about specific meta-data > types attached to packets on the paths. > > Some types of SF might be agnostic about the paths traversing them, but > most transport-layer-flow-aware devices will require this configuration. > > When bidirectional chains are deployed, the C3 interface provisions > each SF with each path identifier/path index pair that will pass through. > Each such pair is associated with an opposite-direction pair of > identifier/index. > > Meta-data is for the benefit of SFs. The C3 interface informs the SF > about the semantics of the meta-data, which would otherwise have > opaque meaning. Meta-data attributes include "scope" (per-packet, per-flow > or per host), "mandatory" (must be understood), "bidirectional" (same > value may be used in both directions), "is_qualifier" (indicates a > distinct routing domain). > > > I think there is quite a bit to explore, but I believe this starts the discussion. > Thoughts? > > > David Dolson > Senior Software Architect, Sandvine Inc. > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Sat May 30 13:45:54 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A024E1ACD56 for ; Sat, 30 May 2015 13:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 VRdCgB4m2f14 for ; Sat, 30 May 2015 13:45:51 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5611ACD53 for ; Sat, 30 May 2015 13:45:51 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Sat, 30 May 2015 16:45:50 -0400 From: Dave Dolson To: Joel Halpern , "sfc@ietf.org" Thread-Topic: [sfc] Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAABf9ORQAFesYgP//4gcR Date: Sat, 30 May 2015 20:45:49 +0000 Message-ID: <20150530204548.5374031.37211.16062@sandvine.com> References: , <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> , <556A0261.3040305@joelhalpern.com> In-Reply-To: <556A0261.3040305@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 20:45:53 -0000 If, in the general case, every SF requires a co-located classifier, doesn't= that lead to the question of why an SFC data-plane protocol (NSH) is requi= red? Every SF could choose the next hop with a classifier. But no, I think we all see the benefits of avoiding classification in the S= F. Telling the SF about some aspects of the encapsulation goes a long way. =FD David Dolson Senior Software Architect, Sandvine Inc. Original Message From: Joel Halpern Sent: Saturday, May 30, 2015 2:33 PM To: sfc@ietf.org Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 Clearly, there are cases where a service funtion will originate packets. I would strongly hope that the service function is not required to know the details of the service function path identification inorder to do so. My assumption has been that to support this need (both for bidirectional cases, and for others), there would be a classifier in place to apply the necessary headers. That classifier could be colocated with the SFF, or could be colocated with the service function itself. Thus, if one wants to deploy a service function and the ability to add path information, I would expect a service funciton with colocated classifier. Arguably this is only a descriptive difference. But that description keeps much clearer what functionality we are discussing, and where it may exist. Yours, Joel On 5/30/15 8:13 AM, Dave Dolson wrote: > I will review the document later, but I can quickly answer your question. >> I have question why not the SFC forwarding system handle the paired chai= n itself? > > Here is the very simple example that indicates the problem: > - An SF firewall has a policy to respond to not-permitted incoming conn= ections with TCP RST > (rather than allowing the connection to reach the protected host). > - Therefore when a TCP SYN packet arrives at the SF firewall with NSH e= ncapsulation > having path ID x and Path Index y, it must be able to insert the response= into the path that is > the bidirectional complement, an NSH encapsulation having path ID x' and = path index y' to send > the packet back to the source, following the reverse path. > > I hope that shows why the paths need to be paired? > > I believe that most flow-stateful devices will require the pairing inform= ation. > > -Dave > > > ________________________________ > From: Huangyong (Oliver) [oliver.huang@huawei.com] > Sent: Friday, May 29, 2015 9:06 PM > To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.boucada= ir@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafone.com= ; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Li= nda Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 > > Hello Dave, > > Thank you for your detailed consideration on the draft. I agree= that the SF should support the capability of bidirectional chains. For exa= mple, the NAT SF may provide the new allocated address/port to the controll= er. You mentioned the control plane should inform SF bidirectional chain (= which path id are paired). I have question why not the SFC forwarding syst= em handle the paired chain itself? > > Performance mornitoring is a basic capability which should exist= in all interfaces C1,C2,C3. > > Mohamed have developed a new version of this draft and made a bi= g promotion. In the new draft, C3,C4 are introduced for SF and SF proxy sep= arately. I think it may cover the related scenario. I attached it in this= email, please check it. > > Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar a= re representative of Huawei on this draft. Please contact more detail to th= em. Thank you very much! > > BR > Oliver > > --------------------------- > Huangyong (Oliver) > Network research, Huawei > > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Saturday, May 30, 2015 4:42 AM > To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); mohamed.= boucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodaf= one.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com > Subject: Comments on draft-ww-sfc-control-plane-04 > > Authors of draft-ww-sfc-control-plane, > > I=92ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control= -plane-04 > > I have some very high-level suggestions: > > > 1. I believe the =93F=94 interface should be split into two interfac= es. One for performance monitoring (availability and workload were cited), = and one for updating classification information. > > Call these F1 and F2, I suppose. My reasons are that (a) as a general pri= nciple, interfaces should not have multiple purposes and (b) F1 and F2 coul= d be communicating to different control-plane managers. > > > > 2. A control interface is required to SF components. Call it C3. Thi= s interface is required to (a) inform the SF about bidirectional chains (i.= e., which Path IDs are paired) and (b) inform the SF about semantics of typ= es of meta-data. C3 should also be connected to the SFC Proxy. > > I propose: > > 4.5 C3 Interface > > A service function may need information about the service paths > passing through it, and may need information about specific meta-data > types attached to packets on the paths. > > Some types of SF might be agnostic about the paths traversing them, b= ut > most transport-layer-flow-aware devices will require this configurati= on. > > When bidirectional chains are deployed, the C3 interface provisions > each SF with each path identifier/path index pair that will pass thro= ugh. > Each such pair is associated with an opposite-direction pair of > identifier/index. > > Meta-data is for the benefit of SFs. The C3 interface informs the SF > about the semantics of the meta-data, which would otherwise have > opaque meaning. Meta-data attributes include "scope" (per-packet, per= -flow > or per host), "mandatory" (must be understood), "bidirectional" (same > value may be used in both directions), "is_qualifier" (indicates a > distinct routing domain). > > > I think there is quite a bit to explore, but I believe this starts the di= scussion. > Thoughts? > > > David Dolson > Senior Software Architect, Sandvine Inc. > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Sat May 30 13:57:41 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DE81ACC85 for ; Sat, 30 May 2015 13:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 ka340aaZ_bHi for ; Sat, 30 May 2015 13:57:37 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3FB1ACD65 for ; Sat, 30 May 2015 13:57:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9A8A7240673; Sat, 30 May 2015 13:57:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 0906524032C; Sat, 30 May 2015 13:57:36 -0700 (PDT) Message-ID: <556A242A.3010204@joelhalpern.com> Date: Sat, 30 May 2015 16:57:14 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Dolson , "sfc@ietf.org" References: , <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> , <556A0261.3040305@joelhalpern.com> <20150530204548.5374031.37211.16062@sandvine.com> In-Reply-To: <20150530204548.5374031.37211.16062@sandvine.com> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 20:57:39 -0000 I don't see any indication that every SF requires a classifier. There are some functions that need it. But most functions are not generating packets nor changing the path the packets are on. Yours, Joel On 5/30/15 4:45 PM, Dave Dolson wrote: > If, in the general case, every SF requires a co-located classifier, doesn't that lead to the question of why an SFC data-plane protocol (NSH) is required? Every SF could choose the next hop with a classifier. > > But no, I think we all see the benefits of avoiding classification in the SF. > Telling the SF about some aspects of the encapsulation goes a long way. > ý > > David Dolson > Senior Software Architect, Sandvine Inc. > Original Message > From: Joel Halpern > Sent: Saturday, May 30, 2015 2:33 PM > To: sfc@ietf.org > Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 > > > Clearly, there are cases where a service funtion will originate packets. > I would strongly hope that the service function is not required to know > the details of the service function path identification inorder to do so. > My assumption has been that to support this need (both for bidirectional > cases, and for others), there would be a classifier in place to apply > the necessary headers. That classifier could be colocated with the SFF, > or could be colocated with the service function itself. > > Thus, if one wants to deploy a service function and the ability to add > path information, I would expect a service funciton with colocated > classifier. Arguably this is only a descriptive difference. But that > description keeps much clearer what functionality we are discussing, and > where it may exist. > > Yours, > Joel > > On 5/30/15 8:13 AM, Dave Dolson wrote: >> I will review the document later, but I can quickly answer your question. >>> I have question why not the SFC forwarding system handle the paired chain itself? >> >> Here is the very simple example that indicates the problem: >> - An SF firewall has a policy to respond to not-permitted incoming connections with TCP RST >> (rather than allowing the connection to reach the protected host). >> - Therefore when a TCP SYN packet arrives at the SF firewall with NSH encapsulation >> having path ID x and Path Index y, it must be able to insert the response into the path that is >> the bidirectional complement, an NSH encapsulation having path ID x' and path index y' to send >> the packet back to the source, following the reverse path. >> >> I hope that shows why the paths need to be paired? >> >> I believe that most flow-stateful devices will require the pairing information. >> >> -Dave >> >> >> ________________________________ >> From: Huangyong (Oliver) [oliver.huang@huawei.com] >> Sent: Friday, May 29, 2015 9:06 PM >> To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Linda Dunbar >> Subject: RE: Comments on draft-ww-sfc-control-plane-04 >> >> Hello Dave, >> >> Thank you for your detailed consideration on the draft. I agree that the SF should support the capability of bidirectional chains. For example, the NAT SF may provide the new allocated address/port to the controller. You mentioned the control plane should inform SF bidirectional chain (which path id are paired). I have question why not the SFC forwarding system handle the paired chain itself? >> >> Performance mornitoring is a basic capability which should exist in all interfaces C1,C2,C3. >> >> Mohamed have developed a new version of this draft and made a big promotion. In the new draft, C3,C4 are introduced for SF and SF proxy separately. I think it may cover the related scenario. I attached it in this email, please check it. >> >> Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are representative of Huawei on this draft. Please contact more detail to them. Thank you very much! >> >> BR >> Oliver >> >> --------------------------- >> Huangyong (Oliver) >> Network research, Huawei >> >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: Saturday, May 30, 2015 4:42 AM >> To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com >> Subject: Comments on draft-ww-sfc-control-plane-04 >> >> Authors of draft-ww-sfc-control-plane, >> >> I’ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04 >> >> I have some very high-level suggestions: >> >> >> 1. I believe the “F” interface should be split into two interfaces. One for performance monitoring (availability and workload were cited), and one for updating classification information. >> >> Call these F1 and F2, I suppose. My reasons are that (a) as a general principle, interfaces should not have multiple purposes and (b) F1 and F2 could be communicating to different control-plane managers. >> >> >> >> 2. A control interface is required to SF components. Call it C3. This interface is required to (a) inform the SF about bidirectional chains (i.e., which Path IDs are paired) and (b) inform the SF about semantics of types of meta-data. C3 should also be connected to the SFC Proxy. >> >> I propose: >> >> 4.5 C3 Interface >> >> A service function may need information about the service paths >> passing through it, and may need information about specific meta-data >> types attached to packets on the paths. >> >> Some types of SF might be agnostic about the paths traversing them, but >> most transport-layer-flow-aware devices will require this configuration. >> >> When bidirectional chains are deployed, the C3 interface provisions >> each SF with each path identifier/path index pair that will pass through. >> Each such pair is associated with an opposite-direction pair of >> identifier/index. >> >> Meta-data is for the benefit of SFs. The C3 interface informs the SF >> about the semantics of the meta-data, which would otherwise have >> opaque meaning. Meta-data attributes include "scope" (per-packet, per-flow >> or per host), "mandatory" (must be understood), "bidirectional" (same >> value may be used in both directions), "is_qualifier" (indicates a >> distinct routing domain). >> >> >> I think there is quite a bit to explore, but I believe this starts the discussion. >> Thoughts? >> >> >> David Dolson >> Senior Software Architect, Sandvine Inc. >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Sun May 31 12:51:03 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B771A8A59; Sun, 31 May 2015 12:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.567 X-Spam-Level: X-Spam-Status: No, score=-11.567 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 GQffLpi5_bkq; Sun, 31 May 2015 12:50:55 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370171A8981; Sun, 31 May 2015 12:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25791; q=dns/txt; s=iport; t=1433101855; x=1434311455; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=JEbonSH4dy5pzGbp2KWSIWiHIUWim94NwY8y2BW0tsQ=; b=eydH6wbmATCrpdhp6azN62svAQgC7MrZ6BKc8x/HHCfe8yDz6PCfhXtU Bq/BVJyemdrI7ISJI0HRhEth5b8XQftHbSaaLDTAFpIv1/DMlesQbcxNW k8YD6jo6ipdEzPC3ACaqDwYxKrqELfwfVtr2bhET1DcTw290surtKXFCo o=; X-IronPort-AV: E=Sophos;i="5.13,527,1427760000"; d="scan'208,217";a="154970308" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 31 May 2015 19:50:54 +0000 Received: from [10.82.210.14] (rtp-vpn4-526.cisco.com [10.82.210.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4VJomjs029905; Sun, 31 May 2015 19:50:49 GMT Message-ID: <556B098C.7030102@cisco.com> Date: Sun, 31 May 2015 15:15:56 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <20150528144454.10612.14109.idtracker@ietfa.amsl.com> <5568759A.4030104@cisco.com> <301FC39F-1B3E-4D3C-B012-B5EE980F4CE3@cisco.com> In-Reply-To: <301FC39F-1B3E-4D3C-B012-B5EE980F4CE3@cisco.com> Content-Type: multipart/alternative; boundary="------------050502020909060801090800" Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Benoit Claise's No Objection on draft-ietf-sfc-architecture-08: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 19:50:58 -0000 This is a multi-part message in MIME format. --------------050502020909060801090800 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Carlos for taking care of my comments. The draft is now improved IMO. At least for someone like me who doesn't have all the SFC background Regards, Benoit > Hi, Benoit, > > Thanks for the follow-up and trimming down the set of comments. Please > see inline. > >> On May 29, 2015, at 10:20 AM, Benoit Claise (bclaise) >> > wrote: >> >> Thanks Carlos for the detailed answer. >> I remove all points we agree with. >> See in line. >>> Hi Benoit, >>> >>> Many thanks again for your review — let me also reply to your >>> COMMENTs point-by-point below, to make sure we are on the same page. >>> >>> >>>>> >>>>> >>>>> - Service Function Path definition: I'm confused. you don't >>>>> explain what >>>>> it is, but only explain why you need it. >>> >>> The definition of SFP took quite significant crafting and wording, >>> and WG cycles. It is correct, yet a bit complex. >> I didn't assert the definition was not correct. I wrote "I'm >> confused", because, even after reading it multiple times, I can't >> make the link between the different concepts: SFP, SFC, RSP. > > Understood. I did not asset you asserted it was not correct :-) I was > merely acknowledging that it was not an easy read, but stating that it > was correct despite it being complex. > > Regarding the link between SFC, SFP, and RSP, please see below. > >>> >>> >>>>> Later on, I see "As an example of such an intermediate >>>>> specificity, there >>>>> may be two >>>>> SFPs associated with a given SFC". I'm confused. >>>>> Not too clear on how the SFP and RSP relate to each others. >>>>> Is the Service Function Path the ordered list of SFs, while the RSP is >>>>> the ordered list of SFFs? >>> >>> The SFC is an ordered set of abstract functions — e.g., “a >>> firewall”. An SFP applies (policy, service function, etc) constrains >>> as e.g., “this firewall”, or “this firewall via this SFF …”; as >>> detailed in Section 2.3, SFPs do not have a requirement of full >>> specificity. SFPs can have varying degrees of specificity (from >>> fully specified SFFs and SFs to reach that SF and there’s degree of >>> freedom over which SFFs to use). Lastly, an RSP is the fully >>> specified set of SFFs and SFs actually visited. In other words, from >>> less specified to fully specified: SFC -> SFP -> RSP. >> Ah, now that makes sense (at least to me) >> With that in mind, I reviewed the definitions and section 2.3, and >> here are my conclusions. >> >> 1. I found the Service Function Path definition in the RSP definition: >> "The Service Function Path is a >> constrained specification of where packets assigned to a certain >> service function path must go. While it may be so constrained >> as to identify the exact locations, it can also be less >> specific. >> These sentences should be the first sentences of the Service Function >> Path definition. >> > > Sure — moved text around a bit. > >> 2. This example below must be mentioned in the draft >> >> The SFC is an ordered set of abstract functions — e.g., “a >> firewall”. An SFP applies (policy, service function, etc) >> constrains as e.g., “this firewall”, or “this firewall via this >> SFF …”; as detailed in Section 2.3, SFPs do not have a >> requirement of full specificity. SFPs can have varying degrees of >> specificity (from fully specified SFFs and SFs to reach that SF >> and there’s degree of freedom over which SFFs to use). Lastly, an >> RSP is the fully specified set of SFFs and SFs actually visited. >> In other words, from less specified to fully specified: SFC -> >> SFP -> RSP. >> >> Potentially in Section 2.3. If yes, section 2.3 should be called >> "Service Function Paths and RSP" >> Alternatively in a section 2.4 > > Ack — instead, we are adding a Section 2.3.1 (since it is separate, > but within context of S2.3). > > Joel and I crafter some text, here’s the proposal (and see attached > diffs). > > >
title="Service Function Chains, Service Function Paths, and Rendered > Service Path" > > >As an example of this progressive refinement, consider a service > function chain (SFC) which states that packets using this chain should > be delivered to a firewall and a caching engine. > >A Service Function Path (SFP) could refine this, considering that > this architecture does not mandate the degree of specificity an SFP > has to have. It might specify that the firewall and caching engine are > both to be in a specific Data Center (e.g., in DC1), or it might > specify exactly which instance of each firewall and chaching engine is > to be used. > >The Rendered Service Path (RSP) is the actual sequence of SFFs and > SFs that the packets will actually visit. So if the SFP picked the DC, > the RSP would be more specific. >
> > > >> >>> >>> >>>>> >>>>> - >>>>> "Traffic from SFs eventually returns to the same SFF, which is >>>>> responsible for injecting traffic back onto the network. >>>>> >>>>> Am I correct that it only applies in case of a SFC proxy? >>> >>> Please note also that SFFs and SFs are architectural functional >>> blocks, and an IPS might include both functions. >> I completely missed that from the draft. Where is it explained or how >> have you improved the draft? >> I had in mind this use case : SFF = switch, SF = attached appliance. > > OK, clarifying text at the beginning of Section 4 — please see > attached diffs FYI. > >>> >>>>> Related question, along the same lines: >>>>> >>>>> 1. SFP forwarding : Traffic arrives at an SFF from the network. >>>>> The >>>>> SFF determines the appropriate SF the traffic should be forwarded >>>>> to via information contained in the SFC encapsulation. Post-SF, >>>>> the traffic is returned to the SFF, and, if needed, is forwarded >>>>> to another SF associated with that SFF. If there is another non- >>>>> local (i.e., different SFF) hop in the SFP, the SFF further >>>>> encapsulates the traffic in the appropriate network transport >>>>> protocol and delivers it to the network for delivery to the next >>>>> SFF along the path. >>>>> >>>>> Returned to the initial SFF, or to the next SFF in the RSP? >>>>> I guess the next SFF in the chain (again, unless we speak about a >>>>> proxy) >>> >>> Not about proxy. Traffic returns from the SF to the SFF that sent it >>> to that SF. From that SFF, it can go to another SF or to another SFF >>> -> SF. >>> >>> To exemplify (what I believe might be the confusion), if a >>> classifier sends traffic to a firewall, traffic does not return to >>> the classifier. After the firewall SF is applied, it returns to the >>> functional SFF. >> Understood now. I'll look at the diff. If you have them now, please >> forward. > > Sure — see attached, noting that these include all the edits thus far > since -08, a super-set of the ones from your comments. > > If you still believe there are issues unadressed, please provide a > specific textual proposal to understand what might be missing. > > Thanks, > > — Carlos. > > > > > >>> >>> >> Thanks and regards, Benoit > --------------050502020909060801090800 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks Carlos for taking care of my comments.
The draft is now improved IMO. At least for someone like me who doesn't have all the SFC background

Regards, Benoit


Hi, Benoit,

Thanks for the follow-up and trimming down the set of comments. Please see inline.

On May 29, 2015, at 10:20 AM, Benoit Claise (bclaise) <bclaise@cisco.com> wrote:

Thanks Carlos for the detailed answer.
I remove all points we agree with.
See in line.
Hi Benoit,

Many thanks again for your review — let me also reply to your COMMENTs point-by-point below, to make sure we are on the same page.




- Service Function Path definition: I'm confused. you don't explain what
it is, but only explain why you need it.

The definition of SFP took quite significant crafting and wording, and WG cycles. It is correct, yet a bit complex.
I didn't assert the definition was not correct. I wrote "I'm confused", because, even after reading it multiple times, I can't make the link between the different concepts: SFP, SFC, RSP.

Understood. I did not asset you asserted it was not correct :-) I was merely acknowledging that it was not an easy read, but stating that it was correct despite it being complex.

Regarding the link between SFC, SFP, and RSP, please see below.



Later on, I see "As an example of such an intermediate specificity, there
may be two
SFPs associated with a given SFC". I'm confused.
Not too clear on how the SFP and RSP relate to each others.
Is the Service Function Path the ordered list of SFs, while the RSP is
the ordered list of SFFs?

The SFC is an ordered set of abstract functions — e.g., “a firewall”. An SFP applies (policy, service function, etc) constrains as e.g., “this firewall”, or “this firewall via this SFF …”; as detailed in Section 2.3, SFPs do not have a requirement of full specificity. SFPs can have varying degrees of specificity (from fully specified SFFs and SFs to reach that SF and there’s degree of freedom over which SFFs to use). Lastly, an RSP is the fully specified set of SFFs and SFs actually visited. In other words, from less specified to fully specified: SFC -> SFP -> RSP.
Ah, now that makes sense (at least to me)
With that in mind, I reviewed the definitions and section 2.3, and here are my conclusions.

1. I found the Service Function Path definition in the RSP definition:
	"The Service Function Path is a
        constrained specification of where packets assigned to a certain
        service function path must go.  While it may be so constrained
        as to identify the exact locations, it can also be less
        specific.
These sentences should be the first sentences of the Service Function Path definition.


Sure — moved text around a bit.

2. This example below must be mentioned in the draft
The SFC is an ordered set of abstract functions — e.g., “a firewall”. An SFP applies (policy, service function, etc) constrains as e.g., “this firewall”, or “this firewall via this SFF …”; as detailed in Section 2.3, SFPs do not have a requirement of full specificity. SFPs can have varying degrees of specificity (from fully specified SFFs and SFs to reach that SF and there’s degree of freedom over which SFFs to use). Lastly, an RSP is the fully specified set of SFFs and SFs actually visited. In other words, from less specified to fully specified: SFC -> SFP -> RSP.
Potentially in Section 2.3. If yes, section 2.3 should be called "Service Function Paths and RSP"
Alternatively in a section 2.4

Ack — instead, we are adding a Section 2.3.1 (since it is separate, but within context of S2.3).

Joel and I crafter some text, here’s the proposal (and see attached diffs).

<?xml version="1.0"?>
<section
title="Service Function Chains, Service Function Paths, and Rendered Service Path"
><t
>As an example of this progressive refinement, consider a service function chain (SFC) which states that packets using this chain should be delivered to a firewall and a caching engine.</t
><t
>A Service Function Path (SFP) could refine this, considering that this architecture does not mandate the degree of specificity an SFP has to have. It might specify that the firewall and caching engine are both to be in a specific Data Center (e.g., in DC1), or it might specify exactly which instance of each firewall and chaching engine is to be used.</t
><t
>The Rendered Service Path (RSP) is the actual sequence of SFFs and SFs that the packets will actually visit. So if the SFP picked the DC, the RSP would be more specific.</t
></section
>






-
"Traffic from SFs eventually returns to the same SFF, which is
responsible for injecting traffic back onto the network.

Am I correct that it only applies in case of a SFC proxy?

Please note also that SFFs and SFs are architectural functional blocks, and an IPS might include both functions.
I completely missed that from the draft. Where is it explained or how have you improved the draft?
I had in mind this use case : SFF = switch, SF = attached appliance.

OK, clarifying text at the beginning of Section 4 — please see attached diffs FYI.


Related question, along the same lines:

     1.  SFP forwarding : Traffic arrives at an SFF from the network.
The
     SFF determines the appropriate SF the traffic should be forwarded
     to via information contained in the SFC encapsulation.  Post-SF,
     the traffic is returned to the SFF, and, if needed, is forwarded
     to another SF associated with that SFF.  If there is another non-
     local (i.e., different SFF) hop in the SFP, the SFF further
     encapsulates the traffic in the appropriate network transport
     protocol and delivers it to the network for delivery to the next
     SFF along the path.

Returned to the initial SFF, or to the next SFF in the RSP?
I guess the next SFF in the chain (again, unless we speak about a proxy)

Not about proxy. Traffic returns from the SF to the SFF that sent it to that SF. From that SFF, it can go to another SF or to another SFF -> SF.

To exemplify (what I believe might be the confusion), if a classifier sends traffic to a firewall, traffic does not return to the classifier. After the firewall SF is applied, it returns to the functional SFF.
Understood now. I'll look at the diff. If you have them now, please forward.

Sure — see attached, noting that these include all the edits thus far since -08, a super-set of the ones from your comments.

If you still believe there are issues unadressed, please provide a specific textual proposal to understand what might be missing.

Thanks,

— Carlos.







Thanks and regards, Benoit


--------------050502020909060801090800--