From nobody Wed Apr 1 10:31:54 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC741A0A6A; Wed, 1 Apr 2015 10:31:51 -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, HTML_MESSAGE=0.001, 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 GeJYC-7WFxFg; Wed, 1 Apr 2015 10:31:44 -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 8DC221A0084; Wed, 1 Apr 2015 10:31:43 -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 BUJ88743; Wed, 01 Apr 2015 17:31:41 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 1 Apr 2015 18:31:41 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Wed, 1 Apr 2015 10:31:31 -0700 From: Linda Dunbar To: "Teague, Nik" , "dots@ietf.org" Thread-Topic: scope Thread-Index: AQHQa8ImfNQMx27PokCfZQ+6rvOaCp04aHXg Date: Wed, 1 Apr 2015 17:31:30 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657BFF946@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.214] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657BFF946dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] scope X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:31:51 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657BFF946dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nik, Can you elaborate a bit more on the "peacetime provisioning channel"? What kind of "configuration data" is exchanged on over this channel? What p= rotocol? Is it NETCONF? In parallel to DOTS, there is the I2NSF initiative intended for specifying = the security policies to security functions (primarily the flow based secu= rity functions). https://datatracker.ietf.org/doc/draft-lopez-i2nsf-packet/ has identified t= hree types interfaces to security functions: * Configuration - Device configuration - Network configuration * Signaling - Status - Counters - Queries - Alerts * Provisioning - Capabilities - Policy - Object Configuration I2NSF will focus on the 3rd bullet, i.e. the Provisioning part. Just want to see if the provisioning you mentioned could provide the synerg= y to I2NSF's provisioning. Thanks, Linda From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Teague, Nik Sent: Tuesday, March 31, 2015 9:51 AM To: dots@ietf.org Subject: [Dots] scope Hi, I hope everyone had good journeys home or onward to wherever you may be. I wanted to follow up on the BOF and the outcomes - in particular I wanted = to discuss scope, requirements and some thoughts. Please feedback your tho= ughts/opinions... Firstly applicability - as was clear from the BOF we were defining DDoS mit= igation devices/applications or devices which may have other functions but = contain a DDoS mitigation element. The devices/applications may have eithe= r inline or out of band detection/mitigation capabilities and may be deploy= ed as part of a larger mitigation strategy. Its signaling between these el= ements and an upstream or service provider that we're concerned with. The = term CPE was used which we will clarify to the term 'on-premise' to remove = any confusion as to what we're discussing. These devices/applications already provide a degree of sophisticated analyt= ics based on the traffic they observe. The upstream element may, therefore= , only require data relevant to its needs in identifying that an offramp is= desired and telemetry in order for situational awareness in providing the = correct mitigation strategy. As was discussed feedback from the upstream/s= ervice provider is desirable relating to ongoing attack statistics and also= its conclusion. Characteristics Signaling: >From discussions its clear that the signaling element should include a leve= l of encryption/obfuscation to negate the need for additional vpns, infrast= ructure etc. Signaling should be lightweight and transport should not be s= ession oriented in the classical sense. It may be assumed likely that the = ingress path to the on-premise device may be congested and loss should be e= xpected and tolerated. The ability to optimise as much information as poss= ible into discrete packets is a definite advantage based upon the high prob= ability of link/path congestion. Provisioning: A peacetime provisioning channel has proven effective in various vendor imp= lementations for authentication, key exchange, configuration exchange etc. = and it seems a good way to proceed since the information exchanged is usual= ly weightier and doesn't have restrictions relating to a congested network.= From discussions it was suggested the on-premise device would be in the b= est position to communicate thresholds as to when a traffic swing should be= triggered. The ability to simply signal (without additional qualification= ) that an upstream mitigation is requested is also desirable. This may be = a potential in-road to enabling this on less sophisticated (re DDoS) device= types - e.g. If link >=3D80% then call for help. Thanks, -Nik "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." --_000_4A95BA014132FF49AE685FAB4B9F17F657BFF946dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nik,

 <= /p>

Can you elaborate a bit m= ore on the  “peacetime provisioni= ng channel”?

 

What kind of “confi= guration data” is exchanged on over this channel? What protocol? Is i= t NETCONF?

 <= /p>

In parallel to DOTS, ther= e is the I2NSF initiative intended for specifying the security policies to =  security functions (primarily the flow based security functions).

https://datatracker.ietf.= org/doc/draft-lopez-i2nsf-packet/ has identified three types interfaces to = security functions:

• &nbs= p;     Configuration

– &nbs= p;    Device configurat= ion

– &nbs= p;    Network configura= tion

• &nbs= p;     Signaling

– &nbs= p;    Status=

– &nbs= p;    Counters

– &nbs= p;    Queries

– &nbs= p;    Alerts=

• &nbs= p;     Provisioning=

– &nbs= p;    Capabilities=

– &nbs= p;    Policy=

– &nbs= p;    Object Configurat= ion

 <= /p>

 <= /p>

I2NSF will focus on the 3= rd bullet, i.e. the Provisioning part.

 <= /p>

Just want to see if the p= rovisioning you mentioned could provide the synergy to I2NSF’s provis= ioning.  

 <= /p>

Thanks,

Linda

 <= /p>

From: Dots [ma= ilto:dots-bounces@ietf.org] On Behalf Of Teague, Nik
Sent: Tuesday, March 31, 2015 9:51 AM
To: dots@ietf.org
Subject: [Dots] scope

 

Hi,

 

I hope everyone had good jou= rneys home or onward to wherever you may be.

 

I wanted to follow up on the= BOF and the outcomes – in particular I wanted to discuss scope, requ= irements and some thoughts.  Please feedback your thoughts/opinions= 230;

 

Firstly applicability –= ; as was clear from the BOF we were defining DDoS mitigation devices/applic= ations or devices which may have other functions but contain a DDoS mitigation element.  The devices/applications may have either in= line or out of band detection/mitigation capabilities and may be deployed a= s part of a larger mitigation strategy.  Its signaling between these e= lements and an upstream or service provider that we’re concerned with.  The term CPE was used which we will= clarify to the term ‘on-premise’ to remove any confusion as to= what we’re discussing.

 

These devices/applications a= lready provide a degree of sophisticated analytics based on the traffic the= y observe.  The upstream element may, therefore, only require data relevant to its needs in identifying that an offramp is desired and t= elemetry in order for situational awareness in providing the correct mitiga= tion strategy.  As was discussed feedback from the upstream/service pr= ovider is desirable relating to ongoing attack statistics and also its conclusion.

 

Characteristics 

 

Signaling:=

From discussions its clear t= hat the signaling element should include a level of encryption/obfuscation = to negate the need for additional vpns, infrastructure etc.  Signaling should be lightweight and transport should not be session = oriented in the classical sense.  It may be assumed likely that the in= gress path to the on-premise device may be congested and loss should be exp= ected and tolerated.  The ability to optimise as much information as possible into discrete packets is a definite advant= age based upon the high probability of link/path congestion.

 

Provisioning:

A peacetime provisioning cha= nnel has proven effective in various vendor implementations for authenticat= ion, key exchange, configuration exchange etc. and it seems a good way to proceed since the information exchanged is usually weightier= and doesn’t have restrictions relating to a congested network.  = ;From discussions it was suggested the on-premise device would be in the be= st position to communicate thresholds as to when a traffic swing should be triggered.  The ability to simply sign= al (without additional qualification) that an upstream mitigation is reques= ted is also desirable.  This may be a potential in-road to enabling th= is on less sophisticated (re DDoS) device types – e.g. If link >=3D80% then call for help.

 

Thanks,

 

-Nik

 

 

“This message (including any attachments) is intended only= for the use of the individual or entity to which it is addressed, and may = contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be con= stituted as attorney work product. If you are not the intended recipient, y= ou are hereby notified that any use, dissemination, distribution, or copyin= g of this communication is strictly prohibited. If you have received this message in error, notify sender imme= diately and delete this message immediately.”
--_000_4A95BA014132FF49AE685FAB4B9F17F657BFF946dfweml701chm_-- From nobody Wed Apr 1 14:15:29 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B791A01E2 for ; Wed, 1 Apr 2015 14:15:28 -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, HTML_MESSAGE=0.001, 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 FP42W2LgZybZ for ; Wed, 1 Apr 2015 14:15:25 -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 CEDC51A0199 for ; Wed, 1 Apr 2015 14:15:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQY59736; Wed, 01 Apr 2015 21:15:20 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 1 Apr 2015 22:15:20 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Wed, 1 Apr 2015 14:15:15 -0700 From: Linda Dunbar To: "Adam W. Montville" , Melinda Shore Thread-Topic: [I2nsf] The defense 'ecosystem' paradigm Thread-Index: AQHQZyIxU6gyBSrNlkOm5jaf0cbqeJ0xnUQAgACyxYCABmLpAA== Date: Wed, 1 Apr 2015 21:15:14 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657BFFB52@dfweml701-chm> References: <5512F1ED.8020104@htt-consult.com> <55160B74.1010009@gmail.com> <032CF466-C78E-46C7-A171-5176555A97DA@gmail.com> In-Reply-To: <032CF466-C78E-46C7-A171-5176555A97DA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.214] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657BFFB52dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] The defense 'ecosystem' paradigm X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:15:28 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657BFFB52dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRhbSwNCg0KWW91IHNhaWQ6DQpzYWNtIGlzLCBhdCBpdHMgY29yZSwgcHJpbWFyaWx5IGludGVy ZXN0ZWQgaW4gYXNzZXNzaW5nIGVuZHBvaW50IGF0dHJpYnV0ZXMuICBUaGlzIG1lYW5zIGV4cHJl c3NpbmcgdGhlIGRlc2lyZWQgYXR0cmlidXRlIHRvIGNvbGxlY3QsIGNvbGxlY3RpbmcgaXQsIGFu ZCBldmFsdWF0aW5nIGl0IGFnYWluc3Qgc29tZSBleHByZXNzZWQgZXhwZWN0YXRpb24uICBUaGUg YXNzZXNzbWVudCByZXN1bHQgaXMgcHJvdmlkZWQgZm9yIGRvd25zdHJlYW0gdXNlLCBpcnJlc3Bl Y3RpdmUgb2Ygd2hhdCB0aGF0IHVzZSBtaWdodCBiZS4gIEFkZGl0aW9uYWxseSwgY29sbGVjdGlv biBjb3VsZCBiZSB0aGUgb25seSByZXN1bHRzIHByb3ZpZGVkIChpZiBubyBldmFsdWF0aW9uIHBp ZWNlIGlzIG5lZWRlZCkuDQoNCkhvdyBhcmUgdGhlIOKAnGRlc2lyZWQgYXR0cmlidXRlc+KAnSBl eHByZXNzZWQgYnkgU0FDTT8gSG93IGFyZSB0aGUg4oCcZXhwZWN0YXRpb27igJ0gYmVpbmcgc3Bl Y2lmaWVkPw0KDQpUaGFua3MsIExpbmRhDQoNCkZyb206IEkybnNmIFttYWlsdG86aTJuc2YtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gVy4gTW9udHZpbGxlDQpTZW50OiBTYXR1 cmRheSwgTWFyY2ggMjgsIDIwMTUgNzo0MSBBTQ0KVG86IE1lbGluZGEgU2hvcmUNCkNjOiBpMm5z ZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJMm5zZl0gVGhlIGRlZmVuc2UgJ2Vjb3N5c3RlbScg cGFyYWRpZ20NCg0KSGF2aW5nIGEgY3Jvc3MtZ3JvdXAgdW5kZXJzdGFuZGluZyBvZiB0aGUgcmVs YXRpb25zaGlwIGJldHdlZW4gaTJuc2YsIHNhY20sIG1pbGUsIGFuZCBkb3RzIHdvdWxkIGJlIGJl bmVmaWNpYWwuICBJ4oCZbSBsZXNzIGZhbWlsaWFyIHdpdGggaTJuc2YgYW5kIGRvdHMgKGluIHRo ZSBkZXRhaWxzKS4NCg0KDQpJdCBzZWVtcyB0aGF0IG1pbGUsIGkybnNmLCBhbmQgZG90cyB3b3Vs ZCBhbGwgYmVuZWZpdCBmcm9tIHNhY20gaW4gc29tZSB3YXksIGFzIHRoZXkgYXJlIGxhcmdlbHkg ZG93bnN0cmVhbSBmcm9tIHRoZSBjb3JlIHByb2JsZW0gc2FjbSBpbnRlbmRzIHRvIHNvbHZlLg0K DQppMm5zZiBzZWVrcyB0byBleHByZXNzIGFuZCBldmFsdWF0ZSBuZXR3b3JrIHNlcnZpY2UgcmVs YXRlZCBpbmZvcm1hdGlvbiwgd2hpY2ggd2lsbCB1bHRpbWF0ZWx5IG5lZWQgdG8gaWRlbnRpZnkg c3BlY2lmaWMgZW5kcG9pbnRzICh2aXJ0dWFsIG9yIG90aGVyd2lzZSkgdG8gY29sbGVjdCBzcGVj aWZpYyBhdHRyaWJ1dGVzLCBldmFsdWF0ZSB0aGVtIGFnYWluc3Qgc29tZSBleHByZXNzZWQgZXhw ZWN0YXRpb24sIHRoZW4gbWFrZSBzZW5zZSBvZiB0aGF0IGF0IHRoZSBpMm5zZiBsZXZlbC4NCg0K bWlsZSBjb3VsZCBiZW5lZml0IGZyb20gc2FjbSBieSBsZXZlcmFnaW5nIHRoZSBhdHRyaWJ1dGUg ZXhwcmVzc2lvbiBhbmQgZXZhbHVhdGlvbiBmb3JtYXRzLiAgQWRkaXRpb25hbGx5LCB0aGUg4oCc YWQgaG9j4oCdIGV4cGxvcmF0b3J5IHRvb2xzIG9mdGVuIGZhdm9yZWQgZHVyaW5nIGluY2lkZW50 IHJlc3BvbnNlIGNvdWxkIHVzZSBzYWNtIGFzIGEgbWVhbnMgb2YgdGhhdCBleHBsb3JhdGlvbi4N Cg0KZG90cyBpcyBteSBsZWFzdCB1bmRlcnN0b29kIGRvbWFpbiwgYnV0IGFmdGVyIHNwZWFraW5n IHdpdGggQW5hIEhlZGFucGluZyBmb3IgYSBicmllZiB0aW1lLCBpdCBzZWVtcyB0aGF0IGRvdHMg d2lsbCBoYXZlIHNvbWUgbmVlZCB0byBleHByZXNzIGVuZHBvaW50IGF0dHJpYnV0ZXMsIGNvbGxl Y3QgdmFsdWVzLCBhbmQgZXZhbHVhdGUgdGhlbSBhZ2FpbnN0IHNvbWUgZXhwZWN0YXRpb24gYXMg d2VsbC4gIE9ubHksIHRoaXMgd2lsbCBiZSBtb3JlIG9mIGEg4oCccmVhbCB0aW1l4oCdIGNpcmN1 bXN0YW5jZSAoSSBwcmVzdW1lKS4NCg0KQXMgQm9iIHBvaW50ZWQgb3V0LCB0aGVzZSBhcmUgYWxs IHBhcnRzIG9mIGEgd2hvbGUgLSB0aGUg4oCcZGVmZW5zZSBlY29zeXN0ZW0gcGFyYWRpZ23igJ0u ICAgQW5kLCB3aGlsZSBkZXJpdmluZyBhIHNwZWNpZmljIHRheG9ub215IGNvdWxkIGJlIHVzZWZ1 bCwgaXTigJlzIGFscmVhZHkgZG9uZSBpbiBhIHdheS4gIFRoZSDigJxkZWZlbnNlIOKAmGVjb3N5 c3RlbeKAmSBwYXJhZGlnbSIgc2VlbXMgdG8gbWUgbGlrZSBhIHN5bm9ueW0gZm9yIOKAnHNlY3Vy aXR5IHByb2dyYW3igJ0sIGFuZCB0aG9zZSBhcmUgd2VsbCBjb3ZlcmVkLiAgVGhpbmsgSVNPIDI3 MDAwIHNlcmllcywgTklTVCA4MDAtNTMsIFBDSSBEU1MsIENPQklULCAyMCBDcml0aWNhbCBTZWN1 cml0eSBDb250cm9scywgYW5kIHRoZSBsaWtlLiAgSW4gZmFjdCwgSSB1c2VkIGEgc2ltaWxhciBw ZXJzcGVjdGl2ZSAoSSBjYWxsZWQgaXQg4oCcZnJhbWUgb2YgcmVmZXJlbmNl4oCdKSBhdCBhIHNh Y20gQm9GIChiYWNrIGluIEF0bGFudGEgZHVyaW5nIElFVEYgODUgWzFdKSB0byBmcmFtZSB0aGUg 4oCcc3BhY2XigJ0gaW4gd2hpY2ggc2FjbSBwbGF5cy4gIEkgdGhpbmsgbWlsZSAgLCBpMm5zZiwg YW5kIGRvdHMgYWxsIHBsYXkgaW4gdGhpcyBzYW1lIHNwYWNlIChzZWUgdGhlIHNlY29uZCwgdGhp cmQsIGFuZCBmb3VydGggc2xpZGVzKS4NCg0KV2hhdCBzZWVtcyBpbXBvcnRhbnQgaXMgdGhhdCB3 ZSByZWNvZ25pemUgKGFuZCBuYW1lKSB0aGUgZGlmZmVyZW50IGJ1c2luZXNzIHByb2Nlc3NlcyB3 ZSBhcmUgc3VwcG9ydGluZy4gIFRoaXMgc2hvdWxkIGhlbHAgdXMgcmVjb2duaXplIHRoZSByZWxh dGlvbnNoaXBzIGJldHdlZW4gb3VyIHdvcmsuDQoNClRob3VnaHRzPw0KDQpSZWdhcmRzLA0KDQpB ZGFtDQoNClsxXSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NS9zbGlkZXMvc2xp ZGVzLTg1LXNhY20tMi5wZGYNCg0KDQoNCk9uIE1hciAyNywgMjAxNSwgYXQgOTowMSBQTSwgTWVs aW5kYSBTaG9yZSA8bWVsaW5kYS5zaG9yZUBnbWFpbC5jb208bWFpbHRvOm1lbGluZGEuc2hvcmVA Z21haWwuY29tPj4gd3JvdGU6DQoNCkknbSByYXRoZXIgc3VycHJpc2VkIHRoYXQgbm9ib2R5IGhh cyBhbnN3ZXJlZCB0aGlzIQ0KDQpJIHRoaW5rIHRoaXMgaXMgYSB2ZXJ5IHJlYXNvbmFibGUgYXBw cm9hY2gsIHdpdGggdGhlDQpjYXZlYXQgdGhhdCB3aGF0J3MgbmVlZGVkICpoZXJlKiBpcyBub3Qg c28gbXVjaCBhbiBhcmNoaXRlY3R1cmUNCmJ1dCBhbiBhY3R1YWwgcHJvdG9jb2wgY29udmV5aW5n IGFjdHVhbCBkYXRhIGJldHdlZW4gYWN0dWFsDQpuZXR3b3JrIGVsZW1lbnRzLiAgVGhpcyBtYXkg YmUgd2h5IG90aGVyIG1pZGRsZWJveCBwcm90b2NvbHMNCjxyaW1zaG90PiBoYXZlIGJlZW4gYWJs ZSB0byBtb3ZlIGZvcndhcmQsIGV2ZW4gd2hpbGUgYmVpbmcNCnJlZHVuZGFudCwgd2hpbGUgdGhp cyBlZmZvcnQgaGFzIGJlZW4gc3R1Y2suICBJdCBzZWVtcyB0bw0KbWUsIGJhc2VkIG9uIGRpc2N1 c3Npb25zIGR1cmluZyB0aGUgd2VlayBhbmQgb24gYm90aCB0aGUNCmlucHV0IHRvIGFuZCB0aGUg b3V0cHV0IGZyb20gdGhlIGRvdHMgQk9GLCB0aGF0IHRoZXJlJ3MNCnN0aWxsIHJvb20gZm9yIGEg Z29vZCBiYWNrZW5kIHByb3RvY29sIHRvIGNvbnZleSByZXF1ZXN0cw0KdG8gd2hhdCB1c2VkIHRv IGJlIGNhbGxlZCBwb2xpY3kgZW5mb3JjZW1lbnQgcG9pbnRzIGJhc2VkDQpvbiB0aGUgYWN0aXZl IHRocmVhdCBkYXRhIGJlaW5nIHNoYXJlZCB0aHJvdWdoIGEgZG90cy1saWtlIG1lY2hhbmlzbS4N CkJ1dCB0aGF0J3MgYSB2ZXJ5IG5hcnJvdyBleGFtcGxlLg0KDQpTbywgSSB0aGluayB0byB0aGUg ZXh0ZW50IHRoYXQgYSB0YXhvbm9teSBjYW4gaGVscCB0aGlzDQplZmZvcnQgZGV2ZWxvcCBhIG5h cnJvdyBmb2N1cywgaXQgd291bGQgYmUgYSB2ZXJ5IGhlbHBmdWwNCnRoaW5nIGluZGVlZC4gIEJ1 dCBpdCdzIGdvdCB0byBiZSB2ZXJ5IGFwcGxpZWQgLSBJIGFtDQpza2VwdGljYWwgYWJvdXQgdGhl IHZhbHVlIG9mIGhpZ2gtbGV2ZWwgYXJjaGl0ZWN0dXJlcyBpbg0KdGhlIElFVEYuDQoNCk1lbGlu ZGENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkky bnNmIG1haWxpbmcgbGlzdA0KSTJuc2ZAaWV0Zi5vcmc8bWFpbHRvOkkybnNmQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMm5zZg0KDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657BFFB52dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QWRhbSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91IHNhaWQ6DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPnNhY20gaXMsIGF0IGl0cyBjb3JlLCBwcmltYXJp bHkgaW50ZXJlc3RlZCBpbiBhc3Nlc3NpbmcgZW5kcG9pbnQgYXR0cmlidXRlcy4gJm5ic3A7VGhp cyBtZWFucyBleHByZXNzaW5nIHRoZSBkZXNpcmVkIGF0dHJpYnV0ZSB0byBjb2xsZWN0LCBjb2xs ZWN0aW5nIGl0LCBhbmQgZXZhbHVhdGluZyBpdCBhZ2FpbnN0IHNvbWUNCiBleHByZXNzZWQgZXhw ZWN0YXRpb24uICZuYnNwO1RoZSBhc3Nlc3NtZW50IHJlc3VsdCBpcyBwcm92aWRlZCBmb3IgZG93 bnN0cmVhbSB1c2UsIGlycmVzcGVjdGl2ZSBvZiB3aGF0IHRoYXQgdXNlIG1pZ2h0IGJlLiAmbmJz cDtBZGRpdGlvbmFsbHksIGNvbGxlY3Rpb24gY291bGQgYmUgdGhlIG9ubHkgcmVzdWx0cyBwcm92 aWRlZCAoaWYgbm8gZXZhbHVhdGlvbiBwaWVjZSBpcyBuZWVkZWQpLjxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhv dyBhcmUgdGhlIOKAnGRlc2lyZWQgYXR0cmlidXRlc+KAnSBleHByZXNzZWQgYnkgU0FDTT8gSG93 IGFyZSB0aGUg4oCcZXhwZWN0YXRpb27igJ0gYmVpbmcgc3BlY2lmaWVkPw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFua3MsIExpbmRhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSTJuc2YgW21haWx0bzppMm5zZi1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BZGFtIFcuIE1vbnR2aWxsZTxicj4N CjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWFyY2ggMjgsIDIwMTUgNzo0MSBBTTxicj4NCjxiPlRv OjwvYj4gTWVsaW5kYSBTaG9yZTxicj4NCjxiPkNjOjwvYj4gaTJuc2ZAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtJMm5zZl0gVGhlIGRlZmVuc2UgJ2Vjb3N5c3RlbScgcGFyYWRp Z208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXZpbmcg YSBjcm9zcy1ncm91cCB1bmRlcnN0YW5kaW5nIG9mIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBp Mm5zZiwgc2FjbSwgbWlsZSwgYW5kIGRvdHMgd291bGQgYmUgYmVuZWZpY2lhbC4gJm5ic3A7SeKA mW0gbGVzcyBmYW1pbGlhciB3aXRoIGkybnNmIGFuZCBkb3RzIChpbiB0aGUgZGV0YWlscykuJm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNl ZW1zIHRoYXQgbWlsZSwgaTJuc2YsIGFuZCBkb3RzIHdvdWxkIGFsbCBiZW5lZml0IGZyb20gc2Fj bSBpbiBzb21lIHdheSwgYXMgdGhleSBhcmUgbGFyZ2VseSBkb3duc3RyZWFtIGZyb20gdGhlIGNv cmUgcHJvYmxlbSBzYWNtIGludGVuZHMgdG8gc29sdmUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pMm5zZiBzZWVrcyB0byBleHBy ZXNzIGFuZCBldmFsdWF0ZSBuZXR3b3JrIHNlcnZpY2UgcmVsYXRlZCBpbmZvcm1hdGlvbiwgd2hp Y2ggd2lsbCB1bHRpbWF0ZWx5IG5lZWQgdG8gaWRlbnRpZnkgc3BlY2lmaWMgZW5kcG9pbnRzICh2 aXJ0dWFsIG9yIG90aGVyd2lzZSkgdG8gY29sbGVjdCBzcGVjaWZpYyBhdHRyaWJ1dGVzLCBldmFs dWF0ZSB0aGVtIGFnYWluc3Qgc29tZSBleHByZXNzZWQgZXhwZWN0YXRpb24sDQogdGhlbiBtYWtl IHNlbnNlIG9mIHRoYXQgYXQgdGhlIGkybnNmIGxldmVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5taWxlIGNvdWxkIGJlbmVmaXQgZnJvbSBz YWNtIGJ5IGxldmVyYWdpbmcgdGhlIGF0dHJpYnV0ZSBleHByZXNzaW9uIGFuZCBldmFsdWF0aW9u IGZvcm1hdHMuICZuYnNwO0FkZGl0aW9uYWxseSwgdGhlIOKAnGFkIGhvY+KAnSBleHBsb3JhdG9y eSB0b29scyBvZnRlbiBmYXZvcmVkIGR1cmluZyBpbmNpZGVudCByZXNwb25zZSBjb3VsZCB1c2Ug c2FjbSBhcyBhIG1lYW5zIG9mIHRoYXQgZXhwbG9yYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRvdHMgaXMgbXkgbGVhc3QgdW5kZXJz dG9vZCBkb21haW4sIGJ1dCBhZnRlciBzcGVha2luZyB3aXRoIEFuYSBIZWRhbnBpbmcgZm9yIGEg YnJpZWYgdGltZSwgaXQgc2VlbXMgdGhhdCBkb3RzIHdpbGwgaGF2ZSBzb21lIG5lZWQgdG8gZXhw cmVzcyBlbmRwb2ludCBhdHRyaWJ1dGVzLCBjb2xsZWN0IHZhbHVlcywgYW5kIGV2YWx1YXRlIHRo ZW0gYWdhaW5zdCBzb21lIGV4cGVjdGF0aW9uIGFzIHdlbGwuICZuYnNwO09ubHksDQogdGhpcyB3 aWxsIGJlIG1vcmUgb2YgYSDigJxyZWFsIHRpbWXigJ0gY2lyY3Vtc3RhbmNlIChJIHByZXN1bWUp LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B cyBCb2IgcG9pbnRlZCBvdXQsIHRoZXNlIGFyZSBhbGwgcGFydHMgb2YgYSB3aG9sZSAtIHRoZSDi gJxkZWZlbnNlIGVjb3N5c3RlbSBwYXJhZGlnbeKAnS4gJm5ic3A7IEFuZCwgd2hpbGUgZGVyaXZp bmcgYSBzcGVjaWZpYyB0YXhvbm9teSBjb3VsZCBiZSB1c2VmdWwsIGl04oCZcyBhbHJlYWR5IGRv bmUgaW4gYSB3YXkuICZuYnNwO1RoZSDigJxkZWZlbnNlIOKAmGVjb3N5c3RlbeKAmSBwYXJhZGln bSZxdW90OyBzZWVtcyB0byBtZSBsaWtlIGEgc3lub255bQ0KIGZvciDigJxzZWN1cml0eSBwcm9n cmFt4oCdLCBhbmQgdGhvc2UgYXJlIHdlbGwgY292ZXJlZC4gJm5ic3A7VGhpbmsgSVNPIDI3MDAw IHNlcmllcywgTklTVCA4MDAtNTMsIFBDSSBEU1MsIENPQklULCAyMCBDcml0aWNhbCBTZWN1cml0 eSBDb250cm9scywgYW5kIHRoZSBsaWtlLiAmbmJzcDtJbiBmYWN0LCBJIHVzZWQgYSBzaW1pbGFy IHBlcnNwZWN0aXZlIChJIGNhbGxlZCBpdCDigJxmcmFtZSBvZiByZWZlcmVuY2XigJ0pIGF0IGEg c2FjbSBCb0YgKGJhY2sgaW4gQXRsYW50YQ0KIGR1cmluZyBJRVRGIDg1IFsxXSkgdG8gZnJhbWUg dGhlIOKAnHNwYWNl4oCdIGluIHdoaWNoIHNhY20gcGxheXMuICZuYnNwO0kgdGhpbmsgbWlsZSAm bmJzcDssIGkybnNmLCBhbmQgZG90cyBhbGwgcGxheSBpbiB0aGlzIHNhbWUgc3BhY2UgKHNlZSB0 aGUgc2Vjb25kLCB0aGlyZCwgYW5kIGZvdXJ0aCBzbGlkZXMpLiAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBzZWVtcyBpbXBv cnRhbnQgaXMgdGhhdCB3ZSByZWNvZ25pemUgKGFuZCBuYW1lKSB0aGUgZGlmZmVyZW50IGJ1c2lu ZXNzIHByb2Nlc3NlcyB3ZSBhcmUgc3VwcG9ydGluZy4gJm5ic3A7VGhpcyBzaG91bGQgaGVscCB1 cyByZWNvZ25pemUgdGhlIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBvdXIgd29yay48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvdWdodHM/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFkYW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODUv c2xpZGVzL3NsaWRlcy04NS1zYWNtLTIucGRmIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy84NS9zbGlkZXMvc2xpZGVzLTg1LXNhY20tMi5wZGY8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAy NywgMjAxNSwgYXQgOTowMSBQTSwgTWVsaW5kYSBTaG9yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1l bGluZGEuc2hvcmVAZ21haWwuY29tIj5tZWxpbmRhLnNob3JlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gcmF0aGVyIHN1 cnByaXNlZCB0aGF0IG5vYm9keSBoYXMgYW5zd2VyZWQgdGhpcyE8YnI+DQo8YnI+DQpJIHRoaW5r IHRoaXMgaXMgYSB2ZXJ5IHJlYXNvbmFibGUgYXBwcm9hY2gsIHdpdGggdGhlPGJyPg0KY2F2ZWF0 IHRoYXQgd2hhdCdzIG5lZWRlZCAqaGVyZSogaXMgbm90IHNvIG11Y2ggYW4gYXJjaGl0ZWN0dXJl PGJyPg0KYnV0IGFuIGFjdHVhbCBwcm90b2NvbCBjb252ZXlpbmcgYWN0dWFsIGRhdGEgYmV0d2Vl biBhY3R1YWw8YnI+DQpuZXR3b3JrIGVsZW1lbnRzLiAmbmJzcDtUaGlzIG1heSBiZSB3aHkgb3Ro ZXIgbWlkZGxlYm94IHByb3RvY29sczxicj4NCiZsdDtyaW1zaG90Jmd0OyBoYXZlIGJlZW4gYWJs ZSB0byBtb3ZlIGZvcndhcmQsIGV2ZW4gd2hpbGUgYmVpbmc8YnI+DQpyZWR1bmRhbnQsIHdoaWxl IHRoaXMgZWZmb3J0IGhhcyBiZWVuIHN0dWNrLiAmbmJzcDtJdCBzZWVtcyB0bzxicj4NCm1lLCBi YXNlZCBvbiBkaXNjdXNzaW9ucyBkdXJpbmcgdGhlIHdlZWsgYW5kIG9uIGJvdGggdGhlPGJyPg0K aW5wdXQgdG8gYW5kIHRoZSBvdXRwdXQgZnJvbSB0aGUgZG90cyBCT0YsIHRoYXQgdGhlcmUnczxi cj4NCnN0aWxsIHJvb20gZm9yIGEgZ29vZCBiYWNrZW5kIHByb3RvY29sIHRvIGNvbnZleSByZXF1 ZXN0czxicj4NCnRvIHdoYXQgdXNlZCB0byBiZSBjYWxsZWQgcG9saWN5IGVuZm9yY2VtZW50IHBv aW50cyBiYXNlZDxicj4NCm9uIHRoZSBhY3RpdmUgdGhyZWF0IGRhdGEgYmVpbmcgc2hhcmVkIHRo cm91Z2ggYSBkb3RzLWxpa2UgbWVjaGFuaXNtLjxicj4NCkJ1dCB0aGF0J3MgYSB2ZXJ5IG5hcnJv dyBleGFtcGxlLjxicj4NCjxicj4NClNvLCBJIHRoaW5rIHRvIHRoZSBleHRlbnQgdGhhdCBhIHRh eG9ub215IGNhbiBoZWxwIHRoaXM8YnI+DQplZmZvcnQgZGV2ZWxvcCBhIG5hcnJvdyBmb2N1cywg aXQgd291bGQgYmUgYSB2ZXJ5IGhlbHBmdWw8YnI+DQp0aGluZyBpbmRlZWQuICZuYnNwO0J1dCBp dCdzIGdvdCB0byBiZSB2ZXJ5IGFwcGxpZWQgLSBJIGFtPGJyPg0Kc2tlcHRpY2FsIGFib3V0IHRo ZSB2YWx1ZSBvZiBoaWdoLWxldmVsIGFyY2hpdGVjdHVyZXMgaW48YnI+DQp0aGUgSUVURi48YnI+ DQo8YnI+DQpNZWxpbmRhPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpJMm5zZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86STJuc2ZAaWV0Zi5vcmciPkkybnNmQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJuc2YiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJuc2Y8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657BFFB52dfweml701chm_-- From nobody Thu Apr 2 04:41:54 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD1E1B2C7A for ; Thu, 2 Apr 2015 04:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 zSizfOwHIu0l for ; Thu, 2 Apr 2015 04:41:49 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::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 4AA851B2C78 for ; Thu, 2 Apr 2015 04:41:48 -0700 (PDT) Received: by pdea3 with SMTP id a3so35794970pde.3 for ; Thu, 02 Apr 2015 04:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4fQ0LbRsO20YyFWwmyJEstC5/VswTH5+2z0A+5WBGLE=; b=IuT9FNHLCv2BtrHk7eaHHLJaxkosLu9+i8EEXjeR1Q1BYeNX6y3+VyXOTvLZTDSfd0 Y/tolbG/SbLrWK4o5lszo/Gb3qslJcJkNmUi5ZZvqArb1O9On209/cAV492rOU38JDUs aMvpIuXOusyIZtpF1pj/LZmWxyyn9M49fCwjL6z3Fd4TlyWJFNQ1qaDM04v2Buhpoo8b wm/Kz+ju+3mhpXe0KUxXiVRHywxHloKBhOtzjWnIlonh2ouYO3EiSnBgTmvD+W9NI5Qg NBjoZIr+qatUq5he6koarb28BlBHGaWfAsZmfXMLHy1f9Bq8RIr4nxzytQDNL1nM1Mtu YsMA== X-Received: by 10.66.228.104 with SMTP id sh8mr85210778pac.63.1427974907945; Thu, 02 Apr 2015 04:41:47 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:3927:f888:4490:4af7? ([2602:306:3406:4f00:3927:f888:4490:4af7]) by mx.google.com with ESMTPSA id jc9sm4976189pbd.54.2015.04.02.04.41.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 04:41:46 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_547EA9C0-2E14-4825-A9D5-B11AD065AD99" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Adam W. Montville" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657BFFB52@dfweml701-chm> Date: Thu, 2 Apr 2015 06:41:43 -0500 Message-Id: References: <5512F1ED.8020104@htt-consult.com> <55160B74.1010009@gmail.com> <032CF466-C78E-46C7-A171-5176555A97DA@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657BFFB52@dfweml701-chm> To: Linda Dunbar X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "i2nsf@ietf.org" , Melinda Shore Subject: Re: [I2nsf] The defense 'ecosystem' paradigm X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 11:41:52 -0000 --Apple-Mail=_547EA9C0-2E14-4825-A9D5-B11AD065AD99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 1, 2015, at 4:15 PM, Linda Dunbar = wrote: >=20 > Adam, > =20 > You said: > sacm is, at its core, primarily interested in assessing endpoint = attributes. This means expressing the desired attribute to collect, = collecting it, and evaluating it against some expressed expectation. = The assessment result is provided for downstream use, irrespective of = what that use might be. Additionally, collection could be the only = results provided (if no evaluation piece is needed). > =20 > How are the =E2=80=9Cdesired attributes=E2=80=9D expressed by SACM? = How are the =E2=80=9Cexpectation=E2=80=9D being specified? At this point we are working on an information model [1] and have not = yet arrived at data models. I would anticipate several data models to = exist, depending on the source of the data being collected. [1] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ = = (note that this will almost certainly updated between now and IETF 93). = Intermediate work can be found here: = https://github.com/sacmwg/draft-ietf-sacm-information-model = ). > =20 > Thanks, Linda > =20 > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Adam W. = Montville > Sent: Saturday, March 28, 2015 7:41 AM > To: Melinda Shore > Cc: i2nsf@ietf.org > Subject: Re: [I2nsf] The defense 'ecosystem' paradigm > =20 > Having a cross-group understanding of the relationship between i2nsf, = sacm, mile, and dots would be beneficial. I=E2=80=99m less familiar = with i2nsf and dots (in the details).=20 > =20 > =20 > It seems that mile, i2nsf, and dots would all benefit from sacm in = some way, as they are largely downstream from the core problem sacm = intends to solve. =20 > =20 > i2nsf seeks to express and evaluate network service related = information, which will ultimately need to identify specific endpoints = (virtual or otherwise) to collect specific attributes, evaluate them = against some expressed expectation, then make sense of that at the i2nsf = level. > =20 > mile could benefit from sacm by leveraging the attribute expression = and evaluation formats. Additionally, the =E2=80=9Cad hoc=E2=80=9D = exploratory tools often favored during incident response could use sacm = as a means of that exploration. > =20 > dots is my least understood domain, but after speaking with Ana = Hedanping for a brief time, it seems that dots will have some need to = express endpoint attributes, collect values, and evaluate them against = some expectation as well. Only, this will be more of a =E2=80=9Creal = time=E2=80=9D circumstance (I presume). > =20 > As Bob pointed out, these are all parts of a whole - the =E2=80=9Cdefens= e ecosystem paradigm=E2=80=9D. And, while deriving a specific taxonomy = could be useful, it=E2=80=99s already done in a way. The =E2=80=9Cdefense= =E2=80=98ecosystem=E2=80=99 paradigm" seems to me like a synonym for = =E2=80=9Csecurity program=E2=80=9D, and those are well covered. Think = ISO 27000 series, NIST 800-53, PCI DSS, COBIT, 20 Critical Security = Controls, and the like. In fact, I used a similar perspective (I called = it =E2=80=9Cframe of reference=E2=80=9D) at a sacm BoF (back in Atlanta = during IETF 85 [1]) to frame the =E2=80=9Cspace=E2=80=9D in which sacm = plays. I think mile , i2nsf, and dots all play in this same space (see = the second, third, and fourth slides). =20 > =20 > What seems important is that we recognize (and name) the different = business processes we are supporting. This should help us recognize the = relationships between our work. > =20 > Thoughts? > =20 > Regards, > =20 > Adam > =20 > [1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf = > =20 > =20 > =20 > On Mar 27, 2015, at 9:01 PM, Melinda Shore > wrote: > =20 > I'm rather surprised that nobody has answered this! >=20 > I think this is a very reasonable approach, with the > caveat that what's needed *here* is not so much an architecture > but an actual protocol conveying actual data between actual > network elements. This may be why other middlebox protocols > have been able to move forward, even while being > redundant, while this effort has been stuck. It seems to > me, based on discussions during the week and on both the > input to and the output from the dots BOF, that there's > still room for a good backend protocol to convey requests > to what used to be called policy enforcement points based > on the active threat data being shared through a dots-like mechanism. > But that's a very narrow example. >=20 > So, I think to the extent that a taxonomy can help this > effort develop a narrow focus, it would be a very helpful > thing indeed. But it's got to be very applied - I am > skeptical about the value of high-level architectures in > the IETF. >=20 > Melinda >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf = --Apple-Mail=_547EA9C0-2E14-4825-A9D5-B11AD065AD99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 1, 2015, at 4:15 PM, Linda Dunbar = <linda.dunbar@huawei.com> wrote:

Adam,
 
You said:
sacm is, at its core, primarily interested in assessing = endpoint attributes.  This means expressing the desired attribute = to collect, collecting it, and evaluating it against some expressed = expectation.  The assessment result is provided for downstream use, = irrespective of what that use might be.  Additionally, collection = could be the only results provided (if no evaluation piece is = needed).
 
How= are the =E2=80=9Cdesired attributes=E2=80=9D expressed by SACM? How are = the =E2=80=9Cexpectation=E2=80=9D being = specified?


At this point we are = working on an information model [1] and have not yet arrived at data = models.  I would anticipate several data models to exist, depending = on the source of the data being collected.


[1] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-mo= del/ (note that this will almost certainly updated between now = and IETF 93).  Intermediate work can be found here: https://github.com/sacmwg/draft-ietf-sacm-information-model= ).



 
Thanks, Linda
 
From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf = Of Adam W. = Montville
Sent: Saturday, March 28, 2015 = 7:41 AM
To: Melinda Shore
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] The defense = 'ecosystem' paradigm
 
Having a cross-group understanding of the = relationship between i2nsf, sacm, mile, and dots would be beneficial. =  I=E2=80=99m less familiar with i2nsf and dots (in the = details). 
 
 
It seems that mile, = i2nsf, and dots would all benefit from sacm in some way, as they are = largely downstream from the core problem sacm intends to solve. =  
 
i2nsf seeks to express and evaluate network service = related information, which will ultimately need to identify specific = endpoints (virtual or otherwise) to collect specific attributes, = evaluate them against some expressed expectation, then make sense of = that at the i2nsf level.
 
mile could benefit from sacm by leveraging the = attribute expression and evaluation formats.  Additionally, the = =E2=80=9Cad hoc=E2=80=9D exploratory tools often favored during incident = response could use sacm as a means of that exploration.
 
dots is my least understood domain, but = after speaking with Ana Hedanping for a brief time, it seems that dots = will have some need to express endpoint attributes, collect values, and = evaluate them against some expectation as well.  Only, this will be = more of a =E2=80=9Creal time=E2=80=9D circumstance (I presume).
 
As Bob pointed out, these are all parts = of a whole - the =E2=80=9Cdefense ecosystem paradigm=E2=80=9D.   = And, while deriving a specific taxonomy could be useful, it=E2=80=99s = already done in a way.  The =E2=80=9Cdefense =E2=80=98ecosystem=E2=80= =99 paradigm" seems to me like a synonym for =E2=80=9Csecurity = program=E2=80=9D, and those are well covered.  Think ISO 27000 = series, NIST 800-53, PCI DSS, COBIT, 20 Critical Security Controls, and = the like.  In fact, I used a similar perspective (I called it = =E2=80=9Cframe of reference=E2=80=9D) at a sacm BoF (back in Atlanta = during IETF 85 [1]) to frame the =E2=80=9Cspace=E2=80=9D in which sacm = plays.  I think mile  , i2nsf, and dots all play in this same = space (see the second, third, and fourth slides).  
 
What seems important is that we recognize = (and name) the different business processes we are supporting. =  This should help us recognize the relationships between our = work.
 
Thoughts?
 
Regards,
 
Adam
 
[1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf=
 
 
 
On Mar 27, 2015, at = 9:01 PM, Melinda Shore <melinda.shore@gmail.com> wrote:
 
I'm rather surprised that nobody has answered this!

I think this is a very reasonable approach, = with the
caveat that what's needed *here* is not so much = an architecture
but an actual protocol conveying actual = data between actual
network elements.  This may be = why other middlebox protocols
<rimshot> have been = able to move forward, even while being
redundant, while = this effort has been stuck.  It seems to
me, based on = discussions during the week and on both the
input to and = the output from the dots BOF, that there's
still room for = a good backend protocol to convey requests
to what used to = be called policy enforcement points based
on the active = threat data being shared through a dots-like mechanism.
But = that's a very narrow example.

So, I think = to the extent that a taxonomy can help this
effort develop = a narrow focus, it would be a very helpful
thing indeed. =  But it's got to be very applied - I am
skeptical = about the value of high-level architectures in
the = IETF.

Melinda

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

= --Apple-Mail=_547EA9C0-2E14-4825-A9D5-B11AD065AD99-- From nobody Sat Apr 4 08:54:27 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A401B2BDE for ; Sat, 4 Apr 2015 08:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 eVjk_GZn_JIc for ; Sat, 4 Apr 2015 08:54:22 -0700 (PDT) Received: from mxe01.gs.com (mxe01.gs.com [204.4.178.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19011A9090 for ; Sat, 4 Apr 2015 08:54:21 -0700 (PDT) Received: from pps.filterd (gsppacdp01sd.idz.gs.com [127.0.0.1]) by gsppacdp01sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t34FnwVa021535; Sat, 4 Apr 2015 11:54:18 -0400 Received: from gsppabdp05nd.inz.gs.com ([10.204.43.244]) by gsppacdp01sd.idz.gs.com with ESMTP id 1tht7ywqc4-1; Sat, 04 Apr 2015 11:54:18 -0400 Received: from pps.filterd (gsppabdp05nd.inz.gs.com [127.0.0.1]) by gsppabdp05nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t34FoKZf007301; Sat, 4 Apr 2015 11:54:18 -0400 Received: from gshcbdp03ex.firmwide.corp.gs.com (gshcbdp03ex.firmwide.corp.gs.com [10.135.172.6]) by gsppabdp05nd.inz.gs.com with ESMTP id 1thvcpavfa-1; Sat, 04 Apr 2015 11:54:18 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp03ex.firmwide.corp.gs.com ([10.135.172.6]) with mapi; Sat, 4 Apr 2015 11:54:17 -0400 From: "Zarny, Myo" To: "'Edward Lopez'" , "'i2nsf@ietf.org'" Date: Sat, 4 Apr 2015 11:54:16 -0400 Thread-Topic: I-D on a 'Packet-Based Paradigm For Interfaces to NSFs' Thread-Index: AQHQZxqcvBHK9sEPskOI5Hr01iT/EZ08/aZw Message-ID: References: <4FC19FE9-20C0-4188-AD37-76DC8737C649@fortinet.com> In-Reply-To: <4FC19FE9-20C0-4188-AD37-76DC8737C649@fortinet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C23071E887DE7GSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-04_02:2015-04-03,2015-04-04,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-04_02:2015-04-03,2015-04-04,1970-01-01 signatures=0 Archived-At: Subject: Re: [I2nsf] I-D on a 'Packet-Based Paradigm For Interfaces to NSFs' X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 15:54:26 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C23071E887DE7GSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ed, Sorry, I couldn't make it to Dallas. But here's my feedback. * I like how you broke up the problem set into three areas: (1) (de= vice/network) configuration, (2) signaling, and (3) (policy and object) pro= visioning as you call them. * I also quite like how the "packet-based" approach using a generic= "subject.object.function.action" (SOFA) format allows us to get away from = getting mired in specific definitions of NSFs. Seems like a very extensible= approach. A few questions/comments/suggestions: * Given that the approach covers just the service provisioning aspe= ct, do you have a position as to whether or not the I2NSF charter should co= ver configuration and signaling? * Do I understand correctly that the approach requires the callers = of the I2NSF Provisioning API to provide their intent? If so, you might wan= t to add that the entity receiving the request in a SOFA format MUST be abl= e to interpret the request, and map it to southbound NSFs. (And I feel like= it's even more than that. The entity needs to be able to map signaling req= uests to the appropriate southbound NSFs as well. That is, does a SOFA appr= oach for provisioning necessarily require intent-based APIs for configurati= on and signaling as well?) * This leads to my next point: It'll be very helpful for readers to= see a couple of examples of how the SOFA approach could be carried out in = practice. In general, the approach definitely is neat-perhaps, too neat!? I= 'd like to see some real world examples. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Edward Lopez Sent: 25 March 2015 12:42 PM To: i2nsf@ietf.org Subject: [I2nsf] I-D on a 'Packet-Based Paradigm For Interfaces to NSFs' Team, Sorry for the lateness of this relative to our meeting this evening. I jus= t posted an initial I-D on the concept of using a packet-based paradigm in = developing a provisioning interface to NSFs. It is located at: https://datatracker.ietf.org/doc/draft-lopez-i2nsf-packet/ The idea is that rather than attempting to define provisioning interfaces b= ased on the capabilities of classes of NSFs, a better method may be to cons= ider how any given NSF will process received packets. Such a provisioning = interface would use match values based on packet data, as well as contextua= l information associated with packets. It also considers the idea that functions and egress actions may not be eas= ily defined, since the functional capabilities of NSFs are not easily defin= ed, especially from a standards basis. It would be far easier for us to de= fine a standards-based function, such as OSPF on a router, than to define a= vendor-specific function, such as used by flow-match functions like IPS, w= here even signature formats are implementation-specific. This results in t= he need for a capabilities exchange between NSFs and provisioning applicati= ons. This draft is not intended to be a specific implementation, but rather a lo= gical argument relative to the formation of the scope of our WG charter. Q= uestions and comments are appreciated Thanks! Ed Lopez - Fortinet ________________________________ *** Please note that this message and any attachments may contain confident= ial and proprietary material and information and are intended only for the = use of the intended recipient(s). If you are not the intended recipient, yo= u are hereby notified that any review, use, disclosure, dissemination, dist= ribution or copying of this message and any attachments is strictly prohibi= ted. If you have received this email in error, please immediately notify th= e sender and destroy this e-mail and any attachments and all copies, whethe= r electronic or printed. Please also note that any views, opinions, conclus= ions or commitments expressed in this message are those of the individual s= ender and do not necessarily reflect the views of Fortinet, Inc., its affil= iates, and emails are not binding on Fortinet and only a writing manually s= igned by Fortinet's General Counsel can be a binding commitment of Fortinet= to Fortinet's customers or partners. Thank you. *** ________________________________ --_000_A3233753A4B65F43BCA1B64DA99A9C23071E887DE7GSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ed,

 

=

Sorry, I couldn’t make it to Dallas. But = here’s my feedback.

<= span style=3D'font-size:11.0pt;font-family:Symbol;color:#1F497D'>·=          I like how you broke up the problem set into three areas: (1) (= device/network) configuration, (2) signaling, and (3) (policy and object) p= rovisioning as you call them.

·         <= ![endif]>I also quite like how the “packet-based” approa= ch using a generic “subject.object.function.action” (SOFA) form= at allows us to get away from getting mired in specific definitions of NSFs= . Seems like a very extensible approach.

 

A fe= w questions/comments/suggestions:

·         Given that the approach covers just the service provisi= oning aspect, do you have a position as to whether or not the I2NSF charter= should cover configuration and signaling?

·         Do I understand correctly that the approach re= quires the callers of the I2NSF Provisioning API to provide their intent? I= f so, you might want to add that the entity receiving the request in a SOFA= format MUST be able to interpret the request, and map it to southbound NSF= s. (And I feel like it’s even more than that. The entity needs to be = able to map signaling requests to the appropriate southbound NSFs as well. = That is, does a SOFA approach for provisioning necessarily require intent-b= ased APIs for configuration and signaling as well?)

<= p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l2 level1 l= fo2'>·        = This leads to my next point: It̵= 7;ll be very helpful for readers to see a couple of examples of how the SOF= A approach could be carried out in practice. In general, the approach defin= itely is neat—perhaps, too neat!? I’d like to see some r= eal world examples.

 

Myo

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>From: I2nsf [mailto:i2nsf-boun= ces@ietf.org] On Behalf Of Edward Lopez
Sent: 25 March 201= 5 12:42 PM
To: i2nsf@ietf.org
Subject: [I2nsf] I-D on a= 'Packet-Based Paradigm For Interfaces to NSFs'

=

 

=

Team,

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

<= div>

Sorry for the lateness = of this relative to our meeting this evening.  I just posted an initia= l I-D on the concept of using a packet-based paradigm in developing a provi= sioning interface to NSFs.  It is located at:

 

 

The idea is that rather than attem= pting to define provisioning interfaces based on the capabilities of classe= s of NSFs, a better method may be to consider how any given NSF will proces= s received packets.  Such a provisioning interface would use match val= ues based on packet data, as well as contextual information associated with= packets.

 

It also considers the idea that functions and egress actions m= ay not be easily defined, since the functional capabilities of NSFs are not= easily defined, especially from a standards basis.  It would be far e= asier for us to define a standards-based function, such as OSPF on a router= , than to define a vendor-specific function, such as used by flow-match fun= ctions like IPS, where even signature formats are implementation-specific. =  This results in the need for a capabilities exchange between NSFs and= provisioning applications.

 

This draft is not intended to be a specific = implementation, but rather a logical argument relative to the formation of = the scope of our WG charter.  Questions and comments are appreciated

 

Thanks!

 

Ed Lopez - Fortinet

 

 

*** Please note that this me= ssage and any attachments may contain confidential and proprietary material= and information and are intended only for the use of the intended recipien= t(s). If you are not the intended recipient, you are hereby notified that a= ny review, use, disclosure, dissemination, distribution or copying of this = message and any attachments is strictly prohibited. If you have received th= is email in error, please immediately notify the sender and destroy this e-= mail and any attachments and all copies, whether electronic or printed. Ple= ase also note that any views, opinions, conclusions or commitments expresse= d in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not bi= nding on Fortinet and only a writing manually signed by Fortinet's General = Counsel can be a binding commitment of Fortinet to Fortinet's customers or = partners. Thank you. ***

= --_000_A3233753A4B65F43BCA1B64DA99A9C23071E887DE7GSCMAMP19EXfi_-- From nobody Wed Apr 8 08:32:20 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AB11B32A7 for ; Wed, 8 Apr 2015 08:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 o8VXGrWIj1Cz for ; Wed, 8 Apr 2015 08:32:17 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (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 1B6101B3274 for ; Wed, 8 Apr 2015 08:32:15 -0700 (PDT) Received: by qgdq107 with SMTP id q107so4912049qgd.2 for ; Wed, 08 Apr 2015 08:32:14 -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:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=sgjrFGXkNXrXRxfN8TJVIILct/T1Ny3IsrqD7VPKJpU=; b=j/BTB4m3O00pYKEKcM7s94B0Eplvc0q9IEFilTtTXmcmdUUmpRh0Tv2DpWvSbly7ma 2M+YlSJkbEmHIgIj8dtLEcnTzFG57UCBRh5d7NCEzYF9tKnmPLX62fENo2WCxRkjMZpA DA9peLmG8xLfynq+ZIR22seEbFitXdoVoZe2QgBPNziSe7REbmBwaXtJud4nvMba24fN rRIjyHr/1/rbPI5AgCgGsY8vKQiVyCXhVCIemS1fmXIRU3lTANvcSMDj46MH16HMEJt4 h0R3dGac/rHONCa+rQMPXeDMG7jkZwboKUGjw4fWQIyblQl5XzisgJoe6y1scI+0hnHp 097Q== X-Gm-Message-State: ALoCoQmo3/DfMLcPhsWL4SgeIYeO8+6DiIU1utN9lpqBtGjSjQ9j8+H7QrIn9LxcnLww5ICl77PcwzADBB218PSPQaYvCbMkOg== X-Received: by 10.140.47.1 with SMTP id l1mr29781517qga.44.1428507134317; Wed, 08 Apr 2015 08:32:14 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id y7sm1993386qci.3.2015.04.08.08.32.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 08 Apr 2015 08:32:14 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t38FWDS5021224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Apr 2015 11:32:13 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 8 Apr 2015 11:32:13 -0400 From: "Teague, Nik" To: Linda Dunbar , "dots@ietf.org" Thread-Topic: scope Thread-Index: AQHQa8ImfNQMx27PokCfZQ+6rvOaCp04aHXggAs2MwA= Date: Wed, 8 Apr 2015 15:32:12 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657BFF946@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657BFF946@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <59ABE2FF5274E242B97313182603819B@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] scope X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 15:32:18 -0000 Hi, On 01/04/2015 13:31, "Linda Dunbar" wrote: >Nik, > >=20 >Can you elaborate a bit more on the =B3peacetime provisioning channel=B2? > >=20 >What kind of =B3configuration data=B2 is exchanged on over this channel? W= hat >protocol? Is it NETCONF? The term peacetime is somewhat fuzzy and I keep trying out variations that feel/describe better. The intent of the channel is the exchange of information that relates to the service setup/provisioning and not to the actual signaling - This could be authentication, key/token exchanges, whitelist, megaproxy lists etc. In addition this could be the describing of capabilities (some devices/applications may only monitor while others may have a mitigation capability). As far as the protocol - I had thought JSON RPC API over HTTPS - its reasonably light to implement (anything with access to cURL can take advantage of it. It also means little to no re-tooling across many DDoS mitigation platforms which may be *nix based at their core. > >=20 >In parallel to DOTS, there is the I2NSF initiative intended for >specifying the security policies to security functions (primarily the >flow based security functions). > >https://datatracker.ietf.org/doc/draft-lopez-i2nsf-packet/ has identified >three types interfaces to security functions: > >=80 =20 >Configuration >=AD =20 >Device configuration >=AD =20 >Network configuration >=80 =20 >Signaling >=AD =20 >Status >=AD =20 >Counters >=AD =20 >Queries >=AD =20 >Alerts >=80 =20 >Provisioning >=AD =20 >Capabilities >=AD =20 >Policy >=AD =20 >Object Configuration > >=20 >=20 >I2NSF will focus on the 3rd bullet, i.e. the Provisioning part. > >=20 >Just want to see if the provisioning you mentioned could provide the >synergy to I2NSF=B9s provisioning. >=20 >Thanks, > >Linda I would suggest that the device provisioning is already assumed to have happened and the provisioning we discuss here relates to the service. I think there is some potential overlap (filter lists of whatever type) and its worth investigating and identifying where this occurs and what to leverage in that event. Thanks, -Nik From nobody Fri Apr 10 09:39:38 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E981ACE96 for ; Fri, 10 Apr 2015 09:39:37 -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, HTML_MESSAGE=0.001, 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 BBDnQ5g8meSn for ; Fri, 10 Apr 2015 09:39:36 -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 ED1921AC3CD for ; Fri, 10 Apr 2015 09:39:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUS12046; Fri, 10 Apr 2015 16:39:34 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Apr 2015 17:39:33 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Fri, 10 Apr 2015 09:39:20 -0700 From: Linda Dunbar To: "'Kathleen Moriarty'" , "jlinn@rsasecurity.com" Thread-Topic: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side Thread-Index: AdBzrORuLVYvhVovTKOih+zc6h5VvQ== Date: Fri, 10 Apr 2015 16:39:21 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C04685@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.86] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C04685dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" Subject: [I2nsf] inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:39:37 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C04685dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kathleen, I2NSF has two layers of interfaces: - Security policies interface towards client side (between clients= and security service providers) - Security policies at functional layer (between Security Controll= er and individual functions). I noticed that IETF had work on Generic Security Service APIs (RFC2078, RFC= 2743, RFC2744, RFC 4752, RFC5554). Is it an active working group? We are in= vestigating the feasibility of using GSSAPIs for the I2NSF Interface toward= s client Layer. But need to study the pros-cons of GSSAPI. Do you know much of GSSAPIs? If not, can you recommend someone else who kno= w more? Thank you very much. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C04685dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kathleen,

I2NSF has two layers of interfaces:

-          Security policies interface towards= client side (between clients and security service providers)

-          Security policies at functional lay= er (between Security Controller and individual functions).

I noticed that IETF had work on Generic Security Service APIs (RFC= 2078, RFC2743, RFC2744, RFC 4752, RFC5554). Is it an active working group? = We are investigating the feasibility of using GSSAPIs for the I2NSF Interface towards client Layer. But need to= study the pros-cons of GSSAPI.

Do you know much of GSSAPIs? If not, can you recommend someone els= e who know more?

Thank you very much.

Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C04685dfweml701chm_-- From nobody Fri Apr 10 11:28:22 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED911B2D39 for ; Fri, 10 Apr 2015 11:28: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 aErBP3O7nY-b for ; Fri, 10 Apr 2015 11:28:20 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 72A4C1B2D2A for ; Fri, 10 Apr 2015 11:28:20 -0700 (PDT) Received: by qkhg7 with SMTP id g7so40440087qkh.2 for ; Fri, 10 Apr 2015 11:28:19 -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=Qn5BUDG2Rh5+YceYuvAF9u1OSDgetXJZvfrxZUH5Qqc=; b=nTVkfAohRqZaXqjSVgYHNL3W1gm0f69DuUH0rQAvN/C+bntt/fkfghj/XiIZBBc4ZE B/p1fSFxXk2+BFzcd1Y9r4ZqSBEhWdwrLptVjmJQvyTowd9BMjY63ZbVRAKl7vfYjaK4 tXjTj3k0aTvoYHsgoqO66exoyqo7C0O0GJo+FFQFqCEzIjsAj7SdbiRM1UaV1QpypRTc u98FJi+UfFeFyhLR5fbURJrnHIKVeezjMpMnNBx+2R9Zm8/edMvldU7auTzAsF2aahxD 2rwImXaz36HUKC0Ir/6i24+D3E61R20xALynJ4K1pcFimcuZZUpUo7bQ5AmtknZE8Hol nnrw== X-Received: by 10.55.31.168 with SMTP id n40mr5804645qkh.56.1428690499805; Fri, 10 Apr 2015 11:28:19 -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 b74sm2167523qhc.28.2015.04.10.11.28.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Apr 2015 11:28:18 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-FBADC730-2BF7-4E85-8282-FA0A01F9D074 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C04685@dfweml701-chm> Date: Fri, 10 Apr 2015 14:28:17 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F657C04685@dfweml701-chm> To: Linda Dunbar Archived-At: Cc: "i2nsf@ietf.org" , Sam Hartman Subject: Re: [I2nsf] inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 18:28:22 -0000 --Apple-Mail-FBADC730-2BF7-4E85-8282-FA0A01F9D074 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Linda, I'm pretty sure ABFab uses the GSS-API as does Kitten, so Sam may be a good p= erson to ask. John Linn has a different email address. If you have a question for him tha= t Sam can't help with, I can reach out to John and see if I can add him to t= he thread with an email he's okay using on list. Thanks, Kathleen=20 Sent from my iPhone > On Apr 10, 2015, at 12:39 PM, Linda Dunbar wrote= : >=20 > Kathleen, > I2NSF has two layers of interfaces: > - Security policies interface towards client side (between client= s and security service providers) >=20 > - Security policies at functional layer (between Security Control= ler and individual functions). >=20 > I noticed that IETF had work on Generic Security Service APIs (RFC2078, RFC= 2743, RFC2744, RFC 4752, RFC5554). Is it an active working group? We are inv= estigating the feasibility of using GSSAPIs for the I2NSF Interface towards c= lient Layer. But need to study the pros-cons of GSSAPI. > Do you know much of GSSAPIs? If not, can you recommend someone else who kn= ow more? > Thank you very much. > Linda Dunbar > =20 --Apple-Mail-FBADC730-2BF7-4E85-8282-FA0A01F9D074 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Linda,

I'm pretty sure ABFab uses the GSS-API as does Kitten, so Sam may be a good person to ask.

John Linn has a different email address.  If you have a question for him that Sam can't help with, I can reach out to John and see if I can add him to the thread with an email he's okay using on list.

Thanks,
Kathleen 


Sent from my iPhone

On Apr 10, 2015, at 12:39 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

Kathleen,

I2NSF has two layers of interfaces:

-          Security policies interface towards client side (between clients and security service providers)

-          Security policies at functional layer (between Security Controller and individual functions).

I noticed that IETF had work on Generic Security Service APIs (RFC2078, RFC2743, RFC2744, RFC 4752, RFC5554). Is it an active working group? We are investigating the feasibility of using GSSAPIs for the I2NSF Interface towards client Layer. But need to study the pros-cons of GSSAPI.

Do you know much of GSSAPIs? If not, can you recommend someone else who know more?

Thank you very much.

Linda Dunbar

 

--Apple-Mail-FBADC730-2BF7-4E85-8282-FA0A01F9D074-- From nobody Wed Apr 15 11:26:53 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C661A00B8 for ; Wed, 15 Apr 2015 11:09:04 -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 rXAUC1mzCzT5 for ; Wed, 15 Apr 2015 11:08:59 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202CF1A00C7 for ; Wed, 15 Apr 2015 11:08:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 1F7D3206AD; Wed, 15 Apr 2015 14:08:35 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tWbtmYPdgnY; Wed, 15 Apr 2015 14:08:35 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 15 Apr 2015 14:08:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4382081C51; Wed, 15 Apr 2015 14:08:56 -0400 (EDT) From: Sam Hartman To: Kathleen Moriarty References: <4A95BA014132FF49AE685FAB4B9F17F657C04685@dfweml701-chm> Date: Wed, 15 Apr 2015 14:08:56 -0400 In-Reply-To: (Kathleen Moriarty's message of "Fri, 10 Apr 2015 14:28:17 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Wed, 15 Apr 2015 11:26:52 -0700 Cc: "i2nsf@ietf.org" , Linda Dunbar Subject: Re: [I2nsf] inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 18:09:04 -0000 How do the security requirements of the interface between the client and I2SF differ from typical client-server applications? That is, how do your security requirements differ from LDAP, ssh, and IMAP? --Sam From nobody Wed Apr 15 20:57:18 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088601B2F45 for ; Wed, 15 Apr 2015 20:57:18 -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, HTML_MESSAGE=0.001, 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 yDJSzUzusCs6 for ; Wed, 15 Apr 2015 20:57:16 -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 86D9B1B2F44 for ; Wed, 15 Apr 2015 20:57:15 -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 BRL72993; Thu, 16 Apr 2015 03:57:14 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Apr 2015 04:57:13 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Wed, 15 Apr 2015 20:57:02 -0700 From: Linda Dunbar To: Sam Hartman , Kathleen Moriarty Thread-Topic: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side Thread-Index: AQHQd6hlr5hqvFOj7UKRHY72wWKmlp1PACZA Date: Thu, 16 Apr 2015 03:57:01 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C06807@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C04685@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.98] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C06807dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 03:57:18 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C06807dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premise but instead hosted in service provid= er domain, to establish how to communicate desired security policies to NSF= and how to get performance data or report out of NSF. Past: customers own security devices, manage them directly, all security po= licies are supported by single device. Features are locked in Future (and now): security functions are distributed across networks, some are at custo= mer premises, some are hosted in service provider premises, some are accomp= lished by a collection of security functions. Not all functions are equal The Problems: Customers don't own actual security devices anymore Customers need to have their security policies supported by a collect= ion of security functions in both their own and security service providers'= premises. Customers need assurance of their specified security policies are pro= perly enforced by the security functions in the provider domain. Without standard interfaces to Security Functions, Service Providers = can't build proper management system to manage many types of security func= tions from different vendors. Linda -----Original Message----- From: Sam Hartman [mailto:hartmans@painless-security.com] Sent: Wednesday, April 15, 2015 1:09 PM To: Kathleen Moriarty Cc: Linda Dunbar; i2nsf@ietf.org Subject: Re: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Int= erface towards client side How do the security requirements of the interface between the client and I2= SF differ from typical client-server applications? That is, how do your security requirements differ from LDAP, ssh, and IMAP? --Sam --_000_4A95BA014132FF49AE685FAB4B9F17F657C06807dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The ultimate goal of I2NSF is to enable enterprises to utilize securit= y functions not hosted on their own premise but instead hosted in service p= rovider domain, to establish how to communicate desired security policies t= o NSF and how to get performance data or report out of NSF.
 
Past:
customers own security devices, manage th= em directly, all security policies are supported by single device. Features= are locked in
 
Future (and now):
security functions are distributed across= networks, some are at customer premises, some are hosted in service provid= er premises, some are accomplished by a collection of security functions. N= ot all functions are equal
 
 
The Problems:
Customers don’t own actual security= devices anymore
Customers need to have their security pol= icies supported by a collection of security functions in both their own and= security service providers’ premises.
Customers need assurance of their specifi= ed security policies are properly enforced by the security functions in the= provider domain.
Without standard interfaces to Security F= unctions, Service Providers can’t build proper  management syste= m to manage many types of security functions from different vendors.
 
 
Linda
 
-----Original Message-----
From: Sam Hartman [mailto= :hartmans@painless-security.com]
Sent: Wednesday, April 15, 2015 1:09 PM
To: Kathleen Moriarty
Cc: Linda Dunbar; i2nsf@ietf.org
Subject: Re: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Int= erface towards client side
 
How do the security requirements of the interface between the client a= nd I2SF differ from typical client-server applications?
That is, how do your security requirements differ from LDAP, ssh, and = IMAP?
 
--Sam
 
 --_000_4A95BA014132FF49AE685FAB4B9F17F657C06807dfweml701chm_-- From nobody Thu Apr 16 06:26:39 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572801A8F50 for ; Thu, 16 Apr 2015 06:26: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, 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 rHE57u66Swcq for ; Thu, 16 Apr 2015 06:26:36 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87191A8F3B for ; Thu, 16 Apr 2015 06:26:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 4E231206A7; Thu, 16 Apr 2015 09:26:10 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uthN5fG7xbgU; Thu, 16 Apr 2015 09:26:10 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 16 Apr 2015 09:26:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E19878169B; Thu, 16 Apr 2015 09:26:33 -0400 (EDT) From: Sam Hartman To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F657C04685@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C06807@dfweml701-chm> Date: Thu, 16 Apr 2015 09:26:33 -0400 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C06807@dfweml701-chm> (Linda Dunbar's message of "Thu, 16 Apr 2015 03:57:01 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty Subject: Re: [I2nsf] inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 13:26:37 -0000 Linda, I'm confused and frustrated when I read your message because I don't understand how it was responsive to the question I asked. I would like to understand how the communications security of your protocol will work, and to that end I'd like to understand how your requirements are similar to requirements for protocols we've already worked on. I was not able to learn anything about the communications security of your protocol from your message. --Sam From nobody Thu Apr 16 08:18:29 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496C91A87C2 for ; Thu, 16 Apr 2015 08:18:27 -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, HTML_MESSAGE=0.001, 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 BXG6EhxZt_Ey for ; Thu, 16 Apr 2015 08:18:24 -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 A9A871A87CA for ; Thu, 16 Apr 2015 08:18:17 -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 BUY45769; Thu, 16 Apr 2015 15:18:16 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Apr 2015 16:18:15 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Thu, 16 Apr 2015 08:18:12 -0700 From: Linda Dunbar To: Sam Hartman Thread-Topic: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side Thread-Index: AQHQeEj0r5hqvFOj7UKRHY72wWKmlp1Pu+wQ Date: Thu, 16 Apr 2015 15:18:11 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C069AE@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C04685@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C06807@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.179] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C069AEdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty Subject: Re: [I2nsf] inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 15:18:27 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C069AEdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sam, I2NSF is more about security functions management, i.e. how customers can r= equest & monitor their desired security policies from service providers. There are two aspects of I2NSF: 1) the security policy information exchange between enterprises and the se= rvice provider that offers the hosted security functions 2) the secure channel for the information exchange. (I think this is what y= ou call "communication security" ) I2NSF's first step will focus on 1) above. The "communication security" (2)= above is secondary. draft-lopez-i2nsf-packet-00 suggests that the 1) above can be characterized= by: * Subject - match values based on packet data Packet header - Can be standardized Packet payload - Provided by NSF capabilities * Object - match values based on context Ex.: State, time, geo-location, etc. Many can (and should) be standardized, but many also from NSF c= apabilities * Function - invoked security function Defined by NSF capabilities Function:Instance (ex. IPS: which can be provid= ed by vendors) * Action - egress processing Invoke signaling Packet forwarding and/or transformation Possibility for SDN/NFV integration We have done some study of GSS-API, and assessed that GSS-API might be usef= ul for the 2) above. But for 1), we think the NETCONF or Restful API is more appropriate. Do you agree? Any other suggestions? Linda -----Original Message----- From: Sam Hartman [mailto:hartmans@painless-security.com] Sent: Thursday, April 16, 2015 8:27 AM To: Linda Dunbar Cc: Kathleen Moriarty; i2nsf@ietf.org Subject: Re: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Int= erface towards client side Linda, I'm confused and frustrated when I read your message because I don't= understand how it was responsive to the question I asked. I would like to understand how the communications security of your protocol= will work, and to that end I'd like to understand how your requirements ar= e similar to requirements for protocols we've already worked on. I was not able to learn anything about the communications security of your = protocol from your message. --Sam --_000_4A95BA014132FF49AE685FAB4B9F17F657C069AEdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sam,
 
I2NSF is more about security functions management, i.e. how customers = can request & monitor their desired security policies from service prov= iders.
 
There are two aspects of I2NSF:
1) the security policy information exchange between enterprises and t= he service provider that offers the hosted security functions
2) the secure channel for the information exchange. (I think this is w= hat you call "communication security" )
 
I2NSF's first step will focus on 1) above. The "communication sec= urity" (2) above is secondary.
 
draft-lopez-i2nsf-packet-00 suggests that the 1) above can be characte= rized by:
 
  • Subject – match values based on packet data
Packet header - Can be standardized
Packet payload - Provided by NSF capabili= ties
  • Object – match values based on context
Ex.: State, time, geo-location, etc.
Many can (and should) be standardized, bu= t many also from NSF capabilities
  • Function – invoked security function
Defined by NSF capabilities
Function:Instance (ex. IPS:<signature = base> which can be provided by vendors)
  • Action – egress processing
Invoke signaling
Packet forwarding and/or transformation
Possibility for SDN/NFV integration
 
 
We have done some study of GSS-API, and assessed that GSS-API might be= useful for the 2) above.
But for 1), we think the NETCONF or Restful API is more appropriate. <= /div>
 
Do you agree? Any other suggestions?
 
 
Linda
 
 
-----Original Message-----
From: Sam Hartman [mailto= :hartmans@painless-security.com]
Sent: Thursday, April 16, 2015 8:27 AM
To: Linda Dunbar
Cc: Kathleen Moriarty; i2nsf@ietf.org
Subject: Re: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Int= erface towards client side
 
Linda, I'm confused and frustrated when I read your message because I = don't understand how it was responsive to the question I asked.
I would like to understand how the communications security of your pro= tocol will work, and to that end I'd like to understand how your requiremen= ts are similar to requirements for protocols we've already worked on.
I was not able to learn anything about the communications security of = your protocol from your message.
 
--Sam
 
 --_000_4A95BA014132FF49AE685FAB4B9F17F657C069AEdfweml701chm_-- From nobody Thu Apr 16 08:24:32 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077281A88BE for ; Thu, 16 Apr 2015 08:24:31 -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 4vRGJrmiaGCj for ; Thu, 16 Apr 2015 08:24:29 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD7F1A88BC for ; Thu, 16 Apr 2015 08:24:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C305A206A4; Thu, 16 Apr 2015 11:24:03 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZoiDjZpQAjf; Thu, 16 Apr 2015 11:24:03 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 16 Apr 2015 11:24:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6655F8169B; Thu, 16 Apr 2015 11:24:27 -0400 (EDT) From: Sam Hartman To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F657C04685@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C06807@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C069AE@dfweml701-chm> Date: Thu, 16 Apr 2015 11:24:27 -0400 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C069AE@dfweml701-chm> (Linda Dunbar's message of "Thu, 16 Apr 2015 15:18:11 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty Subject: Re: [I2nsf] inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 15:24:31 -0000 OK. Well, GSS-API is a communications security layer. If you aren't ready to discuss your communications security then you aren't ready to think about whether GSS-API is a good fit for your work. From nobody Thu Apr 16 08:57:50 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117111AC3D0 for ; Thu, 16 Apr 2015 08:57:49 -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 Ahu0QHwG_vsm for ; Thu, 16 Apr 2015 08:57:47 -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 809C21A9237 for ; Thu, 16 Apr 2015 08:57:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRM44212; Thu, 16 Apr 2015 15:57:44 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Apr 2015 16:57:44 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Thu, 16 Apr 2015 08:57:35 -0700 From: Linda Dunbar To: Sam Hartman Thread-Topic: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side Thread-Index: AQHQeFltr5hqvFOj7UKRHY72wWKmlp1PyeAw Date: Thu, 16 Apr 2015 15:57:34 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C06A42@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C04685@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C06807@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C069AE@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty Subject: Re: [I2nsf] inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 15:57:49 -0000 Sam,=20 Thank you very much for the feedback.=20 TLS is another way to secure the communication channel.=20 For the purpose of exchanging security policies between clients and provide= r and reporting data for clients to monitor their desired security policies= enforced by security functions hosted in a different domain, what is your = opinion of pros/cons of using GSS-API vs. TLS?=20 Thanks, Linda -----Original Message----- From: Sam Hartman [mailto:hartmans@painless-security.com]=20 Sent: Thursday, April 16, 2015 10:24 AM To: Linda Dunbar Cc: Kathleen Moriarty; i2nsf@ietf.org Subject: Re: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Int= erface towards client side OK. Well, GSS-API is a communications security layer. If you aren't ready to discuss your communications security then you aren't= ready to think about whether GSS-API is a good fit for your work. From nobody Thu Apr 16 08:59:15 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2128F1AC3E8 for ; Thu, 16 Apr 2015 08:59:14 -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 ghGm8y387fJu for ; Thu, 16 Apr 2015 08:59:13 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20E981AC3D0 for ; Thu, 16 Apr 2015 08:59:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id EB96D206A4; Thu, 16 Apr 2015 11:58:46 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_NTS-Elu2E4; Thu, 16 Apr 2015 11:58:46 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 16 Apr 2015 11:58:46 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9FAFF8169B; Thu, 16 Apr 2015 11:59:09 -0400 (EDT) From: Sam Hartman To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F657C04685@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C06807@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C069AE@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C06A42@dfweml701-chm> Date: Thu, 16 Apr 2015 11:59:09 -0400 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C06A42@dfweml701-chm> (Linda Dunbar's message of "Thu, 16 Apr 2015 15:57:34 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty Subject: Re: [I2nsf] inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 15:59:14 -0000 >>>>> "Linda" == Linda Dunbar writes: Linda> For the purpose of exchanging security policies between Linda> clients and provider and reporting data for clients to Linda> monitor their desired security policies enforced by security Linda> functions hosted in a different domain, what is your opinion Linda> of pros/cons of using GSS-API vs. TLS? I'd need to have an answer to the question of how your requirements differ from things like we've done before. For many application protocols the combination of TLS + SASL has worked very well. I'd recommend that combination to you if it works for your needs. TLS + SASL will also happen to meet the needs of anyone who wants GSS-API for security. --Sam From nobody Tue Apr 21 06:18:38 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ECF1A1A7C for ; Tue, 21 Apr 2015 06:18:37 -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 ChvKuGfdY4lz for ; Tue, 21 Apr 2015 06:18:33 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::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 C080A1A1A66 for ; Tue, 21 Apr 2015 06:18:32 -0700 (PDT) Received: by lagv1 with SMTP id v1so150914363lag.3 for ; Tue, 21 Apr 2015 06:18: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 :content-type; bh=pAbZ6kKkO8tdBtVV3bgYr4BAR0yZAxRGrKC9r0uQ5qE=; b=lsDi/acouimVbf27NcuwSd6kIrf2CuFnC0cXsRlZpojFo3xmN2DUKW1VmM1My/fx5b PId2iq4xXXMxVj9wTXlKA0BosGvGzT4rxmNCYMaYbBdbNF5fY0eXCNyUDnCXdlbzoBk/ 4kP36jLJzo1DmpNhCvvKlWauQFx2X7eRuglUnqnruFGc7nG2YKJbE7I3YLKFwR8bqXMK JdJyJOzLAke3RGznAJOW48vzSTrWBDodmqNrrecxeZvIxUcqLF4H40q3PikJCE0vLhPq H9+4yxbvyZHL4ID5WxBdVsgcttDZM1NM0OHKgFavd8nwRPmAF7ucyO4qnugJjPkHyImh 6OsA== MIME-Version: 1.0 X-Received: by 10.112.199.133 with SMTP id jk5mr20647241lbc.32.1429622311244; Tue, 21 Apr 2015 06:18:31 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 21 Apr 2015 06:18:31 -0700 (PDT) In-Reply-To: <20150421022013.7693.86328.idtracker@ietfa.amsl.com> References: <20150421022013.7693.86328.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 09:18:31 -0400 Message-ID: From: Kathleen Moriarty To: "i2nsf@ietf.org" Content-Type: multipart/alternative; boundary=001a11c264be0657f305143be20e Archived-At: Subject: [I2nsf] Fwd: IETF 93 - Working Group/BOF/IRTF Scheduling X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 13:18:37 -0000 --001a11c264be0657f305143be20e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, If you are planning on a BoF for Prague, I'd like to see the items we discussed previously, which include updated drafts in advance of the request so it is clear that you are ready for a WG forming BoF. It would be good to have use cases narrowed down (4 drafts is too many on that topic) and the charter aligning with the proposed work. Thank you, Kathleen ---------- Forwarded message ---------- From: IETF Agenda Date: Mon, Apr 20, 2015 at 10:20 PM Subject: IETF 93 - Working Group/BOF/IRTF Scheduling To: Working Group Chairs Cc: irsg@irtf.org ----------------------------------------------------------------- IETF 93 =E2=80=93 Prague, Czech Republic Meeting Dates: July 19-24, 2015 ----------------------------------------------------------------- We are accepting scheduling requests for all Working Groups, BOFs, and Research Groups starting today. The milestones and deadlines for scheduling-related activities are as follows: Cut-off dates are subject to change. =E2=80=A2 2015-04-20 (Monday): Working Group and BOF scheduling begin= s. To request a Working Group session, use the IETF Meeting Session Request Tool. =E2=80=A2 2015-06-05 (Friday): Cut-off date for requests to schedule = Working Group meetings at UTC 23:59. To request a Working Group session, use the IETF Meeting Session Request Tool. =E2=80=A2 2015-06-05 (Friday): Cut-off date for BOF proposal requests= to Area Directors at UTC 23:59. To request a BOF, please see instructions on Requesting a BOF. =E2=80=A2 2015-06-12 (Friday): Cut-off date for Area Directors to app= rove BOFs at UTC 23:59. =E2=80=A2 2015-06-19 (Friday): Preliminary agenda published for comme= nt. =E2=80=A2 2015-06-24 (Wednesday): Cut-off date for requests to resche= dule Working Group and BOF meetings UTC 23:59. =E2=80=A2 2015-06-26 (Friday): Final agenda to be published. =E2=80=A2 2015-07-06 (Monday): Draft Working Group agendas due by UTC= 23:59, upload using IETF Meeting Materials Management Tool. =E2=80=A2 2015-07-13 (Monday): Revised Working Group agendas due by U= TC 23:59, upload using IETF Meeting Materials Management Tool. =E2=80=A2 2015-08-14 (Friday): Proceedings submission cutoff date by = UTC 23:59, upload using IETF Meeting Materials Management Tool. =E2=80=A2 2015-09-14 (Monday): Proceedings submission corrections cut= off date by UTC 23:59, upload using IETF Meeting Materials Management Tool. =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=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=3D=3D=3D=3D=3D Comprehensive information on requesting meeting sessions is below: 1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions. The URL for the tool is: https://datatracker.ietf.org/secr/sreq/ Instructions for using the tool are available at: http://www.ietf.org/wg/request-tool-instructions.html If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org. If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s). Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s). When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line. 2. BOFs will NOT be scheduled unless the Area Director approves the BOF. The proponents behind a BOF need to contact a relevant Area Director, preferably well in advance of the BOF approval deadline date. The AD needs to have the full name of the BOF, its acronym, suggested names of chairs, an agenda, full description of the BOF and the information covered in item 4. Please read RFC 5434 for instructions on how to drive a successful BOF effort. The approval depends on, for instance, Internet-Drafts and list discussion on the suggested topic. BOF agenda requests, if approved, will be submitted to the IETF Secretariat by the ADs. 3. A Working Group may request either one or two sessions. If your Working Group requires more than two sessions, then your request must be approved by an Area Director. Additional sessions will be assigned, based on availability, after Wednesday, June 24th, 2015, the cut-off date for requests to reschedule a session. 4. You MUST provide the following information before a Working Group or BOF session will be scheduled: a. Working Group or BOF full name with acronym in brackets: b. AREA under which Working Group or BOF appears: c. CONFLICTS you wish to avoid, please be as specific as possible: d. Expected Attendance: e. Special requests: f. Number of sessions: g. Length of session: 1 hour, 1.5 hours, 2 hours, 2.5 hours For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" = ( http://www.ietf.org/rfc/rfc2418.txt). =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=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=3D=3D=3D=3D=3D Submitting Session Agendas For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible. Draft Working Group agendas are due Monday, July 6th, 2015 at UTC 23:59. Revised Working Group agendas are due no later than Monday, July 13th, 2015 at UTC 23:59. The proposed agenda for a BOF session should be submitted along with your request for a session. Please be sure to copy your Area Director on that message. Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting. If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved. The URL for the tool is: https://datatracker.ietf.org/secr/proceedings/ Additional information about this tool is available at: http://www.ietf.org/wg/meeting-materials.html Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" webpage as soon as they are submitted. The URL for the "IETF 93 Meeting Materials" Web page is: https://datatracker.ietf.org/meeting/93/materials.html If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool." The same User ID and password will work for both tools. If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved. If you require assistance in using either tool, or wish to report a bug, then please send a message to: ietf-action@ietf.org. =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=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=3D=3D=3D=3D=3D For your convenience please find a list of the IETF Area Directors with their e-mail addresses below: IETF Chair Jari Arkko Applications Area (app) Barry Leiba Internet Area (int) Brian Haberman Terry Manderson Operations & Management Area (ops) Benoit Claise Joel Jaeggli Real-time Applications and Infrastructure Area (rai) Ben Campbell Alissa Cooper Routing Area (rtg) Alia Atlas Deborah Brungard Alvaro Retana Security Area (sec) Stephen Farrell Kathleen Moriarty Transport Area (tsv) Spencer Dawkins Martin Stiemerling =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=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=3D IETF 92 Meeting Attendance Numbers 6lo =E2=80=93 73 6man - 133 6tisch =E2=80=93 64 6tisch - 46 ace - 79 acme (BoF) - 162 alto - 14 anima =E2=80=93 64 anima (2nd session) - 49 appsawg/apparea - 83 aqm =E2=80=93 50 avtcore - 54 avtext =E2=80=93 40 bess =E2=80=93 104 bfd =E2=80=93 50 bier - 78 bmwg - 25 ccamp - 47 cdni =E2=80=93 34 cfrg - 84 clue =E2=80=93 25 core - 54 core (2nd session) =E2=80=93 48 dane - 125 dhc =E2=80=93 28 dime - 20 dispatch - 46 dmm =E2=80=93 28 dmm (2nd session) - 27 dnsop - 107 dnssd =E2=80=93 76 dots (BoF) - 115 dprive =E2=80=93 109 dtn =E2=80=93 21 ecrit - 20 eppext =E2=80=93 23 grow - 32 homenet =E2=80=93 141 hrpc - 48 httpauth - 38 httpbis - 110 i2rs - 116 iccrg - 88 icnrg - 83 idr =E2=80=93 98 intarea - 46 ippm - 50 ipsecme - 26 IRTF Open Meeting - 60 isis - 45 jose - 45 kitten - 16 lime - 37 lisp - 37 lmap =E2=80=93 47 lucid (BoF) - 53 lwig - 41 manet - 26 mboned - 31 mile - 28 mmusic - 43 mmusic (2nd session) - 53 mpls - 124 mpls (2nd session) - 87 netconf - 93 netmod =E2=80=93 122 netmod (2nd session) =E2=80=93 111 netvc (BoF) =E2=80=93 92 nfsv4 =E2=80=93 13 nfvrg =E2=80=93 157 nfvrg (2nd session) - 98 ntp (combined with tictoc) - 28 nvo3 =E2=80=93 192 nvo3 (2nd session) - 146 nwcrg - 28 oauth - 52 opsawg/opsarea =E2=80=93 30 opsec - 20 ospf =E2=80=93 47 pals =E2=80=93 61 payload - 34 pce =E2=80=93 71 pim - 40 ppsp - 15 precis - 21 radext - 12 rmcat - 37 rtcweb - 118 rtcweb (2nd session) - 72 rtgarea - 72 rtgwg =E2=80=93 51 rtgwg (2nd session) - 82 saag - 209 sacm - 44 sacm (2nd session) - 39 scim - 19 sdnrg =E2=80=93 196 sfc - 176 sidr - 72 spring =E2=80=93 94 spud (BoF) - 213 stir =E2=80=93 52 sunset4 =E2=80=93 63 supa (BoF) - 164 taps - 97 tcpinc - 80 tcpm =E2=80=93 52 teas - 69 tictoc (combined with ntp) - 28 tls =E2=80=93 111 tokbind - 55 tram - 30 trans - 26 trill =E2=80=93 16 tsvarea =E2=80=93 100 tsvarea (2nd session) - 45 tsvwg - 79 tsvwg (2nd session) - 56 uta - 63 v6ops - 86 v6ops (2nd session) =E2=80=93 77 webpush - 72 --=20 Best regards, Kathleen --001a11c264be0657f305143be20e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

If you are planning on a BoF for= Prague, I'd like to see the items we discussed previously, which inclu= de updated drafts in advance of the request so it is clear that you are rea= dy for a WG forming BoF.=C2=A0 It would be good to have use cases narrowed = down (4 drafts is too many on that topic) and the charter aligning with the= proposed work.

Thank you,
Kathleen

---------- Forwarded message ---------= -
From: IETF Agenda = <agenda@ietf.org>
Da= te: Mon, Apr 20, 2015 at 10:20 PM
Subject: IETF 93 - Working Group/BOF/I= RTF Scheduling
To: Working Group Chairs <wgchairs@ietf.org>
Cc: = irsg@irtf.org


----------------------------------------------= -------------------
IETF 93 =E2=80=93 Prague, Czech Republic
Meeting Dates: July 19-24, 2015
-----------------------------------------------------------------

We are accepting scheduling requests for all Working Groups, BOFs, and Rese= arch Groups starting today.

The milestones and deadlines for scheduling-related activities are as follo= ws:
Cut-off dates are subject to change.

=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-04-20 (Monday): Working Group and = BOF scheduling begins. To request a Working Group session, use the IETF Mee= ting Session Request Tool.
=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-06-05 (Friday): Cut-off date for r= equests to schedule Working Group meetings at UTC 23:59. To request a Worki= ng Group session, use the IETF Meeting Session Request Tool.
=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-06-05 (Friday): Cut-off date for B= OF proposal requests to Area Directors at UTC 23:59. To request a BOF, plea= se see instructions on Requesting a BOF.
=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-06-12 (Friday): Cut-off date for A= rea Directors to approve BOFs at UTC 23:59.
=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-06-19 (Friday): Preliminary agenda= published for comment.
=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-06-24 (Wednesday): Cut-off date fo= r requests to reschedule Working Group and BOF meetings UTC 23:59.
=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-06-26 (Friday): Final agenda to be= published.
=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-07-06 (Monday): Draft Working Grou= p agendas due by UTC 23:59, upload using IETF Meeting Materials Management = Tool.
=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-07-13 (Monday): Revised Working Gr= oup agendas due by UTC 23:59, upload using IETF Meeting Materials Managemen= t Tool.
=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-08-14 (Friday): Proceedings submis= sion cutoff date by UTC 23:59, upload using IETF Meeting Materials Manageme= nt Tool.
=E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A02015-09-14 (Monday): Proceedings submis= sion corrections cutoff date by UTC 23:59, upload using IETF Meeting Materi= als Management Tool.


=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=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=3D=3D=3D=3D=3D
Comprehensive information on requesting meeting sessions is below:

1. Requests to schedule Working Group sessions should be submitted using th= e "IETF Meeting Session Request Tool," a Web-based tool for submi= tting all of the information required by the Secretariat to schedule your s= essions.=C2=A0 The URL for the tool is:

https= ://datatracker.ietf.org/secr/sreq/

Instructions for using the tool are available at:

http://www.ietf.org/wg/request-tool-instructions.html

If you require an account on this tool, or assistance in using it, then ple= ase send a message to ietf-action@i= etf.org. If you are unable to use the tool, then you may send your requ= est via e-mail to agenda@ietf.org, w= ith a copy to the appropriate Area Director(s).

Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(= s).

When submitting a Working Group or BOF session request by e-mail, please in= clude the Working Group or BOF acronym in the Subject line.

2. BOFs will NOT be scheduled unless the Area Director approves the BOF. Th= e proponents behind a BOF need to contact a relevant Area Director, prefera= bly well in advance of the BOF approval deadline date. The AD needs to have= the full name of the BOF, its acronym, suggested names of chairs, an agend= a, full description of the BOF and the information covered in item 4. Pleas= e read RFC 5434 for instructions on how to drive a successful BOF effort. T= he approval depends on, for instance, Internet-Drafts and list discussion o= n the suggested topic. BOF agenda requests, if approved, will be submitted = to the IETF Secretariat by the ADs.

3. A Working Group may request either one or two sessions. If your Working = Group requires more than two sessions, then your request must be approved b= y an Area Director. Additional sessions will be assigned, based on availabi= lity, after Wednesday, June 24th, 2015, the cut-off date for requests to re= schedule a session.

4. You MUST provide the following information before a Working Group or BOF= session will be scheduled:

a. Working Group or BOF full name with acronym in brackets:
b. AREA under which Working Group or BOF appears:
c. CONFLICTS you wish to avoid, please be as specific as possible:
d. Expected Attendance:
e. Special requests:
f. Number of sessions:
g. Length of session: 1 hour, 1.5 hours, 2 hours, 2.5 hours

For more information on scheduling Working Group and BOF sessions, please r= efer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedur= es" (http://www.ietf.org/rfc/rfc2418.txt).

=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=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=3D=3D=3D=3D=3D

Submitting Session Agendas

For the convenience of meeting attendees, we ask that you submit the agenda= s for your Working Group sessions as early as possible.=C2=A0 Draft Working= Group agendas are due Monday, July 6th, 2015 at UTC 23:59.=C2=A0 Revised W= orking Group agendas are due no later than Monday, July 13th, 2015 at UTC 2= 3:59.=C2=A0 The proposed agenda for a BOF session should be submitted along= with your request for a session.=C2=A0 Please be sure to copy your Area Di= rector on that message.

Please submit the agendas for your Working Group sessions using the "I= ETF Meeting Materials Management Tool," a Web-based tool for making yo= ur meeting agenda, minutes, and presentation slides available to the commun= ity before, during, and after an IETF meeting.=C2=A0 If you are a BOF chair= , then you may use the tool to submit a revised agenda as well as other mat= erials for your BOF once the BOF has been approved.

The URL for the tool is:

https://datatracker.ietf.org/secr/proceedings/

Additional information about this tool is available at:

http://www.ietf.org/wg/meeting-materials.html

Agendas submitted via the tool will be available to the public on the "= ;IETF Meeting Materials" webpage as soon as they are submitted.

The URL for the "IETF 93 Meeting Materials" Web page is:

https://datatracker.ietf.org/meeting/93/materials.html

If you are a Working Group chair, then you already have accounts on the &qu= ot;IETF Meeting Session Request Tool" and the "IETF Meeting Mater= ials Management Tool."=C2=A0 The same User ID and password will work f= or both tools.=C2=A0 If you are a BOF chair who is not also a Working Group= chair, then you will be given an account on the "IETF Meeting Materia= ls Management Tool" when your BOF has been approved.=C2=A0 If you requ= ire assistance in using either tool, or wish to report a bug, then please s= end a message to:
ietf-action@ietf.org.

=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=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=3D=3D=3D=3D=3D
For your convenience please find a list of the IETF Area Directors with the= ir e-mail addresses below:

IETF Chair
Jari Arkko <jari.arkko@piuha.net= >

Applications Area (app)
Barry Leiba <barryleiba@compu= ter.org>

Internet Area (int)
Brian Haberman <brian@innova= tionslab.net>
Terry Manderson <terry.mand= erson@icann.org>

Operations & Management Area (ops)
Benoit Claise <bclaise@cisco.com>
Joel Jaeggli <joelja@bogus.com&g= t;

Real-time Applications and Infrastructure Area (rai)
Ben Campbell <ben@nostrum.com>=
Alissa Cooper <alissa@cooperw.in>

Routing Area (rtg)
Alia Atlas <akatlas+iesg@gma= il.com>
Deborah Brungard <dbrungard@att.com= >
Alvaro Retana <aretana@cisco.com>

Security Area (sec)
Stephen Farrell <stephen.fa= rrell@cs.tcd.ie>
Kathleen Moriarty <K= athleen.Moriarty.ietf@gmail.com>

Transport Area (tsv)
Spencer Dawkins=C2=A0 <= spencerdawkins.ietf@gmail.com>
Martin Stiemerling <mart= in.stiemerling@neclab.eu>

=C2=A0=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=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=3D
IETF 92 Meeting Attendance Numbers

6lo =E2=80=93 73
6man - 133
6tisch =E2=80=93 64
6tisch - 46
ace - 79
acme (BoF) - 162
alto=C2=A0 - 14
anima =E2=80=93 64
anima (2nd session) - 49
appsawg/apparea - 83
aqm =E2=80=93 50
avtcore - 54
avtext =E2=80=93 40
bess =E2=80=93 104
bfd =E2=80=93 50
bier - 78
bmwg - 25
ccamp - 47
cdni =E2=80=93 34
cfrg - 84
clue =E2=80=93 25
core - 54
core (2nd session) =E2=80=93 48
dane - 125
dhc =E2=80=93 28
dime - 20
dispatch - 46
dmm =E2=80=93 28
dmm (2nd session) - 27
dnsop - 107
dnssd =E2=80=93 76
dots (BoF) - 115
dprive =E2=80=93 109
dtn =E2=80=93 21
ecrit - 20
eppext =E2=80=93 23
grow - 32
homenet =E2=80=93 141
hrpc - 48
httpauth - 38
httpbis - 110
i2rs - 116
iccrg - 88
icnrg - 83
idr =E2=80=93 98
intarea - 46
ippm - 50
ipsecme - 26
IRTF Open Meeting - 60
isis - 45
jose - 45
kitten - 16
lime - 37
lisp - 37
lmap =E2=80=93 47
lucid (BoF) - 53
lwig - 41
manet - 26
mboned - 31
mile - 28
mmusic - 43
mmusic (2nd session) - 53
mpls - 124
mpls (2nd session) - 87
netconf - 93
netmod =E2=80=93 122
netmod (2nd session) =E2=80=93 111
netvc (BoF) =E2=80=93 92
nfsv4 =E2=80=93 13
nfvrg =E2=80=93 157
nfvrg (2nd session) - 98
ntp (combined with tictoc) - 28
nvo3 =E2=80=93 192
nvo3 (2nd session) - 146
nwcrg - 28
oauth - 52
opsawg/opsarea =E2=80=93 30
opsec - 20
ospf =E2=80=93 47
pals =E2=80=93 61
payload - 34
pce =E2=80=93 71
pim - 40
ppsp - 15
precis - 21
radext - 12
rmcat - 37
rtcweb - 118
rtcweb (2nd session) - 72
rtgarea - 72
rtgwg =E2=80=93 51
rtgwg (2nd session) - 82
saag - 209
sacm - 44
sacm (2nd session) - 39
scim - 19
sdnrg =E2=80=93 196
sfc - 176
sidr - 72
spring =E2=80=93 94
spud (BoF) - 213
stir =E2=80=93 52
sunset4 =E2=80=93 63
supa (BoF) - 164
taps - 97
tcpinc - 80
tcpm =E2=80=93 52
teas - 69
tictoc (combined with ntp) - 28
tls =E2=80=93 111
tokbind - 55
tram - 30
trans - 26
trill =E2=80=93 16
tsvarea =E2=80=93 100
tsvarea (2nd session) - 45
tsvwg - 79
tsvwg (2nd session) - 56
uta - 63
v6ops - 86
v6ops (2nd session) =E2=80=93 77
webpush - 72




--

Best regards,
Kathleen
--001a11c264be0657f305143be20e-- From nobody Tue Apr 21 15:55:51 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EFC1B2DFA; Tue, 21 Apr 2015 15:55: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, HTML_MESSAGE=0.001, 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 MUdyrLKVvEWr; Tue, 21 Apr 2015 15:55:42 -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 8707B1B2DFB; Tue, 21 Apr 2015 15:55:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVD24326; Tue, 21 Apr 2015 22:55:38 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Apr 2015 23:55:37 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Tue, 21 Apr 2015 15:55:35 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" Thread-Topic: New Version Notification for draft-merged-i2nsf-framework-00.txt Thread-Index: AQHQfINyor7fMB1FSUC6JcO7boLwQJ1YDq9g Date: Tue, 21 Apr 2015 22:55:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C087D9@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.84] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C087D9dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pcp@ietf.org" , "dots@ietf.org" , "sacm@ietf.org" Subject: [I2nsf] FW: New Version Notification for draft-merged-i2nsf-framework-00.txt X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 22:55:45 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C087D9dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGZyYW1ld29yayBmb3IgSW50ZXJmYWNlIHRvIE5l dHdvcmsgU2VjdXJpdHkgRnVuY3Rpb25zIGFuZCBkZWZpbmVzIGEgcmVmZXJlbmNlIG1vZGVsIGFs b25nIHdpdGggZnVuY3Rpb25hbCBjb21wb25lbnRzLg0KDQoNCkNvcHkgdG8gRE9UUy9QQ1AvU0FD TSBhdWRpZW5jZSBpbiBob3BlIGZvciBnZXR0aW5nIGZlZWRiYWNrIGZyb20gd2lkZXIgYXVkaWVu Y2UuIEkyTlNGIGlzIGFib3V0IHNlY3VyaXR5IGZ1bmN0aW9ucyBtYW5hZ2VtZW50LCBpLmUuIGhv dyBjdXN0b21lcnMgY2FuIHJlcXVlc3QgJiBtb25pdG9yIHRoZWlyIGRlc2lyZWQgc2VjdXJpdHkg cG9saWNpZXMgZnJvbSBzZWN1cml0eSBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgaW50ZXJmYWNlIHRv IG1hbmFnZS9tb25pdG9yIHBhY2tldCBiYXNlZCBzZWN1cml0eSBmdW5jdGlvbnMgZnJvbSBtdWx0 aXBsZSB2ZW5kb3JzLCB3aGVyZWFzIERPVFMgaXMgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlIGJl dHdlZW4gbXVsdGlwbGUgQW50aURvUyBmdW5jdGlvbnMuDQoNClRoZXJlIGFyZSB0d28gYXNwZWN0 cyBvZiBJMk5TRjoNCjEpICB0aGUgc2VjdXJpdHkgcG9saWN5IGluZm9ybWF0aW9uIGV4Y2hhbmdl IGJldHdlZW4gY3VzdG9tZXJzIGFuZCB0aGUgc2VydmljZSBwcm92aWRlciB0aGF0IG9mZmVycyB0 aGUgaG9zdGVkIHNlY3VyaXR5IGZ1bmN0aW9ucw0KMikgdGhlIHNlY3VyZSBjaGFubmVsIGZvciB0 aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2UsICh3aGljaCBjYW4gYmUgYWNoaWV2ZWQgYnkgVExTIG9y IFNBU0wgb3IgY29tYmluYXRpb24gb2YgdGhlbSApDQoNCkkyTlNGJ3MgZmlyc3Qgc3RlcCB3aWxs IGZvY3VzIG9uIDEpIGFib3ZlLiBUaGUgImNvbW11bmljYXRpb24gc2VjdXJpdHkiICgyKSBhYm92 ZSBpcyBzZWNvbmRhcnkuDQoNClRoZSBJMk5TRiBmcmFtZXdvcmsgdXRpbGl6ZXMgdGhlIGNhdGVn b3JpZXMgY2hhcmFjdGVyaXplZCBieSBkcmFmdC1sb3Blei1pMm5zZi1wYWNrZXQtMDAgZm9yIE5T RjoNCg0K4oCiICAgICAgIFN1YmplY3Qg4oCTIG1hdGNoIHZhbHVlcyBiYXNlZCBvbiBwYWNrZXQg ZGF0YQ0KICAgICAgUGFja2V0IGhlYWRlciAtIENhbiBiZSBzdGFuZGFyZGl6ZWQNCiAgICAgIFBh Y2tldCBwYXlsb2FkIC0gUHJvdmlkZWQgYnkgTlNGIGNhcGFiaWxpdGllcw0K4oCiICAgICAgIE9i amVjdCDigJMgbWF0Y2ggdmFsdWVzIGJhc2VkIG9uIGNvbnRleHQNCiAgICAgIEV4LjogU3RhdGUs IHRpbWUsIGdlby1sb2NhdGlvbiwgZXRjLg0KICAgICAgTWFueSBjYW4gKGFuZCBzaG91bGQpIGJl IHN0YW5kYXJkaXplZCwgYnV0IG1hbnkgYWxzbyBmcm9tIE5TRiBjYXBhYmlsaXRpZXMNCuKAoiAg ICAgICBGdW5jdGlvbiDigJMgaW52b2tlZCBzZWN1cml0eSBmdW5jdGlvbg0KICAgICAgRGVmaW5l ZCBieSBOU0YgY2FwYWJpbGl0aWVzDQogICAgICBGdW5jdGlvbjpJbnN0YW5jZSAoZXguIElQUzo8 c2lnbmF0dXJlIGJhc2U+IHdoaWNoIGNhbiBiZSBwcm92aWRlZCBieSB2ZW5kb3JzKQ0K4oCiICAg ICAgIEFjdGlvbiDigJMgZWdyZXNzIHByb2Nlc3NpbmcNCiAgICAgIEludm9rZSBzaWduYWxpbmcN CiAgICAgIFBhY2tldCBmb3J3YXJkaW5nIGFuZC9vciB0cmFuc2Zvcm1hdGlvbg0KICAgICAgUG9z c2liaWxpdHkgZm9yIFNETi9ORlYgaW50ZWdyYXRpb24NCg0KDQpBbnkgZmVlZGJhY2ssIGNvbW1l bnRzIG9yIHN1Z2dlc3Rpb25zIGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLg0KDQpDaGVlcnMsDQpM aW5kYQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBUdWVz ZGF5LCBBcHJpbCAyMSwgMjAxNSA1OjM1IFBNDQpUbzogSm9lIFBhcnJvdHQ7IFNlZXRoYXJhbWEg UmFvIER1cmJoYTsgWGlhb2p1biBaaHVhbmc7IExpbmRhIER1bmJhcjsgTGluZGEgRHVuYmFyOyBE aWVnbyBMb3BlejsgU2VldGhhcmFtYSBSYW8gRHVyYmhhOyBSYW0gKFJhbWtpKSBLcmlzaG5hbjsg RGllZ28gTG9wZXo7IFhpYW9KdW4gWmh1YW5nOyBKb2UgUGFycm90dDsgUmFta2kgS3Jpc2huYW4N ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWVyZ2VkLWkybnNm LWZyYW1ld29yay0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWVyZ2Vk LWkybnNmLWZyYW1ld29yay0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgTGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZTogICAgICAgICAgIGRyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmsNClJldmlzaW9uOiAgICAg ICAwMA0KVGl0bGU6ICAgICAgICAgIEZyYW1ld29yayBmb3IgSW50ZXJmYWNlIHRvIE5ldHdvcmsg U2VjdXJpdHkgRnVuY3Rpb25zDQpEb2N1bWVudCBkYXRlOiAgMjAxNS0wNC0yMQ0KR3JvdXA6ICAg ICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDE2DQpVUkw6ICAg ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWVyZ2Vk LWkybnNmLWZyYW1ld29yay0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZXJnZWQtaTJuc2YtZnJhbWV3b3JrLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFt ZXdvcmstMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBm cmFtZXdvcmsgZm9yIEludGVyZmFjZSB0byBOZXR3b3JrDQogICBTZWN1cml0eSBGdW5jdGlvbnMg YW5kIGRlZmluZXMgYSByZWZlcmVuY2UgbW9kZWwgYWxvbmcgd2l0aA0KICAgZnVuY3Rpb25hbCBj b21wb25lbnRzLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_4A95BA014132FF49AE685FAB4B9F17F657C087D9dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4NCjxkaXY+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhl IGZyYW1ld29yayBmb3IgSW50ZXJmYWNlIHRvIE5ldHdvcmsgU2VjdXJpdHkgRnVuY3Rpb25zIGFu ZCBkZWZpbmVzIGEgcmVmZXJlbmNlIG1vZGVsIGFsb25nIHdpdGggZnVuY3Rpb25hbCBjb21wb25l bnRzLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj5Db3B5IHRvIERPVFMvUENQL1NBQ00g YXVkaWVuY2UgaW4gaG9wZSBmb3IgZ2V0dGluZyBmZWVkYmFjayBmcm9tIHdpZGVyIGF1ZGllbmNl LiBJMk5TRiBpcyBhYm91dCBzZWN1cml0eSBmdW5jdGlvbnMgbWFuYWdlbWVudCwgaS5lLiBob3cg Y3VzdG9tZXJzIGNhbiByZXF1ZXN0ICZhbXA7IG1vbml0b3IgdGhlaXIgZGVzaXJlZCBzZWN1cml0 eSBwb2xpY2llcyBmcm9tIHNlY3VyaXR5IHNlcnZpY2UgcHJvdmlkZXJzIGFuZCBpbnRlcmZhY2Ug dG8gbWFuYWdlL21vbml0b3INCnBhY2tldCBiYXNlZCBzZWN1cml0eSBmdW5jdGlvbnMgZnJvbSBt dWx0aXBsZSB2ZW5kb3JzLCB3aGVyZWFzIERPVFMgaXMgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdl IGJldHdlZW4gbXVsdGlwbGUgQW50aURvUyBmdW5jdGlvbnMuIDwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+VGhlcmUgYXJl IHR3byBhc3BlY3RzIG9mIEkyTlNGOjwvZGl2Pg0KPGRpdj4xKSZuYnNwOyB0aGUgc2VjdXJpdHkg cG9saWN5IGluZm9ybWF0aW9uIGV4Y2hhbmdlIGJldHdlZW4gY3VzdG9tZXJzIGFuZCB0aGUgc2Vy dmljZSBwcm92aWRlciB0aGF0IG9mZmVycyB0aGUgaG9zdGVkIHNlY3VyaXR5IGZ1bmN0aW9ucyA8 L2Rpdj4NCjxkaXY+MikgdGhlIHNlY3VyZSBjaGFubmVsIGZvciB0aGUgaW5mb3JtYXRpb24gZXhj aGFuZ2UsICh3aGljaCBjYW4gYmUgYWNoaWV2ZWQgYnkgVExTIG9yIFNBU0wgb3IgY29tYmluYXRp b24gb2YgdGhlbSApPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JMk5TRidzIGZpcnN0 IHN0ZXAgd2lsbCBmb2N1cyBvbiAxKSBhYm92ZS4gVGhlICZxdW90O2NvbW11bmljYXRpb24gc2Vj dXJpdHkmcXVvdDsgKDIpIGFib3ZlIGlzIHNlY29uZGFyeS4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5UaGUgSTJOU0YgZnJhbWV3b3JrIHV0aWxpemVzIHRoZSBjYXRlZ29yaWVzIGNo YXJhY3Rlcml6ZWQgYnkgZHJhZnQtbG9wZXotaTJuc2YtcGFja2V0LTAwIGZvciBOU0Y6PC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj7igKImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgU3ViamVjdCDigJMgbWF0Y2ggdmFsdWVzIGJhc2VkIG9uIHBhY2tldCBkYXRhPC9k aXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsiPlBhY2tldCBoZWFkZXIgLSBDYW4g YmUgc3RhbmRhcmRpemVkPC9kaXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsiPlBh Y2tldCBwYXlsb2FkIC0gUHJvdmlkZWQgYnkgTlNGIGNhcGFiaWxpdGllczwvZGl2Pg0KPGRpdj7i gKImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT2JqZWN0IOKAkyBtYXRjaCB2 YWx1ZXMgYmFzZWQgb24gY29udGV4dDwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2 cHQ7Ij5FeC46IFN0YXRlLCB0aW1lLCBnZW8tbG9jYXRpb24sIGV0Yy48L2Rpdj4NCjxkaXYgc3R5 bGU9InBhZGRpbmctbGVmdDozNnB0OyI+TWFueSBjYW4gKGFuZCBzaG91bGQpIGJlIHN0YW5kYXJk aXplZCwgYnV0IG1hbnkgYWxzbyBmcm9tIE5TRiBjYXBhYmlsaXRpZXM8L2Rpdj4NCjxkaXY+4oCi Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZ1bmN0aW9uIOKAkyBpbnZva2Vk IHNlY3VyaXR5IGZ1bmN0aW9uPC9kaXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsi PkRlZmluZWQgYnkgTlNGIGNhcGFiaWxpdGllczwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1s ZWZ0OjM2cHQ7Ij5GdW5jdGlvbjpJbnN0YW5jZSAoZXguIElQUzombHQ7c2lnbmF0dXJlIGJhc2Um Z3Q7IHdoaWNoIGNhbiBiZSBwcm92aWRlZCBieSB2ZW5kb3JzKTwvZGl2Pg0KPGRpdj7igKImbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWN0aW9uIOKAkyBlZ3Jlc3MgcHJvY2Vz c2luZzwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7Ij5JbnZva2Ugc2lnbmFs aW5nPC9kaXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsiPlBhY2tldCBmb3J3YXJk aW5nIGFuZC9vciB0cmFuc2Zvcm1hdGlvbjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0 OjM2cHQ7Ij5Qb3NzaWJpbGl0eSBmb3IgU0ROL05GViBpbnRlZ3JhdGlvbjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PkFueSBm ZWVkYmFjaywgY29tbWVudHMgb3Igc3VnZ2VzdGlvbnMgYXJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQu IDwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48 L2Rpdj4NCjxkaXY+Q2hlZXJzLCA8L2Rpdj4NCjxkaXY+TGluZGE8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjwv ZGl2Pg0KPGRpdj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCg0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIj5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl0NCjxicj4NCg0KU2VudDog VHVlc2RheSwgQXByaWwgMjEsIDIwMTUgNTozNSBQTTxicj4NCg0KVG86IEpvZSBQYXJyb3R0OyBT ZWV0aGFyYW1hIFJhbyBEdXJiaGE7IFhpYW9qdW4gWmh1YW5nOyBMaW5kYSBEdW5iYXI7IExpbmRh IER1bmJhcjsgRGllZ28gTG9wZXo7IFNlZXRoYXJhbWEgUmFvIER1cmJoYTsgUmFtIChSYW1raSkg S3Jpc2huYW47IERpZWdvIExvcGV6OyBYaWFvSnVuIFpodWFuZzsgSm9lIFBhcnJvdHQ7IFJhbWtp IEtyaXNobmFuPGJyPg0KDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmstMDAudHh0PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+QSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmstMDAudHh0PC9kaXY+DQo8ZGl2Pmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk5h bWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcms8L2Rpdj4NCjxkaXY+UmV2aXNpb246 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAwPC9kaXY+DQo8ZGl2PlRpdGxl OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBG cmFtZXdvcmsgZm9yIEludGVyZmFjZSB0byBOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9uczwvZGl2 Pg0KPGRpdj5Eb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE1LTA0LTIxPC9kaXY+DQo8ZGl2Pkdyb3Vw OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJ bmRpdmlkdWFsIFN1Ym1pc3Npb248L2Rpdj4NCjxkaXY+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE2PC9kaXY+DQo8ZGl2PlVSTDom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbWVyZ2VkLWkybnNmLWZyYW1ld29yay0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmstMDAudHh0PC9hPjwvZGl2 Pg0KPGRpdj5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1l cmdlZC1pMm5zZi1mcmFtZXdvcmsvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1tZXJnZWQtaTJuc2YtZnJhbWV3b3JrLzwvYT48L2Rpdj4NCjxkaXY+SHRtbGl6ZWQ6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmstMDAiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmstMDA8L2E+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxk aXY+QWJzdHJhY3Q6PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyB0aGUgZnJhbWV3b3JrIGZvciBJbnRlcmZhY2UgdG8gTmV0d29yazwvZGl2Pg0KPGRpdj4m bmJzcDsmbmJzcDsgU2VjdXJpdHkgRnVuY3Rpb25zIGFuZCBkZWZpbmVzIGEgcmVmZXJlbmNlIG1v ZGVsIGFsb25nIHdpdGg8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IGZ1bmN0aW9uYWwgY29tcG9u ZW50cy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoZSBJRVRGIFNlY3Jl dGFyaWF0PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C087D9dfweml701chm_-- From nobody Thu Apr 23 02:59:44 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC6B1A90AA for ; Thu, 23 Apr 2015 02:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.509 X-Spam-Level: X-Spam-Status: No, score=-5.509 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 mI-Z2OJknx7A for ; Thu, 23 Apr 2015 02:59:41 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B381A90BB for ; Thu, 23 Apr 2015 02:59:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAMLBOFWHCzIm/2dsb2JhbABbgkUhJlJhtE4GmT0CgThMAQEBAQEBgQuEIgEBAxIbXgEMCRVWJgEEGxqICQGna4UFn18MIIYWiUEzg0+BFgWEZ4xahj6Bb4Mmgz+CZAuKHoNOI4NzgjOBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,630,1422939600"; d="scan'208,217";a="113398209" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Apr 2015 05:59:13 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 23 Apr 2015 05:59:13 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Thu, 23 Apr 2015 11:59:12 +0200 From: "Romascanu, Dan (Dan)" To: "i2nsf@ietf.org" Thread-Topic: draft-jeong-i2nsf-sdn-security-services Thread-Index: AdB9rCWO2TpNwZxzTLuybAjn8Ls/Mg== Date: Thu, 23 Apr 2015 09:59:12 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9FB350@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C9FB350AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [I2nsf] draft-jeong-i2nsf-sdn-security-services X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 09:59:43 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9FB350AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to draw your attention to draft-jeong-i2nsf-sdn-security-servi= ces which was posted about a month ago. According to one of its authors thi= s I-D address the use cases for I2NSF in SDN In order to explain why and how distributed security functions need standar= d interfaces in those use cases. Please read, ask questions and comment - s= pecifically we need to understand if and how this fits in the scope we are = discussing for I2NSF. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9FB350AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I would like to draw your attention to draft-jeong-i= 2nsf-sdn-security-services which was posted about a month ago. According to= one of its authors this I-D address the use cases for I2NSF in SDN

In order to explain why and how distributed security= functions need standard interfaces in those use cases. Please read, ask qu= estions and comment – specifically we need to understand if and how t= his fits in the scope we are discussing for I2NSF.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C9FB350AZFFEXMB04globa_-- From nobody Thu Apr 23 04:07:27 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386491B2D70 for ; Thu, 23 Apr 2015 04:07:27 -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 iHiJDRdfe7U5 for ; Thu, 23 Apr 2015 04:07:12 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 4476C1B2D51 for ; Thu, 23 Apr 2015 04:06:48 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so20487114igb.1 for ; Thu, 23 Apr 2015 04:06: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=mI2jNFDhKLvGMqnCdfRHOX11vUFMtWJHlfwhNCl7F3g=; b=q9LFIY/Ot/DCC+Efj+eWO4n0uimRlimKmBVeFJkp2wPWhW+NADePGNQnNj/VxwAUeS ZtIqXvj9d5a2e/+S0GGzpWEV8/PbnH52RRphVzc1wYTfB4g+n+PpAJBpmZweRJkLA1OK 6tOwX3j3zDTa746uj9jevfO+E+rkSkxBmd4ludlet/48JrRis5/VDsCcTm1pUKhgcvX9 tBgOhHgqeuUJuJMoNzrCqkc+ebbUW9Igj99do77O+S1ut9v7Mm4G5Vp8idUTGWLOFB8N el2Zh/MEBdutMifKI39cAOdKI5FUSnvdgR1kXggyXdyGystp3p8/ro0/404SEdaQ2CNS sUgw== MIME-Version: 1.0 X-Received: by 10.50.138.70 with SMTP id qo6mr3585621igb.40.1429787207783; Thu, 23 Apr 2015 04:06:47 -0700 (PDT) Received: by 10.64.76.10 with HTTP; Thu, 23 Apr 2015 04:06:47 -0700 (PDT) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C9FB350@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C9FB350@AZ-FFEXMB04.global.avaya.com> Date: Thu, 23 Apr 2015 20:06:47 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: "i2nsf@ietf.org" , "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=001a1134bbc69fdc3205146246ed Archived-At: Cc: "Prof. Hyoungshick Kim" , Jung-Soo Park Subject: Re: [I2nsf] draft-jeong-i2nsf-sdn-security-services X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 11:07:27 -0000 --001a1134bbc69fdc3205146246ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I am Paul, one of the authors of draft-jeong-i2nsf-sdn-security-services: https://datatracker.ietf.org/doc/draft-jeong-i2nsf-sdn-security-services/?i= nclude_text=3D1 In this document, I have suggested requirements for security services in SDN framework and two use cases, such as firewall and DDoS-attack mitigator. To the next revision, I will add why and how distributed security functions need standard interfaces in those use cases. If you have comments or suggestions, please let me know. Thanks. Paul =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 Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Thu, Apr 23, 2015 at 6:59 PM, Romascanu, Dan (Dan) wrote: > Hi, > > > > I would like to draw your attention to > draft-jeong-i2nsf-sdn-security-services which was posted about a month ag= o. > According to one of its authors this I-D address the use cases for I2NSF = in > SDN > > In order to explain why and how distributed security functions need > standard interfaces in those use cases. Please read, ask questions and > comment =E2=80=93 specifically we need to understand if and how this fits= in the > scope we are discussing for I2NSF. > > > > Thanks and Regards, > > > > Dan > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > --001a1134bbc69fdc3205146246ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I am Paul, one of the authors of=C2=A0draft-j= eong-i2nsf-sdn-security-services:

<= /span>
In this document, I have suggested requirements fo= r security services in SDN framework and
two use cases, s= uch as firewall and DDoS-attack mitigator.
To the next re= vision, I will add=C2=A0why and how distributed security functions = need standard interfaces in those use cases.=C2=A0

If you have comments or suggestions, please let me= know.

Thanks.
<= br>
Paul
=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
Mr. Jaehoon (Paul) J= eong, Ph.D.
Assistant Professor
Department of Software /
Departmen= t of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-= 4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmai= l.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.s= kku.edu/people-jaehoon-jeong.php

On Thu, Apr 23, 2015 at 6:59 PM, Romascanu, = Dan (Dan) <dromasca@avaya.com> wrote:

Hi,

=C2=A0

I would like to draw your attention to draft-jeong-i= 2nsf-sdn-security-services which was posted about a month ago. According to= one of its authors this I-D address the use cases for I2NSF in SDN<= u>

In order to explain why and how distributed security= functions need standard interfaces in those use cases. Please read, ask qu= estions and comment =E2=80=93 specifically we need to understand if and how= this fits in the scope we are discussing for I2NSF.

=C2=A0

Thanks and Regards,

=C2=A0

Dan

=C2=A0


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/i2nsf


--001a1134bbc69fdc3205146246ed-- From nobody Thu Apr 23 10:04:08 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE6B1AC3C3 for ; Thu, 23 Apr 2015 10:04:01 -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 6exNUDwjl_zN for ; Thu, 23 Apr 2015 10:03:55 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::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 6225E1AC437 for ; Thu, 23 Apr 2015 10:03:44 -0700 (PDT) Received: by labbd9 with SMTP id bd9so17368464lab.2 for ; Thu, 23 Apr 2015 10:03:42 -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=1SMLQuP0YV8HNppaj9RXel/0G1J8xKVtFQNqJWW5IWM=; b=sMARvaPd9TAbsuzeUUvrHnEZqXWHV6E6N4KoIV23WxF76WLTyspjO08xGFfIKaoiaE SRutWtMUY86SN/06+C/Lrr4W6kelC+vdI+blYk8He3zDMeHv+JCoZCUEL+NDs5uD/twL UEy+4vcVM59XUuVUSbdPGrAOTsi88XscDi/P3Gh9T2n/GatfPVPvNSveTg/2t9Gt1v5X GDHT0J/4sfaQdkL3arEMHgiXE/thEkV45nbwlSh1b8ppXbqllCKT/JdwEm+fDVe4uyQL Iyjh/9N8S0sxU+V2Q7YgadB2jQ01XM+YwHhgmtrnY5yy7RAUJ67ryiAYU3hF+TcH24+H fRLg== MIME-Version: 1.0 X-Received: by 10.152.121.42 with SMTP id lh10mr3388585lab.0.1429808622794; Thu, 23 Apr 2015 10:03:42 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 23 Apr 2015 10:03:42 -0700 (PDT) In-Reply-To: References: <5512F1ED.8020104@htt-consult.com> <55160B74.1010009@gmail.com> <032CF466-C78E-46C7-A171-5176555A97DA@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657BFFB52@dfweml701-chm> Date: Thu, 23 Apr 2015 13:03:42 -0400 Message-ID: From: Kathleen Moriarty To: "Adam W. Montville" Content-Type: multipart/alternative; boundary=089e011774850efe9c051467430e Archived-At: Cc: "i2nsf@ietf.org" , Melinda Shore , Linda Dunbar Subject: Re: [I2nsf] The defense 'ecosystem' paradigm X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:04:01 -0000 --089e011774850efe9c051467430e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have been meaning to respond on how MILE and SACM fit with I2NSF and DOTS in a bigger picture view. I just have old slides for MILE and SACM. See slide 12 of this PPT, where SACM is on the far left (Configuration and possibly Assets) and MILE is circled. http://scap.nist.gov/events/2011/itsac/presentations/day2/Moriarty%20-%20IE= TF%20MILE,%20Improving%20Incident%20and%20Information%20Sharing%20Standards= .pdf I had better versions of that slide, but I am not able to find them online and don't want to clog up everyone's email. This should be good enough. DOTS could feed into MILE, where reports from DOTS are part of a larger investigation or set of indicators being exchanged using DOTS formatted data within an IODEF envelope. It's a specific sub-use case that has different enough requirements that it should not be in MILE. I2NSF is concerned with tenant's ability to provision/change rules on hosted security devices, allowing tenants to make these changes. This is different from SACM as SACM is assessing posture and not doing things like managing firewall rule sets or changing filtering options for flow based protocols. On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville < adam.w.montville@gmail.com> wrote: > > On Apr 1, 2015, at 4:15 PM, Linda Dunbar wrote: > > Adam, > > You said: > *sacm is, at its core, primarily interested in assessing endpoint > attributes. This means expressing the desired attribute to collect, > collecting it, and evaluating it against some expressed expectation. The > assessment result is provided for downstream use, irrespective of what th= at > use might be. Additionally, collection could be the only results provide= d > (if no evaluation piece is needed).* > > How are the =E2=80=9Cdesired attributes=E2=80=9D expressed by SACM? How a= re the > =E2=80=9Cexpectation=E2=80=9D being specified? > > > > At this point we are working on an information model [1] and have not yet > arrived at data models. I would anticipate several data models to exist, > depending on the source of the data being collected. > > > [1] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ (= note > that this will almost certainly updated between now and IETF 93). > Intermediate work can be found here: > https://github.com/sacmwg/draft-ietf-sacm-information-model). > > > > > Thanks, Linda > > *From:* I2nsf [mailto:i2nsf-bounces@ietf.org ] *O= n > Behalf Of *Adam W. Montville > *Sent:* Saturday, March 28, 2015 7:41 AM > *To:* Melinda Shore > *Cc:* i2nsf@ietf.org > *Subject:* Re: [I2nsf] The defense 'ecosystem' paradigm > > Having a cross-group understanding of the relationship between i2nsf, > sacm, mile, and dots would be beneficial. I=E2=80=99m less familiar with= i2nsf and > dots (in the details). > > > It seems that mile, i2nsf, and dots would all benefit from sacm in some > way, as they are largely downstream from the core problem sacm intends to > solve. > > i2nsf seeks to express and evaluate network service related information, > which will ultimately need to identify specific endpoints (virtual or > otherwise) to collect specific attributes, evaluate them against some > expressed expectation, then make sense of that at the i2nsf level. > > mile could benefit from sacm by leveraging the attribute expression and > evaluation formats. Additionally, the =E2=80=9Cad hoc=E2=80=9D explorato= ry tools often > favored during incident response could use sacm as a means of that > exploration. > > dots is my least understood domain, but after speaking with Ana Hedanping > for a brief time, it seems that dots will have some need to express > endpoint attributes, collect values, and evaluate them against some > expectation as well. Only, this will be more of a =E2=80=9Creal time=E2= =80=9D circumstance > (I presume). > > As Bob pointed out, these are all parts of a whole - the =E2=80=9Cdefense > ecosystem paradigm=E2=80=9D. And, while deriving a specific taxonomy co= uld be > useful, it=E2=80=99s already done in a way. The =E2=80=9Cdefense =E2=80= =98ecosystem=E2=80=99 paradigm" > seems to me like a synonym for =E2=80=9Csecurity program=E2=80=9D, and th= ose are well > covered. Think ISO 27000 series, NIST 800-53, PCI DSS, COBIT, 20 Critica= l > Security Controls, and the like. In fact, I used a similar perspective (= I > called it =E2=80=9Cframe of reference=E2=80=9D) at a sacm BoF (back in At= lanta during IETF > 85 [1]) to frame the =E2=80=9Cspace=E2=80=9D in which sacm plays. I thin= k mile , i2nsf, > and dots all play in this same space (see the second, third, and fourth > slides). > > What seems important is that we recognize (and name) the different > business processes we are supporting. This should help us recognize the > relationships between our work. > > Thoughts? > > Regards, > > Adam > > [1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf > > > > > On Mar 27, 2015, at 9:01 PM, Melinda Shore > wrote: > > I'm rather surprised that nobody has answered this! > > I think this is a very reasonable approach, with the > caveat that what's needed *here* is not so much an architecture > but an actual protocol conveying actual data between actual > network elements. This may be why other middlebox protocols > have been able to move forward, even while being > redundant, while this effort has been stuck. It seems to > me, based on discussions during the week and on both the > input to and the output from the dots BOF, that there's > still room for a good backend protocol to convey requests > to what used to be called policy enforcement points based > on the active threat data being shared through a dots-like mechanism. > But that's a very narrow example. > > So, I think to the extent that a taxonomy can help this > effort develop a narrow focus, it would be a very helpful > thing indeed. But it's got to be very applied - I am > skeptical about the value of high-level architectures in > the IETF. > > Melinda > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > --=20 Best regards, Kathleen --089e011774850efe9c051467430e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have been meaning to respond on h= ow MILE and SACM fit with I2NSF and DOTS in a bigger picture view.=C2=A0 I = just have old slides for MILE and SACM.=C2=A0 See slide 12 of this PPT, whe= re SACM is on the far left (Configuration and possibly Assets) and MILE is = circled.

I= had better versions of that slide, but I am not able to find them online a= nd don't want to clog up everyone's email.=C2=A0 This should be goo= d enough.

DOTS could feed into MILE, where reports= from DOTS are part of a larger investigation or set of indicators being ex= changed using DOTS formatted data within an IODEF envelope.=C2=A0 It's = a specific sub-use case that has different enough requirements that it shou= ld not be in MILE.

I2NSF is concerned with tenant&= #39;s ability to provision/change rules on hosted security devices, allowin= g tenants to make these changes.=C2=A0 This is different from SACM as SACM = is assessing posture and not doing things like managing firewall rule sets = or changing filtering options for flow based protocols.=C2=A0

On Thu, Apr 2, 2015= at 7:41 AM, Adam W. Montville <adam.w.montville@gmail.com>= ; wrote:

On= Apr 1, 2015, at 4:15 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:
Adam,
=C2=A0
You said:
sacm is, at its core, primaril= y interested in assessing endpoint attributes.=C2=A0 This means expressing = the desired attribute to collect, collecting it, and evaluating it against = some expressed expectation.=C2=A0 The assessment result is provided for dow= nstream use, irrespective of what that use might be.=C2=A0 Additionally, co= llection could be the only results provided (if no evaluation piece is need= ed).
=C2=A0
How are the =E2=80=9Cdesired attri= butes=E2=80=9D expressed by SACM? How are the =E2=80=9Cexpectation=E2=80=9D= being specified?

=
At this point we are working on an information model = [1] and have not yet arrived at data models.=C2=A0 I would anticipate sever= al data models to exist, depending on the source of the data being collecte= d.


[1]=C2=A0= https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/=C2= =A0(note that this will almost certainly updated between now and IETF 93).= =C2=A0 Intermediate work can be found here:=C2=A0https://git= hub.com/sacmwg/draft-ietf-sacm-information-model).



=C2=A0
Thanks, Linda
=C2= =A0
From:=C2=A0I2nsf [mailto:i2nsf-bounces@ietf.org]=C2=A0On B= ehalf Of=C2=A0Adam W. Montville
Sent:=C2= =A0Saturday, March 28, 2015 7:41 AM
To:=C2=A0= Melinda Shore
Cc:=C2=A0i2nsf@ietf.org
Subject:=C2=A0Re: [I2nsf] The defense 'ecosystem' paradigm
=C2=A0
Having a cross-group understanding of the relationship bet= ween i2nsf, sacm, mile, and dots would be beneficial.=C2=A0 I=E2=80=99m les= s familiar with i2nsf and dots (in the details).=C2=A0
<= div>
=C2=A0
=C2=A0
It= seems that mile, i2nsf, and dots would all benefit from sacm in some way, = as they are largely downstream from the core problem sacm intends to solve.= =C2=A0
=C2=A0<= u>
i2nsf seeks to express and ev= aluate network service related information, which will ultimately need to i= dentify specific endpoints (virtual or otherwise) to collect specific attri= butes, evaluate them against some expressed expectation, then make sense of= that at the i2nsf level.
=C2=A0
mile could = benefit from sacm by leveraging the attribute expression and evaluation for= mats.=C2=A0 Additionally, the =E2=80=9Cad hoc=E2=80=9D exploratory tools of= ten favored during incident response could use sacm as a means of that expl= oration.
=C2=A0=
dots is my least understood = domain, but after speaking with Ana Hedanping for a brief time, it seems th= at dots will have some need to express endpoint attributes, collect values,= and evaluate them against some expectation as well.=C2=A0 Only, this will = be more of a =E2=80=9Creal time=E2=80=9D circumstance (I presume).
=C2=A0
As Bob pointed out, these are all parts of a = whole - the =E2=80=9Cdefense ecosystem paradigm=E2=80=9D. =C2=A0 And, while= deriving a specific taxonomy could be useful, it=E2=80=99s already done in= a way.=C2=A0 The =E2=80=9Cdefense =E2=80=98ecosystem=E2=80=99 paradigm&quo= t; seems to me like a synonym for =E2=80=9Csecurity program=E2=80=9D, and t= hose are well covered.=C2=A0 Think ISO 27000 series, NIST 800-53, PCI DSS, = COBIT, 20 Critical Security Controls, and the like.=C2=A0 In fact, I used a= similar perspective (I called it =E2=80=9Cframe of reference=E2=80=9D) at = a sacm BoF (back in Atlanta during IETF 85 [1]) to frame the =E2=80=9Cspace= =E2=80=9D in which sacm plays.=C2=A0 I think mile =C2=A0, i2nsf, and dots a= ll play in this same space (see the second, third, and fourth slides). =C2= =A0
=C2=A0
What seems important is that we r= ecognize (and name) the different business processes we are supporting.=C2= =A0 This should help us recognize the relationships between our work.
=C2=A0
<= /div>
Thoughts?
=C2=A0
Regards,
= =C2=A0
=C2=A0
=C2=A0<= /div>
=C2=A0
=
On Mar 27, 2015, at 9:01 PM, Melinda Shore <melinda.shore@gmail.com> wrote:
=C2=A0
I'm rather surprised that nobody has answered this!

I thin= k this is a very reasonable approach, with the
caveat that what's ne= eded *here* is not so much an architecture
but an actual protocol convey= ing actual data between actual
network elements.=C2=A0 This may be why o= ther middlebox protocols
<rimshot> have been able to move forward,= even while being
redundant, while this effort has been stuck.=C2=A0 It = seems to
me, based on discussions during the week and on both the
inp= ut to and the output from the dots BOF, that there's
still room for = a good backend protocol to convey requests
to what used to be called pol= icy enforcement points based
on the active threat data being shared thro= ugh a dots-like mechanism.
But that's a very narrow example.

= So, I think to the extent that a taxonomy can help this
effort develop a= narrow focus, it would be a very helpful
thing indeed.=C2=A0 But it'= ;s got to be very applied - I am
skeptical about the value of high-level= architectures in
the IETF.

Melinda

______________________= _________________________
I2nsf mailing list
I2nsf@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/i2nsf
=


= _______________________________________________
I2nsf mailing list
I2nsf@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/i2nsf




--

Best regards,
Ka= thleen
--089e011774850efe9c051467430e-- From nobody Thu Apr 23 10:15:11 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002261ACDBC; Thu, 23 Apr 2015 10:13: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 xy2gqxZa2nZv; Thu, 23 Apr 2015 10:13:03 -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 5311B1ACDA7; Thu, 23 Apr 2015 10:13:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT49007; Thu, 23 Apr 2015 17:12:59 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Apr 2015 18:12:58 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Thu, 23 Apr 2015 10:12:53 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" , "i2rs@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "pcp@ietf.org" , "sfc@ietf.org" , "dots@ietf.org" , "opsawg@ietf.org" , "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" Thread-Topic: I2NSF: Interface to network security functions : problem-statement, framework, use cases, and potential solution Thread-Index: AQHQfeL7u793L89A7kyGIFebPlU0DZ1aykFw Date: Thu, 23 Apr 2015 17:12:53 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C09765@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Thu, 23 Apr 2015 10:15:05 -0700 Cc: "mile@ietf.org" Subject: [I2nsf] I2NSF: Interface to network security functions : problem-statement, framework, use cases, and potential solution X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:13:05 -0000 VGhlICJpMm5zZi1wcm9ibGVtLXN0YXRlbWVudCIgZHJhZnQgZGVzY3JpYmVzIHRoZSBtb3RpdmF0 aW9uIGFuZCB0aGUgcHJvYmxlbSBzcGFjZSBhc3NvY2lhdGVkIHdpdGggc2VydmljZSBwcm92aWRl cnMgcHJvdmlkaW5nIGhvc3RlZCBzZWN1cml0eSBzb2x1dGlvbnMgdG8gZGVsaXZlciBjb3N0LWVm ZmVjdGl2ZSBtYW5hZ2VkIHNlY3VyaXR5IHNlcnZpY2VzIHRvIGVudGVycHJpc2UgY3VzdG9tZXJz IHdobyBkb24ndCBvd24gb3IgaGF2ZSB0aGUgc2VjdXJpdHkgZnVuY3Rpb25zIG9uIHRoZWlyIHBy ZW1pc2VzLiANCg0KU2luY2UgdGhlIGkybnNmLXByb2JsZW0tc3RhdGVtZW50LTAxIGRyYWZ0LCB0 aHJlZSBJMk5TRiB1c2UgY2FzZSBkcmFmdHMsIGEgZ2FwIGFuYWx5c2lzIGRyYWZ0LCBhbmQgYSBw YWNrZXQtYmFzZWQgcGFyYWRpZ20gZHJhZnQgaGF2ZSBiZWVuIHB1Ymxpc2hlZC4gDQpXZSByZW1v dmVkIHRoZSByZWR1bmRhbnQgY29udGVudCBmcm9tIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFm dCwgbWFraW5nIGl0IGZvY3VzIGV4Y2x1c2l2ZWx5IG9uIHRoZSBwcm9ibGVtIHNwYWNlIG9mIHNl Y3VyaXR5IGZ1bmN0aW9ucyBub3QgaG9zdGVkIG9uIGN1c3RvbWVyJ3MgcHJlbWlzZXMgYW5kIGJl aW5nIGRpc3RyaWJ1dGVkIChkcml2ZW4gYnkgTkZWIGFuZCBob3N0ZWQgc2VjdXJpdHkgc2Vydmlj ZXMpLg0KDQpJbiBjb25qdW5jdGlvbiB3aXRoIHRoZSAiaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnRz IiwgdGhlcmUgYXJlIGFsc28gSTJOU0YgZnJhbWV3b3JrIGRyYWZ0LCBwb3RlbnRpYWwgSTJOU0Yg c29sdXRpb24gZHJhZnQsIHVzZSBjYXNlIGRyYWZ0cyAodW5kZXIgcHJvY2VzcyBvZiBtZXJnaW5n KSwgZ2FwLWFuYWx5c2lzIGFuZCBkYXRhIG1vZGVsaW5nIGRyYWZ0Og0KDQpodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmsvDQoNCmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9wZXotaTJuc2YtcGFja2V0Lw0KDQpo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpYS1pMm5zZi1jYXBhYmlsaXR5 LWludGVyZmFjZS1pbS8gKG5ldyByZXZpc2lvbiBpcyB0byBiZSB1cGxvYWRlZCBzb29uIHRvIHJl ZmxlY3QgdGhlIGRpc2N1c3Npb24gb2YgRjJGIG1lZXRpbmdzIGF0IElFVEY5MiBEYWxsYXMpLiAN Cg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXN0b3ItaTJuc2YtYWNj ZXNzLXVzZWNhc2VzLw0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xaS1p Mm5zZi1hY2Nlc3MtbmV0d29yay11c2VjYXNlLw0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC16YXJueS1pMm5zZi1kYXRhLWNlbnRlci11c2UtY2FzZXMvDQoNCmh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctZ2FwLWFuYWx5c2lzLw0KDQpJMk5T RiBpcyBhYm91dCBzZWN1cml0eSBmdW5jdGlvbnMgbWFuYWdlbWVudC4gVGhlIHVsdGltYXRlIGdv YWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxlIGVudGVycHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkg ZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24gdGhlaXIgb3duIHByZW1pc2UgYnV0IGluc3RlYWQgaG9z dGVkIGluIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCB0byBlc3RhYmxpc2ggaG93IHRvIGNvbW11 bmljYXRlIGRlc2lyZWQgc2VjdXJpdHkgcG9saWNpZXMgdG8gTlNGIGFuZCBob3cgdG8gZ2V0IHBl cmZvcm1hbmNlIGRhdGEgb3IgcmVwb3J0IG91dCBvZiBOU0YuICANCg0KQWxzbyBjb3B5IHRvIHRo ZSBJMk5TRiByZWxldmFudCBJRVRGIFdHczogSTJSUywgTkVUTU9ELCBORVRDT05GLCBTQUNNLCBN SUxFLCBQQ1AsIERPVFMsIFNGQywgYW5kIE9wQXJlYXMsIGluIGhvcGUgdG8gZ2V0IGZlZWRiYWNr IGFuZCBzdWdnZXN0aW9ucyBmcm9tIHdpZGVyIGF1ZGllbmNlLiANCg0KVGhhbmtzIGluIGFkdmFu Y2UsIA0KDQpMaW5kYSBEdW5iYXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10gDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgMTE6MzEgQU0NClRvOiBNb2hhbWVk IEJvdWNhZGFpcjsgU2hhaWJhbCBDaGFrcmFiYXJ0eTsgTGluZGEgRHVuYmFyOyBDaHJpc3RpYW4g SmFjcXVlbmV0OyBNeW8gWmFybnk7IENocmlzdGlhbiBKYWNxdWVuZXQ7IE15byBaYXJueTsgU2hh aWJhbCBDaGFrcmFiYXJ0eTsgTGluZGEgRHVuYmFyOyBNb2hhbWVkIEJvdWNhZGFpcg0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxl bS1zdGF0ZW1lbnQtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWR1bmJh ci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudC0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgTGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZToJCWRyYWZ0LWR1bmJhci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudA0KUmV2aXNp b246CTAzDQpUaXRsZToJCUludGVyZmFjZSB0byBOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyAo STJOU0YpIFByb2JsZW0gU3RhdGVtZW50DQpEb2N1bWVudCBkYXRlOgkyMDE1LTA0LTIzDQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyMQ0KVVJMOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1pMm5zZi1wcm9i bGVtLXN0YXRlbWVudC0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQvDQpIdG1s aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHVuYmFyLWkybnNm LXByb2JsZW0tc3RhdGVtZW50LTAzDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTAzDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG1vdGl2YXRpb24gYW5k IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBmb3INCiAgIEludGVyZmFjZSB0byBOZXR3b3JrIFNlY3Vy aXR5IEZ1bmN0aW9ucyAoSTJOU0YpLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQo= From nobody Thu Apr 23 11:20:28 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82061B3179 for ; Thu, 23 Apr 2015 11:20:27 -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 r51Cvgna-BJ5 for ; Thu, 23 Apr 2015 11:20:25 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 47A1D1B3161 for ; Thu, 23 Apr 2015 11:20:24 -0700 (PDT) Received: by oica37 with SMTP id a37so21531483oic.0 for ; Thu, 23 Apr 2015 11:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VklZxVHLV4qe6iabAJKqdjgmKklVuDT6qYq4fQuG+uc=; b=zP2NNsIqMdRfrGsI5KaShNvIE2d4pbjGh85gs1RLrQDoPmvJhwzCAMaBdxWAmZ8T9+ fE0Ocbq+NmD5+jlfyMfgd0Emiy5pS0MYXSTqYhv01oZZ8CWfhtmO+raHZD2Pcjd0gFZD w4dUvjXgXFQL7bV7OIvPqS0HPIR22GH+y5blBxAmo8uQ4EKxkVPPin7LSgIKrqzGeEpy ofjxQdyKjfBYTscwnLETCTR68xq9gr13B7QfgnBVE9k/Gr1mdaMi3gWlKuNONFLm/jiT Qd3BzKgE2+BtDDUcjslTGMcl7hJ0THPzCkuavHP7J5PXEi3LUO34xC0+ry9DikVIFfKW E9rg== X-Received: by 10.60.37.73 with SMTP id w9mr3694330oej.49.1429813222678; Thu, 23 Apr 2015 11:20:22 -0700 (PDT) Received: from adams-mac-mini.attlocal.net ([2602:306:3406:4830:3dcc:65b3:7234:d74b]) by mx.google.com with ESMTPSA id x18sm5180711oep.1.2015.04.23.11.20.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Apr 2015 11:20:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EA735003-75E4-4F86-B6D2-4752D8893CD4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Adam W. Montville" In-Reply-To: Date: Thu, 23 Apr 2015 13:20:19 -0500 Message-Id: References: <5512F1ED.8020104@htt-consult.com> <55160B74.1010009@gmail.com> <032CF466-C78E-46C7-A171-5176555A97DA@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657BFFB52@dfweml701-chm> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "i2nsf@ietf.org" , Melinda Shore , Linda Dunbar Subject: Re: [I2nsf] The defense 'ecosystem' paradigm X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 18:20:28 -0000 --Apple-Mail=_EA735003-75E4-4F86-B6D2-4752D8893CD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Has anyone else been able to grab these slides? It may be my network, = but I can=E2=80=99t get to them completely - the download hangs. > On Apr 23, 2015, at 12:03 PM, Kathleen Moriarty = wrote: >=20 > Hi, >=20 > I have been meaning to respond on how MILE and SACM fit with I2NSF and = DOTS in a bigger picture view. I just have old slides for MILE and = SACM. See slide 12 of this PPT, where SACM is on the far left = (Configuration and possibly Assets) and MILE is circled. > = http://scap.nist.gov/events/2011/itsac/presentations/day2/Moriarty%20-%20I= ETF%20MILE,%20Improving%20Incident%20and%20Information%20Sharing%20Standar= ds.pdf = >=20 > I had better versions of that slide, but I am not able to find them = online and don't want to clog up everyone's email. This should be good = enough. >=20 > DOTS could feed into MILE, where reports from DOTS are part of a = larger investigation or set of indicators being exchanged using DOTS = formatted data within an IODEF envelope. It's a specific sub-use case = that has different enough requirements that it should not be in MILE. >=20 > I2NSF is concerned with tenant's ability to provision/change rules on = hosted security devices, allowing tenants to make these changes. This = is different from SACM as SACM is assessing posture and not doing things = like managing firewall rule sets or changing filtering options for flow = based protocols.=20 >=20 > On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville = > wrote: >=20 >> On Apr 1, 2015, at 4:15 PM, Linda Dunbar > wrote: >>=20 >> Adam, >> =20 >> You said: >> sacm is, at its core, primarily interested in assessing endpoint = attributes. This means expressing the desired attribute to collect, = collecting it, and evaluating it against some expressed expectation. = The assessment result is provided for downstream use, irrespective of = what that use might be. Additionally, collection could be the only = results provided (if no evaluation piece is needed). >> =20 >> How are the =E2=80=9Cdesired attributes=E2=80=9D expressed by SACM? = How are the =E2=80=9Cexpectation=E2=80=9D being specified? >=20 >=20 > At this point we are working on an information model [1] and have not = yet arrived at data models. I would anticipate several data models to = exist, depending on the source of the data being collected. >=20 >=20 > [1] = https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ = = (note that this will almost certainly updated between now and IETF 93). = Intermediate work can be found here: = https://github.com/sacmwg/draft-ietf-sacm-information-model = ). >=20 >=20 >=20 >> =20 >> Thanks, Linda >> =20 >> From: I2nsf [mailto:i2nsf-bounces@ietf.org = ] On Behalf Of Adam W. Montville >> Sent: Saturday, March 28, 2015 7:41 AM >> To: Melinda Shore >> Cc: i2nsf@ietf.org >> Subject: Re: [I2nsf] The defense 'ecosystem' paradigm >> =20 >> Having a cross-group understanding of the relationship between i2nsf, = sacm, mile, and dots would be beneficial. I=E2=80=99m less familiar = with i2nsf and dots (in the details).=20 >> =20 >> =20 >> It seems that mile, i2nsf, and dots would all benefit from sacm in = some way, as they are largely downstream from the core problem sacm = intends to solve. =20 >> =20 >> i2nsf seeks to express and evaluate network service related = information, which will ultimately need to identify specific endpoints = (virtual or otherwise) to collect specific attributes, evaluate them = against some expressed expectation, then make sense of that at the i2nsf = level. >> =20 >> mile could benefit from sacm by leveraging the attribute expression = and evaluation formats. Additionally, the =E2=80=9Cad hoc=E2=80=9D = exploratory tools often favored during incident response could use sacm = as a means of that exploration. >> =20 >> dots is my least understood domain, but after speaking with Ana = Hedanping for a brief time, it seems that dots will have some need to = express endpoint attributes, collect values, and evaluate them against = some expectation as well. Only, this will be more of a =E2=80=9Creal = time=E2=80=9D circumstance (I presume). >> =20 >> As Bob pointed out, these are all parts of a whole - the =E2=80=9Cdefen= se ecosystem paradigm=E2=80=9D. And, while deriving a specific = taxonomy could be useful, it=E2=80=99s already done in a way. The = =E2=80=9Cdefense =E2=80=98ecosystem=E2=80=99 paradigm" seems to me like = a synonym for =E2=80=9Csecurity program=E2=80=9D, and those are well = covered. Think ISO 27000 series, NIST 800-53, PCI DSS, COBIT, 20 = Critical Security Controls, and the like. In fact, I used a similar = perspective (I called it =E2=80=9Cframe of reference=E2=80=9D) at a sacm = BoF (back in Atlanta during IETF 85 [1]) to frame the =E2=80=9Cspace=E2=80= =9D in which sacm plays. I think mile , i2nsf, and dots all play in = this same space (see the second, third, and fourth slides). =20 >> =20 >> What seems important is that we recognize (and name) the different = business processes we are supporting. This should help us recognize the = relationships between our work. >> =20 >> Thoughts? >> =20 >> Regards, >> =20 >> Adam >> =20 >> [1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf = >> =20 >> =20 >> =20 >> On Mar 27, 2015, at 9:01 PM, Melinda Shore > wrote: >> =20 >> I'm rather surprised that nobody has answered this! >>=20 >> I think this is a very reasonable approach, with the >> caveat that what's needed *here* is not so much an architecture >> but an actual protocol conveying actual data between actual >> network elements. This may be why other middlebox protocols >> have been able to move forward, even while being >> redundant, while this effort has been stuck. It seems to >> me, based on discussions during the week and on both the >> input to and the output from the dots BOF, that there's >> still room for a good backend protocol to convey requests >> to what used to be called policy enforcement points based >> on the active threat data being shared through a dots-like mechanism. >> But that's a very narrow example. >>=20 >> So, I think to the extent that a taxonomy can help this >> effort develop a narrow focus, it would be a very helpful >> thing indeed. But it's got to be very applied - I am >> skeptical about the value of high-level architectures in >> the IETF. >>=20 >> Melinda >>=20 >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf = >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf = >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_EA735003-75E4-4F86-B6D2-4752D8893CD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Has anyone else been able to grab these slides?  It may = be my network, but I can=E2=80=99t get to them completely - the download = hangs.



On Apr 23, 2015, at 12:03 PM, = Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:

Hi,

I = have been meaning to respond on how MILE and SACM fit with I2NSF and = DOTS in a bigger picture view.  I just have old slides for MILE and = SACM.  See slide 12 of this PPT, where SACM is on the far left = (Configuration and possibly Assets) and MILE is circled.
http://scap.nist.gov/events/2011/itsac/presentations/day2/Moria= rty%20-%20IETF%20MILE,%20Improving%20Incident%20and%20Information%20Sharin= g%20Standards.pdf

I had better versions of that slide, = but I am not able to find them online and don't want to clog up = everyone's email.  This should be good enough.

DOTS could feed into = MILE, where reports from DOTS are part of a larger investigation or set = of indicators being exchanged using DOTS formatted data within an IODEF = envelope.  It's a specific sub-use case that has different enough = requirements that it should not be in MILE.

I2NSF is concerned with tenant's = ability to provision/change rules on hosted security devices, allowing = tenants to make these changes.  This is different from SACM as SACM = is assessing posture and not doing things like managing firewall rule = sets or changing filtering options for flow based = protocols. 

On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville = <adam.w.montville@gmail.com> wrote:

On Apr 1, 2015, at 4:15 PM, Linda Dunbar = <linda.dunbar@huawei.com> wrote:

Adam,
 
You said:
sacm is, at = its core, primarily interested in assessing endpoint attributes.  = This means expressing the desired attribute to collect, collecting it, = and evaluating it against some expressed expectation.  The = assessment result is provided for downstream use, irrespective of what = that use might be.  Additionally, collection could be the only = results provided (if no evaluation piece is needed).
 
How are the =E2=80=9Cdesired attributes=E2=80=9D expressed = by SACM? How are the =E2=80=9Cexpectation=E2=80=9D being = specified?


At this point we are working on an information model [1] and = have not yet arrived at data models.  I would anticipate several = data models to exist, depending on the source of the data being = collected.


[1] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-mo= del/ (note that this will almost certainly updated between now = and IETF 93).  Intermediate work can be found here: https://github.com/sacmwg/draft-ietf-sacm-information-model= ).



 
Thanks, Linda
 
From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Adam W. Montville
Sent: Saturday, March 28, = 2015 7:41 AM
To: Melinda Shore
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] The = defense 'ecosystem' paradigm
 
Having a cross-group understanding of the relationship = between i2nsf, sacm, mile, and dots would be beneficial.  I=E2=80=99m= less familiar with i2nsf and dots (in the details). 
 
 
It seems that mile, i2nsf, and dots would all = benefit from sacm in some way, as they are largely downstream from the = core problem sacm intends to solve.  
 
i2nsf seeks to express and evaluate network = service related information, which will ultimately need to identify = specific endpoints (virtual or otherwise) to collect specific = attributes, evaluate them against some expressed expectation, then make = sense of that at the i2nsf level.
 
mile could benefit from sacm by leveraging the = attribute expression and evaluation formats.  Additionally, the = =E2=80=9Cad hoc=E2=80=9D exploratory tools often favored during incident = response could use sacm as a means of that exploration.
 
dots is my least understood domain, but after speaking with = Ana Hedanping for a brief time, it seems that dots will have some need = to express endpoint attributes, collect values, and evaluate them = against some expectation as well.  Only, this will be more of a = =E2=80=9Creal time=E2=80=9D circumstance (I presume).
 
As Bob pointed out, these are all parts of a = whole - the =E2=80=9Cdefense ecosystem paradigm=E2=80=9D.   And, = while deriving a specific taxonomy could be useful, it=E2=80=99s already = done in a way.  The =E2=80=9Cdefense =E2=80=98ecosystem=E2=80=99 = paradigm" seems to me like a synonym for =E2=80=9Csecurity program=E2=80=9D= , and those are well covered.  Think ISO 27000 series, NIST 800-53, = PCI DSS, COBIT, 20 Critical Security Controls, and the like.  In = fact, I used a similar perspective (I called it =E2=80=9Cframe of = reference=E2=80=9D) at a sacm BoF (back in Atlanta during IETF 85 [1]) = to frame the =E2=80=9Cspace=E2=80=9D in which sacm plays.  I think = mile  , i2nsf, and dots all play in this same space (see the = second, third, and fourth slides).  
 
What seems important is that we recognize (and = name) the different business processes we are supporting.  This = should help us recognize the relationships between our work.
 
Thoughts?
 
Regards,
 
Adam
 
[1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf=
 
 
 
On Mar 27, 2015, at 9:01 PM, Melinda Shore = <melinda.shore@gmail.com> wrote:
 
I'm rather surprised that nobody has answered = this!

I think this is a very reasonable = approach, with the
caveat that what's needed *here* is not = so much an architecture
but an actual protocol conveying = actual data between actual
network elements.  This = may be why other middlebox protocols
<rimshot> have = been able to move forward, even while being
redundant, = while this effort has been stuck.  It seems to
me, = based on discussions during the week and on both the
input = to and the output from the dots BOF, that there's
still = room for a good backend protocol to convey requests
to = what used to be called policy enforcement points based
on = the active threat data being shared through a dots-like mechanism.
But that's a very narrow example.

So, I think to the extent that a taxonomy can help this
effort develop a narrow focus, it would be a very helpful
thing indeed.  But it's got to be very applied - I am
skeptical about the value of high-level architectures in
the IETF.

Melinda

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf




--

Best regards,
Kathleen

= --Apple-Mail=_EA735003-75E4-4F86-B6D2-4752D8893CD4-- From nobody Thu Apr 23 15:07:32 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E15B1A002D for ; Thu, 23 Apr 2015 15:07:30 -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, HTML_MESSAGE=0.001, 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 4IZJkCtehiyn for ; Thu, 23 Apr 2015 15:07:27 -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 34AE61A00C8 for ; Thu, 23 Apr 2015 15:07:21 -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 BRT62872; Thu, 23 Apr 2015 22:07:19 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Apr 2015 23:07:18 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Thu, 23 Apr 2015 15:07:16 -0700 From: Linda Dunbar To: Kathleen Moriarty , "Adam W. Montville" Thread-Topic: [I2nsf] The defense 'ecosystem' paradigm Thread-Index: AQHQZyIxU6gyBSrNlkOm5jaf0cbqeJ0xnUQAgACyxYCABmLpAIABaB2AgCFa7AD//92EgA== Date: Thu, 23 Apr 2015 22:07:16 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C09ADA@dfweml701-chm> References: <5512F1ED.8020104@htt-consult.com> <55160B74.1010009@gmail.com> <032CF466-C78E-46C7-A171-5176555A97DA@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657BFFB52@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.72] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C09ADAdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" , Melinda Shore Subject: Re: [I2nsf] The defense 'ecosystem' paradigm X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 22:07:30 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C09ADAdfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2F0aGxlZW4sDQoNClBhZ2UgMTIgaGFzIEluY2lkZW50L1JJRC9JT0RFRiBjaXJjbGVkIGluIEJs dWUgKElFVEYpLiBBcmUgdGhleSBhbGwgcGFydCBvZiBNSUxFPw0KDQpZb3VyIHN1bW1hcnkgb2Yg STJOU0YgaXMgdmVyeSBhY2N1cmF0ZTogcHJvdmlkZSBpbnRlcmZhY2UgZm9yIGN1c3RvbWVycyB0 byBzcGVjaWZ5L21vbml0b3IgdGhlaXIgc2VjdXJpdHkgcG9saWNlcyB0byBiZSBlbmZvcmNlZCBi eSBTZWN1cml0eSBGdW5jdGlvbnMgaG9zdGVkIGJ5IHByb3ZpZGVycy4NCg0KQ3VzdG9tZXJzIG1h eSBhbHNvIHJlcXVlc3Qgc3BlY2lmaWMgcHJvZmlsZSBvciBzaWduYXR1cmUgZmlsZSBmb3Igc2Vj dXJpdHkgZnVuY3Rpb25zIGhvc3RlZCBpbiBwcm92aWRlciBkb21haW4gKGUuZy4gSVBTOjxzaWdu YXR1cmU+KS4gVGhlIGludGVyZmFjZSBuZWVkIHRvIGhhdmUgdGhpcyBleHRyYSBhdHRyaWJ1dGUs IGluIGFkZGl0aW9uIHRvIHRoZSDigJxTdWJqZWN0IG1hdGNoaW5nIChiaXRzL2ZpZWxkcyBmcm9t IHBhY2tldHMp4oCdLCDigJxvYmplY3QgbWF0Y2hpbmcgKGNvbnRleHR1YWw6IGV2ZW50cywgdGlt ZSwgZ2VvLWxvY2F0aW9uLCBldGMpLiBUaGlzIGlzIGRlZmluaXRlbHkgZGlmZmVyZW50IGZyb20g dGhlIOKAnEluY2lkZW504oCdIGRlc2NyaWJlZCBieSBNSUxFLg0KDQpMaW5kYQ0KDQpGcm9tOiBL YXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29t XQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDIzLCAyMDE1IDEyOjA0IFBNDQpUbzogQWRhbSBXLiBN b250dmlsbGUNCkNjOiBMaW5kYSBEdW5iYXI7IGkybnNmQGlldGYub3JnOyBNZWxpbmRhIFNob3Jl DQpTdWJqZWN0OiBSZTogW0kybnNmXSBUaGUgZGVmZW5zZSAnZWNvc3lzdGVtJyBwYXJhZGlnbQ0K DQpIaSwNCg0KSSBoYXZlIGJlZW4gbWVhbmluZyB0byByZXNwb25kIG9uIGhvdyBNSUxFIGFuZCBT QUNNIGZpdCB3aXRoIEkyTlNGIGFuZCBET1RTIGluIGEgYmlnZ2VyIHBpY3R1cmUgdmlldy4gIEkg anVzdCBoYXZlIG9sZCBzbGlkZXMgZm9yIE1JTEUgYW5kIFNBQ00uICBTZWUgc2xpZGUgMTIgb2Yg dGhpcyBQUFQsIHdoZXJlIFNBQ00gaXMgb24gdGhlIGZhciBsZWZ0IChDb25maWd1cmF0aW9uIGFu ZCBwb3NzaWJseSBBc3NldHMpIGFuZCBNSUxFIGlzIGNpcmNsZWQuDQpodHRwOi8vc2NhcC5uaXN0 Lmdvdi9ldmVudHMvMjAxMS9pdHNhYy9wcmVzZW50YXRpb25zL2RheTIvTW9yaWFydHklMjAtJTIw SUVURiUyME1JTEUsJTIwSW1wcm92aW5nJTIwSW5jaWRlbnQlMjBhbmQlMjBJbmZvcm1hdGlvbiUy MFNoYXJpbmclMjBTdGFuZGFyZHMucGRmDQoNCkkgaGFkIGJldHRlciB2ZXJzaW9ucyBvZiB0aGF0 IHNsaWRlLCBidXQgSSBhbSBub3QgYWJsZSB0byBmaW5kIHRoZW0gb25saW5lIGFuZCBkb24ndCB3 YW50IHRvIGNsb2cgdXAgZXZlcnlvbmUncyBlbWFpbC4gIFRoaXMgc2hvdWxkIGJlIGdvb2QgZW5v dWdoLg0KDQpET1RTIGNvdWxkIGZlZWQgaW50byBNSUxFLCB3aGVyZSByZXBvcnRzIGZyb20gRE9U UyBhcmUgcGFydCBvZiBhIGxhcmdlciBpbnZlc3RpZ2F0aW9uIG9yIHNldCBvZiBpbmRpY2F0b3Jz IGJlaW5nIGV4Y2hhbmdlZCB1c2luZyBET1RTIGZvcm1hdHRlZCBkYXRhIHdpdGhpbiBhbiBJT0RF RiBlbnZlbG9wZS4gIEl0J3MgYSBzcGVjaWZpYyBzdWItdXNlIGNhc2UgdGhhdCBoYXMgZGlmZmVy ZW50IGVub3VnaCByZXF1aXJlbWVudHMgdGhhdCBpdCBzaG91bGQgbm90IGJlIGluIE1JTEUuDQoN CkkyTlNGIGlzIGNvbmNlcm5lZCB3aXRoIHRlbmFudCdzIGFiaWxpdHkgdG8gcHJvdmlzaW9uL2No YW5nZSBydWxlcyBvbiBob3N0ZWQgc2VjdXJpdHkgZGV2aWNlcywgYWxsb3dpbmcgdGVuYW50cyB0 byBtYWtlIHRoZXNlIGNoYW5nZXMuICBUaGlzIGlzIGRpZmZlcmVudCBmcm9tIFNBQ00gYXMgU0FD TSBpcyBhc3Nlc3NpbmcgcG9zdHVyZSBhbmQgbm90IGRvaW5nIHRoaW5ncyBsaWtlIG1hbmFnaW5n IGZpcmV3YWxsIHJ1bGUgc2V0cyBvciBjaGFuZ2luZyBmaWx0ZXJpbmcgb3B0aW9ucyBmb3IgZmxv dyBiYXNlZCBwcm90b2NvbHMuDQoNCk9uIFRodSwgQXByIDIsIDIwMTUgYXQgNzo0MSBBTSwgQWRh bSBXLiBNb250dmlsbGUgPGFkYW0udy5tb250dmlsbGVAZ21haWwuY29tPG1haWx0bzphZGFtLncu bW9udHZpbGxlQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpPbiBBcHIgMSwgMjAxNSwgYXQgNDoxNSBQ TSwgTGluZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbTxtYWlsdG86bGluZGEuZHVu YmFyQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KQWRhbSwNCg0KWW91IHNhaWQ6DQpzYWNtIGlzLCBh dCBpdHMgY29yZSwgcHJpbWFyaWx5IGludGVyZXN0ZWQgaW4gYXNzZXNzaW5nIGVuZHBvaW50IGF0 dHJpYnV0ZXMuICBUaGlzIG1lYW5zIGV4cHJlc3NpbmcgdGhlIGRlc2lyZWQgYXR0cmlidXRlIHRv IGNvbGxlY3QsIGNvbGxlY3RpbmcgaXQsIGFuZCBldmFsdWF0aW5nIGl0IGFnYWluc3Qgc29tZSBl eHByZXNzZWQgZXhwZWN0YXRpb24uICBUaGUgYXNzZXNzbWVudCByZXN1bHQgaXMgcHJvdmlkZWQg Zm9yIGRvd25zdHJlYW0gdXNlLCBpcnJlc3BlY3RpdmUgb2Ygd2hhdCB0aGF0IHVzZSBtaWdodCBi ZS4gIEFkZGl0aW9uYWxseSwgY29sbGVjdGlvbiBjb3VsZCBiZSB0aGUgb25seSByZXN1bHRzIHBy b3ZpZGVkIChpZiBubyBldmFsdWF0aW9uIHBpZWNlIGlzIG5lZWRlZCkuDQoNCkhvdyBhcmUgdGhl IOKAnGRlc2lyZWQgYXR0cmlidXRlc+KAnSBleHByZXNzZWQgYnkgU0FDTT8gSG93IGFyZSB0aGUg 4oCcZXhwZWN0YXRpb27igJ0gYmVpbmcgc3BlY2lmaWVkPw0KDQoNCkF0IHRoaXMgcG9pbnQgd2Ug YXJlIHdvcmtpbmcgb24gYW4gaW5mb3JtYXRpb24gbW9kZWwgWzFdIGFuZCBoYXZlIG5vdCB5ZXQg YXJyaXZlZCBhdCBkYXRhIG1vZGVscy4gIEkgd291bGQgYW50aWNpcGF0ZSBzZXZlcmFsIGRhdGEg bW9kZWxzIHRvIGV4aXN0LCBkZXBlbmRpbmcgb24gdGhlIHNvdXJjZSBvZiB0aGUgZGF0YSBiZWlu ZyBjb2xsZWN0ZWQuDQoNCg0KWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtc2FjbS1pbmZvcm1hdGlvbi1tb2RlbC8gKG5vdGUgdGhhdCB0aGlzIHdpbGwgYWxt b3N0IGNlcnRhaW5seSB1cGRhdGVkIGJldHdlZW4gbm93IGFuZCBJRVRGIDkzKS4gIEludGVybWVk aWF0ZSB3b3JrIGNhbiBiZSBmb3VuZCBoZXJlOiBodHRwczovL2dpdGh1Yi5jb20vc2FjbXdnL2Ry YWZ0LWlldGYtc2FjbS1pbmZvcm1hdGlvbi1tb2RlbCkuDQoNCg0KDQoNCg0KVGhhbmtzLCBMaW5k YQ0KDQpGcm9tOiBJMm5zZiBbbWFpbHRvOmkybnNmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBZGFtIFcuIE1vbnR2aWxsZQ0KU2VudDogU2F0dXJkYXksIE1hcmNoIDI4LCAyMDE1IDc6 NDEgQU0NClRvOiBNZWxpbmRhIFNob3JlDQpDYzogaTJuc2ZAaWV0Zi5vcmc8bWFpbHRvOmkybnNm QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJMm5zZl0gVGhlIGRlZmVuc2UgJ2Vjb3N5c3RlbScg cGFyYWRpZ20NCg0KSGF2aW5nIGEgY3Jvc3MtZ3JvdXAgdW5kZXJzdGFuZGluZyBvZiB0aGUgcmVs YXRpb25zaGlwIGJldHdlZW4gaTJuc2YsIHNhY20sIG1pbGUsIGFuZCBkb3RzIHdvdWxkIGJlIGJl bmVmaWNpYWwuICBJ4oCZbSBsZXNzIGZhbWlsaWFyIHdpdGggaTJuc2YgYW5kIGRvdHMgKGluIHRo ZSBkZXRhaWxzKS4NCg0KDQpJdCBzZWVtcyB0aGF0IG1pbGUsIGkybnNmLCBhbmQgZG90cyB3b3Vs ZCBhbGwgYmVuZWZpdCBmcm9tIHNhY20gaW4gc29tZSB3YXksIGFzIHRoZXkgYXJlIGxhcmdlbHkg ZG93bnN0cmVhbSBmcm9tIHRoZSBjb3JlIHByb2JsZW0gc2FjbSBpbnRlbmRzIHRvIHNvbHZlLg0K DQppMm5zZiBzZWVrcyB0byBleHByZXNzIGFuZCBldmFsdWF0ZSBuZXR3b3JrIHNlcnZpY2UgcmVs YXRlZCBpbmZvcm1hdGlvbiwgd2hpY2ggd2lsbCB1bHRpbWF0ZWx5IG5lZWQgdG8gaWRlbnRpZnkg c3BlY2lmaWMgZW5kcG9pbnRzICh2aXJ0dWFsIG9yIG90aGVyd2lzZSkgdG8gY29sbGVjdCBzcGVj aWZpYyBhdHRyaWJ1dGVzLCBldmFsdWF0ZSB0aGVtIGFnYWluc3Qgc29tZSBleHByZXNzZWQgZXhw ZWN0YXRpb24sIHRoZW4gbWFrZSBzZW5zZSBvZiB0aGF0IGF0IHRoZSBpMm5zZiBsZXZlbC4NCg0K bWlsZSBjb3VsZCBiZW5lZml0IGZyb20gc2FjbSBieSBsZXZlcmFnaW5nIHRoZSBhdHRyaWJ1dGUg ZXhwcmVzc2lvbiBhbmQgZXZhbHVhdGlvbiBmb3JtYXRzLiAgQWRkaXRpb25hbGx5LCB0aGUg4oCc YWQgaG9j4oCdIGV4cGxvcmF0b3J5IHRvb2xzIG9mdGVuIGZhdm9yZWQgZHVyaW5nIGluY2lkZW50 IHJlc3BvbnNlIGNvdWxkIHVzZSBzYWNtIGFzIGEgbWVhbnMgb2YgdGhhdCBleHBsb3JhdGlvbi4N Cg0KZG90cyBpcyBteSBsZWFzdCB1bmRlcnN0b29kIGRvbWFpbiwgYnV0IGFmdGVyIHNwZWFraW5n IHdpdGggQW5hIEhlZGFucGluZyBmb3IgYSBicmllZiB0aW1lLCBpdCBzZWVtcyB0aGF0IGRvdHMg d2lsbCBoYXZlIHNvbWUgbmVlZCB0byBleHByZXNzIGVuZHBvaW50IGF0dHJpYnV0ZXMsIGNvbGxl Y3QgdmFsdWVzLCBhbmQgZXZhbHVhdGUgdGhlbSBhZ2FpbnN0IHNvbWUgZXhwZWN0YXRpb24gYXMg d2VsbC4gIE9ubHksIHRoaXMgd2lsbCBiZSBtb3JlIG9mIGEg4oCccmVhbCB0aW1l4oCdIGNpcmN1 bXN0YW5jZSAoSSBwcmVzdW1lKS4NCg0KQXMgQm9iIHBvaW50ZWQgb3V0LCB0aGVzZSBhcmUgYWxs IHBhcnRzIG9mIGEgd2hvbGUgLSB0aGUg4oCcZGVmZW5zZSBlY29zeXN0ZW0gcGFyYWRpZ23igJ0u ICAgQW5kLCB3aGlsZSBkZXJpdmluZyBhIHNwZWNpZmljIHRheG9ub215IGNvdWxkIGJlIHVzZWZ1 bCwgaXTigJlzIGFscmVhZHkgZG9uZSBpbiBhIHdheS4gIFRoZSDigJxkZWZlbnNlIOKAmGVjb3N5 c3RlbeKAmSBwYXJhZGlnbSIgc2VlbXMgdG8gbWUgbGlrZSBhIHN5bm9ueW0gZm9yIOKAnHNlY3Vy aXR5IHByb2dyYW3igJ0sIGFuZCB0aG9zZSBhcmUgd2VsbCBjb3ZlcmVkLiAgVGhpbmsgSVNPIDI3 MDAwIHNlcmllcywgTklTVCA4MDAtNTMsIFBDSSBEU1MsIENPQklULCAyMCBDcml0aWNhbCBTZWN1 cml0eSBDb250cm9scywgYW5kIHRoZSBsaWtlLiAgSW4gZmFjdCwgSSB1c2VkIGEgc2ltaWxhciBw ZXJzcGVjdGl2ZSAoSSBjYWxsZWQgaXQg4oCcZnJhbWUgb2YgcmVmZXJlbmNl4oCdKSBhdCBhIHNh Y20gQm9GIChiYWNrIGluIEF0bGFudGEgZHVyaW5nIElFVEYgODUgWzFdKSB0byBmcmFtZSB0aGUg 4oCcc3BhY2XigJ0gaW4gd2hpY2ggc2FjbSBwbGF5cy4gIEkgdGhpbmsgbWlsZSAgLCBpMm5zZiwg YW5kIGRvdHMgYWxsIHBsYXkgaW4gdGhpcyBzYW1lIHNwYWNlIChzZWUgdGhlIHNlY29uZCwgdGhp cmQsIGFuZCBmb3VydGggc2xpZGVzKS4NCg0KV2hhdCBzZWVtcyBpbXBvcnRhbnQgaXMgdGhhdCB3 ZSByZWNvZ25pemUgKGFuZCBuYW1lKSB0aGUgZGlmZmVyZW50IGJ1c2luZXNzIHByb2Nlc3NlcyB3 ZSBhcmUgc3VwcG9ydGluZy4gIFRoaXMgc2hvdWxkIGhlbHAgdXMgcmVjb2duaXplIHRoZSByZWxh dGlvbnNoaXBzIGJldHdlZW4gb3VyIHdvcmsuDQoNClRob3VnaHRzPw0KDQpSZWdhcmRzLA0KDQpB ZGFtDQoNClsxXSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NS9zbGlkZXMvc2xp ZGVzLTg1LXNhY20tMi5wZGYNCg0KDQoNCk9uIE1hciAyNywgMjAxNSwgYXQgOTowMSBQTSwgTWVs aW5kYSBTaG9yZSA8bWVsaW5kYS5zaG9yZUBnbWFpbC5jb208bWFpbHRvOm1lbGluZGEuc2hvcmVA Z21haWwuY29tPj4gd3JvdGU6DQoNCkknbSByYXRoZXIgc3VycHJpc2VkIHRoYXQgbm9ib2R5IGhh cyBhbnN3ZXJlZCB0aGlzIQ0KDQpJIHRoaW5rIHRoaXMgaXMgYSB2ZXJ5IHJlYXNvbmFibGUgYXBw cm9hY2gsIHdpdGggdGhlDQpjYXZlYXQgdGhhdCB3aGF0J3MgbmVlZGVkICpoZXJlKiBpcyBub3Qg c28gbXVjaCBhbiBhcmNoaXRlY3R1cmUNCmJ1dCBhbiBhY3R1YWwgcHJvdG9jb2wgY29udmV5aW5n IGFjdHVhbCBkYXRhIGJldHdlZW4gYWN0dWFsDQpuZXR3b3JrIGVsZW1lbnRzLiAgVGhpcyBtYXkg YmUgd2h5IG90aGVyIG1pZGRsZWJveCBwcm90b2NvbHMNCjxyaW1zaG90PiBoYXZlIGJlZW4gYWJs ZSB0byBtb3ZlIGZvcndhcmQsIGV2ZW4gd2hpbGUgYmVpbmcNCnJlZHVuZGFudCwgd2hpbGUgdGhp cyBlZmZvcnQgaGFzIGJlZW4gc3R1Y2suICBJdCBzZWVtcyB0bw0KbWUsIGJhc2VkIG9uIGRpc2N1 c3Npb25zIGR1cmluZyB0aGUgd2VlayBhbmQgb24gYm90aCB0aGUNCmlucHV0IHRvIGFuZCB0aGUg b3V0cHV0IGZyb20gdGhlIGRvdHMgQk9GLCB0aGF0IHRoZXJlJ3MNCnN0aWxsIHJvb20gZm9yIGEg Z29vZCBiYWNrZW5kIHByb3RvY29sIHRvIGNvbnZleSByZXF1ZXN0cw0KdG8gd2hhdCB1c2VkIHRv IGJlIGNhbGxlZCBwb2xpY3kgZW5mb3JjZW1lbnQgcG9pbnRzIGJhc2VkDQpvbiB0aGUgYWN0aXZl IHRocmVhdCBkYXRhIGJlaW5nIHNoYXJlZCB0aHJvdWdoIGEgZG90cy1saWtlIG1lY2hhbmlzbS4N CkJ1dCB0aGF0J3MgYSB2ZXJ5IG5hcnJvdyBleGFtcGxlLg0KDQpTbywgSSB0aGluayB0byB0aGUg ZXh0ZW50IHRoYXQgYSB0YXhvbm9teSBjYW4gaGVscCB0aGlzDQplZmZvcnQgZGV2ZWxvcCBhIG5h cnJvdyBmb2N1cywgaXQgd291bGQgYmUgYSB2ZXJ5IGhlbHBmdWwNCnRoaW5nIGluZGVlZC4gIEJ1 dCBpdCdzIGdvdCB0byBiZSB2ZXJ5IGFwcGxpZWQgLSBJIGFtDQpza2VwdGljYWwgYWJvdXQgdGhl IHZhbHVlIG9mIGhpZ2gtbGV2ZWwgYXJjaGl0ZWN0dXJlcyBpbg0KdGhlIElFVEYuDQoNCk1lbGlu ZGENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkky bnNmIG1haWxpbmcgbGlzdA0KSTJuc2ZAaWV0Zi5vcmc8bWFpbHRvOkkybnNmQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMm5zZg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJMm5zZiBtYWlsaW5nIGxp c3QNCkkybnNmQGlldGYub3JnPG1haWx0bzpJMm5zZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJuc2YNCg0KDQoNCi0tDQoNCkJlc3QgcmVnYXJkcywN CkthdGhsZWVuDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C09ADAdfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+S2F0aGxlZW4sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBhZ2UgMTIgaGFzIEluY2lkZW50L1JJ RC9JT0RFRiBjaXJjbGVkIGluIEJsdWUgKElFVEYpLiBBcmUgdGhleSBhbGwgcGFydCBvZiBNSUxF PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+WW91ciBzdW1tYXJ5IG9mIEkyTlNGIGlzIHZlcnkgYWNjdXJhdGU6IHByb3Zp ZGUgaW50ZXJmYWNlIGZvciBjdXN0b21lcnMgdG8gc3BlY2lmeS9tb25pdG9yIHRoZWlyIHNlY3Vy aXR5IHBvbGljZXMgdG8gYmUgZW5mb3JjZWQgYnkgU2VjdXJpdHkgRnVuY3Rpb25zIGhvc3RlZA0K IGJ5IHByb3ZpZGVycy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DdXN0b21lcnMgbWF5IGFsc28gcmVxdWVzdCBzcGVj aWZpYyBwcm9maWxlIG9yIHNpZ25hdHVyZSBmaWxlIGZvciBzZWN1cml0eSBmdW5jdGlvbnMgaG9z dGVkIGluIHByb3ZpZGVyIGRvbWFpbiAoZS5nLiBJUFM6Jmx0O3NpZ25hdHVyZSZndDspLiBUaGUg aW50ZXJmYWNlIG5lZWQgdG8NCiBoYXZlIHRoaXMgZXh0cmEgYXR0cmlidXRlLCBpbiBhZGRpdGlv biB0byB0aGUg4oCcU3ViamVjdCBtYXRjaGluZyAoYml0cy9maWVsZHMgZnJvbSBwYWNrZXRzKeKA nSwg4oCcb2JqZWN0IG1hdGNoaW5nIChjb250ZXh0dWFsOiBldmVudHMsIHRpbWUsIGdlby1sb2Nh dGlvbiwgZXRjKS4gVGhpcyBpcyBkZWZpbml0ZWx5IGRpZmZlcmVudCBmcm9tIHRoZSDigJxJbmNp ZGVudOKAnSBkZXNjcmliZWQgYnkgTUlMRS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGluZGENCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gS2F0aGxlZW4gTW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWls LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgMTI6MDQg UE08YnI+DQo8Yj5Ubzo8L2I+IEFkYW0gVy4gTW9udHZpbGxlPGJyPg0KPGI+Q2M6PC9iPiBMaW5k YSBEdW5iYXI7IGkybnNmQGlldGYub3JnOyBNZWxpbmRhIFNob3JlPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbSTJuc2ZdIFRoZSBkZWZlbnNlICdlY29zeXN0ZW0nIHBhcmFkaWdtPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBiZWVuIG1lYW5pbmcgdG8gcmVz cG9uZCBvbiBob3cgTUlMRSBhbmQgU0FDTSBmaXQgd2l0aCBJMk5TRiBhbmQgRE9UUyBpbiBhIGJp Z2dlciBwaWN0dXJlIHZpZXcuJm5ic3A7IEkganVzdCBoYXZlIG9sZCBzbGlkZXMgZm9yIE1JTEUg YW5kIFNBQ00uJm5ic3A7IFNlZSBzbGlkZSAxMiBvZiB0aGlzIFBQVCwgd2hlcmUgU0FDTSBpcyBv biB0aGUgZmFyIGxlZnQgKENvbmZpZ3VyYXRpb24gYW5kIHBvc3NpYmx5IEFzc2V0cykNCiBhbmQg TUlMRSBpcyBjaXJjbGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3NjYXAubmlzdC5nb3YvZXZlbnRzLzIwMTEvaXRz YWMvcHJlc2VudGF0aW9ucy9kYXkyL01vcmlhcnR5JTIwLSUyMElFVEYlMjBNSUxFLCUyMEltcHJv dmluZyUyMEluY2lkZW50JTIwYW5kJTIwSW5mb3JtYXRpb24lMjBTaGFyaW5nJTIwU3RhbmRhcmRz LnBkZiI+aHR0cDovL3NjYXAubmlzdC5nb3YvZXZlbnRzLzIwMTEvaXRzYWMvcHJlc2VudGF0aW9u cy9kYXkyL01vcmlhcnR5JTIwLSUyMElFVEYlMjBNSUxFLCUyMEltcHJvdmluZyUyMEluY2lkZW50 JTIwYW5kJTIwSW5mb3JtYXRpb24lMjBTaGFyaW5nJTIwU3RhbmRhcmRzLnBkZjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYWQgYmV0 dGVyIHZlcnNpb25zIG9mIHRoYXQgc2xpZGUsIGJ1dCBJIGFtIG5vdCBhYmxlIHRvIGZpbmQgdGhl bSBvbmxpbmUgYW5kIGRvbid0IHdhbnQgdG8gY2xvZyB1cCBldmVyeW9uZSdzIGVtYWlsLiZuYnNw OyBUaGlzIHNob3VsZCBiZSBnb29kIGVub3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RE9UUyBjb3VsZCBmZWVkIGludG8gTUlMRSwgd2hl cmUgcmVwb3J0cyBmcm9tIERPVFMgYXJlIHBhcnQgb2YgYSBsYXJnZXIgaW52ZXN0aWdhdGlvbiBv ciBzZXQgb2YgaW5kaWNhdG9ycyBiZWluZyBleGNoYW5nZWQgdXNpbmcgRE9UUyBmb3JtYXR0ZWQg ZGF0YSB3aXRoaW4gYW4gSU9ERUYgZW52ZWxvcGUuJm5ic3A7IEl0J3MgYSBzcGVjaWZpYyBzdWIt dXNlIGNhc2UgdGhhdCBoYXMgZGlmZmVyZW50IGVub3VnaCByZXF1aXJlbWVudHMNCiB0aGF0IGl0 IHNob3VsZCBub3QgYmUgaW4gTUlMRS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+STJOU0YgaXMgY29uY2VybmVkIHdpdGggdGVuYW50J3MgYWJp bGl0eSB0byBwcm92aXNpb24vY2hhbmdlIHJ1bGVzIG9uIGhvc3RlZCBzZWN1cml0eSBkZXZpY2Vz LCBhbGxvd2luZyB0ZW5hbnRzIHRvIG1ha2UgdGhlc2UgY2hhbmdlcy4mbmJzcDsgVGhpcyBpcyBk aWZmZXJlbnQgZnJvbSBTQUNNIGFzIFNBQ00gaXMgYXNzZXNzaW5nIHBvc3R1cmUgYW5kIG5vdCBk b2luZyB0aGluZ3MgbGlrZSBtYW5hZ2luZyBmaXJld2FsbA0KIHJ1bGUgc2V0cyBvciBjaGFuZ2lu ZyBmaWx0ZXJpbmcgb3B0aW9ucyBmb3IgZmxvdyBiYXNlZCBwcm90b2NvbHMuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwg QXByIDIsIDIwMTUgYXQgNzo0MSBBTSwgQWRhbSBXLiBNb250dmlsbGUgJmx0OzxhIGhyZWY9Im1h aWx0bzphZGFtLncubW9udHZpbGxlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYW0udy5t b250dmlsbGVAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEFwciAxLCAyMDE1LCBhdCA0OjE1IFBN LCBMaW5kYSBEdW5iYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFkYW0sPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3Ugc2FpZDo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPnNhY20gaXMsIGF0IGl0cyBj b3JlLCBwcmltYXJpbHkgaW50ZXJlc3RlZCBpbiBhc3Nlc3NpbmcgZW5kcG9pbnQgYXR0cmlidXRl cy4mbmJzcDsgVGhpcyBtZWFucyBleHByZXNzaW5nIHRoZSBkZXNpcmVkIGF0dHJpYnV0ZSB0byBj b2xsZWN0LCBjb2xsZWN0aW5nIGl0LCBhbmQgZXZhbHVhdGluZyBpdCBhZ2FpbnN0IHNvbWUgZXhw cmVzc2VkIGV4cGVjdGF0aW9uLiZuYnNwOyBUaGUNCiBhc3Nlc3NtZW50IHJlc3VsdCBpcyBwcm92 aWRlZCBmb3IgZG93bnN0cmVhbSB1c2UsIGlycmVzcGVjdGl2ZSBvZiB3aGF0IHRoYXQgdXNlIG1p Z2h0IGJlLiZuYnNwOyBBZGRpdGlvbmFsbHksIGNvbGxlY3Rpb24gY291bGQgYmUgdGhlIG9ubHkg cmVzdWx0cyBwcm92aWRlZCAoaWYgbm8gZXZhbHVhdGlvbiBwaWVjZSBpcyBuZWVkZWQpLjwvc3Bh bj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvdyBhcmUgdGhlIOKAnGRl c2lyZWQgYXR0cmlidXRlc+KAnSBleHByZXNzZWQgYnkgU0FDTT8gSG93IGFyZSB0aGUg4oCcZXhw ZWN0YXRpb27igJ0gYmVpbmcgc3BlY2lmaWVkPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QXQgdGhpcyBwb2ludCB3ZSBhcmUgd29ya2luZyBvbiBhbiBpbmZvcm1hdGlvbiBt b2RlbCBbMV0gYW5kIGhhdmUgbm90IHlldCBhcnJpdmVkIGF0IGRhdGEgbW9kZWxzLiZuYnNwOyBJ IHdvdWxkIGFudGljaXBhdGUgc2V2ZXJhbCBkYXRhIG1vZGVscyB0byBleGlzdCwgZGVwZW5kaW5n IG9uIHRoZSBzb3VyY2Ugb2YgdGhlIGRhdGEgYmVpbmcgY29sbGVjdGVkLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2FjbS1pbmZv cm1hdGlvbi1tb2RlbC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXNhY20taW5mb3JtYXRpb24tbW9kZWwvPC9hPiZuYnNwOyhub3Rl IHRoYXQgdGhpcyB3aWxsIGFsbW9zdCBjZXJ0YWlubHkgdXBkYXRlZCBiZXR3ZWVuIG5vdyBhbmQg SUVURg0KIDkzKS4mbmJzcDsgSW50ZXJtZWRpYXRlIHdvcmsgY2FuIGJlIGZvdW5kIGhlcmU6Jm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3NhY213Zy9kcmFmdC1pZXRmLXNhY20taW5m b3JtYXRpb24tbW9kZWwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vc2FjbXdn L2RyYWZ0LWlldGYtc2FjbS1pbmZvcm1hdGlvbi1tb2RlbDwvYT4pLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCBMaW5kYTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7STJu c2YgWzxhIGhyZWY9Im1haWx0bzppMm5zZi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOmkybnNmLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSZuYnNwOzxiPk9uDQogQmVoYWxm IE9mJm5ic3A7PC9iPkFkYW0gVy4gTW9udHZpbGxlPGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7U2F0 dXJkYXksIE1hcmNoIDI4LCAyMDE1IDc6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7TWVsaW5k YSBTaG9yZTxicj4NCjxiPkNjOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86aTJuc2ZAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pMm5zZkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4mbmJzcDtSZTogW0kybnNmXSBUaGUgZGVmZW5zZSAnZWNvc3lzdGVtJyBwYXJhZGlnbTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhhdmluZyBhIGNyb3NzLWdyb3VwIHVuZGVyc3RhbmRpbmcgb2YgdGhl IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGkybnNmLCBzYWNtLCBtaWxlLCBhbmQgZG90cyB3b3VsZCBi ZSBiZW5lZmljaWFsLiZuYnNwOyBJ4oCZbSBsZXNzIGZhbWlsaWFyIHdpdGggaTJuc2YgYW5kIGRv dHMgKGluIHRoZSBkZXRhaWxzKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXQgc2VlbXMgdGhhdCBtaWxlLCBpMm5zZiwgYW5kIGRvdHMgd291bGQgYWxsIGJlbmVm aXQgZnJvbSBzYWNtIGluIHNvbWUgd2F5LCBhcyB0aGV5IGFyZSBsYXJnZWx5IGRvd25zdHJlYW0g ZnJvbSB0aGUgY29yZSBwcm9ibGVtIHNhY20gaW50ZW5kcyB0byBzb2x2ZS4gJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmkybnNmIHNlZWtzIHRvIGV4cHJlc3MgYW5kIGV2YWx1YXRl IG5ldHdvcmsgc2VydmljZSByZWxhdGVkIGluZm9ybWF0aW9uLCB3aGljaCB3aWxsIHVsdGltYXRl bHkgbmVlZCB0byBpZGVudGlmeSBzcGVjaWZpYyBlbmRwb2ludHMgKHZpcnR1YWwgb3Igb3RoZXJ3 aXNlKSB0byBjb2xsZWN0IHNwZWNpZmljIGF0dHJpYnV0ZXMsIGV2YWx1YXRlIHRoZW0gYWdhaW5z dCBzb21lIGV4cHJlc3NlZCBleHBlY3RhdGlvbiwNCiB0aGVuIG1ha2Ugc2Vuc2Ugb2YgdGhhdCBh dCB0aGUgaTJuc2YgbGV2ZWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1pbGUgY291bGQg YmVuZWZpdCBmcm9tIHNhY20gYnkgbGV2ZXJhZ2luZyB0aGUgYXR0cmlidXRlIGV4cHJlc3Npb24g YW5kIGV2YWx1YXRpb24gZm9ybWF0cy4mbmJzcDsgQWRkaXRpb25hbGx5LCB0aGUg4oCcYWQgaG9j 4oCdIGV4cGxvcmF0b3J5IHRvb2xzIG9mdGVuIGZhdm9yZWQgZHVyaW5nIGluY2lkZW50IHJlc3Bv bnNlIGNvdWxkIHVzZSBzYWNtIGFzIGEgbWVhbnMgb2YgdGhhdCBleHBsb3JhdGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+ZG90cyBpcyBteSBsZWFzdCB1bmRlcnN0b29kIGRvbWFpbiwg YnV0IGFmdGVyIHNwZWFraW5nIHdpdGggQW5hIEhlZGFucGluZyBmb3IgYSBicmllZiB0aW1lLCBp dCBzZWVtcyB0aGF0IGRvdHMgd2lsbCBoYXZlIHNvbWUgbmVlZCB0byBleHByZXNzIGVuZHBvaW50 IGF0dHJpYnV0ZXMsIGNvbGxlY3QgdmFsdWVzLCBhbmQgZXZhbHVhdGUgdGhlbSBhZ2FpbnN0IHNv bWUgZXhwZWN0YXRpb24gYXMgd2VsbC4mbmJzcDsgT25seSwNCiB0aGlzIHdpbGwgYmUgbW9yZSBv ZiBhIOKAnHJlYWwgdGltZeKAnSBjaXJjdW1zdGFuY2UgKEkgcHJlc3VtZSkuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFzIEJvYiBwb2ludGVkIG91dCwgdGhlc2UgYXJlIGFsbCBwYXJ0cyBv ZiBhIHdob2xlIC0gdGhlIOKAnGRlZmVuc2UgZWNvc3lzdGVtIHBhcmFkaWdt4oCdLiAmbmJzcDsg QW5kLCB3aGlsZSBkZXJpdmluZyBhIHNwZWNpZmljIHRheG9ub215IGNvdWxkIGJlIHVzZWZ1bCwg aXTigJlzIGFscmVhZHkgZG9uZSBpbiBhIHdheS4mbmJzcDsgVGhlIOKAnGRlZmVuc2Ug4oCYZWNv c3lzdGVt4oCZIHBhcmFkaWdtJnF1b3Q7IHNlZW1zIHRvIG1lIGxpa2UgYSBzeW5vbnltDQogZm9y IOKAnHNlY3VyaXR5IHByb2dyYW3igJ0sIGFuZCB0aG9zZSBhcmUgd2VsbCBjb3ZlcmVkLiZuYnNw OyBUaGluayBJU08gMjcwMDAgc2VyaWVzLCBOSVNUIDgwMC01MywgUENJIERTUywgQ09CSVQsIDIw IENyaXRpY2FsIFNlY3VyaXR5IENvbnRyb2xzLCBhbmQgdGhlIGxpa2UuJm5ic3A7IEluIGZhY3Qs IEkgdXNlZCBhIHNpbWlsYXIgcGVyc3BlY3RpdmUgKEkgY2FsbGVkIGl0IOKAnGZyYW1lIG9mIHJl ZmVyZW5jZeKAnSkgYXQgYSBzYWNtIEJvRiAoYmFjayBpbiBBdGxhbnRhDQogZHVyaW5nIElFVEYg ODUgWzFdKSB0byBmcmFtZSB0aGUg4oCcc3BhY2XigJ0gaW4gd2hpY2ggc2FjbSBwbGF5cy4mbmJz cDsgSSB0aGluayBtaWxlICZuYnNwOywgaTJuc2YsIGFuZCBkb3RzIGFsbCBwbGF5IGluIHRoaXMg c2FtZSBzcGFjZSAoc2VlIHRoZSBzZWNvbmQsIHRoaXJkLCBhbmQgZm91cnRoIHNsaWRlcykuICZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHNlZW1zIGltcG9ydGFudCBpcyB0 aGF0IHdlIHJlY29nbml6ZSAoYW5kIG5hbWUpIHRoZSBkaWZmZXJlbnQgYnVzaW5lc3MgcHJvY2Vz c2VzIHdlIGFyZSBzdXBwb3J0aW5nLiZuYnNwOyBUaGlzIHNob3VsZCBoZWxwIHVzIHJlY29nbml6 ZSB0aGUgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIG91ciB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaG91Z2h0cz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b MV0mbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NS9zbGlk ZXMvc2xpZGVzLTg1LXNhY20tMi5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NS9zbGlkZXMvc2xp ZGVzLTg1LXNhY20tMi5wZGY8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMjcsIDIwMTUs IGF0IDk6MDEgUE0sIE1lbGluZGEgU2hvcmUgJmx0OzxhIGhyZWY9Im1haWx0bzptZWxpbmRhLnNo b3JlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pm1lbGluZGEuc2hvcmVAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JJ20gcmF0aGVyIHN1cnByaXNlZCB0aGF0IG5vYm9keSBoYXMgYW5zd2VyZWQgdGhpcyE8YnI+ DQo8YnI+DQpJIHRoaW5rIHRoaXMgaXMgYSB2ZXJ5IHJlYXNvbmFibGUgYXBwcm9hY2gsIHdpdGgg dGhlPGJyPg0KY2F2ZWF0IHRoYXQgd2hhdCdzIG5lZWRlZCAqaGVyZSogaXMgbm90IHNvIG11Y2gg YW4gYXJjaGl0ZWN0dXJlPGJyPg0KYnV0IGFuIGFjdHVhbCBwcm90b2NvbCBjb252ZXlpbmcgYWN0 dWFsIGRhdGEgYmV0d2VlbiBhY3R1YWw8YnI+DQpuZXR3b3JrIGVsZW1lbnRzLiZuYnNwOyBUaGlz IG1heSBiZSB3aHkgb3RoZXIgbWlkZGxlYm94IHByb3RvY29sczxicj4NCiZsdDtyaW1zaG90Jmd0 OyBoYXZlIGJlZW4gYWJsZSB0byBtb3ZlIGZvcndhcmQsIGV2ZW4gd2hpbGUgYmVpbmc8YnI+DQpy ZWR1bmRhbnQsIHdoaWxlIHRoaXMgZWZmb3J0IGhhcyBiZWVuIHN0dWNrLiZuYnNwOyBJdCBzZWVt cyB0bzxicj4NCm1lLCBiYXNlZCBvbiBkaXNjdXNzaW9ucyBkdXJpbmcgdGhlIHdlZWsgYW5kIG9u IGJvdGggdGhlPGJyPg0KaW5wdXQgdG8gYW5kIHRoZSBvdXRwdXQgZnJvbSB0aGUgZG90cyBCT0Ys IHRoYXQgdGhlcmUnczxicj4NCnN0aWxsIHJvb20gZm9yIGEgZ29vZCBiYWNrZW5kIHByb3RvY29s IHRvIGNvbnZleSByZXF1ZXN0czxicj4NCnRvIHdoYXQgdXNlZCB0byBiZSBjYWxsZWQgcG9saWN5 IGVuZm9yY2VtZW50IHBvaW50cyBiYXNlZDxicj4NCm9uIHRoZSBhY3RpdmUgdGhyZWF0IGRhdGEg YmVpbmcgc2hhcmVkIHRocm91Z2ggYSBkb3RzLWxpa2UgbWVjaGFuaXNtLjxicj4NCkJ1dCB0aGF0 J3MgYSB2ZXJ5IG5hcnJvdyBleGFtcGxlLjxicj4NCjxicj4NClNvLCBJIHRoaW5rIHRvIHRoZSBl eHRlbnQgdGhhdCBhIHRheG9ub215IGNhbiBoZWxwIHRoaXM8YnI+DQplZmZvcnQgZGV2ZWxvcCBh IG5hcnJvdyBmb2N1cywgaXQgd291bGQgYmUgYSB2ZXJ5IGhlbHBmdWw8YnI+DQp0aGluZyBpbmRl ZWQuJm5ic3A7IEJ1dCBpdCdzIGdvdCB0byBiZSB2ZXJ5IGFwcGxpZWQgLSBJIGFtPGJyPg0Kc2tl cHRpY2FsIGFib3V0IHRoZSB2YWx1ZSBvZiBoaWdoLWxldmVsIGFyY2hpdGVjdHVyZXMgaW48YnI+ DQp0aGUgSUVURi48YnI+DQo8YnI+DQpNZWxpbmRhPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJMm5zZiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86STJuc2ZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5JMm5zZkBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMm5zZiIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaTJuc2Y8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSTJuc2YgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOkkybnNmQGlldGYub3JnIj5JMm5zZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kybnNmIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMm5zZjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNs ZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LYXRo bGVlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657C09ADAdfweml701chm_-- From nobody Thu Apr 23 16:26:56 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50D51A8A1B for ; Thu, 23 Apr 2015 16:26:54 -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 Gw3sAsVlaMtL for ; Thu, 23 Apr 2015 16:26:51 -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 BCFA81AD066 for ; Thu, 23 Apr 2015 16:26:45 -0700 (PDT) Received: by labbd9 with SMTP id bd9so23551574lab.2 for ; Thu, 23 Apr 2015 16:26:44 -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=kPQiZ5eQh0pUsYqN/CSjMrEUtUlejwp8gQ8m5r7RCAc=; b=piMo+pY4AB1pyO6M+TsOwxBiYpm2qxnz5Udz4TXayzMm2EuSpMO7Q1hEHBS2pHwEga rEXLWrlWtyf1fvVnokpErhTMAPqftQFMwPtL/dc+qMvDmGFZvDdVgs19u7gmT6H3qzVx Pgqp6lpotLge7KQuu4o4XEPkRnEyrGUu2SQBs+stFarSNjLyioWBvPlYxrCPprI0dE0E vf6O9+qcDQJ8R+DEvvsvmsH0WJmhOVCtn8LoP918D77GhoU8ossut3j8wk7ZDsSRpXqW J/OnUBPl2/Y7mVuU+dF6OPrSBrBBp9pYRivSpgYFha1C0Kq/Q2Y7m8OMkO4bOuziNTaB TRqA== MIME-Version: 1.0 X-Received: by 10.112.167.228 with SMTP id zr4mr4454357lbb.113.1429831604296; Thu, 23 Apr 2015 16:26:44 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 23 Apr 2015 16:26:44 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C09ADA@dfweml701-chm> References: <5512F1ED.8020104@htt-consult.com> <55160B74.1010009@gmail.com> <032CF466-C78E-46C7-A171-5176555A97DA@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657BFFB52@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C09ADA@dfweml701-chm> Date: Thu, 23 Apr 2015 19:26:44 -0400 Message-ID: From: Kathleen Moriarty To: Linda Dunbar Content-Type: multipart/alternative; boundary=001a11c2432adcdfc905146c9c9d Archived-At: Cc: "i2nsf@ietf.org" , Melinda Shore , "Adam W. Montville" Subject: Re: [I2nsf] The defense 'ecosystem' paradigm X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 23:26:55 -0000 --001a11c2432adcdfc905146c9c9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Linda, On Thu, Apr 23, 2015 at 6:07 PM, Linda Dunbar wrote: > Kathleen, > > > > Page 12 has Incident/RID/IODEF circled in Blue (IETF). Are they all part > of MILE? > No, only the Incident area in Blue is covered by MILE. SACM covers the Configuration and it must use asset information. Remediation from posture assessment is all part of that configuration section, but they may add that on and do it in other ways - but it's limited to asset assessment/remediation and not what I2NSF is doing. > > > Your summary of I2NSF is very accurate: provide interface for customers t= o > specify/monitor their security polices to be enforced by Security Functio= ns > hosted by providers. > > > > Customers may also request specific profile or signature file for securit= y > functions hosted in provider domain (e.g. IPS:). The interface > need to have this extra attribute, in addition to the =E2=80=9CSubject ma= tching > (bits/fields from packets)=E2=80=9D, =E2=80=9Cobject matching (contextual= : events, time, > geo-location, etc). This is definitely different from the =E2=80=9CIncide= nt=E2=80=9D > described by MILE. > MILE's data format can carry signatures, but they are used in different ways than what you are describing for I2NSF. For MILE, it might be that a signature can help identify a particular incident or be an indicator of a threat. MILE might be used to get this information, but then hand of to something done by I2NSF to deploy signatures against those threats. MILE could also hand something off to the SACM work where they can see they are vulnerable to specific threats if systems have specific assessment characteristics. DOTS could hand off to MILE, but the reverse is probably true too. Kathleen > > > Linda > > > > *From:* Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > *Sent:* Thursday, April 23, 2015 12:04 PM > *To:* Adam W. Montville > *Cc:* Linda Dunbar; i2nsf@ietf.org; Melinda Shore > > *Subject:* Re: [I2nsf] The defense 'ecosystem' paradigm > > > > Hi, > > > > I have been meaning to respond on how MILE and SACM fit with I2NSF and > DOTS in a bigger picture view. I just have old slides for MILE and SACM. > See slide 12 of this PPT, where SACM is on the far left (Configuration an= d > possibly Assets) and MILE is circled. > > > http://scap.nist.gov/events/2011/itsac/presentations/day2/Moriarty%20-%20= IETF%20MILE,%20Improving%20Incident%20and%20Information%20Sharing%20Standar= ds.pdf > > > > I had better versions of that slide, but I am not able to find them onlin= e > and don't want to clog up everyone's email. This should be good enough. > > > > DOTS could feed into MILE, where reports from DOTS are part of a larger > investigation or set of indicators being exchanged using DOTS formatted > data within an IODEF envelope. It's a specific sub-use case that has > different enough requirements that it should not be in MILE. > > > > I2NSF is concerned with tenant's ability to provision/change rules on > hosted security devices, allowing tenants to make these changes. This is > different from SACM as SACM is assessing posture and not doing things lik= e > managing firewall rule sets or changing filtering options for flow based > protocols. > > > > On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville < > adam.w.montville@gmail.com> wrote: > > > > On Apr 1, 2015, at 4:15 PM, Linda Dunbar wrote= : > > > > Adam, > > > > You said: > > *sacm is, at its core, primarily interested in assessing endpoint > attributes. This means expressing the desired attribute to collect, > collecting it, and evaluating it against some expressed expectation. The > assessment result is provided for downstream use, irrespective of what th= at > use might be. Additionally, collection could be the only results provide= d > (if no evaluation piece is needed).* > > > > How are the =E2=80=9Cdesired attributes=E2=80=9D expressed by SACM? How a= re the > =E2=80=9Cexpectation=E2=80=9D being specified? > > > > > > At this point we are working on an information model [1] and have not yet > arrived at data models. I would anticipate several data models to exist, > depending on the source of the data being collected. > > > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ (= note > that this will almost certainly updated between now and IETF 93). > Intermediate work can be found here: > https://github.com/sacmwg/draft-ietf-sacm-information-model). > > > > > > > > > > Thanks, Linda > > > > *From:* I2nsf [mailto:i2nsf-bounces@ietf.org ] *O= n > Behalf Of *Adam W. Montville > *Sent:* Saturday, March 28, 2015 7:41 AM > *To:* Melinda Shore > *Cc:* i2nsf@ietf.org > *Subject:* Re: [I2nsf] The defense 'ecosystem' paradigm > > > > Having a cross-group understanding of the relationship between i2nsf, > sacm, mile, and dots would be beneficial. I=E2=80=99m less familiar with= i2nsf and > dots (in the details). > > > > > > It seems that mile, i2nsf, and dots would all benefit from sacm in some > way, as they are largely downstream from the core problem sacm intends to > solve. > > > > i2nsf seeks to express and evaluate network service related information, > which will ultimately need to identify specific endpoints (virtual or > otherwise) to collect specific attributes, evaluate them against some > expressed expectation, then make sense of that at the i2nsf level. > > > > mile could benefit from sacm by leveraging the attribute expression and > evaluation formats. Additionally, the =E2=80=9Cad hoc=E2=80=9D explorato= ry tools often > favored during incident response could use sacm as a means of that > exploration. > > > > dots is my least understood domain, but after speaking with Ana Hedanping > for a brief time, it seems that dots will have some need to express > endpoint attributes, collect values, and evaluate them against some > expectation as well. Only, this will be more of a =E2=80=9Creal time=E2= =80=9D circumstance > (I presume). > > > > As Bob pointed out, these are all parts of a whole - the =E2=80=9Cdefense > ecosystem paradigm=E2=80=9D. And, while deriving a specific taxonomy co= uld be > useful, it=E2=80=99s already done in a way. The =E2=80=9Cdefense =E2=80= =98ecosystem=E2=80=99 paradigm" > seems to me like a synonym for =E2=80=9Csecurity program=E2=80=9D, and th= ose are well > covered. Think ISO 27000 series, NIST 800-53, PCI DSS, COBIT, 20 Critica= l > Security Controls, and the like. In fact, I used a similar perspective (= I > called it =E2=80=9Cframe of reference=E2=80=9D) at a sacm BoF (back in At= lanta during IETF > 85 [1]) to frame the =E2=80=9Cspace=E2=80=9D in which sacm plays. I thin= k mile , i2nsf, > and dots all play in this same space (see the second, third, and fourth > slides). > > > > What seems important is that we recognize (and name) the different > business processes we are supporting. This should help us recognize the > relationships between our work. > > > > Thoughts? > > > > Regards, > > > > Adam > > > > [1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf > > > > > > > > On Mar 27, 2015, at 9:01 PM, Melinda Shore > wrote: > > > > I'm rather surprised that nobody has answered this! > > I think this is a very reasonable approach, with the > caveat that what's needed *here* is not so much an architecture > but an actual protocol conveying actual data between actual > network elements. This may be why other middlebox protocols > have been able to move forward, even while being > redundant, while this effort has been stuck. It seems to > me, based on discussions during the week and on both the > input to and the output from the dots BOF, that there's > still room for a good backend protocol to convey requests > to what used to be called policy enforcement points based > on the active threat data being shared through a dots-like mechanism. > But that's a very narrow example. > > So, I think to the extent that a taxonomy can help this > effort develop a narrow focus, it would be a very helpful > thing indeed. But it's got to be very applied - I am > skeptical about the value of high-level architectures in > the IETF. > > Melinda > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > > -- > > > > Best regards, > > Kathleen > --=20 Best regards, Kathleen --001a11c2432adcdfc905146c9c9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Linda,

On Thu, Apr 23, 2015 at 6:07 PM, Linda Dunbar &l= t;linda.dunbar= @huawei.com> wrote:

Kathleen,

=C2=A0

Page 12 has Incident/RID/= IODEF circled in Blue (IETF). Are they all part of MILE?


No, only the Incident area in Blue is = covered by MILE.=C2=A0 SACM covers the Configuration and it must use asset = information.=C2=A0 Remediation from posture assessment is all part of that = configuration section, but they may add that on and do it in other ways - b= ut it's limited to asset assessment/remediation and not what I2NSF is d= oing.=C2=A0

=C2=A0

Your summary of I2NSF is = very accurate: provide interface for customers to specify/monitor their sec= urity polices to be enforced by Security Functions hosted by providers.

=C2=A0

Customers may also reques= t specific profile or signature file for security functions hosted in provi= der domain (e.g. IPS:<signature>). The interface need to have this extra attribute, in addition to the =E2=80=9CSubject matching (b= its/fields from packets)=E2=80=9D, =E2=80=9Cobject matching (contextual: ev= ents, time, geo-location, etc). This is definitely different from the =E2= =80=9CIncident=E2=80=9D described by MILE.


MILE's data format can carry signatures, but the= y are used in different ways than what you are describing for I2NSF.=C2=A0 = For MILE, it might be that a signature can help identify a particular incid= ent or be an indicator of a threat.=C2=A0 MILE might be used to get this in= formation, but then hand of to something done by I2NSF to deploy signatures= against those threats.=C2=A0 MILE could also hand something off to the SAC= M work where they can see they are vulnerable to specific threats if system= s have specific assessment characteristics.

DOTS c= ould hand off to MILE, but the reverse is probably true too. =C2=A0

Kathleen

=C2=A0

Linda

=C2=A0

From: Kathleen= Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
Sent: Thursday, April 23, 2015 12:04 PM
To: Adam W. Montville
Cc: Linda Dunbar; i2nsf@ietf.org; Melinda Shore


Subject: Re: [I2nsf] The defense 'ecosystem' paradigm=

=C2=A0

Hi,

=C2=A0

I have been meaning to respond on how MILE and SACM = fit with I2NSF and DOTS in a bigger picture view.=C2=A0 I just have old sli= des for MILE and SACM.=C2=A0 See slide 12 of this PPT, where SACM is on the= far left (Configuration and possibly Assets) and MILE is circled.

=C2=A0

I had better versions of that slide, but I am not ab= le to find them online and don't want to clog up everyone's email.= =C2=A0 This should be good enough.

=C2=A0

DOTS could feed into MILE, where reports from DOTS a= re part of a larger investigation or set of indicators being exchanged usin= g DOTS formatted data within an IODEF envelope.=C2=A0 It's a specific s= ub-use case that has different enough requirements that it should not be in MILE.

=C2=A0

I2NSF is concerned with tenant's ability to prov= ision/change rules on hosted security devices, allowing tenants to make the= se changes.=C2=A0 This is different from SACM as SACM is assessing posture = and not doing things like managing firewall rule sets or changing filtering options for flow based protocols.=C2=A0=

=C2=A0

On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville &l= t;adam.w.mo= ntville@gmail.com> wrote:

=C2=A0

On Apr 1, 2015, at 4:15 PM, Linda Dunbar <linda.dunbar@huawei.c= om> wrote:

=C2=A0

Adam,

=C2=A0

You said:

sacm is, at its cor= e, primarily interested in assessing endpoint attributes.=C2=A0 This means = expressing the desired attribute to collect, collecting it, and evaluating = it against some expressed expectation.=C2=A0 The assessment result is provided for downstream use, irrespective of what tha= t use might be.=C2=A0 Additionally, collection could be the only results pr= ovided (if no evaluation piece is needed).

=C2=A0

How are the =E2=80=9Cdesi= red attributes=E2=80=9D expressed by SACM? How are the =E2=80=9Cexpectation= =E2=80=9D being specified?

=C2=A0

=C2=A0

At this point we are working on an information model= [1] and have not yet arrived at data models.=C2=A0 I would anticipate seve= ral data models to exist, depending on the source of the data being collect= ed.

=C2=A0

=C2=A0

[1]=C2=A0https://datatracker.= ietf.org/doc/draft-ietf-sacm-information-model/=C2=A0(note that this wi= ll almost certainly updated between now and IETF 93).=C2=A0 Intermediate work can be found here:=C2=A0https:= //github.com/sacmwg/draft-ietf-sacm-information-model).

=C2=A0

=C2=A0



=C2=A0

Thanks, Linda

=C2=A0

From:=C2=A0I2n= sf [mailto:i2ns= f-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Adam W. Montville
Sent:=C2=A0Saturday, March 28, 2015 7:41 AM
To:=C2=A0Melinda Shore
Cc:=C2=A0i2nsf@i= etf.org
Subject:=C2=A0Re: [I2nsf] The defense 'ecosystem' paradigm

=C2=A0

Having a cross-group understanding of the relationsh= ip between i2nsf, sacm, mile, and dots would be beneficial.=C2=A0 I=E2=80= =99m less familiar with i2nsf and dots (in the details).=C2=A0

=C2=A0

=C2=A0

It seems that mile, i2nsf, and dots would all benefi= t from sacm in some way, as they are largely downstream from the core probl= em sacm intends to solve. =C2=A0

=C2=A0

i2nsf seeks to express and evaluate network service = related information, which will ultimately need to identify specific endpoi= nts (virtual or otherwise) to collect specific attributes, evaluate them ag= ainst some expressed expectation, then make sense of that at the i2nsf level.

=C2=A0

mile could benefit from sacm by leveraging the attri= bute expression and evaluation formats.=C2=A0 Additionally, the =E2=80=9Cad= hoc=E2=80=9D exploratory tools often favored during incident response coul= d use sacm as a means of that exploration.

=C2=A0

dots is my least understood domain, but after speaki= ng with Ana Hedanping for a brief time, it seems that dots will have some n= eed to express endpoint attributes, collect values, and evaluate them again= st some expectation as well.=C2=A0 Only, this will be more of a =E2=80=9Creal time=E2=80=9D circumstance (I presume= ).

=C2=A0

As Bob pointed out, these are all parts of a whole -= the =E2=80=9Cdefense ecosystem paradigm=E2=80=9D. =C2=A0 And, while derivi= ng a specific taxonomy could be useful, it=E2=80=99s already done in a way.= =C2=A0 The =E2=80=9Cdefense =E2=80=98ecosystem=E2=80=99 paradigm" seem= s to me like a synonym for =E2=80=9Csecurity program=E2=80=9D, and those are well covered.=C2=A0 = Think ISO 27000 series, NIST 800-53, PCI DSS, COBIT, 20 Critical Security C= ontrols, and the like.=C2=A0 In fact, I used a similar perspective (I calle= d it =E2=80=9Cframe of reference=E2=80=9D) at a sacm BoF (back in Atlanta during IETF 85 [1]) to frame the =E2=80=9Cspace=E2=80=9D in which sacm pla= ys.=C2=A0 I think mile =C2=A0, i2nsf, and dots all play in this same space = (see the second, third, and fourth slides). =C2=A0

=C2=A0

What seems important is that we recognize (and name)= the different business processes we are supporting.=C2=A0 This should help= us recognize the relationships between our work.

=C2=A0

Thoughts?

=C2=A0

Regards,

=C2=A0

Adam

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mar 27, 2015, at 9:01 PM, Melinda Shore <melinda.shore@gmail.com> wrote:

=C2=A0

I'm rather surprised that nobody has answered th= is!

I think this is a very reasonable approach, with the
caveat that what's needed *here* is not so much an architecture
but an actual protocol conveying actual data between actual
network elements.=C2=A0 This may be why other middlebox protocols
<rimshot> have been able to move forward, even while being
redundant, while this effort has been stuck.=C2=A0 It seems to
me, based on discussions during the week and on both the
input to and the output from the dots BOF, that there's
still room for a good backend protocol to convey requests
to what used to be called policy enforcement points based
on the active threat data being shared through a dots-like mechanism.
But that's a very narrow example.

So, I think to the extent that a taxonomy can help this
effort develop a narrow focus, it would be a very helpful
thing indeed.=C2=A0 But it's got to be very applied - I am
skeptical about the value of high-level architectures in
the IETF.

Melinda

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/i2nsf

=C2=A0


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/i2nsf



=C2=A0

--

=C2=A0

Best regards,

Kathleen




--

Best regards,
Kath= leen
--001a11c2432adcdfc905146c9c9d-- From nobody Fri Apr 24 00:36:39 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEC51B352A for ; Fri, 24 Apr 2015 00:36:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2JQKmvhR036d for ; Fri, 24 Apr 2015 00:36:33 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EF91B3524 for ; Fri, 24 Apr 2015 00:35:43 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 86439E009A; Fri, 24 Apr 2015 09:35:40 +0200 (CEST) Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 730D3E016E; Fri, 24 Apr 2015 09:35:40 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.52) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 24 Apr 2015 09:35:39 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0621.eurprd06.prod.outlook.com (25.161.13.139) with Microsoft SMTP Server (TLS) id 15.1.136.25; Fri, 24 Apr 2015 07:35:38 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0136.026; Fri, 24 Apr 2015 07:35:38 +0000 From: DIEGO LOPEZ GARCIA To: Kathleen Moriarty Thread-Topic: [I2nsf] The defense 'ecosystem' paradigm Thread-Index: AQHQZyJJ7Y8KFD7s+UyPmqnfFjT0J50xJ+sAgACyxYCABtjvAIAA8heAgCFa7ACAAPOcgA== Date: Fri, 24 Apr 2015 07:35:37 +0000 Message-ID: References: <5512F1ED.8020104@htt-consult.com> <55160B74.1010009@gmail.com> <032CF466-C78E-46C7-A171-5176555A97DA@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657BFFB52@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [176.84.210.227] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0621; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(243025005)(252514010)(164054003)(377454003)(124975003)(19580405001)(93886004)(46102003)(106116001)(110136001)(19617315012)(40100003)(36756003)(66066001)(2656002)(122556002)(87936001)(92566002)(86362001)(16236675004)(54356999)(62966003)(2950100001)(83716003)(77156002)(19580395003)(33656002)(76176999)(102836002)(50986999)(82746002)(2900100001)(15975445007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0621; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006)(3002001); SRVR:DB4PR06MB0621; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; x-forefront-prvs: 05568D1FF7 Content-Type: multipart/alternative; boundary="_000_FC5058E7E0B74EB7B4C17F1AE40A421Ftelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2015 07:35:37.8101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0621 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , Melinda Shore , "Adam W. Montville" , Linda Dunbar Subject: Re: [I2nsf] The defense 'ecosystem' paradigm X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 07:36:38 -0000 --_000_FC5058E7E0B74EB7B4C17F1AE40A421Ftelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Just a note regarding SACM and I2NSF: In many cases, I2NSF tenants would be= interested in having some assessment about the conditions of the security = functions, and there SACM postures could be of applicability. Be goode, On 23 Apr 2015, at 19:03 , Kathleen Moriarty > wrote: Hi, I have been meaning to respond on how MILE and SACM fit with I2NSF and DOTS= in a bigger picture view. I just have old slides for MILE and SACM. See = slide 12 of this PPT, where SACM is on the far left (Configuration and poss= ibly Assets) and MILE is circled. http://scap.nist.gov/events/2011/itsac/presentations/day2/Moriarty%20-%20IE= TF%20MILE,%20Improving%20Incident%20and%20Information%20Sharing%20Standards= .pdf I had better versions of that slide, but I am not able to find them online = and don't want to clog up everyone's email. This should be good enough. DOTS could feed into MILE, where reports from DOTS are part of a larger inv= estigation or set of indicators being exchanged using DOTS formatted data w= ithin an IODEF envelope. It's a specific sub-use case that has different e= nough requirements that it should not be in MILE. I2NSF is concerned with tenant's ability to provision/change rules on hoste= d security devices, allowing tenants to make these changes. This is differ= ent from SACM as SACM is assessing posture and not doing things like managi= ng firewall rule sets or changing filtering options for flow based protocol= s. On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville > wrote: On Apr 1, 2015, at 4:15 PM, Linda Dunbar > wrote: Adam, You said: sacm is, at its core, primarily interested in assessing endpoint attributes= . This means expressing the desired attribute to collect, collecting it, a= nd evaluating it against some expressed expectation. The assessment result= is provided for downstream use, irrespective of what that use might be. A= dditionally, collection could be the only results provided (if no evaluatio= n piece is needed). How are the =93desired attributes=94 expressed by SACM? How are the =93expe= ctation=94 being specified? At this point we are working on an information model [1] and have not yet a= rrived at data models. I would anticipate several data models to exist, de= pending on the source of the data being collected. [1] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ (no= te that this will almost certainly updated between now and IETF 93). Inter= mediate work can be found here: https://github.com/sacmwg/draft-ietf-sacm-i= nformation-model). Thanks, Linda From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Adam W. Montville Sent: Saturday, March 28, 2015 7:41 AM To: Melinda Shore Cc: i2nsf@ietf.org Subject: Re: [I2nsf] The defense 'ecosystem' paradigm Having a cross-group understanding of the relationship between i2nsf, sacm,= mile, and dots would be beneficial. I=92m less familiar with i2nsf and do= ts (in the details). It seems that mile, i2nsf, and dots would all benefit from sacm in some way= , as they are largely downstream from the core problem sacm intends to solv= e. i2nsf seeks to express and evaluate network service related information, wh= ich will ultimately need to identify specific endpoints (virtual or otherwi= se) to collect specific attributes, evaluate them against some expressed ex= pectation, then make sense of that at the i2nsf level. mile could benefit from sacm by leveraging the attribute expression and eva= luation formats. Additionally, the =93ad hoc=94 exploratory tools often fa= vored during incident response could use sacm as a means of that exploratio= n. dots is my least understood domain, but after speaking with Ana Hedanping f= or a brief time, it seems that dots will have some need to express endpoint= attributes, collect values, and evaluate them against some expectation as = well. Only, this will be more of a =93real time=94 circumstance (I presume= ). As Bob pointed out, these are all parts of a whole - the =93defense ecosyst= em paradigm=94. And, while deriving a specific taxonomy could be useful, = it=92s already done in a way. The =93defense =91ecosystem=92 paradigm" see= ms to me like a synonym for =93security program=94, and those are well cove= red. Think ISO 27000 series, NIST 800-53, PCI DSS, COBIT, 20 Critical Secu= rity Controls, and the like. In fact, I used a similar perspective (I call= ed it =93frame of reference=94) at a sacm BoF (back in Atlanta during IETF = 85 [1]) to frame the =93space=94 in which sacm plays. I think mile , i2ns= f, and dots all play in this same space (see the second, third, and fourth = slides). What seems important is that we recognize (and name) the different business= processes we are supporting. This should help us recognize the relationsh= ips between our work. Thoughts? Regards, Adam [1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf On Mar 27, 2015, at 9:01 PM, Melinda Shore > wrote: I'm rather surprised that nobody has answered this! I think this is a very reasonable approach, with the caveat that what's needed *here* is not so much an architecture but an actual protocol conveying actual data between actual network elements. This may be why other middlebox protocols have been able to move forward, even while being redundant, while this effort has been stuck. It seems to me, based on discussions during the week and on both the input to and the output from the dots BOF, that there's still room for a good backend protocol to convey requests to what used to be called policy enforcement points based on the active threat data being shared through a dots-like mechanism. But that's a very narrow example. So, I think to the extent that a taxonomy can help this effort develop a narrow focus, it would be a very helpful thing indeed. But it's got to be very applied - I am skeptical about the value of high-level architectures in the IETF. Melinda _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf -- Best regards, Kathleen _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_FC5058E7E0B74EB7B4C17F1AE40A421Ftelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

Just a note regarding SACM and I2NSF: In many cases, I2NSF tenants wou= ld be interested in having some assessment about the conditions of the secu= rity functions, and there SACM postures could be of applicability.

Be goode,

On 23 Apr 2015, at 19:03 , Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wro= te:

Hi,

I have been meaning to respond on how MILE and SACM fit with I2NSF and= DOTS in a bigger picture view.  I just have old slides for MILE and S= ACM.  See slide 12 of this PPT, where SACM is on the far left (Configu= ration and possibly Assets) and MILE is circled.

I had better versions of that slide, but I am not able to find them on= line and don't want to clog up everyone's email.  This should be good = enough.

DOTS could feed into MILE, where reports from DOTS are part of a large= r investigation or set of indicators being exchanged using DOTS formatted d= ata within an IODEF envelope.  It's a specific sub-use case that has d= ifferent enough requirements that it should not be in MILE.

I2NSF is concerned with tenant's ability to provision/change rules on = hosted security devices, allowing tenants to make these changes.  This= is different from SACM as SACM is assessing posture and not doing things l= ike managing firewall rule sets or changing filtering options for flow based protocols. 

On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montvill= e <adam.w.= montville@gmail.com> wrote:

On Apr 1, 2015, at 4:15 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:<= /div>
Adam,
 
You said:
sacm is, at its core, primarily int= erested in assessing endpoint attributes.  This means expressing the d= esired attribute to collect, collecting it, and evaluating it against some = expressed expectation.  The assessment result is provided for downstream use, irrespective of what that use might= be.  Additionally, collection could be the only results provided (if = no evaluation piece is needed).
 
How are the =93desired attributes=94 expressed by SACM? How are the= =93expectation=94 being specified?
At this point we are working on an information model [1] and have not = yet arrived at data models.  I would anticipate several data models to= exist, depending on the source of the data being collected.


[1] https://datatracker.ietf.org/doc/draft= -ietf-sacm-information-model/ (note that this will almost certainl= y updated between now and IETF 93).  Intermediate work can be found here: https://github.com/sacmwg/draf= t-ietf-sacm-information-model).



 
Thanks, Linda
 
From:&nb= sp;I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Adam W. Montville
Sent: Saturday, March 28, 2015 7:41 AM
To: Melinda Shore
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] The defense 'ecosystem' parad= igm
 
Having a cross-group understanding of the relationship between i2nsf, sacm,= mile, and dots would be beneficial.  I=92m less familiar with i2nsf a= nd dots (in the details). 
 
 
It seems that mile, i2nsf, and dots would all benefit from sacm in some way= , as they are largely downstream from the core problem sacm intends to solv= e.  
 
i2nsf seeks to express and evaluate network service related information, wh= ich will ultimately need to identify specific endpoints (virtual or otherwi= se) to collect specific attributes, evaluate them against some expressed ex= pectation, then make sense of that at the i2nsf level.
 
mile could benefit from sacm by leveraging the attribute expression and eva= luation formats.  Additionally, the =93ad hoc=94 exploratory tools oft= en favored during incident response could use sacm as a means of that explo= ration.
 
dots is my least understood domain, but after speaking with Ana Hedanping f= or a brief time, it seems that dots will have some need to express endpoint= attributes, collect values, and evaluate them against some expectation as = well.  Only, this will be more of a =93real time=94 circumstance (I presume).
 
As Bob pointed out, these are all parts of a whole - the =93defense ecosyst= em paradigm=94.   And, while deriving a specific taxonomy could be use= ful, it=92s already done in a way.  The =93defense =91ecosystem=92 par= adigm" seems to me like a synonym for =93security program=94, and those are well covered.  Think ISO 27000 series, NIST 800-53, PCI= DSS, COBIT, 20 Critical Security Controls, and the like.  In fact, I = used a similar perspective (I called it =93frame of reference=94) at a sacm= BoF (back in Atlanta during IETF 85 [1]) to frame the =93space=94 in which sacm plays.  I think mile  , i2nsf, and= dots all play in this same space (see the second, third, and fourth slides= ).  
 
What seems important is that we recognize (and name) the different business= processes we are supporting.  This should help us recognize the relat= ionships between our work.
 
Thoughts?
 
Regards,
 
Adam
 
 
 
 
On Mar 27, 2015, at 9:01 PM, Melinda Shore <melinda.shore@gmail.com> wrote:
 
I'm rather surprised that nobody has answered this!

I think this is a very reasonable approach, with the
caveat that what's needed *here* is not so much an architecture
but an actual protocol conveying actual data between actual
network elements.  This may be why other middlebox protocols
<rimshot> have been able to move forward, even while being
redundant, while this effort has been stuck.  It seems to
me, based on discussions during the week and on both the
input to and the output from the dots BOF, that there's
still room for a good backend protocol to convey requests
to what used to be called policy enforcement points based
on the active threat data being shared through a dots-like mechanism.
But that's a very narrow example.

So, I think to the extent that a taxonomy can help this
effort develop a narrow focus, it would be a very helpful
thing indeed.  But it's got to be very applied - I am
skeptical about the value of high-level architectures in
the IETF.

Melinda

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailma= n/listinfo/i2nsf


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/i2nsf




--

Best regards,
Kathleen
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lo= pez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_FC5058E7E0B74EB7B4C17F1AE40A421Ftelefonicacom_-- From nobody Fri Apr 24 04:44:24 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A6A1A8F3A for ; Fri, 24 Apr 2015 04:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 SSof24yo_3fr for ; Fri, 24 Apr 2015 04:44:17 -0700 (PDT) Received: from mail-vn0-x22e.google.com (mail-vn0-x22e.google.com [IPv6:2607:f8b0:400c:c0f::22e]) (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 600F11A8F36 for ; Fri, 24 Apr 2015 04:44:17 -0700 (PDT) Received: by vnbf129 with SMTP id f129so3719600vnb.9 for ; Fri, 24 Apr 2015 04:44: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=1wDEE/x+Cka0Hh6sS5Pc9mDZwBHsiuGm9alACawrO44=; b=co8ezPSrCurwS6iiW93ssQVVFRct3vERMuFfXx1RPyZJcBPLhvVcdcx4rJ2tAZG7wl vBgP9J8L26ee+j04qUYFRN9ZtqNkfR5iGCx96dKF6yOmgYS6vXIQanWd0PKI2cJfumjJ mJvegLr5bm/r2W91eh8vHCRtz0XmGwtQ0H4wuQNKuS3SXwEnzSfpLiYThMrZ3gJvGp5F /91yIIjCM15xn3+Fyn7HKIhLIZapY+yw1qSZZLAYxVGt0JjXFARrcU7LHg6Ojcv0Bk0V tkcZm+S+WPlZgC8S/dav8Jtne3kyV1W4zpOx6+N0iVw8QHQBZEWTPrmv1BoAu3quXP+r hFZg== X-Received: by 10.52.227.42 with SMTP id rx10mr8093012vdc.14.1429875856583; Fri, 24 Apr 2015 04:44: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 hb1sm4147134vdb.1.2015.04.24.04.44.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Apr 2015 04:44:15 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-505EBA1C-A026-4D70-B854-4E6E3CE89722 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Fri, 24 Apr 2015 07:44:14 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <5512F1ED.8020104@htt-consult.com> <55160B74.1010009@gmail.com> <032CF466-C78E-46C7-A171-5176555A97DA@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657BFFB52@dfweml701-chm> To: DIEGO LOPEZ GARCIA Archived-At: Cc: "i2nsf@ietf.org" , Melinda Shore , "Adam W. Montville" , Linda Dunbar Subject: Re: [I2nsf] The defense 'ecosystem' paradigm X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 11:44:23 -0000 --Apple-Mail-505EBA1C-A026-4D70-B854-4E6E3CE89722 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Deigo, I agree. Sure, there was some work do e 10-15 years ago where assessments o= f posture fed risk assessments. When a vulnerability became known, there co= uld be an automated response to set a firewall rule as a mitigation for that= vulnerability on the systems protected by the firewall. The efforts can interact and feed each other, but don't overlap. Thanks, Kathleen Sent from my iPhone > On Apr 24, 2015, at 3:35 AM, DIEGO LOPEZ GARCIA wrote: >=20 > Hi, >=20 > Just a note regarding SACM and I2NSF: In many cases, I2NSF tenants would b= e interested in having some assessment about the conditions of the security f= unctions, and there SACM postures could be of applicability. >=20 > Be goode, >=20 >> On 23 Apr 2015, at 19:03 , Kathleen Moriarty wrote: >>=20 >> Hi, >>=20 >> I have been meaning to respond on how MILE and SACM fit with I2NSF and DO= TS in a bigger picture view. I just have old slides for MILE and SACM. See= slide 12 of this PPT, where SACM is on the far left (Configuration and poss= ibly Assets) and MILE is circled. >> http://scap.nist.gov/events/2011/itsac/presentations/day2/Moriarty%20-%20= IETF%20MILE,%20Improving%20Incident%20and%20Information%20Sharing%20Standard= s.pdf >>=20 >> I had better versions of that slide, but I am not able to find them onlin= e and don't want to clog up everyone's email. This should be good enough. >>=20 >> DOTS could feed into MILE, where reports from DOTS are part of a larger i= nvestigation or set of indicators being exchanged using DOTS formatted data w= ithin an IODEF envelope. It's a specific sub-use case that has different en= ough requirements that it should not be in MILE. >>=20 >> I2NSF is concerned with tenant's ability to provision/change rules on hos= ted security devices, allowing tenants to make these changes. This is diffe= rent from SACM as SACM is assessing posture and not doing things like managi= ng firewall rule sets or changing filtering options for flow based protocols= .=20 >>=20 >>> On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville wrote: >>>=20 >>>> On Apr 1, 2015, at 4:15 PM, Linda Dunbar wrot= e: >>>>=20 >>>> Adam, >>>> =20 >>>> You said: >>>> sacm is, at its core, primarily interested in assessing endpoint attrib= utes. This means expressing the desired attribute to collect, collecting it= , and evaluating it against some expressed expectation. The assessment resu= lt is provided for downstream use, irrespective of what that use might be. A= dditionally, collection could be the only results provided (if no evaluation= piece is needed). >>>> =20 >>>> How are the =E2=80=9Cdesired attributes=E2=80=9D expressed by SACM? How= are the =E2=80=9Cexpectation=E2=80=9D being specified? >>>=20 >>>=20 >>> At this point we are working on an information model [1] and have not ye= t arrived at data models. I would anticipate several data models to exist, d= epending on the source of the data being collected. >>>=20 >>>=20 >>> [1] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ (= note that this will almost certainly updated between now and IETF 93). Inte= rmediate work can be found here: https://github.com/sacmwg/draft-ietf-sacm-i= nformation-model). >>>=20 >>>=20 >>>=20 >>>> =20 >>>> Thanks, Linda >>>> =20 >>>> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Adam W. Montvi= lle >>>> Sent: Saturday, March 28, 2015 7:41 AM >>>> To: Melinda Shore >>>> Cc: i2nsf@ietf.org >>>> Subject: Re: [I2nsf] The defense 'ecosystem' paradigm >>>> =20 >>>> Having a cross-group understanding of the relationship between i2nsf, s= acm, mile, and dots would be beneficial. I=E2=80=99m less familiar with i2n= sf and dots (in the details).=20 >>>> =20 >>>> =20 >>>> It seems that mile, i2nsf, and dots would all benefit from sacm in some= way, as they are largely downstream from the core problem sacm intends to s= olve. =20 >>>> =20 >>>> i2nsf seeks to express and evaluate network service related information= , which will ultimately need to identify specific endpoints (virtual or othe= rwise) to collect specific attributes, evaluate them against some expressed e= xpectation, then make sense of that at the i2nsf level. >>>> =20 >>>> mile could benefit from sacm by leveraging the attribute expression and= evaluation formats. Additionally, the =E2=80=9Cad hoc=E2=80=9D exploratory= tools often favored during incident response could use sacm as a means of t= hat exploration. >>>> =20 >>>> dots is my least understood domain, but after speaking with Ana Hedanpi= ng for a brief time, it seems that dots will have some need to express endpo= int attributes, collect values, and evaluate them against some expectation a= s well. Only, this will be more of a =E2=80=9Creal time=E2=80=9D circumstan= ce (I presume). >>>> =20 >>>> As Bob pointed out, these are all parts of a whole - the =E2=80=9Cdefen= se ecosystem paradigm=E2=80=9D. And, while deriving a specific taxonomy co= uld be useful, it=E2=80=99s already done in a way. The =E2=80=9Cdefense =E2= =80=98ecosystem=E2=80=99 paradigm" seems to me like a synonym for =E2=80=9Cs= ecurity program=E2=80=9D, and those are well covered. Think ISO 27000 serie= s, NIST 800-53, PCI DSS, COBIT, 20 Critical Security Controls, and the like.= In fact, I used a similar perspective (I called it =E2=80=9Cframe of refer= ence=E2=80=9D) at a sacm BoF (back in Atlanta during IETF 85 [1]) to frame t= he =E2=80=9Cspace=E2=80=9D in which sacm plays. I think mile , i2nsf, and d= ots all play in this same space (see the second, third, and fourth slides). = =20 >>>> =20 >>>> What seems important is that we recognize (and name) the different busi= ness processes we are supporting. This should help us recognize the relatio= nships between our work. >>>> =20 >>>> Thoughts? >>>> =20 >>>> Regards, >>>> =20 >>>> Adam >>>> =20 >>>> [1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf >>>> =20 >>>> =20 >>>> =20 >>>> On Mar 27, 2015, at 9:01 PM, Melinda Shore wr= ote: >>>> =20 >>>> I'm rather surprised that nobody has answered this! >>>>=20 >>>> I think this is a very reasonable approach, with the >>>> caveat that what's needed *here* is not so much an architecture >>>> but an actual protocol conveying actual data between actual >>>> network elements. This may be why other middlebox protocols >>>> have been able to move forward, even while being >>>> redundant, while this effort has been stuck. It seems to >>>> me, based on discussions during the week and on both the >>>> input to and the output from the dots BOF, that there's >>>> still room for a good backend protocol to convey requests >>>> to what used to be called policy enforcement points based >>>> on the active threat data being shared through a dots-like mechanism. >>>> But that's a very narrow example. >>>>=20 >>>> So, I think to the extent that a taxonomy can help this >>>> effort develop a narrow focus, it would be a very helpful >>>> thing indeed. But it's got to be very applied - I am >>>> skeptical about the value of high-level architectures in >>>> the IETF. >>>>=20 >>>> Melinda >>>>=20 >>>> _______________________________________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2nsf >>>=20 >>>=20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf >=20 > -- > "Esta vez no fallaremos, Doctor Infierno" >=20 > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ >=20 > e-mail: diego.r.lopez@telefonica.com > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- >=20 >=20 >=20 > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, p= uede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario i= ndicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3= n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de la legi= slaci=C3=B3n vigente. Si ha recibido este mensaje por error, le rogamos que n= os lo comunique inmediatamente por esta misma v=C3=ADa y proceda a su destru= cci=C3=B3n. >=20 > The information contained in this transmission is privileged and confident= ial information intended only for the use of the individual or entity named a= bove. If the reader of this message is not the intended recipient, you are h= ereby notified that any dissemination, distribution or copying of this commu= nication is strictly prohibited. If you have received this transmission in e= rror, do not read it. Please immediately reply to the sender that you have r= eceived this communication in error and then delete it. >=20 > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 p= ara uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa= senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, ut= iliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3= =A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se rece= beu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente po= r esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --Apple-Mail-505EBA1C-A026-4D70-B854-4E6E3CE89722 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Deigo,

I a= gree.  Sure, there was some work do e 10-15 years ago where assessments= of posture fed risk assessments.  When a vulnerability became known, t= here could be an automated response to set a firewall rule as a mitigation f= or that vulnerability on the systems protected by the firewall.
The efforts can interact and feed each other, but don't overlap= .

Thanks,
Kathleen

Sent from my iP= hone

On Apr 24, 2015, at 3:35 AM, DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com&= gt; wrote:

Hi,

Just a note regarding SACM and I2NSF: In many cases, I2NSF tenants woul= d be interested in having some assessment about the conditions of the securi= ty functions, and there SACM postures could be of applicability.

Be goode,

On 23 Apr 2015, at 19:03 , Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote= :

Hi,

I have been meaning to respond on how MILE and SACM fit with I2NSF and D= OTS in a bigger picture view.  I just have old slides for MILE and SACM= .  See slide 12 of this PPT, where SACM is on the far left (Configurati= on and possibly Assets) and MILE is circled.

I had better versions of that slide, but I am not able to find them onl= ine and don't want to clog up everyone's email.  This should be good en= ough.

DOTS could feed into MILE, where reports from DOTS are part of a larger= investigation or set of indicators being exchanged using DOTS formatted dat= a within an IODEF envelope.  It's a specific sub-use case that has diff= erent enough requirements that it should not be in MILE.

I2NSF is concerned with tenant's ability to provision/change rules on h= osted security devices, allowing tenants to make these changes.  This i= s different from SACM as SACM is assessing posture and not doing things like= managing firewall rule sets or changing filtering options for flow based protocols. 

On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville= <adam.w.m= ontville@gmail.com> wrote:

On Apr 1, 2015, at 4:15 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:
Adam,
 
You said:
sacm is, at its core, primarily inte= rested in assessing endpoint attributes.  This means expressing the des= ired attribute to collect, collecting it, and evaluating it against some exp= ressed expectation.  The assessment result is provided for downstream use, irrespective of what that use might b= e.  Additionally, collection could be the only results provided (if no e= valuation piece is needed).
 
How are the =E2=80=9Cdesired attributes=E2=80=9D expressed by SACM? H= ow are the =E2=80=9Cexpectation=E2=80=9D being specified?
At this point we are working on an information model [1] and have not y= et arrived at data models.  I would anticipate several data models to e= xist, depending on the source of the data being collected.


[1] https://datatracker.ietf.org/doc/draft-i= etf-sacm-information-model/ (note that this will almost certainly u= pdated between now and IETF 93).  Intermediate work can be found here: https://github.com/sacmwg/draft-= ietf-sacm-information-model).



 
Thanks, Linda
 
From:=  = ;I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Adam W. Montville
Sent: Saturday, March 28, 2015 7:41 AM
To: Melinda Shore
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] The defense 'ecosystem' paradi= gm
 
Having a cross-group understanding of the relationship between i2nsf, sacm, m= ile, and dots would be beneficial.  I=E2=80=99m less familiar with i2ns= f and dots (in the details). 
 
 
It seems that mile, i2nsf, and dots would all benefit from sacm in some way,= as they are largely downstream from the core problem sacm intends to solve.=  
 
i2nsf seeks to express and evaluate network service related information, whi= ch will ultimately need to identify specific endpoints (virtual or otherwise= ) to collect specific attributes, evaluate them against some expressed expec= tation, then make sense of that at the i2nsf level.
 
mile could benefit from sacm by leveraging the attribute expression and eval= uation formats.  Additionally, the =E2=80=9Cad hoc=E2=80=9D exploratory= tools often favored during incident response could use sacm as a means of t= hat exploration.
 
dots is my least understood domain, but after speaking with Ana Hedanping fo= r a brief time, it seems that dots will have some need to express endpoint a= ttributes, collect values, and evaluate them against some expectation as wel= l.  Only, this will be more of a =E2=80=9Creal time=E2=80=9D circumstance (I presume).
=
 
As Bob pointed out, these are all parts of a whole - the =E2=80=9Cdefense ec= osystem paradigm=E2=80=9D.   And, while deriving a specific taxonomy co= uld be useful, it=E2=80=99s already done in a way.  The =E2=80=9Cdefens= e =E2=80=98ecosystem=E2=80=99 paradigm" seems to me like a synonym for =E2=80= =9Csecurity program=E2=80=9D, and those are well covered.  Think ISO 27000 series, NIST 800-53, PCI D= SS, COBIT, 20 Critical Security Controls, and the like.  In fact, I use= d a similar perspective (I called it =E2=80=9Cframe of reference=E2=80=9D) a= t a sacm BoF (back in Atlanta during IETF 85 [1]) to frame the =E2=80=9Cspace=E2=80=9D in which sacm plays.  I think mile  ,= i2nsf, and dots all play in this same space (see the second, third, and fou= rth slides).  
 
What seems important is that we recognize (and name) the different business p= rocesses we are supporting.  This should help us recognize the relation= ships between our work.
 
Thoughts?
 
Regards,
 
Adam
 
 
 
 
On Mar 27, 2015, at 9:01 PM, Melinda Shore <melinda.shore@gmail.com> wrote:
 
I'm rather surprised that nobody has answered this!

I think this is a very reasonable approach, with the
caveat that what's needed *here* is not so much an architecture
but an actual protocol conveying actual data between actual
network elements.  This may be why other middlebox protocols
<rimshot> have been able to move forward, even while being
redundant, while this effort has been stuck.  It seems to
me, based on discussions during the week and on both the
input to and the output from the dots BOF, that there's
still room for a good backend protocol to convey requests
to what used to be called policy enforcement points based
on the active threat data being shared through a dots-like mechanism.
But that's a very narrow example.

So, I think to the extent that a taxonomy can help this
effort develop a narrow focus, it would be a very helpful
thing indeed.  But it's got to be very applied - I am
skeptical about the value of high-level architectures in
the IETF.

Melinda

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/= listinfo/i2nsf


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2nsf




--

Best regards,
Kathleen
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org= /mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lop= ez/

e-mail: diego.r.lopez@telefo= nica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pue= de contener informaci=C3=B3n privilegiada o confidencial y es para uso exclu= sivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n= puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha recib= ido este mensaje por error, le rogamos que nos lo comunique inmediatamente p= or esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidentia= l information intended only for the use of the individual or entity named ab= ove. If the reader of this message is not the intended recipient, you are he= reby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If yo= u have received this transmission in error, do not read it. Please immediate= ly reply to the sender that you have received this communication in error an= d then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1r= io, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 p= ara uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa= senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem aut= oriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vi= gente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique im= ediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
= --Apple-Mail-505EBA1C-A026-4D70-B854-4E6E3CE89722-- From nobody Mon Apr 27 20:13:20 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A7A1A8A71 for ; Mon, 27 Apr 2015 20:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, 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 JTp_-GLhb2fj for ; Mon, 27 Apr 2015 20:13:18 -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 5962E1ACE34 for ; Mon, 27 Apr 2015 20:13:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRX08323; Tue, 28 Apr 2015 03:13:15 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Apr 2015 04:10:48 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Tue, 28 Apr 2015 11:10:21 +0800 From: "Xialiang (Frank)" To: "i2nsf@ietf.org" Thread-Topic: Solicit comments on the new design of capability inteface information model: Thread-Index: AdCBYNxg9QwoLZgqQGeTjoRnG6f2nQ== Date: Tue, 28 Apr 2015 03:10:21 +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: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADB57FFSZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] Solicit comments on the new design of capability inteface information model: X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 03:13:20 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB57FFSZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We are updating the -01 version of draft-xia-i2nsf-capability-interface-im = now. We consider all the comments and discussions related in mailing list, = especially the packet-based paradigm proposed in draft-lopez-i2nsf-packet-0= 0, are all very good inputs for this interface. So, we propose a new information model of I2NSF capability(function) interf= ace, which aligns the existing design with all comments and is based on the= packet-based paradigm: +-------------+ +-> User/tenant| | | /VN-id | | +-------------+ | +---------+ | |Address/ | +->address | | |group | | +---------+ | +-----------+ | |Layer 2/3/4| +->header, or | | |payload | +------+ | +-----------+ |Packet| | +---------+ +->based |-+-> Service | | |match | | +---------+ | +------+ | +-----------+ | +->Application| | +-----------+ +----+ +-----+ | | | +->Match|-+ +----------+ +-->Rule| | +-----+ | +-> Session | | | | | | | | state | | +----+ | | +-------+ | +----------+ | | | |context| | +----------+ | * | +->based +-+-> Schedule | | * | |match | | +----------+ | * | +-------+ | +---------+ | | | |Region/ | | | +->region | +------+ +----+ | |group | | | | | | | +---------+ |Policy+--+-->Rule+--+ | | | | | | +-------+ +------+ | +----+ | +->Permit + | | | +-------+ | * | +-------+ | +-------+ | * | +->Basic +-+-> Deny | | * | | |actions| | +-------+ | | | +-------+ | +-------+ | | | +-> Mirror| | | | +-------+ | | | | | | +----------+ | | | +->Antivirus:| | +----+ | | | |profile | | | | | +-------+ | | +----------+ +-->Rule| +->Actions+-+ | +---------+ | | +-------+ | +-> IPS: | +----+ | |signature| | | +---------+ | | +----------+ | | | URL | | +->Filtering:| | |data base | | | +----------+ | +--------+ | +----------+ +->Advanced+-+ | File | |actions | +->Blocking: | +--------+ | |profile | | +----------+ | +----------+ | | Data | +->Filtering:| | |profile | | +----------+ | +-----------+ | |Application| +-> control | | +-----------+ | * +-> * * We hope to get your comments on this new IM design, to help us to go forwar= d. Thanks a lot! B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB57FFSZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

We are updating the -01 version= of draft-xia-i2nsf-capability-interface-im now. We consider all the commen= ts and discussions related in mailing list, especially the packet-based par= adigm proposed in draft-lopez-i2nsf-packet-00, are all very good inputs for this interface.

So, we propose a new informatio= n model of I2NSF capability(function) interface, which aligns the existing = design with all comments and is based on the packet-based paradigm:

   =             &n= bsp;            = ;            &n= bsp;  +-------------+

   =             &nb= sp;            =              &n= bsp;+->  User/tenant|

   =             &nb= sp;            =             &nb= sp; | |  /VN-id     |

   =             &nb= sp;            =             &nb= sp; | +-------------+

   =             &nb= sp;            =             &nb= sp; | +---------+

   =             &nb= sp;            =             &nb= sp; | |Address/ |

   =             &nb= sp;            =             &nb= sp; +->address  |

   =             &nb= sp;            =             &nb= sp; | |group    |

   =             &nb= sp;            =             &nb= sp; | +---------+

   =             &nb= sp;            =             &nb= sp; | +-----------+

   =             &nb= sp;             = ;            &n= bsp;| |Layer 2/3/4|

   =             &nb= sp;            =             &nb= sp; +->header, or |

   =             &nb= sp;            =             &nb= sp; | |payload    |

   =             &nb= sp;            =      +------+ | +-----------+

   =             &nb= sp;            =      |Packet| | +---------+

   =             &nb= sp;            =    +->based |-+-> Service |

   =             &nb= sp;            =    | |match | | +---------+

   =             &nb= sp;            =    | +------+ | +-----------+

   =             &nb= sp;            =    |          +-= >Application|

   =             &nb= sp;             = ;  |          &= nbsp; +-----------+

   =           +----+ =    +-----+ |

   =           |    = |  +->Match|-+       &nb= sp;     +----------+

   =        +-->Rule|  | +-----= 3; |           +->= Session  |

   =        |  |    |  |&= nbsp;        |    &n= bsp;      | | state    |=

   =        |  +----+  | &n= bsp;       | +-------+ | +-------= ---+

   =        |      &= nbsp;   |         | |cont= ext| | +----------+

   =        |    *   = ;  |         +->based&n= bsp; +-+-> Schedule |

   =        |    *   = ;  |           |matc= h  | | +----------+

   =        |    *   = ;  |           += -------+ | +---------+

   =        |      &= nbsp;   |         &n= bsp;           | |Region/=   |

   =        |      &= nbsp;   |         &n= bsp;           +->= region   |

+------+&n= bsp;    +----+  |     =             &nb= sp;     |group    |

|   = ;   |  |  |    |  |  &nbs= p;            &= nbsp;       +---------+

|Policy+--+= ;-->Rule+--+

|   = ;   |  |  |    |  |  &nbs= p;            &= nbsp;         +-------+

+------+&n= bsp; |  +----+  |      &nbs= p;            &= nbsp;   +->Permit +

   =        |      &= nbsp;   |         &n= bsp;            = ; | +-------+

   =        |    *   = ;  |           =   +-------+ | +-------+

   =        |    *   = ;  |           += ->Basic  +-+-> Deny  |

   =        |    *   = ;  |           | |ac= tions| | +-------+

   =        |      &= nbsp;   |         &n= bsp; | +-------+ | +-------+

   =        |      &= nbsp;   |         &n= bsp; |           +-&g= t; Mirror|

   =        |      &= nbsp;   |         &n= bsp; |            &n= bsp;+-------+

   =        |      &= nbsp;   |         &n= bsp; |

   =        |      &= nbsp;   |         &n= bsp; |           &nb= sp;  +----------+

   =        |      &= nbsp;   |         &n= bsp; |            &#= 43;->Antivirus:|

   =        |  +----+  | &n= bsp;         |   &nb= sp;        | |profile   |=

   =        |  |    |  | = +-------+ |         &n= bsp;  | +----------+

   =        +-->Rule|  +->Actio= ns+-+          &n= bsp; | +---------+

   =           |    = |    +-------+ |      =       +->  IPS:   |

   =           +----+ =             &nb= sp;            = | |signature|

   =             &nb= sp;            =      |        &= nbsp;   | +---------+

   =             &nb= sp;            =      |        &= nbsp;   | +----------+

   =             &nb= sp;             = ;    |        &= nbsp;   | | URL      |=

   =             &nb= sp;            =      |        &= nbsp;   +->Filtering:|

   =             &nb= sp;            =             &nb= sp;     | |data base |

   =             &nb= sp;            =      |        &= nbsp;   | +----------+

   =             &nb= sp;            =      | +--------+ | +----------+

   =             &nb= sp;            =      +->Advanced+-+ |  File &n= bsp;  |

   =             &nb= sp;            =        |actions | +->Blocking: |<= /o:p>

   =             &nb= sp;            =        +--------+ | |profile &nb= sp; |

   =             &nb= sp;            =             &nb= sp;     | +----------+

   =             &nb= sp;            =             &nb= sp;     | +----------+

   =             &nb= sp;            =             &nb= sp;     | |  Data    |

   =             &nb= sp;            =             &nb= sp;     +->Filtering:|

   =             &nb= sp;            =             &nb= sp;     | |profile   |

   =             &nb= sp;            =             &nb= sp;     | +----------+

   =             &nb= sp;            =             &nb= sp;     | +-----------+

   =             &nb= sp;            =             &nb= sp;     | |Application|

   =             &nb= sp;            =             &nb= sp;     +->  control  |

   =              &n= bsp;            = ;            &n= bsp;    | +-----------+

   =             &nb= sp;            =             &nb= sp;     |   *

   =             &nb= sp;            =             &nb= sp;     +-> *

   =             &nb= sp;            =             &nb= sp;         *

 

We hope to get your comments on= this new IM design, to help us to go forward.

Thanks a lot!=

 

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADB57FFSZXEMA502MBSchi_-- From nobody Tue Apr 28 07:57:44 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32C51A1BA4 for ; Tue, 28 Apr 2015 07:57:42 -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, HTML_MESSAGE=0.001, 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 7hF7kxF9o3FU for ; Tue, 28 Apr 2015 07:57:38 -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 DAEA51A1B3E for ; Tue, 28 Apr 2015 07:57:37 -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 BVK96173; Tue, 28 Apr 2015 14:57:36 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Apr 2015 15:57:35 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Tue, 28 Apr 2015 07:57:23 -0700 From: Linda Dunbar To: "Xialiang (Frank)" , "i2nsf@ietf.org" Thread-Topic: Solicit comments on the new design of capability inteface information model: Thread-Index: AdCBYNxg9QwoLZgqQGeTjoRnG6f2nQAYg/7Q Date: Tue, 28 Apr 2015 14:57:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C0C609@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.75] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C0C609dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [I2nsf] Solicit comments on the new design of capability inteface information model: X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 14:57:42 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C0C609dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Frank, In a nutshell, you are proposing using draft-lopez-i2nsf-packet-00 proposal= as the base solution for I2NSF, i.e. having the following 4 categories for= provisioning to network security functions: Subject - Match values based on packet data Packet header or Packet payload Object - Match values based on context. E.g. State, time, geo-location, etc= . Action- Egress processing, such as Invoke signaling; Packet forwarding and/= or transformation; Possibility for SDN/NFV integration Functional Profile - E.g. IPS:, signature file, Anti-virus file, U= RL filtering file, etc. Integrated and one-pass checks on the content of pa= ckets. The functional profile is vendor specific and differentiates vendor unique = innovation. Does anyone have comments or other suggestions? Linda From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Xialiang (Frank) Sent: Monday, April 27, 2015 10:10 PM To: i2nsf@ietf.org Subject: [I2nsf] Solicit comments on the new design of capability inteface = information model: Hi all, We are updating the -01 version of draft-xia-i2nsf-capability-interface-im = now. We consider all the comments and discussions related in mailing list, = especially the packet-based paradigm proposed in draft-lopez-i2nsf-packet-0= 0, are all very good inputs for this interface. So, we propose a new information model of I2NSF capability(function) interf= ace, which aligns the existing design with all comments and is based on the= packet-based paradigm: +-------------+ +-> User/tenant| | | /VN-id | | +-------------+ | +---------+ | |Address/ | +->address | | |group | | +---------+ | +-----------+ | |Layer 2/3/4| +->header, or | | |payload | +------+ | +-----------+ |Packet| | +---------+ +->based |-+-> Service | | |match | | +---------+ | +------+ | +-----------+ | +->Application| | +-----------+ +----+ +-----+ | | | +->Match|-+ +----------+ +-->Rule| | +-----+ | +-> Session | | | | | | | | state | | +----+ | | +-------+ | +----------+ | | | |context| | +----------+ | * | +->based +-+-> Schedule | | * | |match | | +----------+ | * | +-------+ | +---------+ | | | |Region/ | | | +->region | +------+ +----+ | |group | | | | | | | +---------+ |Policy+--+-->Rule+--+ | | | | | | +-------+ +------+ | +----+ | +->Permit + | | | +-------+ | * | +-------+ | +-------+ | * | +->Basic +-+-> Deny | | * | | |actions| | +-------+ | | | +-------+ | +-------+ | | | +-> Mirror| | | | +-------+ | | | | | | +----------+ | | | +->Antivirus:| | +----+ | | | |profile | | | | | +-------+ | | +----------+ +-->Rule| +->Actions+-+ | +---------+ | | +-------+ | +-> IPS: | +----+ | |signature| | | +---------+ | | +----------+ | | | URL | | +->Filtering:| | |data base | | | +----------+ | +--------+ | +----------+ +->Advanced+-+ | File | |actions | +->Blocking: | +--------+ | |profile | | +----------+ | +----------+ | | Data | +->Filtering:| | |profile | | +----------+ | +-----------+ | |Application| +-> control | | +-----------+ | * +-> * * We hope to get your comments on this new IM design, to help us to go forwar= d. Thanks a lot! B.R. Frank --_000_4A95BA014132FF49AE685FAB4B9F17F657C0C609dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Frank= ,

=  

In a = nutshell, you are proposing using draft-lopez-i2nsf-packet-00 proposal a= s the base solution for I2NSF, i.e. having the following 4 categories for p= rovisioning to network security functions:

<= span style=3D"color:#1F497D">Subject - Match values based on packet data Pa= cket header or Packet payload

<= span style=3D"color:#1F497D">Object - Match values based on context. E.g. S= tate, time, geo-location, etc.

<= span style=3D"color:#1F497D">Action- Egress processing, such as Invoke sign= aling; Packet forwarding and/or transformation; Possibility for SDN/NFV int= egration

<= span style=3D"color:#1F497D">Functional Profile – E.g. IPS:<Profil= e>, signature file, Anti-virus file, URL filtering file, etc. Integrated= and one-pass checks on the content of packets.

<= span style=3D"color:#1F497D">The functional profile is vendor specific and = differentiates vendor unique innovation.

=  

Does = anyone have comments or other suggestions?

=  

Linda=

=  

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Xialiang (Frank)
Sent: Monday, April 27, 2015 10:10 PM
To: i2nsf@ietf.org
Subject: [I2nsf] Solicit comments on the new design of capability in= teface information model:

 =

Hi all,

We are updating the -01 version of draft-xia-i2nsf-c= apability-interface-im now. We consider all the comments and discussions re= lated in mailing list, especially the packet-based paradigm proposed in dra= ft-lopez-i2nsf-packet-00, are all very good inputs for this interface.

So, we propose a new information model of I2NSF capa= bility(function) interface, which aligns the existing design with all comme= nts and is based on the packet-based paradigm:

      &nb= sp;            =             &nb= sp;            = +-------------+

     &nbs= p;            &= nbsp;            &nb= sp;          +->&n= bsp; User/tenant|

     &nbs= p;            &= nbsp;           &nbs= p;           | |  /V= N-id     |

     &nbs= p;            &= nbsp;           &nbs= p;           | +-----= --------+

     &nbs= p;            &= nbsp;           &nbs= p;           | +-----= ----+

     &nbs= p;            &= nbsp;           &nbs= p;           | |Address/ = |

     &nbs= p;            &= nbsp;           &nbs= p;           +->ad= dress  |

     &nbs= p;            &= nbsp;           &nbs= p;           | |group&nbs= p;   |

     &nbs= p;            &= nbsp;           &nbs= p;           | +-----= ----+

     &nbs= p;            &= nbsp;           &nbs= p;           | +-----= ------+

     &nbs= p;            &= nbsp;            &nb= sp;          | |Layer 2/3= /4|

     &nbs= p;            &= nbsp;           &nbs= p;           +->he= ader, or |

     &nbs= p;            &= nbsp;           &nbs= p;           | |payload&n= bsp;   |

     &nbs= p;            &= nbsp;           &nbs= p;  +------+ | +-----------+

     &nbs= p;            &= nbsp;           &nbs= p;  |Packet| | +---------+

     &nbs= p;            &= nbsp;            = 3;->based |-+-> Service |

     &nbs= p;            &= nbsp;            | |= match | | +---------+

     &nbs= p;            &= nbsp;            | &= #43;------+ | +-----------+

     &nbs= p;            &= nbsp;            |&n= bsp;         +->Application|=

     &nbs= p;            &= nbsp;            |&n= bsp;           +-----= ------+

     &nbs= p;       +----+    = 3;-----+ |

     &nbs= p;       |    |  +-&g= t;Match|-+          &= nbsp;  +----------+

     &nbs= p;    +-->Rule|  | +-----+ |  =          +-> Session  |=

     &nbs= p;    |  |    |  |   = ;      |       =     | | state    |

     &nbs= p;    |  +----+  |    =      | +-------+ | +----------+

     &nbs= p;    |         = ; |         | |context| | +----= ------+

     &nbs= p;    |    *     | &= nbsp;       +->based  +-+= -> Schedule |

     &nbs= p;    |    *     | &= nbsp;         |match  | | += ;----------+

     &nbs= p;    |    *     | &= nbsp;         +-------+ | &= #43;---------+

     &nbs= p;    |         = ; |            =          | |Region/  |

     &nbs= p;    |         = ; |            =          +->region &nbs= p; |

+------+   =   +----+  |       &nbs= p;            &= nbsp;  |group    |

|      |&= nbsp; |  |    |  |     &n= bsp;            = ;     +---------+

|Policy+--+-->Rule+= --+

|      |&= nbsp; |  |    |  |     &n= bsp;            = ;       +-------+

+------+  |  = 3;----+  |         &n= bsp;            = ; +->Permit +

     &nbs= p;    |         = ; |            =            | +-------= +

     &nbs= p;    |    *     | &= nbsp;           +----= ---+ | +-------+

     &nbs= p;    |    *     | &= nbsp;         +->Basic = +-+-> Deny  |

     &nbs= p;    |    *     | &= nbsp;         | |actions| | +--= -----+

     &nbs= p;    |         = ; |           | +----= ---+ | +-------+

     &nbs= p;    |         = ; |           | &nbs= p;         +-> Mirror|<= /o:p>

     &nbs= p;    |         = ; |           | &nbs= p;           +-------= +

     &nbs= p;    |         = ; |           |

     &nbs= p;    |         = ; |           | &nbs= p;            +-= ---------+

     &nbs= p;    |         = ; |           | &nbs= p;          +->Antiviru= s:|

     &nbs= p;    |  +----+  |    =        |      &= nbsp;     | |profile   |

     &nbs= p;    |  |    |  | +-------+= ; |            | = 3;----------+

     &nbs= p;    +-->Rule|  +->Actions+-+&nb= sp;           | +----= -----+

     &nbs= p;       |    |  &nb= sp; +-------+ |        &nbs= p;   +->  IPS:   |

     &nbs= p;       +----+   &nbs= p;            &= nbsp;          | |signature|

     &nbs= p;            &= nbsp;           &nbs= p;  |           = ; | +---------+

     &nbs= p;            &= nbsp;           &nbs= p;  |           = ; | +----------+

     &nbs= p;            &= nbsp;            &nb= sp; |           = ; | | URL      |

     &nbs= p;            &= nbsp;           &nbs= p;  |           = ; +->Filtering:|

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  | |data base |

     &nbs= p;            &= nbsp;           &nbs= p;  |           = ; | +----------+

     &nbs= p;            &= nbsp;           &nbs= p;  | +--------+ | +----------+

     &nbs= p;            &= nbsp;           &nbs= p;  +->Advanced+-+ |  File    |

     &nbs= p;            &= nbsp;           &nbs= p;    |actions | +->Blocking: |

     &nbs= p;            &= nbsp;           &nbs= p;    +--------+ | |profile   |=

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  | +----------+

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  | +----------+

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  | |  Data    |

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  +->Filtering:|

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  | |profile   |

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  | +----------+

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  | +-----------+

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  | |Application|

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  +->  control  |

      &nb= sp;            =             &nb= sp;            =   | +-----------+

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |   *

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  +-> *

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      *

 

We hope to get your comments on this new IM design, = to help us to go forward.

Thanks a lot!

 

 

B.R.

Frank

--_000_4A95BA014132FF49AE685FAB4B9F17F657C0C609dfweml701chm_-- From nobody Tue Apr 28 19:25:36 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822CE1A86EC for ; Tue, 28 Apr 2015 19:25:35 -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 lVqrRg2IMhE8 for ; Tue, 28 Apr 2015 19:25:34 -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 BF51D1A86EB for ; Tue, 28 Apr 2015 19:25:33 -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 BVL33508; Wed, 29 Apr 2015 02:25:32 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Apr 2015 03:25:31 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Wed, 29 Apr 2015 10:25:24 +0800 From: "Xialiang (Frank)" To: "i2nsf@ietf.org" Thread-Topic: New Version Notification for draft-xie-i2nsf-demo-outline-design-00.txt Thread-Index: AQHQgiLP4fq8X3x1VUiCxf7/N4Pfy51jQYpQ Date: Wed, 29 Apr 2015 02:25:25 +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: [I2nsf] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-xie-i2nsf-demo-outline-design-00=2Etxt?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 02:25:35 -0000 SGkgYWxsLA0KQW4gaW5mb3JtYXRpb25hbCBkcmFmdCBmb3IgZGVzY3JpYmluZyBvdXIgSTJOU0Yg RGVtbyAod2hpY2ggaXMgc2hvd24gaW4gSUVURiA5MnRoIEImQiBhY3Rpdml0eX5+KSBkZXNpZ24g aXMganVzdCBzdWJtaXR0ZWQuDQpXZSBob3BlIHRoaXMgZHJhZnQgY2FuIGJlIHVzZWZ1bCBmb3Ig aW50ZXJlc3RpbmcgcGVvcGxlIHRvIGVuaGFuY2UgdW5kZXJzdGFuZGluZyBvZiB0aGUgSTJOU0Yg YXJjaGl0ZWN0dXJlIGFuZCBqdXN0aWZ5IGl0cyBmZWFzaWJpbGl0eS4NCg0KWW91ciBjb21tZW50 cyBhcmUgd2FybWx5IHdlbGNvbWUhDQoNCkIuUi4NCkZyYW5rDQoNCg0KLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0NOaciDI55pelIDEw OjE5DQrmlLbku7bkuro6IFhpYWxpYW5nIChGcmFuayk7IFd1anVuIChJKTsgWGlleXVtaW5nOyBX dWp1biAoSSk7IFhpZXl1bWluZzsgWGlhbGlhbmcgKEZyYW5rKQ0K5Li76aKYOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXhpZS1pMm5zZi1kZW1vLW91dGxpbmUtZGVzaWduLTAw LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14aWUtaTJuc2YtZGVtby1vdXRs aW5lLWRlc2lnbi0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGlh bmcgWGlhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0 LXhpZS1pMm5zZi1kZW1vLW91dGxpbmUtZGVzaWduDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJSW50 ZXJmYWNlIHRvIE5ldHdvcmsgU2VjdXJpdHkgRnVuY3Rpb25zIERlbW8gT3V0bGluZSBEZXNpZ24N CkRvY3VtZW50IGRhdGU6CTIwMTUtMDQtMjkNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczoJCTIwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXhpZS1pMm5zZi1kZW1vLW91dGxpbmUtZGVzaWduLTAwLnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpZS1p Mm5zZi1kZW1vLW91dGxpbmUtZGVzaWduLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC14aWUtaTJuc2YtZGVtby1vdXRsaW5lLWRlc2lnbi0wMA0KDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG91dGxpbmUgZGVzaWdu IG9mIGFuIEludGVyZmFjZSB0bw0KICAgbmV0d29yayBTZWN1cml0eSBGdW5jdGlvbnMgKEkyTlNG KSBkZW1vLCBhaW0gdG8gZW5oYW5jZQ0KICAgdW5kZXJzdGFuZGluZyBvZiB0aGUgSTJOU0YgYXJj aGl0ZWN0dXJlIGFuZCBqdXN0aWZ5IGl0cyBmZWFzaWJpbGl0eS4NCiAgIFRoZSBJMk5TRiBkZW1v IGVuYWJsZXMgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gSTJOU0YgY2xpZW50LCBJMk5TRg0KICAg Y29udHJvbGxlciBhbmQgTlNGL3ZOU0YgYnkgdXNpbmcgTkVUQ09ORiBwcm90b2NvbCBhbmQgWUFO RyBtb2RlbC4NCiAgIFRoZSBhZHZhbnRhZ2Ugb2YgaXQgaXMgdG8gZW5zdXJlIHRoYXQgc3VjaCBk ZW1vIG91dGxpbmUgZGVzaWduIHdpbGwNCiAgIGJlIGFibGUgdG8gc2hhcmUgYW5kIHJldXNlIGNv bnNlbnN1YWxseSBkZXNpZ25lZCBmdW5jdGlvbnMsIHRoZXJlYnkNCiAgIGluY3JlYXNpbmcgaW50 ZXJvcGVyYWJpbGl0eS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Thu Apr 30 00:46:50 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6BD1ACF04 for ; Thu, 30 Apr 2015 00:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hXhzV4GD7kJo for ; Thu, 30 Apr 2015 00:46:44 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296F81ACECF for ; Thu, 30 Apr 2015 00:46:27 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D1D672D0296; Thu, 30 Apr 2015 09:46:24 +0200 (CEST) Received: from ESTGVMSP112.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id B4D222D016C; Thu, 30 Apr 2015 09:46:24 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.54) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 30 Apr 2015 09:46:24 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) with Microsoft SMTP Server (TLS) id 15.1.148.16; Thu, 30 Apr 2015 07:46:22 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0148.008; Thu, 30 Apr 2015 07:46:22 +0000 From: DIEGO LOPEZ GARCIA To: Linda Dunbar Thread-Topic: [I2nsf] Solicit comments on the new design of capability inteface information model: Thread-Index: AdCBYNxg9QwoLZgqQGeTjoRnG6f2nQAYg/7QAFW04IA= Date: Thu, 30 Apr 2015 07:46:22 +0000 Message-ID: <89980F12-0CC2-445D-9CC8-155CFE31148B@telefonica.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C0C609@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C0C609@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.51.58.87] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0624; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0624; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0624; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(479174004)(252514010)(377454003)(24454002)(19580395003)(19580405001)(76176999)(16236675004)(66066001)(46102003)(83716003)(19617315012)(92566002)(5001960100002)(110136002)(54356999)(50986999)(86362001)(87936001)(33656002)(40100003)(561944003)(15975445007)(102836002)(2656002)(2950100001)(122556002)(82746002)(77156002)(62966003)(2900100001)(36756003)(104396002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0624; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_89980F120CC2445D9CC8155CFE31148Btelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2015 07:46:22.1282 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0624 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , "Xialiang \(Frank\)" Subject: Re: [I2nsf] Solicit comments on the new design of capability inteface information model: X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 07:46:49 -0000 --_000_89980F120CC2445D9CC8155CFE31148Btelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, As a result of the SECURED project we have a policy model that operates at = two layers, which is reasonably mature, including language specification an= d implementation. The highest, functional one, is based on a (Subject, Obje= ct, Action, Condition) tuple and I think close to draft-lopez-i2nsf-packet.= The lowest, service layer, is based on the concept of describing the "capa= bilities", within a capability hierarchy, of each function, and a meta-mode= l for associating configuration actions with those capabilities. We are working on transferring this to a (couple of) draft(s) that we will = contribute soon. Be goode, On 28 Apr 2015, at 16:57 , Linda Dunbar > wrote: Frank, In a nutshell, you are proposing using draft-lopez-i2nsf-packet-00 proposal= as the base solution for I2NSF, i.e. having the following 4 categories for= provisioning to network security functions: Subject - Match values based on packet data Packet header or Packet payload Object - Match values based on context. E.g. State, time, geo-location, etc= . Action- Egress processing, such as Invoke signaling; Packet forwarding and/= or transformation; Possibility for SDN/NFV integration Functional Profile =96 E.g. IPS:, signature file, Anti-virus file,= URL filtering file, etc. Integrated and one-pass checks on the content of = packets. The functional profile is vendor specific and differentiates vendor unique = innovation. Does anyone have comments or other suggestions? Linda From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Xialiang (Frank) Sent: Monday, April 27, 2015 10:10 PM To: i2nsf@ietf.org Subject: [I2nsf] Solicit comments on the new design of capability inteface = information model: Hi all, We are updating the -01 version of draft-xia-i2nsf-capability-interface-im = now. We consider all the comments and discussions related in mailing list, = especially the packet-based paradigm proposed in draft-lopez-i2nsf-packet-0= 0, are all very good inputs for this interface. So, we propose a new information model of I2NSF capability(function) interf= ace, which aligns the existing design with all comments and is based on the= packet-based paradigm: +-------------+ +-> User/tenant| | | /VN-id | | +-------------+ | +---------+ | |Address/ | +->address | | |group | | +---------+ | +-----------+ | |Layer 2/3/4| +->header, or | | |payload | +------+ | +-----------+ |Packet| | +---------+ +->based |-+-> Service | | |match | | +---------+ | +------+ | +-----------+ | +->Application| | +-----------+ +----+ +-----+ | | | +->Match|-+ +----------+ +-->Rule| | +-----+ | +-> Session | | | | | | | | state | | +----+ | | +-------+ | +----------+ | | | |context| | +----------+ | * | +->based +-+-> Schedule | | * | |match | | +----------+ | * | +-------+ | +---------+ | | | |Region/ | | | +->region | +------+ +----+ | |group | | | | | | | +---------+ |Policy+--+-->Rule+--+ | | | | | | +-------+ +------+ | +----+ | +->Permit + | | | +-------+ | * | +-------+ | +-------+ | * | +->Basic +-+-> Deny | | * | | |actions| | +-------+ | | | +-------+ | +-------+ | | | +-> Mirror| | | | +-------+ | | | | | | +----------+ | | | +->Antivirus:| | +----+ | | | |profile | | | | | +-------+ | | +----------+ +-->Rule| +->Actions+-+ | +---------+ | | +-------+ | +-> IPS: | +----+ | |signature| | | +---------+ | | +----------+ | | | URL | | +->Filtering:| | |data base | | | +----------+ | +--------+ | +----------+ +->Advanced+-+ | File | |actions | +->Blocking: | +--------+ | |profile | | +----------+ | +----------+ | | Data | +->Filtering:| | |profile | | +----------+ | +-----------+ | |Application| +-> control | | +-----------+ | * +-> * * We hope to get your comments on this new IM design, to help us to go forwar= d. Thanks a lot! B.R. Frank _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_89980F120CC2445D9CC8155CFE31148Btelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7DB79293264FD845805E3AE6A517FFC6@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi,

As a result of the SECURED project we have a policy model that operate= s at two layers, which is reasonably mature, including language specificati= on and implementation. The highest, functional one, is based on a (Subject,= Object, Action, Condition) tuple and I think close to draft-lopez= -i2nsf-packet. The lowest, service layer, is based on the concept of descri= bing the "capabilities", within a capability hierarchy, of each f= unction, and a meta-model for associating configuration actions with those capabilities. 

We are working on transferring th= is to a (couple of) draft(s) that we will contribute soon.

Be goode,


On 28 Apr 2015, at 16:57 , Linda Dunbar <linda.dunbar@huawei.com> wrote:

Frank,=
 
In a nutshell, yo= u are proposing using draft-lopez-i2nsf-packet-00 pr= oposal as the base solution for I2NSF, i.e. having the following 4 categories for provisioning to network security fun= ctions:
Subject - Match values based on pa= cket data Packet header or Packet payload
Object - Match values based on con= text. E.g. State, time, geo-location, etc.
Action- Egress processing, such as= Invoke signaling; Packet forwarding and/or transformation; Possibility for= SDN/NFV integration
Functional Profile =96 E.g. IPS:&l= t;Profile>, signature file, Anti-virus file, URL filtering file, etc. In= tegrated and one-pass checks on the content of packets.
The functional profile is vendor s= pecific and differentiates vendor unique innovation.
 
Does anyone have = comments or other suggestions?
 
Linda<= /span>
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Xialiang (= Frank)
Sent: Monday, Apri= l 27, 2015 10:10 PM
To: i2= nsf@ietf.org
Subject: [I2nsf] S= olicit comments on the new design of capability inteface information model:=
 
Hi all,
We are updating the -01 version of draft-xia-i2nsf-capability-interface-im = now. We consider all the comments and discussions related in mailing list, = especially the packet-based paradigm proposed in draft-lopez-i2nsf-packet-0= 0, are all very good inputs for this interface.
So, we propose a new information model of I2NSF capability(function) interf= ace, which aligns the existing design with all comments and is based on the= packet-based paradigm:
    &n= bsp;            = ;            &n= bsp;            = ;  +-------------+
   &nb= sp;            =             &nb= sp;             = ;+->  User/tenant|
   &nb= sp;            =             &nb= sp;            = | |  /VN-id     |
   &nb= sp;            =             &nb= sp;            = | +-------------+
   &nb= sp;            =             &nb= sp;            = | +---------+
   &nb= sp;            =             &nb= sp;            = | |Address/ |
   &nb= sp;            =             &nb= sp;            = +->address  |
   &nb= sp;            =             &nb= sp;            = | |group    |
   &nb= sp;            =             &nb= sp;            = | +---------+
   &nb= sp;            =             &nb= sp;            = | +-----------+
   &nb= sp;            =              &n= bsp;            = ;| |Layer 2/3/4|
   &nb= sp;            =             &nb= sp;            = +->header, or |
   &nb= sp;            =             &nb= sp;            = | |payload    |
   &nb= sp;            =             &nb= sp;    +------+ | +-----------+
   &nb= sp;            =             &nb= sp;    |Packet| | +---------+
   &nb= sp;            =             &nb= sp;  +->based |-+-> Service |
   &nb= sp;            =             &nb= sp;  | |match | | +---------+
   &nb= sp;            =             &nb= sp;  | +------+ | +-----------+
   &nb= sp;            =             &nb= sp;  |          +->= ;Application|
   &nb= sp;            =              &n= bsp; |          &nbs= p; +-----------+
   &nb= sp;         +----+ &nb= sp;  +-----+ |
   &nb= sp;         |    |&n= bsp; +->Match|-+        =      +----------+
   &nb= sp;      +-->Rule|  | +-----+ = |           +-> Se= ssion  |
   &nb= sp;      |  |    |  |&nbs= p;        |     = ;      | | state    |
   &nb= sp;      |  +----+  |  = ;       | +-------+ | +----------= +
   &nb= sp;      |      &nbs= p;   |         | |context= | | +----------+
   &nb= sp;      |    *   &n= bsp; |         +->based = ; +-+-> Schedule |
   &nb= sp;      |    *   &n= bsp; |           |match&n= bsp; | | +----------+
   &nb= sp;      |    *   &n= bsp; |           +---= ----+ | +---------+
   &nb= sp;      |      &nbs= p;   |          = ;           | |Region/&nb= sp; |
   &nb= sp;      |      &nbs= p;   |          = ;           +->reg= ion   |
+------+ = ;    +----+  |     &nb= sp;            =      |group    |
|   &n= bsp;  |  |  |    |  |   &= nbsp;           &nbs= p;       +---------+
|Policy+--+--= >Rule+--+
|   &n= bsp;  |  |  |    |  |   &= nbsp;           &nbs= p;         +-------+
+------+ = ; |  +----+  |       &= nbsp;           &nbs= p;   +->Permit +
   &nb= sp;      |      &nbs= p;   |          = ;             |= +-------+
   &nb= sp;      |    *   &n= bsp; |           &nb= sp; +-------+ | +-------+
   &nb= sp;      |    *   &n= bsp; |           +-&g= t;Basic  +-+-> Deny  |
   &nb= sp;      |    *   &n= bsp; |           | |actio= ns| | +-------+
   &nb= sp;      |      &nbs= p;   |          = ; | +-------+ | +-------+
   &nb= sp;      |      &nbs= p;   |          = ; |           +-> = Mirror|
   &nb= sp;      |      &nbs= p;   |          = ; |             = ;+-------+
   &nb= sp;      |      &nbs= p;   |          = ; |
   &nb= sp;      |      &nbs= p;   |          = ; |            =   +----------+
   &nb= sp;      |      &nbs= p;   |          = ; |            += ->Antivirus:|
   &nb= sp;      |  +----+  |  = ;         |    =         | |profile   |
   &nb= sp;      |  |    |  | = 3;-------+ |          = ;  | +----------+
   &nb= sp;      +-->Rule|  +->Actions&= #43;-+           = ; | +---------+
   &nb= sp;         |    |&n= bsp;   +-------+ |      &nb= sp;     +->  IPS:   |<= /span>
   &nb= sp;         +----+ &nb= sp;            =              | = |signature|
   &nb= sp;            =             &nb= sp;    |        &nbs= p;   | +---------+
   &nb= sp;            =             &nb= sp;    |        &nbs= p;   | +----------+
   &nb= sp;            =              &n= bsp;   |        &nbs= p;   | | URL      |
   &nb= sp;            =             &nb= sp;    |        &nbs= p;   +->Filtering:|
   &nb= sp;            =             &nb= sp;            =      | |data base |
   &nb= sp;            =             &nb= sp;    |        &nbs= p;   | +----------+
   &nb= sp;            =             &nb= sp;    | +--------+ | +----------+
   &nb= sp;            =             &nb= sp;    +->Advanced+-+ |  File  = ;  |
   &nb= sp;            =             &nb= sp;      |actions | +->Blocking: |
   &nb= sp;            =             &nb= sp;      +--------+ | |profile  = |
   &nb= sp;            =             &nb= sp;            =      | +----------+
   &nb= sp;            =             &nb= sp;            =      | +----------+
   &nb= sp;            =             &nb= sp;            =      | |  Data    |
   &nb= sp;            =             &nb= sp;            =      +->Filtering:|
   &nb= sp;            =             &nb= sp;            =      | |profile   |
   &nb= sp;            =             &nb= sp;            =      | +----------+
   &nb= sp;            =             &nb= sp;            =      | +-----------+
   &nb= sp;            =             &nb= sp;            =      | |Application|
   &nb= sp;            =             &nb= sp;            =      +->  control  |=
   &nb= sp;             = ;            &n= bsp;            = ;    | +-----------+
   &nb= sp;            =             &nb= sp;            =      |   *
   &nb= sp;            =             &nb= sp;            =      +-> *
   &nb= sp;            =             &nb= sp;            =          *
 
We hope to get your comments on this new IM design, to help us to go forwar= d.
Thanks a lot!
 
 
B.R.
Frank
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2n= sf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lo= pez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_89980F120CC2445D9CC8155CFE31148Btelefonicacom_--