From nobody Sun Jul 3 01:08:50 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F7312B03F for ; Sun, 3 Jul 2016 01:08:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Tm2rrDCNEDup for ; Sun, 3 Jul 2016 01:08:46 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2AE12B014 for ; Sun, 3 Jul 2016 01:08:46 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6386Qnq009038; Sun, 3 Jul 2016 01:08:45 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 23xayk2vvs-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 03 Jul 2016 01:08:44 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 3 Jul 2016 11:08:40 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Sun, 3 Jul 2016 11:08:40 +0300 From: Tal Mizrahi To: "petr@fb.com" , "Remy Chang (remy@barefootnetworks.com)" , "opsawg@ietf.org" Thread-Topic: Comments about draft-lapukhov-dataplane-probe Thread-Index: AdHU+5Gqqjch9CDPRWCXyoALja+lSQ== Date: Sun, 3 Jul 2016 08:08:39 +0000 Message-ID: <9311a961f8ae4b7c86631325fc4b8fa9@IL-EXCH02.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: multipart/alternative; boundary="_000_9311a961f8ae4b7c86631325fc4b8fa9ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-03_06:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607030090 Archived-At: Subject: [OPSAWG] Comments about draft-lapukhov-dataplane-probe X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 08:08:49 -0000 --_000_9311a961f8ae4b7c86631325fc4b8fa9ILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, I have read draft-lapukhov-dataplane-probe-1, and I have some comments. https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01 I believe that in-band telemetry is certainly a very interesting method, an= d the community can value from working on this draft. Major comments: * The draft seems to be related to the P4 In-band Network Telemetry= spec (http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf). Ho= wever, the two documents define different packet formats and different meta= data fields. Do you plan to align the two documents? * The draft should probably include a background section that descr= ibes the environment. It should explain which entity adds the INT header, a= nd which entity is supposed to receive the probe information and analyze it= . It should also explain whether INT is applied to all data traffic, to a s= ubset of the data traffic, or to probe traffic (or all of the above). * Since the telemetry header is modified at every hop, there should= be some discussion about how this affects the L4 checksum of the overlay h= eader when using protocols such as VXLAN, Geneve, or GUE. * The draft should include a "Security Considerations" section. It = should discuss potential threats and vulnerabilities imposed by adding INT = to the network. Other comments: * The abstract and introduction may need some rephrasing. For examp= le, there should probably be more text about OAM protocols. Ping and Tracer= oute (which are currently mentioned in the draft) are tools that are used m= anually by network operators, but there is a vast number of OAM protocols t= hat are used for automated proactive telemetry (fault detection, loss and d= elay measurement). * The INT spec is currently missing from the reference list: http:/= /p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf * Section 2.1 says "This document does not prescribe any specific e= ncapsulation for the data-plane probe." On the other hand, Figure 2 defines the fields, which appear= to be encapsulation-specific. Moreover, the length of these fields is enca= psulation-specific, right? Please consider removing the Probe Marker fields= from this draft. * Section 3.2: "residence time is in 48-bits of nanoseconds" - plea= se note that the IEEE 1588 standard uses a 64-bit format to represent the c= orrectionField (residence time). It is recommended to use the same format h= ere. * Section 3.3: the difference between the queueing delay and the re= sidence time is (roughly) constant for a given switch. It would be worthwhi= le to explain why both are needed. * Section 3.5: the word 'analyzer' is mentioned here for the first = time without being defined beforehand. * s/needs to made/needs to be made/ * Section 4: o "Swap the destination/source IP addresses in the transport header to se= nd the packet back to the originator." - again, there is a slight conflict = with section 2.1, which argues for encapsulation-independence. Moreover, sw= apping the IP addresses is typically not enough (L2 addresses, L4 ports...)= . o On the returning path - are devices expected to update the = field? o Since is equal to zero, doesn't the analyzer loose the info= rmation about the number of hops until the loopback device? * Section 5.1: "Probe Id" is mentioned for the first time here with= out prior explanation, so the paragraph is not clear. * Section 6: router alert - again, a conflict with encapsulation in= dependence... Regards, Tal Mizrahi. --_000_9311a961f8ae4b7c86631325fc4b8fa9ILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors,

 

 

I have read draft-lapukhov-dataplane-probe-1, and I = have some comments.

https://tools.ietf.org/html/draft-lapukhov-dataplane-= probe-01

 

I believe that in-band telemetry is certainly a very= interesting method, and the community can value from working on this draft= .

 

 

Major comments:

·         The draft seems to = be related to the P4 In-band Network Telemetry spec (http://p4.org/wp-cont= ent/uploads/fixed/INT/INT-current-spec.pdf). However, the two documents define different packet formats and different m= etadata fields. Do you plan to align the two documents?

·         The draft should pr= obably include a background section that describes the environment. It shou= ld explain which entity adds the INT header, and which entity is supposed t= o receive the probe information and analyze it. It should also explain whether INT is applied to all data traf= fic, to a subset of the data traffic, or to probe traffic (or all of the ab= ove).

·         Since the telemetry= header is modified at every hop, there should be some discussion about how= this affects the L4 checksum of the overlay header when using protocols su= ch as VXLAN, Geneve, or GUE.

·         The draft should in= clude a “Security Considerations” section. It should discuss po= tential threats and vulnerabilities imposed by adding INT to the network.

 

 

Other comments:

·         The abstract and in= troduction may need some rephrasing. For example, there should probably be = more text about OAM protocols. Ping and Traceroute (which are currently men= tioned in the draft) are tools that are used manually by network operators, but there is a vast number of OAM = protocols that are used for automated proactive telemetry (fault detection,= loss and delay measurement).

·         The INT spec is cur= rently missing from the reference list: http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf

·         Section 2.1 says &#= 8220;This document does not prescribe any specific encapsulation for the da= ta-plane probe.”
On the other hand, Figure 2 defines the <Probe Marker> fields, which = appear to be encapsulation-specific. Moreover, the length of these fields i= s encapsulation-specific, right? Please consider removing the Probe Marker = fields from this draft.

·         Section 3.2: “= ;residence time is in 48-bits of nanoseconds” – please note tha= t the IEEE 1588 standard uses a 64-bit format to represent the correctionFi= eld (residence time). It is recommended to use the same format here.

·         Section 3.3: the di= fference between the queueing delay and the residence time is (roughly) con= stant for a given switch. It would be worthwhile to explain why both are ne= eded.

·         Section 3.5: the wo= rd ‘analyzer’ is mentioned here for the first time without bein= g defined beforehand.

·         s/needs to made/nee= ds to be made/

·         Section 4:

o   “Swap the des= tination/source IP addresses in the transport header to send the packet bac= k to the originator.” – again, there is a slight conflict with = section 2.1, which argues for encapsulation-independence. Moreover, swapping the IP addresses is typically not enough (L2 addresses,= L4 ports…).

o   On the returning pa= th – are devices expected to update the <Hop Count> field?=

o   Since <Hop Count= > is equal to zero, doesn’t the analyzer loose the information abo= ut the number of hops until the loopback device?

·         Section 5.1: “= ;Probe Id” is mentioned for the first time here without prior explana= tion, so the paragraph is not clear.

·         Section 6: router a= lert – again, a conflict with encapsulation independence…<= /o:p>

 

 

Regards,

Tal Mizrahi.

--_000_9311a961f8ae4b7c86631325fc4b8fa9ILEXCH02marvellcom_-- From nobody Sun Jul 3 08:51:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A66512D119 for ; Sun, 3 Jul 2016 08:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=PLZ9vt2z; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=P95E1msG 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 KYGMheqx6I87 for ; Sun, 3 Jul 2016 08:51:36 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEF612D13F for ; Sun, 3 Jul 2016 08:51:36 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u63FmoxZ015035; Sun, 3 Jul 2016 08:51:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=aOJ914Eq3AVsi0V40yp4RsojF00gMqeBWlG2mB38aXE=; b=PLZ9vt2zycG5E2CDvCr+hNkWqRPt4d2wKpGPPcPdJ/gbIOvZzt+XqVP6ZfuL+c3YrdqO 74Dmiuah2GPXhvGXjj1Ei8FrUjgfSnrhk862O0LVX2wEFU3FwQpSiLoxDTU6XwfUbAUM hvraBCCjttlTc5wU3xH2jGPJhl810eLbdiQ= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 23x9e93tmt-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 03 Jul 2016 08:51:33 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.24) with Microsoft SMTP Server (TLS) id 14.3.294.0; Sun, 3 Jul 2016 08:51:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Tpredarm8UA/z4d4rQXwS4t+cxf06qN5uVogarGAdik=; b=P95E1msGLY0+OFg/5t1BA8OPdsv7MvMDtja82AGMg94+N05OrDJ/DtL5NkN9XPaA5HRQRVWuh2f0eCvcWfaCanU8MCbqHZvFFnlwi0Qawp66bdzBcLyAQ7NZPNpQ2rhw8fbSzInWecav8RSVkpR1s4BL/BKNzZzr2qyuO4d3ulM= Received: from CY1PR15MB0524.namprd15.prod.outlook.com (10.163.235.157) by CY1PR15MB0522.namprd15.prod.outlook.com (10.163.235.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Sun, 3 Jul 2016 15:51:16 +0000 Received: from CY1PR15MB0524.namprd15.prod.outlook.com ([10.163.235.157]) by CY1PR15MB0524.namprd15.prod.outlook.com ([10.163.235.157]) with mapi id 15.01.0528.022; Sun, 3 Jul 2016 15:51:16 +0000 From: Petr Lapukhov To: Tal Mizrahi , "Remy Chang (remy@barefootnetworks.com)" , "opsawg@ietf.org" Thread-Topic: Comments about draft-lapukhov-dataplane-probe Thread-Index: AdHU+5Gqqjch9CDPRWCXyoALja+lSQARcGK2 Date: Sun, 3 Jul 2016 15:51:15 +0000 Message-ID: References: <9311a961f8ae4b7c86631325fc4b8fa9@IL-EXCH02.marvell.com> In-Reply-To: <9311a961f8ae4b7c86631325fc4b8fa9@IL-EXCH02.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.245.53.181] x-ms-office365-filtering-correlation-id: a7a8936c-a15b-4512-d5e1-08d3a359de22 x-microsoft-exchange-diagnostics: 1; CY1PR15MB0522; 20:c2Cd3FRFqIwkWtizFTK5gpzhVcYRAkyfz0Zi5ilNH2OgJnHcB+8RCwExUnj1/iTZT2+7NfPotVaoVehbZqliiRtYPcLKoP6FAkEgwgPJHe7OpK2QP+/FA0eYGDnujqEhNQ3pxmhMiSS0waX2LvxyAXtoewd5kbBSnolrzLsvx4w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR15MB0522; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR15MB0522; BCL:0; PCL:0; RULEID:; SRVR:CY1PR15MB0522; x-forefront-prvs: 09928BEC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(51914003)(189002)(377454003)(790700001)(8676002)(5001770100001)(189998001)(102836003)(8936002)(6116002)(3846002)(19580405001)(7846002)(106356001)(15975445007)(87936001)(7906003)(7736002)(97736004)(33656002)(2501003)(7696003)(19580395003)(122556002)(5003600100003)(3660700001)(16297215004)(81156014)(68736007)(81166006)(105586002)(92566002)(50986999)(54356999)(76176999)(586003)(107886002)(11100500001)(230783001)(10400500002)(19617315012)(77096005)(76576001)(86362001)(9686002)(2950100001)(19625215002)(3280700002)(19627405001)(99286002)(74316002)(2906002)(2900100001)(16236675004)(15395725005)(101416001)(66066001)(5002640100001)(15398625002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR15MB0522; H:CY1PR15MB0524.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0524C411FEB01553AF40D5F1A2270CY1PR15MB0524namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2016 15:51:15.8108 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR15MB0522 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-03_11:, , signatures=0 Archived-At: Subject: Re: [OPSAWG] Comments about draft-lapukhov-dataplane-probe X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 15:51:40 -0000 --_000_CY1PR15MB0524C411FEB01553AF40D5F1A2270CY1PR15MB0524namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tal, thanks for the feedback! I will likely to take a stab at this next wee= k, though I think we are in lock-down before IETF already. Not a big worry = though, I'm not making it to Berlin, but was planning on South Korea. I'm looking to simplify it even further. Remy might comment on merging with= INT - I think the latter was coming from collaboration from VMware. Petr ________________________________ From: Tal Mizrahi Sent: Sunday, July 3, 2016 1:08:39 AM To: Petr Lapukhov; Remy Chang (remy@barefootnetworks.com); opsawg@ietf.org Subject: Comments about draft-lapukhov-dataplane-probe Dear Authors, I have read draft-lapukhov-dataplane-probe-1, and I have some comments. https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01 I believe that in-band telemetry is certainly a very interesting method, an= d the community can value from working on this draft. Major comments: * The draft seems to be related to the P4 In-band Network Telemetry= spec (http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf). However, the two d= ocuments define different packet formats and different metadata fields. Do = you plan to align the two documents? * The draft should probably include a background section that descr= ibes the environment. It should explain which entity adds the INT header, a= nd which entity is supposed to receive the probe information and analyze it= . It should also explain whether INT is applied to all data traffic, to a s= ubset of the data traffic, or to probe traffic (or all of the above). * Since the telemetry header is modified at every hop, there should= be some discussion about how this affects the L4 checksum of the overlay h= eader when using protocols such as VXLAN, Geneve, or GUE. * The draft should include a "Security Considerations" section. It = should discuss potential threats and vulnerabilities imposed by adding INT = to the network. Other comments: * The abstract and introduction may need some rephrasing. For examp= le, there should probably be more text about OAM protocols. Ping and Tracer= oute (which are currently mentioned in the draft) are tools that are used m= anually by network operators, but there is a vast number of OAM protocols t= hat are used for automated proactive telemetry (fault detection, loss and d= elay measurement). * The INT spec is currently missing from the reference list: http:/= /p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf * Section 2.1 says "This document does not prescribe any specific e= ncapsulation for the data-plane probe." On the other hand, Figure 2 defines the fields, which appear= to be encapsulation-specific. Moreover, the length of these fields is enca= psulation-specific, right? Please consider removing the Probe Marker fields= from this draft. * Section 3.2: "residence time is in 48-bits of nanoseconds" - plea= se note that the IEEE 1588 standard uses a 64-bit format to represent the c= orrectionField (residence time). It is recommended to use the same format h= ere. * Section 3.3: the difference between the queueing delay and the re= sidence time is (roughly) constant for a given switch. It would be worthwhi= le to explain why both are needed. * Section 3.5: the word 'analyzer' is mentioned here for the first = time without being defined beforehand. * s/needs to made/needs to be made/ * Section 4: o "Swap the destination/source IP addresses in the transport header to se= nd the packet back to the originator." - again, there is a slight conflict = with section 2.1, which argues for encapsulation-independence. Moreover, sw= apping the IP addresses is typically not enough (L2 addresses, L4 ports...)= . o On the returning path - are devices expected to update the = field? o Since is equal to zero, doesn't the analyzer loose the info= rmation about the number of hops until the loopback device? * Section 5.1: "Probe Id" is mentioned for the first time here with= out prior explanation, so the paragraph is not clear. * Section 6: router alert - again, a conflict with encapsulation in= dependence... Regards, Tal Mizrahi. --_000_CY1PR15MB0524C411FEB01553AF40D5F1A2270CY1PR15MB0524namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tal, thanks for the feedback! I will likely to take a stab at this next = week, though I think we are in lock-down before IETF already. Not a big wor= ry though, I'm not making it to Berlin, but was planning on South Korea.


I'm looking to simplify it even further. Remy might comment on merging w= ith INT - I think the latter was coming from collaboration from VMware.


Petr

From: Tal Mizrahi <talmi= @marvell.com>
Sent: Sunday, July 3, 2016 1:08:39 AM
To: Petr Lapukhov; Remy Chang (remy@barefootnetworks.com); opsawg@ie= tf.org
Subject: Comments about draft-lapukhov-dataplane-probe
 

Dear Authors,

 

 

I have read draft-lapukhov-dataplane-probe-1, and I = have some comments.

https://tools.ietf.org/html/draft= -lapukhov-dataplane-probe-01

 

I believe that in-band telemetry is certainly a very= interesting method, and the community can value from working on this draft= .

 

 

Major comments:

·         The draft seems to = be related to the P4 In-band Network Telemetry spec (htt= p://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf). However, the two documents define different packet formats and different m= etadata fields. Do you plan to align the two documents?

·         The draft should pr= obably include a background section that describes the environment. It shou= ld explain which entity adds the INT header, and which entity is supposed t= o receive the probe information and analyze it. It should also explain whether INT is applied to all data traf= fic, to a subset of the data traffic, or to probe traffic (or all of the ab= ove).

·         Since the telemetry= header is modified at every hop, there should be some discussion about how= this affects the L4 checksum of the overlay header when using protocols su= ch as VXLAN, Geneve, or GUE.

·         The draft should in= clude a “Security Considerations” section. It should discuss po= tential threats and vulnerabilities imposed by adding INT to the network.

 

 

Other comments:

·         The abstract and in= troduction may need some rephrasing. For example, there should probably be = more text about OAM protocols. Ping and Traceroute (which are currently men= tioned in the draft) are tools that are used manually by network operators, but there is a vast number of OAM = protocols that are used for automated proactive telemetry (fault detection,= loss and delay measurement).

·         The INT spec is cur= rently missing from the reference list: http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf

·         Section 2.1 says &#= 8220;This document does not prescribe any specific encapsulation for the da= ta-plane probe.”
On the other hand, Figure 2 defines the <Probe Marker> fields, which = appear to be encapsulation-specific. Moreover, the length of these fields i= s encapsulation-specific, right? Please consider removing the Probe Marker = fields from this draft.

·         Section 3.2: “= ;residence time is in 48-bits of nanoseconds” – please note tha= t the IEEE 1588 standard uses a 64-bit format to represent the correctionFi= eld (residence time). It is recommended to use the same format here.

·         Section 3.3: the di= fference between the queueing delay and the residence time is (roughly) con= stant for a given switch. It would be worthwhile to explain why both are ne= eded.

·         Section 3.5: the wo= rd ‘analyzer’ is mentioned here for the first time without bein= g defined beforehand.

·         s/needs to made/nee= ds to be made/

·         Section 4:

o   “Swap the des= tination/source IP addresses in the transport header to send the packet bac= k to the originator.” – again, there is a slight conflict with = section 2.1, which argues for encapsulation-independence. Moreover, swapping the IP addresses is typically not enough (L2 addresses,= L4 ports…).

o   On the returning pa= th – are devices expected to update the <Hop Count> field?=

o   Since <Hop Count= > is equal to zero, doesn’t the analyzer loose the information abo= ut the number of hops until the loopback device?

·         Section 5.1: “= ;Probe Id” is mentioned for the first time here without prior explana= tion, so the paragraph is not clear.

·         Section 6: router a= lert – again, a conflict with encapsulation independence…<= /o:p>

 

 

Regards,

Tal Mizrahi.

--_000_CY1PR15MB0524C411FEB01553AF40D5F1A2270CY1PR15MB0524namp_-- From nobody Sun Jul 3 15:20:13 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2E512D0BD for ; Sun, 3 Jul 2016 15:20:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 BCMj4NO9p7VQ for ; Sun, 3 Jul 2016 15:20:09 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 EC0E812B00C for ; Sun, 3 Jul 2016 15:20:08 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id q132so106866493lfe.3 for ; Sun, 03 Jul 2016 15:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=G/WNb97xVfOOI3GRqoTbgYvsodz6x7oO2QeqoQ1GamQ=; b=W1Gs4gEi87bit5HZl1pf04w52ieBYVE9Mm90L/T0BPpamVffMEZSLbUgObBf5scP6D fBLZzaanJhWtUpuHKIzLpqiUHBFmBvREXLfNzN5/EuuEA5W5cPRedlS4f7kuvmtmUh6T sqxc3ZW66p0fgldJ0TpxbTPoHxnaxHqEViEteCW4iJ/pJ1RRk2HysQgXZNbz1lvS7UDQ K1BL3xH34x6dFK1TIQ7/sutSZDArEf3SxkgVD7dTh2jiRTfdS9PFY/ZiBxNsHnd+0BfH lGxE071s+xTbZj7JsBdTQThtEhKRsayoZ7txnosloWbPbYzO7g2bSGc3Hz8JCgs1zzE1 FSaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=G/WNb97xVfOOI3GRqoTbgYvsodz6x7oO2QeqoQ1GamQ=; b=Ixbec5LHeWl05TqsaCHzzyyDN/A4YU0CkpQ07VB0KyXjYuefCk7deZUxS5/93hsB9D 6zCSBErZc6pEKQ2OxpHc+2lw8rBGD9azvmrq4zqnrVk1IzMF0gAheT3VUH6mIBtq4vpi ehiqptZzd1kVWY7FS+OF9zbv5vo0x9/qzubM+f0ElgQk9GrntqCPwhqKky6I7RcvS5NG 5yxbj719TcdgmqTtkLFgGHiF6E0vzfzqgcrAvkh1ev1cGrLUdYqTOnu5i1DhGwPXM0Qt 591NfKz/6zt4L/ZuSowOOwjBGb7vWpu3OPuOX+HQ55XycMFMx8nCpsCjKErFStSsDrRV 2j3g== X-Gm-Message-State: ALyK8tJ0pzujjoeUSHkKhnbPBvLufpJ5sunEoFfWvq5ZNi5mbIfxxaL9aRTDvuXWUfmO57lOqiCUCLZwcmnQQlNS X-Received: by 10.25.144.148 with SMTP id s142mr2407059lfd.191.1467584407113; Sun, 03 Jul 2016 15:20:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.187.234 with HTTP; Sun, 3 Jul 2016 15:19:37 -0700 (PDT) In-Reply-To: References: <9311a961f8ae4b7c86631325fc4b8fa9@IL-EXCH02.marvell.com> From: Warren Kumari Date: Sun, 3 Jul 2016 18:19:37 -0400 Message-ID: To: Petr Lapukhov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "opsawg@ietf.org" , "Remy Chang \(remy@barefootnetworks.com\)" Subject: Re: [OPSAWG] Comments about draft-lapukhov-dataplane-probe X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 22:20:12 -0000 On Sun, Jul 3, 2016 at 11:51 AM, Petr Lapukhov wrote: > Tal, thanks for the feedback! I will likely to take a stab at this next > week, though I think we are in lock-down before IETF already. Nope, you still have a few days: 2016-07-08 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. (This is more for anyone procrastinating -- you still have time to update yer documents...) W > Not a big > worry though, I'm not making it to Berlin, but was planning on South Kore= a. > > > I'm looking to simplify it even further. Remy might comment on merging wi= th > INT - I think the latter was coming from collaboration from VMware. > > > Petr > > ________________________________ > From: Tal Mizrahi > Sent: Sunday, July 3, 2016 1:08:39 AM > To: Petr Lapukhov; Remy Chang (remy@barefootnetworks.com); opsawg@ietf.or= g > Subject: Comments about draft-lapukhov-dataplane-probe > > > Dear Authors, > > > > > > I have read draft-lapukhov-dataplane-probe-1, and I have some comments. > > https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01 > > > > I believe that in-band telemetry is certainly a very interesting method, = and > the community can value from working on this draft. > > > > > > Major comments: > > =C2=B7 The draft seems to be related to the P4 In-band Network Te= lemetry > spec (http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf). > However, the two documents define different packet formats and different > metadata fields. Do you plan to align the two documents? > > =C2=B7 The draft should probably include a background section tha= t > describes the environment. It should explain which entity adds the INT > header, and which entity is supposed to receive the probe information and > analyze it. It should also explain whether INT is applied to all data > traffic, to a subset of the data traffic, or to probe traffic (or all of = the > above). > > =C2=B7 Since the telemetry header is modified at every hop, there= should > be some discussion about how this affects the L4 checksum of the overlay > header when using protocols such as VXLAN, Geneve, or GUE. > > =C2=B7 The draft should include a =E2=80=9CSecurity Consideration= s=E2=80=9D section. It > should discuss potential threats and vulnerabilities imposed by adding IN= T > to the network. > > > > > > Other comments: > > =C2=B7 The abstract and introduction may need some rephrasing. Fo= r > example, there should probably be more text about OAM protocols. Ping and > Traceroute (which are currently mentioned in the draft) are tools that ar= e > used manually by network operators, but there is a vast number of OAM > protocols that are used for automated proactive telemetry (fault detectio= n, > loss and delay measurement). > > =C2=B7 The INT spec is currently missing from the reference list: > http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf > > =C2=B7 Section 2.1 says =E2=80=9CThis document does not prescribe= any specific > encapsulation for the data-plane probe.=E2=80=9D > On the other hand, Figure 2 defines the fields, which appe= ar > to be encapsulation-specific. Moreover, the length of these fields is > encapsulation-specific, right? Please consider removing the Probe Marker > fields from this draft. > > =C2=B7 Section 3.2: =E2=80=9Cresidence time is in 48-bits of nano= seconds=E2=80=9D =E2=80=93 > please note that the IEEE 1588 standard uses a 64-bit format to represent > the correctionField (residence time). It is recommended to use the same > format here. > > =C2=B7 Section 3.3: the difference between the queueing delay and= the > residence time is (roughly) constant for a given switch. It would be > worthwhile to explain why both are needed. > > =C2=B7 Section 3.5: the word =E2=80=98analyzer=E2=80=99 is mentio= ned here for the first > time without being defined beforehand. > > =C2=B7 s/needs to made/needs to be made/ > > =C2=B7 Section 4: > > o =E2=80=9CSwap the destination/source IP addresses in the transport he= ader to > send the packet back to the originator.=E2=80=9D =E2=80=93 again, there i= s a slight conflict > with section 2.1, which argues for encapsulation-independence. Moreover, > swapping the IP addresses is typically not enough (L2 addresses, L4 ports= =E2=80=A6). > > o On the returning path =E2=80=93 are devices expected to update the > field? > > o Since is equal to zero, doesn=E2=80=99t the analyzer loos= e the > information about the number of hops until the loopback device? > > =C2=B7 Section 5.1: =E2=80=9CProbe Id=E2=80=9D is mentioned for t= he first time here > without prior explanation, so the paragraph is not clear. > > =C2=B7 Section 6: router alert =E2=80=93 again, a conflict with e= ncapsulation > independence=E2=80=A6 > > > > > > Regards, > > Tal Mizrahi. > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Jul 5 05:02:33 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584BD12D1ED for ; Tue, 5 Jul 2016 05:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Cf81R9B0xepM for ; Tue, 5 Jul 2016 05:02:28 -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 D844812D0A8 for ; Tue, 5 Jul 2016 05:02:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSB74280; Tue, 05 Jul 2016 12:02:25 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 5 Jul 2016 13:02:24 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 5 Jul 2016 20:02:19 +0800 From: Qin Wu To: "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt Thread-Index: AQHR1rQaqatqqP7izEmdMDgbK+d1g6AJuuFA Date: Tue, 5 Jul 2016 12:02:19 +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.136.79.112] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.577BA1D2.0046, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cb493757c1f3ae7cb0eff59b138acc36 Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 12:02:31 -0000 SGksDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBJLUQgdGhhdCBkaXNjdXNzZXMgdGhlIHNjb3Bl IGFuZCBwdXJwb3NlIG9mIHNlcnZpY2UgbW9kZWxzIHdpdGhpbg0KdGhlIElFVEYgYW5kIGRlc2Ny aWJlcyBob3cgYSBzZXJ2aWNlIG1vZGVsIGNhbiBiZSB1c2VkIGJ5IGEgbmV0d29yaw0Kb3BlcmF0 b3IuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1vcHNhd2ctc2Vy dmljZS1tb2RlbC1leHBsYWluZWQvDQoNCkluIGFkZGl0aW9uLCB0aGlzIGRyYWZ0IGNsYXJpZmll cyB0aGUgcm9sZSBhbmQgcG9zaXRpb24gb2Ygc2VydmljZSBtb2RlbCBpbiB0aGUgU0ROIGFyY2hp dGVjdHVyZSBhbmQNCkNsZWFyIHNldmVyYWwgbWlzY29uY2VwdGlvbiBvbiB0aGUgc2VydmljZSBt b2RlbC4NCg0KWW91ciBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpSZWdh cmRzIQ0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB 5pe26Ze0OiAyMDE25bm0N+aciDXml6UgMTk6NTUNCuaUtuS7tuS6ujogTGl1c2h1Y2hlbmcgKFdp bGwpOyBBZHJpYW4gRmFycmVsOyBMaXVzaHVjaGVuZyAoV2lsbCk7IFFpbiBXdQ0K5Li76aKYOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVs LWV4cGxhaW5lZC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3Utb3Bz YXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBRaW4gV3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkDQpSZXZpc2lv bjoJMDANClRpdGxlOgkJU2VydmljZSBNb2RlbHMgRXhwbGFpbmVkDQpEb2N1bWVudCBkYXRlOgky MDE2LTA3LTA1DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMg0KVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13 dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQtMDAudHh0DQpTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2Ut bW9kZWwtZXhwbGFpbmVkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQtMDANCg0KDQpBYnN0 cmFjdDoNCiAgIFRoZSBJRVRGIGhhcyBwcm9kdWNlZCBhIGNvbnNpZGVyYWJsZSBudW1iZXIgb2Yg ZGF0YSBtb2RlbHMgaW4gdGhlDQogICBZQU5HIG1vZGVsbGluZyBsYW5ndWFnZS4gIFRoZSBtYWpv cml0eSBvZiB0aGVzZSBhcmUgdXNlZCB0byBtb2RlbA0KICAgZGV2aWNlcyBhbmQgdGhleSBhbGxv dyBhY2Nlc3MgZm9yIGNvbmZpZ3VyYXRpb24gYW5kIHRvIHJlYWQNCiAgIG9wZXJhdGlvbmFsIHN0 YXR1cy4NCg0KICAgQSBzbWFsbCBudW1iZXIgb2YgWUFORyBtb2RlbHMgYXJlIHVzZWQgdG8gbW9k ZWwgc2VydmljZXMgKGZvcg0KICAgZXhhbXBsZSwgdGhlIExheWVyIFRocmVlIFZpcnR1YWwgUHJp dmF0ZSBOZXR3b3JrIFNlcnZpY2UgTW9kZWwNCiAgIHByb2R1Y2VkIGJ5IHRoZSBMM1NNIHdvcmtp bmcgZ3JvdXApLg0KDQogICBUaGlzIGRvY3VtZW50IGJyaWVmbHkgc2V0cyBvdXQgdGhlIHNjb3Bl IG9mIGFuZCBwdXJwb3NlIG9mIGFuIElFVEYNCiAgIHNlcnZpY2UgbW9kZWwsIGFuZCBpdCBzaG93 cyB3aGVyZSBhIHNlcnZpY2UgbW9kZWwgbWlnaHQgZml0IGludG8gYQ0KICAgU29mdHdhcmUgRGVm aW5lZCBOZXR3b3JraW5nIGFyY2hpdGVjdHVyZSBvciBkZXBsb3ltZW50Lg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From gurong@chinamobile.com Wed Jul 6 04:20:19 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7E812B014 for ; Wed, 6 Jul 2016 04:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.025 X-Spam-Level: X-Spam-Status: No, score=-4.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 a2E40YHDgQ2e for ; Wed, 6 Jul 2016 04:20:17 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1026812D1D2 for ; Wed, 6 Jul 2016 04:20:15 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.15]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee7577ce968ee2-66d2b; Wed, 06 Jul 2016 19:20:08 +0800 (CST) X-RM-TRANSID: 2ee7577ce968ee2-66d2b X-RM-SPAM-FLAG: 00000000 Received: from GuRong (unknown[223.72.101.132]) by rmsmtp-syy-appsvr08-12008 (RichMail) with SMTP id 2ee8577ce966db3-270cb; Wed, 06 Jul 2016 19:20:08 +0800 (CST) X-RM-TRANSID: 2ee8577ce966db3-270cb From: "Ariel Gu" To: Date: Wed, 6 Jul 2016 19:20:07 +0800 Message-ID: <000001d1d778$5ab27ff0$10177fd0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D1D7BB.68D99080" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdHXd6taGdjpOn/NTCqd7sdV2tR6EQ== Content-Language: zh-cn Archived-At: Cc: lizhenqiang Subject: [OPSAWG] Solicit comments for my draft of draft-li-opsawg-ipfix-bgp-community-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 11:28:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D1D7BB.68D99080 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi=A3=ACdear all. We have submitted a new I-D that specifies an extension to the IPFIX information model to export the BGP community information. In this = draft, we add two information elements in order to carry the community information = for the source IP and destination IP.=20 If you are interested in this, feel free to contact me. Any question and suggestions are welcome. =20 The information of this draft is listed as follows. =20 A new version of I-D, draft-li-opsawg-ipfix-bgp-community-00.txt has = been successfully submitted by Rong Gu and posted to the IETF repository. Name: draft-li-opsawg-ipfix-bgp-community Revision: 00 Title: Export BGP community information in IP Flow Information Export (IPFIX) Document date: 2016-07-06 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-li-opsawg-ipfix-bgp-community-= 00. txt Status: https://datatracker.ietf.org/doc/draft-li-opsawg-ipfix-bgp-community/ Htmlized: https://tools.ietf.org/html/draft-li-opsawg-ipfix-bgp-community-00 Abstract: This draft specifies an extension to the IPFIX information model = defined in [RFC7012] to export the BGP community information. Two information elements, bgpSourceCommunityList and bgpDestinationCommunityList, are introduced in this document to carry the community information for the source IP and destination IP respectively. =20 B.R. ----------------------------------------------------------- Rong Gu China Mobile Research Institute No.32 Xuanwumen West Street, Xicheng District Beijing, China, 100053 Mobile: +86 13811520541 Phone: +86 10 15801696688 Ext. 36211 Email: gurong@chinamobile.com ------=_NextPart_000_0001_01D1D7BB.68D99080 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi=A3=ACdear = all.

We = have submitted a new I-D that specifies an extension to = the IPFIX information model to export the BGP community information. In = this draft, we add two information elements in order to carry the = community information for the source IP and destination IP. =

If you are interested in = this, feel free to contact me. Any question and = suggestions are welcome.

 

The information of this draft is listed as = follows.

 

A new version of I-D, = draft-li-opsawg-ipfix-bgp-community-00.txt has been = successfully submitted by Rong Gu and posted to the IETF repository.

Name:       = ;    draft-li-opsawg-ipfix-bgp-community
Revision:       = 00
Title:      &nbs= p;   Export BGP community information in IP Flow Information = Export (IPFIX)
Document = date:  2016-07-06
Group:      &nbs= p;   Individual Submission
Pages:      &nbs= p;   6
URL:       =      https://www.ietf.org/internet-drafts/dra= ft-li-opsawg-ipfix-bgp-community-00.txt
Status:      &nb= sp;  https://datatracker.ietf.org/doc/draft-l= i-opsawg-ipfix-bgp-community/
Htmlized:      <= span class=3Dapple-converted-space> https://tools.ietf.org/html/draft-li-ops= awg-ipfix-bgp-community-00


Abstract:
   This draft specifies an = extension to the IPFIX information model defined in [RFC7012] to export the BGP = community information.  Two information elements, bgpSourceCommunityList = and bgpDestinationCommunityList, = are introduced in this document to carry the community information for = the source IP and destination IP respectively.

 

B.R.

-------------= ----------------------------------------------

Rong = Gu
China Mobile Research Institute
No.32 Xuanwumen West Street, = Xicheng District
Beijing, China, 100053
Mobile: +86 = 13811520541
Phone: +86 10 15801696688 Ext. 36211
Email: gurong@chinamobile.com<= /p>

------=_NextPart_000_0001_01D1D7BB.68D99080-- From nobody Wed Jul 6 18:42:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A97412D507 for ; Wed, 6 Jul 2016 18:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.015 X-Spam-Level: X-Spam-Status: No, score=-4.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=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 IZZEzqxc88z1 for ; Wed, 6 Jul 2016 18:42:42 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5795B12B020 for ; Wed, 6 Jul 2016 18:42:41 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee2577db38a28a-6ff55; Thu, 07 Jul 2016 09:42:34 +0800 (CST) X-RM-TRANSID: 2ee2577db38a28a-6ff55 X-RM-SPAM-FLAG: 00000000 Received: from GuRong (unknown[223.104.3.184]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee1577db388c7d-40df5; Thu, 07 Jul 2016 09:42:34 +0800 (CST) X-RM-TRANSID: 2ee1577db388c7d-40df5 From: "Ariel Gu" To: "'Zhoutianran'" , , References: In-Reply-To: Date: Thu, 7 Jul 2016 09:42:33 +0800 Message-ID: <002601d1d7f0$d5909400$80b1bc00$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01D1D833.E3BA8AC0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdHXeJrrVxfvGyozT+mNnt2Ad9FgBgAdtOFQ Content-Language: zh-cn Archived-At: Subject: [OPSAWG] =?gb2312?b?16q3ojogQXNrIGZvciB0aW1lIHNsb3QgZm9yIG15IGRy?= =?gb2312?b?YWZ0IG9mIGRyYWZ0LWxpLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAw?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 01:42:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0027_01D1D833.E3BA8AC0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, dear all. =20 I have submitted a draft which specifies an extension to the IPFIX information model to export the BGP community information. In order to collect BGP community information, two information elements need to be added. Time slot is appreciated in order to share this draft with others this = IETF in Berlin. 10 minutes is OK for me. =20 It=A1=AFs grateful of you if you can give me the chance of presentation. =20 Feel free to contact with me. Best regards.=20 ----------------------------------------------------------- Rong Gu China Mobile Research Institute No.32 Xuanwumen West Street, Xicheng District Beijing, China, 100053 Mobile: +86 13811520541 Phone: +86 10 15801696688 Ext. 36211 Email: gurong@chinamobile.com =B7=A2=BC=FE=C8=CB: Ariel Gu [mailto:gurong@chinamobile.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA7=D4=C26=C8=D5 19:20 =CA=D5=BC=FE=C8=CB: 'opsawg@ietf.org' =B3=AD=CB=CD: lizhenqiang; 'Dongjie (Jimmy)' =D6=F7=CC=E2: Solicit comments for my draft of draft-li-opsawg-ipfix-bgp-community-00 =20 Hi=A3=ACdear all. We have submitted a new I-D that specifies an extension to the IPFIX information model to export the BGP community information. In this = draft, we add two information elements in order to carry the community information = for the source IP and destination IP.=20 If you are interested in this, feel free to contact me. Any question and suggestions are welcome. =20 The information of this draft is listed as follows. =20 A new version of I-D, draft-li-opsawg-ipfix-bgp-community-00.txt has = been successfully submitted by Rong Gu and posted to the IETF repository. Name: draft-li-opsawg-ipfix-bgp-community Revision: 00 Title: Export BGP community information in IP Flow Information Export (IPFIX) Document date: 2016-07-06 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-li-opsawg-ipfix-bgp-community-= 00. txt Status: https://datatracker.ietf.org/doc/draft-li-opsawg-ipfix-bgp-community/ Htmlized: https://tools.ietf.org/html/draft-li-opsawg-ipfix-bgp-community-00 Abstract: This draft specifies an extension to the IPFIX information model = defined in [RFC7012] to export the BGP community information. Two information elements, bgpSourceCommunityList and bgpDestinationCommunityList, are introduced in this document to carry the community information for the source IP and destination IP respectively. =20 B.R. ----------------------------------------------------------- Rong Gu China Mobile Research Institute No.32 Xuanwumen West Street, Xicheng District Beijing, China, 100053 Mobile: +86 13811520541 Phone: +86 10 15801696688 Ext. 36211 Email: gurong@chinamobile.com ------=_NextPart_000_0027_01D1D833.E3BA8AC0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, dear = all.

 

I have = submitted a draft which specifies an extension to the IPFIX information = model to export the BGP community information.  In order to collect = BGP community information, two information elements need to be = added.

Time slot is appreciated in order to share this = draft with others this IETF in Berlin. 10 minutes is OK for = me.

 

It=A1=AFs = grateful of you if you can give me the chance of = presentation.

 

Feel free = to contact with me. Best regards.

-------------= ----------------------------------------------

Rong = Gu
China Mobile Research Institute
No.32 Xuanwumen West Street, = Xicheng District
Beijing, China, 100053
Mobile: +86 = 13811520541
Phone: +86 10 15801696688 Ext. 36211
Email: gurong@chinamobile.com<= /p>

=B7=A2=BC=FE=C8=CB: Ariel Gu [mailto:gurong@chinamobile.com]=
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA7=D4=C26=C8=D5 = 19:20
=CA=D5=BC=FE=C8=CB: = 'opsawg@ietf.org'
=B3=AD=CB=CD: lizhenqiang; 'Dongjie = (Jimmy)'
=D6=F7=CC=E2: Solicit comments for my draft of = draft-li-opsawg-ipfix-bgp-community-00

=

 

Hi=A3=ACdear = all.

We = have submitted a new I-D that specifies an extension to = the IPFIX information model to export the BGP community information. In = this draft, we add two information elements in order to carry the = community information for the source IP and destination IP. =

If you are interested in = this, feel free to contact me. Any question and = suggestions are welcome.

 

The information of this draft is listed as = follows.

 

A new version of I-D, = draft-li-opsawg-ipfix-bgp-community-00.txt has been = successfully submitted by Rong Gu and posted to the IETF repository.

Name:       = ;    draft-li-opsawg-ipfix-bgp-community
Revision:       = 00
Title:      &nbs= p;   Export BGP community information in IP Flow Information = Export (IPFIX)
Document = date:  2016-07-06
Group:      &nbs= p;   Individual Submission
Pages:      &nbs= p;   6
URL:       =      https://www.ietf.org/internet-drafts/dra= ft-li-opsawg-ipfix-bgp-community-00.txt
Status:      &nb= sp;  https://datatracker.ietf.org/doc/draft-l= i-opsawg-ipfix-bgp-community/
Htmlized:      <= span class=3Dapple-converted-space> https://tools.ietf.org/html/draft-li-ops= awg-ipfix-bgp-community-00


Abstract:
   This draft specifies an = extension to the IPFIX information model defined in [RFC7012] to export the BGP = community information.  Two information elements, bgpSourceCommunityList = and bgpDestinationCommunityList, = are introduced in this document to carry the community information for = the source IP and destination IP respectively.

 

B.R.

-------------= ----------------------------------------------

Rong = Gu
China Mobile Research Institute
No.32 Xuanwumen West Street, = Xicheng District
Beijing, China, 100053
Mobile: +86 = 13811520541
Phone: +86 10 15801696688 Ext. 36211
Email: gurong@chinamobile.com<= /p>

------=_NextPart_000_0027_01D1D833.E3BA8AC0-- From nobody Wed Jul 6 20:39:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D5012D0A6 for ; Wed, 6 Jul 2016 20:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=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 xEeD4LfElCpU for ; Wed, 6 Jul 2016 20:39:37 -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 06F6812B04A for ; Wed, 6 Jul 2016 20:39:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNG88827; Thu, 07 Jul 2016 03:39:32 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Jul 2016 04:39:31 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 7 Jul 2016 11:39:24 +0800 From: Duzongpeng To: Ariel Gu , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Solicit comments for my draft of draft-li-opsawg-ipfix-bgp-community-00 Thread-Index: AdHXd6taGdjpOn/NTCqd7sdV2tR6EQAiGpfg Date: Thu, 7 Jul 2016 03:39:24 +0000 Message-ID: References: <000001d1d778$5ab27ff0$10177fd0$@chinamobile.com> In-Reply-To: <000001d1d778$5ab27ff0$10177fd0$@chinamobile.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: multipart/alternative; boundary="_000_BAFEC9523F57BC48A51C20226A5589575FE299CAnkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.577DCEF4.00FA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 605cea6576231597020cfab0e1db9099 Archived-At: Cc: lizhenqiang Subject: Re: [OPSAWG] Solicit comments for my draft of draft-li-opsawg-ipfix-bgp-community-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 03:39:40 -0000 --_000_BAFEC9523F57BC48A51C20226A5589575FE299CAnkgeml514mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEFyaWVsDQoNCiAgICAgICAgIEkgYXBwcm92ZSB0aGF0IHdlIG5lZWQgdG8gY29uc2lkZXIg YWRkaW5nIG5ldyBJRXMgYWNjb3JkaW5nIHRvIHRoZSBuZWVkcyBvZiByZWFsIG5ldHdvcmsgZW52 aXJvbm1lbnQuDQoNCiAgICAgICAgIEEgZWRpdG9yaWFsIHN1Z2dlc3Rpb246IHRoaXMgZHJhZnQg aGFzIGEgbG9uZyBpbnRyb2R1Y3Rpb24gd2hpY2ggY29udGFpbnMgcHJvYmxlbSBzdGF0ZW1lbnQg YW5kIHNvbHV0aW9uIHByb3Bvc2VkLiBNYXliZSwgaXQgY2FuIGJlIHJlb3JnYW5pemVkIHRvIHR3 byBzZWN0aW9ucy4NCg0KQmVzdCBSZWdhcmRzDQpab25ncGVuZyBEdQ0KDQpGcm9tOiBPUFNBV0cg W21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFyaWVsIEd1DQpT ZW50OiBXZWRuZXNkYXksIEp1bHkgMDYsIDIwMTYgNzoyMCBQTQ0KVG86IG9wc2F3Z0BpZXRmLm9y Zw0KQ2M6IGxpemhlbnFpYW5nDQpTdWJqZWN0OiBbT1BTQVdHXSBTb2xpY2l0IGNvbW1lbnRzIGZv ciBteSBkcmFmdCBvZiBkcmFmdC1saS1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMA0KDQpI aaOsZGVhciBhbGwuDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBJLUQgdGhhdCBzcGVjaWZpZXMg YW4gZXh0ZW5zaW9uIHRvIHRoZSBJUEZJWCBpbmZvcm1hdGlvbiBtb2RlbCB0byBleHBvcnQgdGhl IEJHUCBjb21tdW5pdHkgaW5mb3JtYXRpb24uIEluIHRoaXMgZHJhZnQsIHdlIGFkZCB0d28gaW5m b3JtYXRpb24gZWxlbWVudHMgaW4gb3JkZXIgdG8gY2FycnkgdGhlIGNvbW11bml0eSBpbmZvcm1h dGlvbiBmb3IgdGhlIHNvdXJjZSBJUCBhbmQgZGVzdGluYXRpb24gSVAuDQpJZiB5b3UgYXJlIGlu dGVyZXN0ZWQgaW4gdGhpcywgZmVlbCBmcmVlIHRvIGNvbnRhY3QgbWUuIEFueSBxdWVzdGlvbiBh bmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNClRoZSBpbmZvcm1hdGlvbiBvZiB0aGlzIGRy YWZ0IGlzIGxpc3RlZCBhcyBmb2xsb3dzLg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt bGktb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHktMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgUm9uZyBHdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1saS1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eQ0K UmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgRXhwb3J0IEJHUCBjb21tdW5pdHkg aW5mb3JtYXRpb24gaW4gSVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQgKElQRklYKQ0KRG9jdW1l bnQgZGF0ZTogIDIwMTYtMDctMDYNCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOiAgICAgICAgICA2DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAw LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWxpLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0 eS0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9u IHRvIHRoZSBJUEZJWCBpbmZvcm1hdGlvbiBtb2RlbCBkZWZpbmVkIGluIFtSRkM3MDEyXSB0byBl eHBvcnQgdGhlIEJHUCBjb21tdW5pdHkgaW5mb3JtYXRpb24uICBUd28gaW5mb3JtYXRpb24gZWxl bWVudHMsIGJncFNvdXJjZUNvbW11bml0eUxpc3QgYW5kIGJncERlc3RpbmF0aW9uQ29tbXVuaXR5 TGlzdCwgYXJlIGludHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudCB0byBjYXJyeSB0aGUgY29tbXVu aXR5IGluZm9ybWF0aW9uIGZvciB0aGUgc291cmNlIElQIGFuZCBkZXN0aW5hdGlvbiBJUCByZXNw ZWN0aXZlbHkuDQoNCkIuUi4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSb25nIEd1DQpDaGluYSBNb2JpbGUgUmVzZWFyY2ggSW5z dGl0dXRlDQpOby4zMiBYdWFud3VtZW4gV2VzdCBTdHJlZXQsIFhpY2hlbmcgRGlzdHJpY3QNCkJl aWppbmcsIENoaW5hLCAxMDAwNTMNCk1vYmlsZTogKzg2IDEzODExNTIwNTQxDQpQaG9uZTogKzg2 IDEwIDE1ODAxNjk2Njg4IEV4dC4gMzYyMTENCkVtYWlsOiBndXJvbmdAY2hpbmFtb2JpbGUuY29t PG1haWx0bzpodWFuZ2x1QGNoaW5hbW9iaWxlLmNvbT4NCg== --_000_BAFEC9523F57BC48A51C20226A5589575FE299CAnkgeml514mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Ari= el

&n= bsp;

 &= nbsp;       I approve that we need to conside= r adding new IEs according to the needs of real network environment.

&n= bsp;

 &= nbsp;       A editorial suggestion: this draf= t has a long introduction which contains problem statement and solution pro= posed. Maybe, it can be reorganized to two sections.

&n= bsp;

Best Re= gards

Zongpen= g Du

&n= bsp;

From: OPSAWG [mail= to:opsawg-bounces@ietf.org] On Behalf Of Ariel Gu
Sent: Wednesday, July 06, 2016 7:20 PM
To: opsawg@ietf.org
Cc: lizhenqiang
Subject: [OPSAWG] Solicit comments for my draft of draft-li-opsawg-i= pfix-bgp-community-00

 

Hi=A3=ACdear all.

We have submitted a new I-D tha= t specifies an extens= ion to the IPFIX information model to export the BGP community information. In this draft, we add two information elements in o= rder to carry the community information for the source IP and destination I= P.

If yo= u are interested in this, feel free to contact me. Any question and sugg= estions are welcome.

 

The information of this draft i= s listed as follows.

 

A new= version of I-D, draft-li-opsawg-ipfix-bgp-community-00.txt has been successfully submitted by Rong Gu= and posted to the IETF repository.

Name:      &= nbsp;    draft-li-opsawg-ipfix-bgp-community
Revision:     &nb= sp; 00
Title:      =     Export BGP community information in IP Flow Information = Export (IPFIX)
Document date:  2016-07-06
Group:      =     Individual Submission
Pages:      =     6
URL:      &n= bsp;     <= span style=3D"font-size:10.0pt;font-family:"Microsoft YaHei UI";b= ackground:white">https://www.ietf.org/internet-drafts/draft-li-opsawg-ipfix= -bgp-community-00.txt
Status:      = ;   https://= datatracker.ietf.org/doc/draft-li-opsawg-ipfix-bgp-community/
Htmlized:     &nb= sp; https://tools.ietf.or= g/html/draft-li-opsawg-ipfix-bgp-community-00


Abstract:
   This draft specifies an exten= sion to the IPFIX information model defined in [RFC7012] to export the BGP com= munity information.  Two information elements, bgpSourceCommunityLi= st and bgpDestinationCommunityList, are introduce= d in this document to carry the community information for the source IP and= destination IP respectively.

=  

B.R.<= /span>

---------------------------------------------------------= --

Rong Gu
China Mobile Research Institute
No.32 Xuanwumen West Street, Xicheng District
Beijing, China, 100053
Mobile: +86 13811520541
Phone: +86 10 15801696688 Ext. 36211
Email: gurong@chinamobile.com

--_000_BAFEC9523F57BC48A51C20226A5589575FE299CAnkgeml514mbxchi_-- From nobody Wed Jul 6 20:48:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F1F128B44 for ; Wed, 6 Jul 2016 20:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.025 X-Spam-Level: X-Spam-Status: No, score=-4.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 GMEQuJSAJ3g3 for ; Wed, 6 Jul 2016 20:48:00 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 65AAE12B057 for ; Wed, 6 Jul 2016 20:47:59 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app08-12008 (RichMail) with SMTP id 2ee8577dd0ec2f3-76bdd; Thu, 07 Jul 2016 11:47:57 +0800 (CST) X-RM-TRANSID: 2ee8577dd0ec2f3-76bdd X-RM-SPAM-FLAG: 00000000 Received: from GuRong (unknown[223.104.3.184]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee5577dd0eb527-3f288; Thu, 07 Jul 2016 11:47:57 +0800 (CST) X-RM-TRANSID: 2ee5577dd0eb527-3f288 From: "Ariel Gu" To: "'Duzongpeng'" , References: <000001d1d778$5ab27ff0$10177fd0$@chinamobile.com> In-Reply-To: Date: Thu, 7 Jul 2016 11:47:55 +0800 Message-ID: <004b01d1d802$5978d3c0$0c6a7b40$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01D1D845.67A366C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHtElatkdMO+T435C1Ih6gwNYJpRgHkCc1kn8a9r/A= Content-Language: zh-cn Archived-At: Cc: 'lizhenqiang' Subject: [OPSAWG] =?gb2312?b?tPC4tDogIFNvbGljaXQgY29tbWVudHMgZm9yIG15IGRy?= =?gb2312?b?YWZ0IG9mIGRyYWZ0LWxpLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAw?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 03:48:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004C_01D1D845.67A366C0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, Zongpeng. Thank you for your suggestion. Introduction can be newly organized in = the updated version. Thanks again. =20 B.R. Gu Rong =B7=A2=BC=FE=C8=CB: Duzongpeng [mailto:duzongpeng@huawei.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA7=D4=C27=C8=D5 11:39 =CA=D5=BC=FE=C8=CB: Ariel Gu; opsawg@ietf.org =B3=AD=CB=CD: lizhenqiang =D6=F7=CC=E2: RE: [OPSAWG] Solicit comments for my draft of draft-li-opsawg-ipfix-bgp-community-00 =20 Hi, Ariel =20 I approve that we need to consider adding new IEs according to = the needs of real network environment. =20 A editorial suggestion: this draft has a long introduction = which contains problem statement and solution proposed. Maybe, it can be reorganized to two sections. =20 Best Regards Zongpeng Du =20 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Ariel Gu Sent: Wednesday, July 06, 2016 7:20 PM To: opsawg@ietf.org =20 Cc: lizhenqiang Subject: [OPSAWG] Solicit comments for my draft of draft-li-opsawg-ipfix-bgp-community-00 =20 Hi=A3=ACdear all. We have submitted a new I-D that specifies an extension to the IPFIX information model to export the BGP community information. In this = draft, we add two information elements in order to carry the community information = for the source IP and destination IP.=20 If you are interested in this, feel free to contact me. Any question and suggestions are welcome. =20 The information of this draft is listed as follows. =20 A new version of I-D, draft-li-opsawg-ipfix-bgp-community-00.txt has = been successfully submitted by Rong Gu and posted to the IETF repository. Name: draft-li-opsawg-ipfix-bgp-community Revision: 00 Title: Export BGP community information in IP Flow Information Export (IPFIX) Document date: 2016-07-06 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-li-opsawg-ipfix-bgp-community-= 00. txt Status: https://datatracker.ietf.org/doc/draft-li-opsawg-ipfix-bgp-community/ Htmlized: https://tools.ietf.org/html/draft-li-opsawg-ipfix-bgp-community-00 Abstract: This draft specifies an extension to the IPFIX information model = defined in [RFC7012] to export the BGP community information. Two information elements, bgpSourceCommunityList and bgpDestinationCommunityList, are introduced in this document to carry the community information for the source IP and destination IP respectively. =20 B.R. ----------------------------------------------------------- Rong Gu China Mobile Research Institute No.32 Xuanwumen West Street, Xicheng District Beijing, China, 100053 Mobile: +86 13811520541 Phone: +86 10 15801696688 Ext. 36211 Email: gurong@chinamobile.com ------=_NextPart_000_004C_01D1D845.67A366C0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, = Zongpeng.

Thank you for your suggestion. Introduction can = be newly organized in the updated version.

Thanks = again.

 

B.R.

Gu = Rong

=B7=A2=BC=FE=C8=CB: Duzongpeng [mailto:duzongpeng@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA7=D4=C27=C8=D5 = 11:39
=CA=D5=BC=FE=C8=CB: Ariel Gu; = opsawg@ietf.org
=B3=AD=CB=CD: = lizhenqiang
=D6=F7=CC=E2: RE: [OPSAWG] Solicit = comments for my draft of = draft-li-opsawg-ipfix-bgp-community-00

=

 

Hi, Ariel

 

         = I approve that we need to consider adding new IEs according to the needs = of real network environment.

 

         = A editorial suggestion: this draft has a long introduction which = contains problem statement and solution proposed. Maybe, it can be = reorganized to two sections.

 

Best = Regards

Zongpeng Du

 

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Ariel Gu
Sent: Wednesday, July 06, 2016 = 7:20 PM
To: opsawg@ietf.org
Cc: = lizhenqiang
Subject: [OPSAWG] Solicit comments for my draft of = draft-li-opsawg-ipfix-bgp-community-00

<= p class=3DMsoNormal align=3Dleft style=3D'text-align:left'> 

Hi=A3=ACdear = all.

We = have submitted a new I-D that specifies an extension to = the IPFIX information model to export the BGP community information. In = this draft, we add two information elements in order to carry the = community information for the source IP and destination IP. =

If you are interested in = this, feel free to contact me. Any question and = suggestions are welcome.

 

The information of this draft is listed as = follows.

 

A new version of I-D, = draft-li-opsawg-ipfix-bgp-community-00.txt has been = successfully submitted by Rong Gu and posted to the IETF repository.

Name:       = ;    draft-li-opsawg-ipfix-bgp-community
Revision:       = 00
Title:      &nbs= p;   Export BGP community information in IP Flow Information = Export (IPFIX)
Document = date:  2016-07-06
Group:      &nbs= p;   Individual Submission
Pages:      &nbs= p;   6
URL:       =      https://www.ietf.org/internet-drafts/dra= ft-li-opsawg-ipfix-bgp-community-00.txt
Status:      &nb= sp;  https://datatracker.ietf.org/doc/draft-l= i-opsawg-ipfix-bgp-community/
Htmlized:      <= span class=3Dapple-converted-space> https://tools.ietf.org/html/draft-li-ops= awg-ipfix-bgp-community-00


Abstract:
   This draft specifies an = extension to the IPFIX information model defined in [RFC7012] to export the BGP = community information.  Two information elements, bgpSourceCommunityList = and bgpDestinationCommunityList, = are introduced in this document to carry the community information for = the source IP and destination IP respectively.

 

B.R.

-------------= ----------------------------------------------

Rong = Gu
China Mobile Research Institute
No.32 Xuanwumen West Street, = Xicheng District
Beijing, China, 100053
Mobile: +86 = 13811520541
Phone: +86 10 15801696688 Ext. 36211
Email: gurong@chinamobile.com<= /p>

------=_NextPart_000_004C_01D1D845.67A366C0-- From nobody Thu Jul 7 06:05:22 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6641C12D7B1 for ; Thu, 7 Jul 2016 06:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ynn_ObFt4IpU for ; Thu, 7 Jul 2016 06:05: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 CE24012D7AF for ; Thu, 7 Jul 2016 06:05:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNH52962; Thu, 07 Jul 2016 13:05:15 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Jul 2016 14:05:14 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 7 Jul 2016 21:05:08 +0800 From: Qin Wu To: Warren Kumari , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Agenda requests Thread-Index: AQHRyOZH8nirr0iSm0GBKnTkeBo3f5//2tIAgABtzICADDby8A== Date: Thu, 7 Jul 2016 13:05:08 +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.45.1.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.577E538B.0245, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 54c2da3af8049809189371146c58afc1 Archived-At: Subject: Re: [OPSAWG] Agenda requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 13:05:21 -0000 if there is space on the agenda, we would like to have a 5 min for a quick = update on service model scope and purpose clarification. https://tools.ietf.org/html/draft-wu-opsawg-service-model-explained-00 -Qin > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren=20 > Kumari > Sent: Wednesday, June 29, 2016 2:29 PM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] Agenda requests >=20 > ... and a reminder that we have open agenda time. >=20 > W >=20 > On Sat, Jun 18, 2016 at 1:18 AM, Warren Kumari > wrote: > > Dear OpsAWG, > > > > We have requested a slot for the joint OpsAWG / OpsArea meeting in > Berlin. > > > > Please send over requests for agenda time. > > Please remember that we give time to drafts that have already=20 > > received significant discussion on list. > > > > > > Also, a reminder that OpsAWG is housing the MUD work -- it would be=20 > > much appreciated if you could read the MUD documents: _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Jul 7 06:48:36 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF0312D76D for ; Thu, 7 Jul 2016 06:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XQJGlc-ElGUj for ; Thu, 7 Jul 2016 06:48:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88C612D768 for ; Thu, 7 Jul 2016 06:48:23 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 57BC383332334; Thu, 7 Jul 2016 13:48:19 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u67DmLAQ011682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2016 13:48:21 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u67DmBXV009699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jul 2016 15:48:21 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 7 Jul 2016 15:47:15 +0200 From: "Scharf, Michael (Nokia - DE)" To: Qin Wu , "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt Thread-Index: AQHR1rQaqatqqP7izEmdMDgbK+d1g6AJuuFAgAMw/BA= Date: Thu, 7 Jul 2016 13:47:14 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48906FBF@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 13:48:34 -0000 SGkgYWxsLA0KDQpJIGhhdmUgcXVpY2tseSBzY2FubmVkIHRoaXMgZG9jdW1lbnQuIFNvbWUgaW5p dGlhbCBjb21tZW50cyBbbXNdOg0KDQoqKiogUGFnZSAzOg0KDQogICBTZXJ2aWNlIE1vZGVsOiAg QSBzZXJ2aWNlIG1vZGVsIGlzIGEgc3BlY2lmaWMgdHlwZSBvZiBkYXRhIG1vZGVsLiAgSXQNCiAg ICAgIGRlc2NyaWJlcyBhIHNlcnZpY2UgYW5kIGFsbCBvZiB0aGUgcGFyYW1ldGVycyBvZiB0aGUg c2VydmljZSBpbiBhDQogICAgICBwb3J0YWJsZSwgb3BlcmF0b3ItaW5kZXBlbmRlbnQgd2F5LiAg SXQgY2FuIGJlIHVzZWQgYnkgYSBodW1hbiBvcg0KICAgICAgYnkgc29mdHdhcmUgdG8gY29uZmln dXJlIG9yIHJlcXVlc3QgYSBzZXJ2aWNlIGFuZCBtYXkgZXF1YWxseSBiZQ0KICAgICAgY29uc3Vt ZWQgYnkgYSBodW1hbiBvciBieSBhIHNvZnR3YXJlIGNvbXBvbmVudC4NCg0KW21zXSBJIHdvdWxk IHN1Z2dlc3QgYSBtb3JlIGNhcmVmdWwgd29yZGluZyByZWdhcmRpbmcgdGhlIGNvbXBsZXRlbmVz cyBvZiB0aGUgbW9kZWwsIGUuZy4sICJJdCBhaW1zIGF0IGRlc2NyaWJpbmcgYSBzZXJ2aWNlIGFu ZCBhbGwgb2YgdGhlIHBhcmFtZXRlcnMgb2YgdGhlIHNlcnZpY2UuLi4iLiBBcyBkaXNjdXNzZWQg aW4gTDNTTSBpbiB0aGUgcGFzdCwgZm9yIGNlcnRhaW4gc2VydmljZXMgKGUuZy4sIGZpcmV3YWxs cywgRG9TIHByZXZlbnRpb24sIC4uLikgdGhlIHNlcnZpY2UgbW9kZWwgd291bGQgaGF2ZSB0byBi ZSBleHRlbmRlZCAvIGF1Z21lbnRlZC4gQWxzbyBub3RlIHRoYXQgdGhlIHN0YXRlbWVudCAiYWxs IHBhcmFtZXRlcnMiIGNvbnRyYWRpY3RzIHRoZSBzdGF0ZW1lbnQgb24gU0xBcyBsYXRlciBpbiB0 aGUgdGV4dC4NCg0KW21zXSBJIGZpbmQgdGhlIHdvcmRpbmcgIml0IGNhbiBiZSB1c2VkIGJ5IGEg aHVtYW4uLi4iIGNvbmZ1c2luZy4gSXMgdGhlIGFzc3VtcHRpb24gdGhhdCBhIHVzZXIgd291bGQg bWFudWFsbHkgdHlwZSBpbiBhIHNlcnZpY2UgcmVxdWVzdCByZXN1bHRpbmcgaW4gYSB2YWxpZCBk YXRhIG1vZGVsLCBlLmcuLCBieSBtYW51YWxseSB0eXBpbmcgaW4gTkVUQ09ORiBjb21tYW5kcz8g SSB3b3VsZCByYXRoZXIgd3JpdGUgc29tZXRoaW5nIGxpa2UgInRoZSBwYXJhbWV0ZXJzIGNhbiBi ZSBlbnRlcmVkIGJ5IHNvZnR3YXJlIG9yIGFsc28gbWFudWFsbHkgYnkgYSBodW1hbi4uLiINCg0K DQoqKiogUGFnZSAzOg0KDQogICBUaGUgZW5jb2RpbmcgYW5kIGNvbW11bmljYXRpb24gcHJvdG9j b2wgdXNlZCB0byBleGNoYW5nZSBhIHNlcnZpY2UNCiAgIG1vZGVsIGJldHdlZW4gY3VzdG9tZXIg YW5kIG5ldHdvcmsgb3BlcmF0b3IgYXJlIGRlcGxveW1lbnQtIGFuZA0KICAgaW1wbGVtZW50YXRp b24tc3BlY2lmaWMuICBUaGUgSUVURiByZWNvbW1lbmRzIHRoZSB1c2Ugb2YgdGhlIE5FVENPTkYN CiAgIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgW1JGQzQ3NDFdIHdpdGggZGF0YSBlbmNvZGVkIGlu IFhNTCBvciBKU09OIGZvcg0KICAgaW50ZXJhY3Rpb25zICJvbiB0aGUgd2lyZSIgYmV0d2VlbiBz b2Z0d2FyZSBjb21wb25lbnRzLiAgSG93ZXZlciwgY28tDQogICBsb2NhdGVkIHNvZnR3YXJlIGNv bXBvbmVudHMgbWlnaHQgdXNlIGFuIEFQSSwgd2hpbGUgc3lzdGVtcyB3aXRoIG1vcmUNCiAgIGRp cmVjdCBodWFuIGludGVyYWN0aW9ucyBtaWdodCB1c2Ugd2ViIHBhZ2VzIG9yIGV2ZW4gcGFwZXIg Zm9ybXMuDQoNClttc10gSSBhbSBub3Qgc3VyZSBpZiB0aGUgSUVURiBzaG91bGQgc3VnZ2VzdCB0 aGUgdXNlIG9mIE5FVENPTkYgb24gdGhlIG5vcnRoYm91bmQgaW50ZXJmYWNlIG9mIGEgInNlcnZp Y2Ugb3JjaGVzdHJhdG9yIiwgd2hpY2ggc2VlbXMgdG8gYmUgdGhlIHNjb3BlIG9mIHRoaXMgZG9j dW1lbnQuIEFyZSB0aGVyZSBwb2ludGVycyB0byBydW5uaW5nIGNvZGUgdGhhdCBhY3R1YWxseSBk byB0aGF0PyBJIHdvdWxkIHJhdGhlciBwcmVmZXIgYSB3b3JkaW5nIHN1Y2ggYXMgIlRoZSBJRVRG IGhhcyBzdGFuZGFyZGl6ZWQgTkVUQ09ORiBhbmQgUkVTVENPTkYgZm9yIGludGVyYWN0aW9ucyAi b24gdGhlIHdpcmUiIGJldHdlZW4gc29mdHdhcmUgY29tcG9uZW50cyIuDQoNCg0KKioqIFBhZ2Ug NzoNCg0KICAgbyAgVGhlIG5ldHdvcmsgb3BlcmF0b3IgbWF5IHVzZSBmdXJ0aGVyIGRhdGEgbW9k ZWxzIHRoYXQgaGVscCB0bw0KICAgICAgZGVzY3JpYmUgaG93IHRoZSBzZXJ2aWNlIGlzIHJlYWxp emVkIGluIHRoZSBuZXR3b3JrLiAgVGhlc2UgbW9kZWxzDQogICAgICBtaWdodCBiZSB1c2VkIG9u IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgU2VydmljZSBPcmNoZXN0cmF0b3INCiAgICAgIGFu ZCB0aGUgTmV0d29yayBPcmNoZXN0cmF0b3IgYXMgc2hvd24gaW4gRmlndXJlIDMgYW5kIG1pZ2h0 DQogICAgICBpbmNsdWRlIG1hbnkgb2YgdGhlIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiBpbiB0aGUg c2VydmljZSBtb2RlbA0KICAgICAgYWxvbmdzaWRlIHByb3RvY29sIHBhcmFtZXRlcnMgYW5kIGRl dmljZSBjb25maWd1cmF0aW4gaW5mb3JtYXRpb24uDQogICAgICBJdCBpcyBpbXBvcnRhbnQgdGhh dCB0aGUgU2VydmljZSBPcmNoZXN0cmF0b3Igc2hvdWxkIGJlIGFibGUgdG8NCiAgICAgIG1hcCBm cm9tIGEgc2VydmljZSBtb2RlbCB0byB0aGVzZSBkYXRhIG1vZGVscywgYnV0IHRoZXkgYXJlIG5v dA0KICAgICAgdGhlIHNhbWUgdGhpbmdzLg0KDQpbbXNdIFdoeSBpcyBpdCBub3QgcG9zc2libGUg dGhhdCB0aGUgZGF0YSBtb2RlbHMgYXJlIHRoZSBzYW1lPyBJbiBGaWd1cmUgMywgdGhlICJzZXJ2 aWNlIG9yY2hlc3RyYXRvciIgaXMgYWN0dWFsbHkgYSAiY2xpZW50IiAocmVhZCB0aGlzIGFzICJj dXN0b21lciIpIG9mIHRoZSAibmV0d29yayBvcmNoZXN0cmF0b3JzIi4gSW5zaWRlIGFuIG9wZXJh dG9yLCB0aGUgInNlcnZpY2Ugb3JjaGVzdHJhdG9yIiBjb3VsZCBiZSBvcGVyYXRlZCBieSBhIGRp ZmZlcmVudCBvcmdhbml6YXRpb24gdGhhbiB0aGUgIm5ldHdvcmsgb3JjaGVzdHJhdG9yIiwgaS5l LiwgdGhlcmUgb3VsZCBldmVuIGJlIGEgYnVzaW5lc3MgcmVsYXRpb25zaGlwLiBJbiBnZW5lcmFs LCBhcmNoaXRlY3R1cmVzIGNhbiBiZSByZWN1cnNpdmUuIEkgdGhpbmsgdGhpcyBzdGF0ZW1lbnQg cmVxdWlyZXMgZnVydGhlciBleHBsYW5hdGlvbiBvciByZXdvcmRpbmcuDQoNCg0KKioqIFBhZ2Ug NzoNCg0KICAgbyAgU2VydmljZSBMZXZlbCBBZ3JlZW1lbnRzIChTTEFzKSBoYXZlIGEgaGlnaCBk ZWdyZWUgb2Ygb3ZlcmxhcCB3aXRoDQogICAgICB0aGUgZGVmaW5pdGlvbiBvZiBzZXZpY2VzIHBy ZXNlbnQgaW4gc2VydmljZSBtb2RlbHMuICBSZXF1ZXN0cyBmb3INCiAgICAgIHNwZWNpZmljIGJh bmR3aWR0aCwgZm9yIGV4YW1wbGUsIG1pZ2h0IGJlIHByZXNlbnQgaW4gYSBzZXJ2aWNlDQogICAg ICBtb2RlbCwgYW5kIGFncmVlbWVudCB0byBkZWxpdmVyIGEgc2VydmljZSBpcyBhIGNvbW1pdG1l bnQgdG8gdGhlDQogICAgICBkZXNjcmlwdGlvbiBvZiB0aGUgc2VydmljZSBpbiB0aGUgc2Vydmlj ZSBtb2RlbCwgaG93ZXZlciwgU0xBcw0KICAgICAgdHlwaWNhbGx5IGluY2x1ZGUgYSBudW1iZXIg b2YgZmluZS1ncmFpbmVkIGRldGFpbHMgYWJvdXQgaG93DQogICAgICBzZXJ2aWNlcyBhcmUgYWxs b3dlZCB0byB2YXJ5LCBieSBob3cgbXVjaCwgYW5kIGhvdyBvZnRlbi4gIFNMQXMNCiAgICAgIGFy ZSBhbHNvIGxpbmtlZCB0byBjb21tZXJjaWFsIHRlcm1zIHdpdGggcGVuYWx0aWVzIGFuZCBzbyBm b3J0aCwNCiAgICAgIGFuZCBzbyBhcmUgYWxzbyBub3QgZ29vZCB0b3BpY3MgZm9yIHN0YW5kYXJk aXphdGlvbi4NCg0KW21zXSBJIHdvbmRlciBpZiBpdCBjb3VsZCBtYWtlIHNlbnNlIHRvIGRpc3Rp bmd1aXNoIGJldHdlZW4gU0xBIGFuZCBTZXJ2aWNlIExldmVsIE9iamVjdGl2ZSAoU0xPKSBvciBT ZXJ2aWNlIExldmVsIFJlcXVpcmVtZW50IChTTFIpLiBXaGlsZSBJIGFncmVlIHRoYXQgaXQgaXMg ZGlmZmljdWx0IHRvIHN0YW5kYXJkaXplIGNvbW1lcmNpYWwgdGVybXMsIHRoaXMgSU1ITyBwYXJ0 bHkgY29udHJhZGljdHMgdGhlIHBvc2l0aW9uaW5nIG9mIHRoZSB0ZXJtICJzZXJ2aWNlIG1vZGVs IiBlYXJsaWVyIGluIHRoZSBkb2N1bWVudC4gTWF5YmUgdGhlIHNjb3BlIG9mIHRoZSBkZWZpbml0 aW9uIG9mICJzZXJ2aWNlIG1vZGVsIiBoYXMgdG8gYmUgbmFycm93ZWQgZG93bj8NCg0KDQoqKiog cGFnZSA5Og0KDQo2LjQuICBTdXBwb3J0aW5nIE11bHRpcGxlIFNlcnZpY2VzDQoNCiAgIE5ldHdv cmsgb3BlcmF0b3JzIHdpbGwsIGluIGdlbmVyYWwsIG9mZmVyIG1hbnkgZGlmZmVyZW50IHNlcnZp Y2VzIHRvDQogICB0aGVpciBjdXN0b21lcnMuICBFYWNoIHdvdWxkIG5vcm1hbGx5IGJlIHRoZSBz dWJqZWN0IG9mIGEgc2VwYXJhdGUNCiAgIHNlcnZpY2UgbW9kZWwuDQoNClttc10gVGhlIGFjdHVh bCBxdWVzdGlvbiBoZXJlIGlzIGlmIHRoZXJlIGNvdWxkIGJlIGNvbW11bmFsaXR5IGJldHdlZW4g c2VydmljZSBtb2RlbHMgZm9yIHNpbWlsYXIgc2VydmljZXMuIFRoYXQgcHJvYmxlbSBjYW5ub3Qg YmUgc29sdmVkIGJ5IHRoaXMgZG9jdW1lbnQgYnV0IHRoZSB0ZXh0IGNvdWxkIGUuZy4gZXhwbGFp biB0aGF0IGZvciBhIGN1c3RvbWVyIGl0IGNhbiBiZSBjb25mdXNpbmcgaWYgc2VwYXJhdGUgc2Vy dmljZSBtb2RlbHMgbW9kZWwgcmVsYXRlZCBjb25jZXB0cyBpbiBkaWZmZXJlbnQgd2F5cy4gDQoN Cg0KVGhhbmtzDQoNCk1pY2hhZWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogT1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBR aW4gV3UNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDUsIDIwMTYgMjowMiBQTQ0KVG86IG9wc2F3Z0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPUFNBV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAwLnR4dA0KDQpIaSwN CldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IEktRCB0aGF0IGRpc2N1c3NlcyB0aGUgc2NvcGUgYW5k IHB1cnBvc2Ugb2Ygc2VydmljZSBtb2RlbHMgd2l0aGluIHRoZSBJRVRGIGFuZCBkZXNjcmliZXMg aG93IGEgc2VydmljZSBtb2RlbCBjYW4gYmUgdXNlZCBieSBhIG5ldHdvcmsgb3BlcmF0b3IuDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1vcHNhd2ctc2VydmljZS1t b2RlbC1leHBsYWluZWQvDQoNCkluIGFkZGl0aW9uLCB0aGlzIGRyYWZ0IGNsYXJpZmllcyB0aGUg cm9sZSBhbmQgcG9zaXRpb24gb2Ygc2VydmljZSBtb2RlbCBpbiB0aGUgU0ROIGFyY2hpdGVjdHVy ZSBhbmQgQ2xlYXIgc2V2ZXJhbCBtaXNjb25jZXB0aW9uIG9uIHRoZSBzZXJ2aWNlIG1vZGVsLg0K DQpZb3VyIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNClJlZ2FyZHMhDQot UWluDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCuWPkemAgeaXtumXtDog MjAxNuW5tDfmnIg15pelIDE5OjU1DQrmlLbku7bkuro6IExpdXNodWNoZW5nIChXaWxsKTsgQWRy aWFuIEZhcnJlbDsgTGl1c2h1Y2hlbmcgKFdpbGwpOyBRaW4gV3UNCuS4u+mimDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWlu ZWQtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1LW9wc2F3Zy1zZXJ2 aWNlLW1vZGVsLWV4cGxhaW5lZC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgUWluIFd1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJ CWRyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZA0KUmV2aXNpb246CTAwDQpU aXRsZToJCVNlcnZpY2UgTW9kZWxzIEV4cGxhaW5lZA0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wNy0w NQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTINClVSTDogICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3Utb3BzYXdn LXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4 cGxhaW5lZC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAwDQoNCg0KQWJzdHJhY3Q6DQog ICBUaGUgSUVURiBoYXMgcHJvZHVjZWQgYSBjb25zaWRlcmFibGUgbnVtYmVyIG9mIGRhdGEgbW9k ZWxzIGluIHRoZQ0KICAgWUFORyBtb2RlbGxpbmcgbGFuZ3VhZ2UuICBUaGUgbWFqb3JpdHkgb2Yg dGhlc2UgYXJlIHVzZWQgdG8gbW9kZWwNCiAgIGRldmljZXMgYW5kIHRoZXkgYWxsb3cgYWNjZXNz IGZvciBjb25maWd1cmF0aW9uIGFuZCB0byByZWFkDQogICBvcGVyYXRpb25hbCBzdGF0dXMuDQoN CiAgIEEgc21hbGwgbnVtYmVyIG9mIFlBTkcgbW9kZWxzIGFyZSB1c2VkIHRvIG1vZGVsIHNlcnZp Y2VzIChmb3INCiAgIGV4YW1wbGUsIHRoZSBMYXllciBUaHJlZSBWaXJ0dWFsIFByaXZhdGUgTmV0 d29yayBTZXJ2aWNlIE1vZGVsDQogICBwcm9kdWNlZCBieSB0aGUgTDNTTSB3b3JraW5nIGdyb3Vw KS4NCg0KICAgVGhpcyBkb2N1bWVudCBicmllZmx5IHNldHMgb3V0IHRoZSBzY29wZSBvZiBhbmQg cHVycG9zZSBvZiBhbiBJRVRGDQogICBzZXJ2aWNlIG1vZGVsLCBhbmQgaXQgc2hvd3Mgd2hlcmUg YSBzZXJ2aWNlIG1vZGVsIG1pZ2h0IGZpdCBpbnRvIGENCiAgIFNvZnR3YXJlIERlZmluZWQgTmV0 d29ya2luZyBhcmNoaXRlY3R1cmUgb3IgZGVwbG95bWVudC4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FXR0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg== From nobody Thu Jul 7 07:08:09 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A091912D14A for ; Thu, 7 Jul 2016 07:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 y2P2sbBTwfiL for ; Thu, 7 Jul 2016 07:08:01 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0112.outbound.protection.outlook.com [104.47.0.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31B312B028 for ; Thu, 7 Jul 2016 07:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hVuVIaToNSJJEXswQwPAvTf01NN8u7kdqWAMmK5ZMSM=; b=BMKMlsme3IV1fBqh35Xipxua8GPmYZAX4CAuTZulSzXZzpINCcjDXP5hFrIaZNR2arIpY/T/0Dalu6PIalPlAQWllP2Zx5MMg3eOIa8hx+WCkl/uSf5FmzTYr4OB/2KBnL3WPyTeEC+KIrdKqEqjQHa9hI3n9MhTM0460EziU28= Received: from AMXPR07MB215.eurprd07.prod.outlook.com (10.242.73.17) by AMXPR07MB215.eurprd07.prod.outlook.com (10.242.73.17) with Microsoft SMTP Server (TLS) id 15.1.523.12; Thu, 7 Jul 2016 14:07:57 +0000 Received: from AMXPR07MB215.eurprd07.prod.outlook.com ([169.254.11.20]) by AMXPR07MB215.eurprd07.prod.outlook.com ([169.254.11.20]) with mapi id 15.01.0523.028; Thu, 7 Jul 2016 14:07:57 +0000 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "opsawg@ietf.org" Thread-Topic: Test Thread-Index: AdHYWPGtMp3QFh5sTOuEpFVDUhHFRw== Date: Thu, 7 Jul 2016 14:07:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mehmet.ersue@nokia.com; x-originating-ip: [62.159.77.186] x-ms-office365-filtering-correlation-id: ece26e95-8670-47f9-b3da-08d3a67018fa x-microsoft-exchange-diagnostics: 1; AMXPR07MB215; 6:VPcZT59SSii+KeT+cYI+bdIzZkLXMme9SWRhU5p3W4KnqazOUXmjQZ/PHzpmL/aEjIOUQsPv5yzr3gXxD1oRrtGveaVED/y1qk7p6cIsNaXAAHuOJu2ZNokAYBKDktfhVGQhm11XxUDfasRAFPqZZLTV+a/7/RXe5x4CVjkX8ccS4BK4c+w5exmep5KQO2SkneC1RqOcIBPKazpIP/8ZFeWuy5Nl8G0DG87brFnNADfGWCHXAjMpbjoi8KpFtcr9je9kBlGOgzs2yEvAI82ND0ZI41HcXPNYQovPClG8cNw=; 5:Gur8m4/ghpzdfENNtxXIoKxkzg8x5ExGj6Hy+EjR08wWmXuIwe/zKVBTQjnhVfMZMUvuAHZIgvr+wBwObm6Ikd1F4qv8zVtyqcMDIpM02nrD22HIdN6mzIdeLbrpUeZB/ugcY7znRFuZFI5gvDEl1Q==; 24:bEC42+VgN6HDHKmCFmWORfWN0VnLMyQvcG7QzeRvyeCkw3KsijjoGOigJAiadSQXWp4ggB6266BY53PE+UzSHsl9Ytsuo1ZtF/mr/rpj60Y=; 7:R5ANgohWZbFNoNXD/Xe+OmiUMDjqnRlAcGDbkiLFN4j4z/xD366h+VKiJgb4+/XehdovE6HY/C48CE8iIdCimP5tfSVIR4COTnZt7wzsa7RT+htLMm+g+Mr+phxIk4e7mCK8zNnJ0Y0YkWZxONN6llH9/sbsL3Ld51FypnCbcPq20FVGrLbrUNFMGPkO+3ZHdGFeEWA4QwjwiwApWAAk5wDv+vXPeG+AffMVjSKI/bi4VJic3PmPamV5mIoCNv0N x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB215; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMXPR07MB215; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB215; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(66066001)(3660700001)(5640700001)(586003)(54356999)(68736007)(50986999)(3280700002)(189998001)(2351001)(87936001)(3846002)(102836003)(450100001)(6116002)(76576001)(105586002)(106356001)(86362001)(229853001)(92566002)(11100500001)(2501003)(81156014)(81166006)(1730700003)(8676002)(2900100001)(101416001)(5002640100001)(97736004)(10400500002)(15975445007)(74316002)(305945005)(7696003)(5003600100003)(9686002)(7736002)(107886002)(122556002)(221733001)(8936002)(110136002)(2906002)(7846002)(33656002)(3480700004)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB215; H:AMXPR07MB215.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:tr; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AMXPR07MB215B13B779AEC9F84679019913B0AMXPR07MB215eurprd_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 14:07:57.4353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB215 Archived-At: Subject: [OPSAWG] Test X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:08:07 -0000 --_000_AMXPR07MB215B13B779AEC9F84679019913B0AMXPR07MB215eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mehmet --_000_AMXPR07MB215B13B779AEC9F84679019913B0AMXPR07MB215eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mehmet
 
 
 
 --_000_AMXPR07MB215B13B779AEC9F84679019913B0AMXPR07MB215eurprd_-- From nobody Thu Jul 7 09:08:54 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F57E12D5C0 for ; Thu, 7 Jul 2016 09:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.776 X-Spam-Level: X-Spam-Status: No, score=-3.776 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hQHa-nVuSVB2 for ; Thu, 7 Jul 2016 09:08:42 -0700 (PDT) Received: from COL004-OMC1S6.hotmail.com (col004-omc1s6.hotmail.com [65.55.34.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1507512D80E for ; Thu, 7 Jul 2016 09:08:42 -0700 (PDT) Received: from COL125-W27 ([65.55.34.9]) by COL004-OMC1S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 7 Jul 2016 09:08:41 -0700 X-TMN: [yuDrae8Sg6SipSSCn/C6fizWxSSDeUcO] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_9cf4c4c0-bb95-4a4b-9383-52b10feb8f81_" From: Hui Deng To: "opsawg@ietf.org" Date: Fri, 8 Jul 2016 00:08:40 +0800 Importance: Normal In-Reply-To: <20160707160325.23666.66407.idtracker@ietfa.amsl.com> References: <20160707160325.23666.66407.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jul 2016 16:08:41.0414 (UTC) FILETIME=[D4393660:01D1D869] Archived-At: Subject: [OPSAWG] FW: New Version Notification for draft-deng-opsawg-composed-vpn-sm-requirements-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 16:08:46 -0000 --_9cf4c4c0-bb95-4a4b-9383-52b10feb8f81_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBDaGFpcnMsDQpJZiBwb3NzaWJsZSwgY291bGQgSSBhc2sgZm9yIDEwIG1pbnV0ZXMgdG8g cHJlc2VudCB0aGlzIGRyYWZ0P3RoYW5rcyBhIGxvdCBmb3IgeW91ciBraW5kIGhlbHANCkJlc3Qg cmVnYXJkcywNCkRFTkcgSHVpDQoNCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ IFRvOiBkZW5naHVpMDJAaG90bWFpbC5jb207IGRlbmdodWkwMkBob3RtYWlsLmNvbQ0KPiBTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBv c2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDAudHh0DQo+IERhdGU6IFRodSwgNyBKdWwgMjAxNiAw OTowMzoyNSAtMDcwMA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kZW5n LW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLTAwLnR4dA0KPiBoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEh1aSBEZW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElF VEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12 cG4tc20tcmVxdWlyZW1lbnRzDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCVJlcXVpcmVtZW50 cyBvZiBDb21wb3NlZCBWUE4gU2VydmljZSBNb2RlbA0KPiBEb2N1bWVudCBkYXRlOgkyMDE2LTA3 LTA2DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNw0KPiBVUkw6 ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRl bmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDAudHh0DQo+IFN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZW5nLW9wc2F3 Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1y ZXF1aXJlbWVudHMtMDANCj4gDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhlIG9wZXJhdG9yIGZh Y2luZyBkYXRhIG1vZGVsIGlzIHZhbHVhYmxlIHRvIHJlZHVjZSB0aGUgb3BlcmF0aW9uDQo+ICAg IGFuZCBtYW5hZ2VtZW50LiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgcmVxdWlyZW1lbnRzIG9m IHRoZSBjb21wb3NlZA0KPiAgICBWUE4gc2VydmljZSBtb2RlbCBmb3Igb3BlcmF0b3JzIHRvIGRl cGxveSBQRS1iYXNlZCBWUE4gc2VydmljZXMNCj4gICAgYWNyb3NzIG11bHRpcGxlIGF1dG9ub21v dXMgc3lzdGVtcy4NCj4gDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+IA0KPiAN Cj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCj4gDQogCQkgCSAgIAkJICA= --_9cf4c4c0-bb95-4a4b-9383-52b10feb8f81_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+RGVhciBDaGFpcnMsPGRpdj48YnI+PC9kaXY+PGRpdj5J ZiBwb3NzaWJsZSwgY291bGQgSSBhc2sgZm9yIDEwIG1pbnV0ZXMgdG8gcHJlc2VudCB0aGlzIGRy YWZ0PzwvZGl2PjxkaXY+dGhhbmtzIGEgbG90IGZvciB5b3VyIGtpbmQgaGVscDwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+REVO RyBIdWk8YnI+PGJyPjxkaXY+Jmd0OyBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8YnI+ Jmd0OyBUbzogZGVuZ2h1aTAyQGhvdG1haWwuY29tOyBkZW5naHVpMDJAaG90bWFpbC5jb208YnI+ Jmd0OyBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRlbmctb3Bz YXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDAudHh0PGJyPiZndDsgRGF0ZTogVGh1 LCA3IEp1bCAyMDE2IDA5OjAzOjI1IC0wNzAwPGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1 aXJlbWVudHMtMDAudHh0PGJyPiZndDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBIdWkgRGVuZyBhbmQgcG9zdGVkIHRvIHRoZTxicj4mZ3Q7IElFVEYgcmVwb3NpdG9yeS48YnI+ Jmd0OyA8YnI+Jmd0OyBOYW1lOgkJZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJl cXVpcmVtZW50czxicj4mZ3Q7IFJldmlzaW9uOgkwMDxicj4mZ3Q7IFRpdGxlOgkJUmVxdWlyZW1l bnRzIG9mIENvbXBvc2VkIFZQTiBTZXJ2aWNlIE1vZGVsPGJyPiZndDsgRG9jdW1lbnQgZGF0ZToJ MjAxNi0wNy0wNjxicj4mZ3Q7IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPiZndDsg UGFnZXM6CQk3PGJyPiZndDsgVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1l bnRzLTAwLnR4dDxicj4mZ3Q7IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRz Lzxicj4mZ3Q7IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMDxicj4mZ3Q7IDxi cj4mZ3Q7IDxicj4mZ3Q7IEFic3RyYWN0Ojxicj4mZ3Q7ICAgIFRoZSBvcGVyYXRvciBmYWNpbmcg ZGF0YSBtb2RlbCBpcyB2YWx1YWJsZSB0byByZWR1Y2UgdGhlIG9wZXJhdGlvbjxicj4mZ3Q7ICAg IGFuZCBtYW5hZ2VtZW50LiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgcmVxdWlyZW1lbnRzIG9m IHRoZSBjb21wb3NlZDxicj4mZ3Q7ICAgIFZQTiBzZXJ2aWNlIG1vZGVsIGZvciBvcGVyYXRvcnMg dG8gZGVwbG95IFBFLWJhc2VkIFZQTiBzZXJ2aWNlczxicj4mZ3Q7ICAgIGFjcm9zcyBtdWx0aXBs ZSBhdXRvbm9tb3VzIHN5c3RlbXMuPGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IFBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb248YnI+Jmd0OyB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxicj4mZ3Q7IDxicj4mZ3Q7IFRoZSBJRVRGIFNlY3Jl dGFyaWF0PGJyPiZndDsgPGJyPjwvZGl2PjwvZGl2PiAJCSAJICAgCQkgIDwvZGl2PjwvYm9keT4N CjwvaHRtbD4= --_9cf4c4c0-bb95-4a4b-9383-52b10feb8f81_-- From nobody Thu Jul 7 19:29:29 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA18112D775 for ; Thu, 7 Jul 2016 19:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GyU_Ym4Di59b for ; Thu, 7 Jul 2016 19:29: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 0762F12D645 for ; Thu, 7 Jul 2016 19:29:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSF31460; Fri, 08 Jul 2016 02:29:12 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 8 Jul 2016 03:29:11 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 8 Jul 2016 10:29:07 +0800 From: Zhoutianran To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" Thread-Topic: a new version of the automatic attachment drafts Thread-Index: AdHSL7Tm7cjwLHTRRWWWYvwrin0y4AGjPzDA Date: Fri, 8 Jul 2016 02:29:07 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA75220B90@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA75220B90@AZ-FFEXMB04.global.avaya.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183BFADBDNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.577F0FF9.0006, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e26fbe729c3486dbe037792d5a0b308b Archived-At: Subject: Re: [OPSAWG] a new version of the automatic attachment drafts X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 02:29:23 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2183BFADBDNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, I am reading the framework draft. Here are some initial comments: 1. In figure 1, the AA controller has connection to both AA client and AA s= erver. I think it's not practical in many cases. AAC and AAS, IMHO, are usu= ally in different administrative domains. For example, AAC installed on a C= E, and the AAS installed on the PE. Usually, CE and PE are controlled by di= fferent domain controllers. It's hard to deploy a super controller for CE a= nd PE. Another example is, as you showed, the IoT. It's not practical to le= t all the end devices connect to the AA controller. Here, what scenario did you consider for this framework? The suggestion, if I am right, is to have the AA controller only connect to= the AAS. AAC can pull additional information from the path: AA controller-= >AAS->AAC. 2. If both AAC and AAS connect to the AA controller, that means the AAC and= AAS can be synchronized and configured by the management plane. So I guess= some of the control plane function between AAC and AAS can be reduced. Regards, Tianran From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (= Dan) Sent: Thursday, June 30, 2016 1:58 AM To: opsawg@ietf.org Subject: [OPSAWG] a new version of the automatic attachment drafts Hi, I have submitted two new Internet-Draft that describe the automatic attachm= ent functionality: https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-framewo= rk/ https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-lldp/ Principal changes: - addressing the comments received at IETF 95 we split the generic protoco= l-independent framework that describes the discovery and service mapping me= chanism in a separate I-D - we clarified terminology and re-drawn the principal building blocks - we connected the discovery and authentication mechanism with the MUD prop= osal Questions and comments are welcome. Thanks and Regards, Dan --_000_BBA82579FD347748BEADC4C445EA0F2183BFADBDNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan,

 

I am reading the framework dr= aft. Here are some initial comments:

 

1. In figure 1, the AA contro= ller has connection to both AA client and AA server. I think it’s not= practical in many cases. AAC and AAS, IMHO, are usually in different administrative domains. For example, AAC installed on a CE, a= nd the AAS installed on the PE. Usually, CE and PE are controlled by differ= ent domain controllers. It’s hard to deploy a super controller for CE= and PE. Another example is, as you showed, the IoT. It’s not practical to let all the end devices connect to th= e AA controller.

Here, what scenario did you c= onsider for this framework?

The suggestion, if I am right= , is to have the AA controller only connect to the AAS. AAC can pull additi= onal information from the path: AA controller->AAS->AAC.

 

2. If both AAC and AAS connec= t to the AA controller, that means the AAC and AAS can be synchronized and = configured by the management plane. So I guess some of the control plane function between AAC and AAS can be reduced.

 

 

Regards,

Tianran

 

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 30, 2016 1:58 AM
To: opsawg@ietf.org
Subject: [OPSAWG] a new version of the automatic attachment drafts

 

Hi,

 

I have submitted two new Intern= et-Draft that describe the automatic attachment functionality:

 

https://datatra= cker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-framework/

https://datatracker.= ietf.org/doc/draft-romascanu-opsawg-auto-attach-lldp/=

 

Principal changes: <= /span>

- addressing the comments re= ceived at IETF 95  we split the generic protocol-independent framework= that describes the discovery and service mapping mechanism in a separate I= -D

- we clarified terminology a= nd re-drawn the principal building blocks

- we connected the discovery an= d authentication mechanism with the MUD proposal

 

Questions and comments are welc= ome.

 

Thanks and Regards,<= /span>

 

Dan

 

--_000_BBA82579FD347748BEADC4C445EA0F2183BFADBDNKGEML515MBXchi_-- From nobody Fri Jul 8 04:06:23 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5DD12B02D; Fri, 8 Jul 2016 04:06:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708110616.32109.16820.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 04:06:16 -0700 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 11:06:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group of the IETF. Title : The TACACS+ Protocol Authors : Thorsten Dahm Andrej Ota Douglas C. Medway Gash David Carrel Lol Grant Filename : draft-ietf-opsawg-tacacs-04.txt Pages : 36 Date : 2016-07-08 Abstract: TACACS+ provides Device Administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document describes the protocol that is used by TACACS+. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 12:36:18 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C9F12D90F; Fri, 8 Jul 2016 12:36:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708193609.32164.64092.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 12:36:09 -0700 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-08.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:36:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group of the IETF. Title : Alternate Tunnel Encapsulation for Data Frames in CAPWAP Authors : Rong Zhang Zhen Cao Hui Deng Rajesh S. Pazhyannur Sri Gundavelli Li Xue Jianjie You Filename : draft-ietf-opsawg-capwap-alt-tunnel-08.txt Pages : 24 Date : 2016-07-08 Abstract: Control and Provisioning of Wireless Access Points (CAPWAP) defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments encapsulating data frames to an entity other than the AC (for example to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines extension to CAPWAP protocol for supporting this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery or join process and AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 17:10:54 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380E112B007 for ; Fri, 8 Jul 2016 17:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 csAIZR99-RpX for ; Fri, 8 Jul 2016 17:10:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC5E128B44 for ; Fri, 8 Jul 2016 17:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1999; q=dns/txt; s=iport; t=1468023051; x=1469232651; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PRW+Zgkl/7tAEUH3Uk1SPPdmos6uXE1K7/y115DK5zA=; b=JeLStqZdlaOSReI/A32v+wvKYtDix19YpDILolrVm6L/pRIEiZo4UWfF cqPiUhSSv4QJgLhXBfsr+CYMXIL5no56aKeP81qRK5or+PwwIBcP9Y5js cMF21ENW3cJRudd+6vD/CfJVUX6tdKRkdCUM4fTlu1sfs3q5DFwhM3VIl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzAgA4QIBX/4UNJK1cgz5WfAa5EYF6J?= =?us-ascii?q?IV0AoEoOBQBAQEBAQEBZRwLhE0BBTotEAIQAgEINhAyGwEGAwIEDgUbiBUOvhM?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEcinSKHAWOBIsQAYYLiEOBak6ECohqkA0BH?= =?us-ascii?q?jaDcW6IM38BAQE?= X-IronPort-AV: E=Sophos;i="5.28,332,1464652800"; d="scan'208";a="122122337" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2016 00:10:50 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u690Aok0019558 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Jul 2016 00:10:50 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 19:10:49 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 19:10:49 -0500 From: "Byju Pularikkal (byjupg)" To: "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-pularikkal-opsawg-wifi-calling-01.txt Thread-Index: AQHR2KTfRw2J0fQda06xJJc6KAbTuKAPGd0A Date: Sat, 9 Jul 2016 00:10:49 +0000 Message-ID: References: <20160707231055.18907.32759.idtracker@ietfa.amsl.com> In-Reply-To: <20160707231055.18907.32759.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.61.58] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Samy Touati , "Mark Grayson \(mgrayson\)" , Tommy Pauly Subject: [OPSAWG] FW: New Version Notification for draft-pularikkal-opsawg-wifi-calling-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 00:10:53 -0000 Hello Everyone, This is an updated version of the Wi-Fi Calling deployment considerartions draft. Appreciate your review and feedback on the same. Regards Byju On 7/7/16, 4:10 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-pularikkal-opsawg-wifi-calling-01.txt >has been successfully submitted by Byju Pularikkal and posted to the >IETF repository. > >Name: draft-pularikkal-opsawg-wifi-calling >Revision: 01 >Title: Carrier Wi-Fi Calling Deployment Considerations >Document date: 2016-07-07 >Group: Individual Submission >Pages: 26 >URL: =20 >https://www.ietf.org/internet-drafts/draft-pularikkal-opsawg-wifi-calling- >01.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-pularikkal-opsawg-wifi-calling/ >Htmlized: =20 >https://tools.ietf.org/html/draft-pularikkal-opsawg-wifi-calling-01 >Diff: =20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-pularikkal-opsawg-wifi-calling-0= 1 > >Abstract: > Carrier Wi-Fi Calling is a solution that allows mobile operators to > seamlessly offload mobile voice signaling and bearer traffic onto Wi- > Fi access networks, which may or may not be managed by the mobile > operators. Mobile data offload onto Wi-Fi access networks has > already become very common, as Wi-Fi access has become more > ubiquitous. However, the offload of mobile voice traffic onto Wi-Fi > networks has become prevalent only in recent years. This was > primarily driven by the native Wi-Fi Calling client support > introduced by device vendors. The objective of this document is to > provide a high level deployment reference to Mobile Operators and Wi- > Fi Operators on Carrier Wi-Fi Calling. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Sun Jul 10 23:52:01 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414EE12B018 for ; Sun, 10 Jul 2016 23:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 oxbfW7WrtqE0 for ; Sun, 10 Jul 2016 23:51:56 -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 CA24012B00A for ; Sun, 10 Jul 2016 23:51:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSJ08049; Mon, 11 Jul 2016 06:51:52 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 11 Jul 2016 07:51:50 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.179]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 11 Jul 2016 14:51:43 +0800 From: Qin Wu To: "Scharf, Michael (Nokia - DE)" , "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt Thread-Index: AQHR1rQaqatqqP7izEmdMDgbK+d1g6AJuuFAgAMw/BCABdqxcA== Date: Mon, 11 Jul 2016 06:51:42 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48906FBF@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48906FBF@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.112] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.57834209.0059, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.179, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cb493757c1f3ae7cb0eff59b138acc36 Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 06:52:00 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBTY2hhcmYsIE1pY2hhZWwgKE5va2lh IC0gREUpIFttYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tXSANCuWPkemAgeaXtumXtDog MjAxNuW5tDfmnIg35pelIDIxOjQ3DQrmlLbku7bkuro6IFFpbiBXdTsgb3BzYXdnQGlldGYub3Jn DQrkuLvpopg6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW9wc2F3 Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMC50eHQNCg0KSGkgYWxsLA0KDQpJIGhhdmUgcXVp Y2tseSBzY2FubmVkIHRoaXMgZG9jdW1lbnQuIFNvbWUgaW5pdGlhbCBjb21tZW50cyBbbXNdOg0K DQoqKiogUGFnZSAzOg0KDQogICBTZXJ2aWNlIE1vZGVsOiAgQSBzZXJ2aWNlIG1vZGVsIGlzIGEg c3BlY2lmaWMgdHlwZSBvZiBkYXRhIG1vZGVsLiAgSXQNCiAgICAgIGRlc2NyaWJlcyBhIHNlcnZp Y2UgYW5kIGFsbCBvZiB0aGUgcGFyYW1ldGVycyBvZiB0aGUgc2VydmljZSBpbiBhDQogICAgICBw b3J0YWJsZSwgb3BlcmF0b3ItaW5kZXBlbmRlbnQgd2F5LiAgSXQgY2FuIGJlIHVzZWQgYnkgYSBo dW1hbiBvcg0KICAgICAgYnkgc29mdHdhcmUgdG8gY29uZmlndXJlIG9yIHJlcXVlc3QgYSBzZXJ2 aWNlIGFuZCBtYXkgZXF1YWxseSBiZQ0KICAgICAgY29uc3VtZWQgYnkgYSBodW1hbiBvciBieSBh IHNvZnR3YXJlIGNvbXBvbmVudC4NCg0KW21zXSBJIHdvdWxkIHN1Z2dlc3QgYSBtb3JlIGNhcmVm dWwgd29yZGluZyByZWdhcmRpbmcgdGhlIGNvbXBsZXRlbmVzcyBvZiB0aGUgbW9kZWwsIGUuZy4s ICJJdCBhaW1zIGF0IGRlc2NyaWJpbmcgYSBzZXJ2aWNlIGFuZCBhbGwgb2YgdGhlIHBhcmFtZXRl cnMgb2YgdGhlIHNlcnZpY2UuLi4iLiBBcyBkaXNjdXNzZWQgaW4gTDNTTSBpbiB0aGUgcGFzdCwg Zm9yIGNlcnRhaW4gc2VydmljZXMgKGUuZy4sIGZpcmV3YWxscywgRG9TIHByZXZlbnRpb24sIC4u LikgdGhlIHNlcnZpY2UgbW9kZWwgd291bGQgaGF2ZSB0byBiZSBleHRlbmRlZCAvIGF1Z21lbnRl ZC4gQWxzbyBub3RlIHRoYXQgdGhlIHN0YXRlbWVudCAiYWxsIHBhcmFtZXRlcnMiIGNvbnRyYWRp Y3RzIHRoZSBzdGF0ZW1lbnQgb24gU0xBcyBsYXRlciBpbiB0aGUgdGV4dC4NCg0KW1Fpbl0gV2hh dCB0aGUgc2VydmljZSBpcyBoYXMgYmVlbiB3ZWxsIGRlZmluZWQgYW5kIGNsYXJpZmllZCBiZWZv cmUgc2VydmljZSBtb2RlbCBkZWZpbml0aW9uIGluIHRoZSBzZWN0aW9uIDIuDQpUaGF0IGlzIHRv IHNheSwgRmlyZXdhbGwgYW5kIERvUyBwcmV2ZW50aW9uIGFyZSBqdXN0IGFkZGl0aW9uYWwgZnVu Y3Rpb25hbGl0aWVzIHRoYXQgYXJlIHVzZWQgdG8gZW5oYW5jZSB0aGUgYmFzaWMgc2VydmljZSB3 ZSBkZWZpbmVkIGluIHRoZSBkb2N1bWVudC4NCkZvciB3aGF0IHRoZSBzZXJ2aWNlIGlzIG5vdCBp cyBmdXJ0aGVyIGNsYXJpZmllZCBpbiB0aGUgc2VjdGlvbiA1LCB0aGUgZmlyc3QgYnVsbGV0Lg0K DQpJbiBhZGRpdGlvbiwgd2UgZG9uJ3QgdGFrZSBTTEEgZmluZSBncmFudWxhcml0eSBkZXRhaWxz IGNvbWJpbmluZyBjb21tZXJjaWFsIHRlcm1zIGFzIHNlcnZpY2UgcGFyYW1ldGVycywgc28gSSBk b24ndCBzZWUgdGhlcmUgaXMgaW5jb25zaXN0ZW5jeSBpc3N1ZSwgZm9yIHNvbWUgbWlzY29uY2Vw dGlvbiBvbiB0aGUgc2VydmljZSBtb2RlbA0KVW5kZXJzdGFuZGluZyBpcyBjbGFyaWZpZWQgaW4g dGhlIGRpZmZlcmVudCBzZWN0aW9uLCB0aGlzIGlzIGludGVudGlvbmFsLg0KDQpbbXNdIEkgZmlu ZCB0aGUgd29yZGluZyAiaXQgY2FuIGJlIHVzZWQgYnkgYSBodW1hbi4uLiIgY29uZnVzaW5nLiBJ cyB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgdXNlciB3b3VsZCBtYW51YWxseSB0eXBlIGluIGEgc2Vy dmljZSByZXF1ZXN0IHJlc3VsdGluZyBpbiBhIHZhbGlkIGRhdGEgbW9kZWwsIGUuZy4sIGJ5IG1h bnVhbGx5IHR5cGluZyBpbiBORVRDT05GIGNvbW1hbmRzPyBJIHdvdWxkIHJhdGhlciB3cml0ZSBz b21ldGhpbmcgbGlrZSAidGhlIHBhcmFtZXRlcnMgY2FuIGJlIGVudGVyZWQgYnkgc29mdHdhcmUg b3IgYWxzbyBtYW51YWxseSBieSBhIGh1bWFuLi4uIg0KDQpbUWluXTogd2hhdCB3ZSB0cnkgdG8g Y29udmV5IGhlcmUgaXMgSHVtYW4gY2FuIHJlbHkgb24gQ0xJLHNjcmlwdCBvciBvdGhlciBodW1h biByZWFkYWJsZSBsYW5ndWFnZSB0byBkZWZpbmUgYSBzZXJ2aWNlLCByZXF1ZXN0IHRoZSBzZXJ2 aWNlLCBidXQgc3VjaCBwYXJhbWV0ZXIgd2lsbCBub3QgZGlyZWN0bHkgaW1wbGVtZW50ZWQgYnkg bmV0d29yayBlbGVtZW50Lg0KDQoqKiogUGFnZSAzOg0KDQogICBUaGUgZW5jb2RpbmcgYW5kIGNv bW11bmljYXRpb24gcHJvdG9jb2wgdXNlZCB0byBleGNoYW5nZSBhIHNlcnZpY2UNCiAgIG1vZGVs IGJldHdlZW4gY3VzdG9tZXIgYW5kIG5ldHdvcmsgb3BlcmF0b3IgYXJlIGRlcGxveW1lbnQtIGFu ZA0KICAgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMuICBUaGUgSUVURiByZWNvbW1lbmRzIHRoZSB1 c2Ugb2YgdGhlIE5FVENPTkYNCiAgIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgW1JGQzQ3NDFdIHdp dGggZGF0YSBlbmNvZGVkIGluIFhNTCBvciBKU09OIGZvcg0KICAgaW50ZXJhY3Rpb25zICJvbiB0 aGUgd2lyZSIgYmV0d2VlbiBzb2Z0d2FyZSBjb21wb25lbnRzLiAgSG93ZXZlciwgY28tDQogICBs b2NhdGVkIHNvZnR3YXJlIGNvbXBvbmVudHMgbWlnaHQgdXNlIGFuIEFQSSwgd2hpbGUgc3lzdGVt cyB3aXRoIG1vcmUNCiAgIGRpcmVjdCBodWFuIGludGVyYWN0aW9ucyBtaWdodCB1c2Ugd2ViIHBh Z2VzIG9yIGV2ZW4gcGFwZXIgZm9ybXMuDQoNClttc10gSSBhbSBub3Qgc3VyZSBpZiB0aGUgSUVU RiBzaG91bGQgc3VnZ2VzdCB0aGUgdXNlIG9mIE5FVENPTkYgb24gdGhlIG5vcnRoYm91bmQgaW50 ZXJmYWNlIG9mIGEgInNlcnZpY2Ugb3JjaGVzdHJhdG9yIiwgd2hpY2ggc2VlbXMgdG8gYmUgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIEFyZSB0aGVyZSBwb2ludGVycyB0byBydW5uaW5nIGNv ZGUgdGhhdCBhY3R1YWxseSBkbyB0aGF0PyBJIHdvdWxkIHJhdGhlciBwcmVmZXIgYSB3b3JkaW5n IHN1Y2ggYXMgIlRoZSBJRVRGIGhhcyBzdGFuZGFyZGl6ZWQgTkVUQ09ORiBhbmQgUkVTVENPTkYg Zm9yIGludGVyYWN0aW9ucyAib24gdGhlIHdpcmUiIGJldHdlZW4gc29mdHdhcmUgY29tcG9uZW50 cyIuDQoNCltRaW5dOiBZb3UgYXJlIHJpZ2h0LCBJIHRoaW5rIFJFU0NPTkYgaXMgcmVjb21tZW5k ZWQgb24gdGhlIG5vcnRoYm91bmQgaW50ZXJmYWNlIG9mIGEgc2VydmljZSBvcmNoZXN0cmF0b3Is IHlvdXIgcHJvcG9zZWQgY2hhbmdlIGxvb2tzIGdvb2QuIFRoYW5rcy4NCg0KKioqIFBhZ2UgNzoN Cg0KICAgbyAgVGhlIG5ldHdvcmsgb3BlcmF0b3IgbWF5IHVzZSBmdXJ0aGVyIGRhdGEgbW9kZWxz IHRoYXQgaGVscCB0bw0KICAgICAgZGVzY3JpYmUgaG93IHRoZSBzZXJ2aWNlIGlzIHJlYWxpemVk IGluIHRoZSBuZXR3b3JrLiAgVGhlc2UgbW9kZWxzDQogICAgICBtaWdodCBiZSB1c2VkIG9uIHRo ZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgU2VydmljZSBPcmNoZXN0cmF0b3INCiAgICAgIGFuZCB0 aGUgTmV0d29yayBPcmNoZXN0cmF0b3IgYXMgc2hvd24gaW4gRmlndXJlIDMgYW5kIG1pZ2h0DQog ICAgICBpbmNsdWRlIG1hbnkgb2YgdGhlIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiBpbiB0aGUgc2Vy dmljZSBtb2RlbA0KICAgICAgYWxvbmdzaWRlIHByb3RvY29sIHBhcmFtZXRlcnMgYW5kIGRldmlj ZSBjb25maWd1cmF0aW4gaW5mb3JtYXRpb24uDQogICAgICBJdCBpcyBpbXBvcnRhbnQgdGhhdCB0 aGUgU2VydmljZSBPcmNoZXN0cmF0b3Igc2hvdWxkIGJlIGFibGUgdG8NCiAgICAgIG1hcCBmcm9t IGEgc2VydmljZSBtb2RlbCB0byB0aGVzZSBkYXRhIG1vZGVscywgYnV0IHRoZXkgYXJlIG5vdA0K ICAgICAgdGhlIHNhbWUgdGhpbmdzLg0KDQpbbXNdIFdoeSBpcyBpdCBub3QgcG9zc2libGUgdGhh dCB0aGUgZGF0YSBtb2RlbHMgYXJlIHRoZSBzYW1lPyBJbiBGaWd1cmUgMywgdGhlICJzZXJ2aWNl IG9yY2hlc3RyYXRvciIgaXMgYWN0dWFsbHkgYSAiY2xpZW50IiAocmVhZCB0aGlzIGFzICJjdXN0 b21lciIpIG9mIHRoZSAibmV0d29yayBvcmNoZXN0cmF0b3JzIi4gSW5zaWRlIGFuIG9wZXJhdG9y LCB0aGUgInNlcnZpY2Ugb3JjaGVzdHJhdG9yIiBjb3VsZCBiZSBvcGVyYXRlZCBieSBhIGRpZmZl cmVudCBvcmdhbml6YXRpb24gdGhhbiB0aGUgIm5ldHdvcmsgb3JjaGVzdHJhdG9yIiwgaS5lLiwg dGhlcmUgb3VsZCBldmVuIGJlIGEgYnVzaW5lc3MgcmVsYXRpb25zaGlwLiBJbiBnZW5lcmFsLCBh cmNoaXRlY3R1cmVzIGNhbiBiZSByZWN1cnNpdmUuIEkgdGhpbmsgdGhpcyBzdGF0ZW1lbnQgcmVx dWlyZXMgZnVydGhlciBleHBsYW5hdGlvbiBvciByZXdvcmRpbmcuDQoNCltRaW5dOiBUaGUgY29u Y2VwdCB0byBzcGxpdCBPcmNoZXN0cmF0b3IgaW50byBzZXJ2aWNlIG9yY2hlc3RyYXRvciBhbmQg bmV0d29yayBvcmNoZXN0cmF0b3IsIGlzIHRoZSBzZXJ2aWNlIG9yY2hlc3RyYXRvciBpcyBuZXR3 b3JrIGFnbm9zdGljIHdoaWxlIG5ldHdvcmsgb3JjaGVzdHJhdG9yIGlzIG5ldHdvcmsgYXdhcmUu DQpTZXJ2aWNlIG1vZGVsIGNvbnN1bWVkIGJ5IHRoZSBzZXJ2aWNlIG9yY2hlc3RyYXRvciBjb3Vs ZCBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgZGF0YSBtb2RlbCBjb25zdW1lZCBieSBuZXR3b3JrIG9y Y2hlc3RyYXRvciBzaW5jZSBuZXR3b3JrIG9yY2hlc3RyYXRvciBuZWVkIHRvIGRlY2lkZSB3aGF0 IG5ldHdvcmsgZGV2aWNlIGlzIHNlbGVjdGVkLCB3aGljaCBwcm90b2NvbCBpcyBlbmFibGVkLCB3 aGljaCB0ZWNobm9sb2d5IGlzIHVzZWQsIHdoaWNoIG5ldHdvcmsgaW50ZXJmYWNlIG9yIHBvcnQg aXMgYXNzaWduZWQuIFRoZSBzZXJ2aWNlIG9yY2hlc3RyYXRvciBkb2Vzbid0IG5lZWQgdG8gY2Fy ZSBhYm91dCB0aGUgdW5kZXJseWluZyB0ZWNobm9sb2d5IG9yIHdoYXQgcHJvdG9jb2wgaXMgYXZh aWxhYmxlLg0KDQoqKiogUGFnZSA3Og0KDQogICBvICBTZXJ2aWNlIExldmVsIEFncmVlbWVudHMg KFNMQXMpIGhhdmUgYSBoaWdoIGRlZ3JlZSBvZiBvdmVybGFwIHdpdGgNCiAgICAgIHRoZSBkZWZp bml0aW9uIG9mIHNldmljZXMgcHJlc2VudCBpbiBzZXJ2aWNlIG1vZGVscy4gIFJlcXVlc3RzIGZv cg0KICAgICAgc3BlY2lmaWMgYmFuZHdpZHRoLCBmb3IgZXhhbXBsZSwgbWlnaHQgYmUgcHJlc2Vu dCBpbiBhIHNlcnZpY2UNCiAgICAgIG1vZGVsLCBhbmQgYWdyZWVtZW50IHRvIGRlbGl2ZXIgYSBz ZXJ2aWNlIGlzIGEgY29tbWl0bWVudCB0byB0aGUNCiAgICAgIGRlc2NyaXB0aW9uIG9mIHRoZSBz ZXJ2aWNlIGluIHRoZSBzZXJ2aWNlIG1vZGVsLCBob3dldmVyLCBTTEFzDQogICAgICB0eXBpY2Fs bHkgaW5jbHVkZSBhIG51bWJlciBvZiBmaW5lLWdyYWluZWQgZGV0YWlscyBhYm91dCBob3cNCiAg ICAgIHNlcnZpY2VzIGFyZSBhbGxvd2VkIHRvIHZhcnksIGJ5IGhvdyBtdWNoLCBhbmQgaG93IG9m dGVuLiAgU0xBcw0KICAgICAgYXJlIGFsc28gbGlua2VkIHRvIGNvbW1lcmNpYWwgdGVybXMgd2l0 aCBwZW5hbHRpZXMgYW5kIHNvIGZvcnRoLA0KICAgICAgYW5kIHNvIGFyZSBhbHNvIG5vdCBnb29k IHRvcGljcyBmb3Igc3RhbmRhcmRpemF0aW9uLg0KDQpbbXNdIEkgd29uZGVyIGlmIGl0IGNvdWxk IG1ha2Ugc2Vuc2UgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBTTEEgYW5kIFNlcnZpY2UgTGV2ZWwg T2JqZWN0aXZlIChTTE8pIG9yIFNlcnZpY2UgTGV2ZWwgUmVxdWlyZW1lbnQgKFNMUikuIFdoaWxl IEkgYWdyZWUgdGhhdCBpdCBpcyBkaWZmaWN1bHQgdG8gc3RhbmRhcmRpemUgY29tbWVyY2lhbCB0 ZXJtcywgdGhpcyBJTUhPIHBhcnRseSBjb250cmFkaWN0cyB0aGUgcG9zaXRpb25pbmcgb2YgdGhl IHRlcm0gInNlcnZpY2UgbW9kZWwiIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50LiBNYXliZSB0aGUg c2NvcGUgb2YgdGhlIGRlZmluaXRpb24gb2YgInNlcnZpY2UgbW9kZWwiIGhhcyB0byBiZSBuYXJy b3dlZCBkb3duPw0KDQpbUWluXTogV2UgaGF2ZSBjbGFyaWZpZWQgd2hhdCB0aGUgc2VydmljZSBp cyBpbiB0aGUgc2VjdGlvbiAyIGFuZCBPdXIgc2VydmljZSBtb2RlbCBkZWZpbml0aW9uIGFsaWdu cyB3aXRoIHNlcnZpY2UgZGVmaW5pdGlvbi4gWWVzLCB3ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIFNM QSBmcm9tIFNlcnZpY2UgTGV2ZWwgT2JqZWN0aXZlL1JlcXVpcmVtZW50LCBidXQgbm90IG5lY2Vz c2FyeSBpbnRyb2R1Y2UgYW5vdGhlciBuZXcgdGVybS4gV2UgaGF2ZSBjbGFyaWZpZWQgdGhlaXIg ZGlmZmVyZW5jZSBpbiB0aGUgdGV4dCB5b3UgcXVvdGVkLg0KDQoqKiogcGFnZSA5Og0KDQo2LjQu ICBTdXBwb3J0aW5nIE11bHRpcGxlIFNlcnZpY2VzDQoNCiAgIE5ldHdvcmsgb3BlcmF0b3JzIHdp bGwsIGluIGdlbmVyYWwsIG9mZmVyIG1hbnkgZGlmZmVyZW50IHNlcnZpY2VzIHRvDQogICB0aGVp ciBjdXN0b21lcnMuICBFYWNoIHdvdWxkIG5vcm1hbGx5IGJlIHRoZSBzdWJqZWN0IG9mIGEgc2Vw YXJhdGUNCiAgIHNlcnZpY2UgbW9kZWwuDQoNClttc10gVGhlIGFjdHVhbCBxdWVzdGlvbiBoZXJl IGlzIGlmIHRoZXJlIGNvdWxkIGJlIGNvbW11bmFsaXR5IGJldHdlZW4gc2VydmljZSBtb2RlbHMg Zm9yIHNpbWlsYXIgc2VydmljZXMuIFRoYXQgcHJvYmxlbSBjYW5ub3QgYmUgc29sdmVkIGJ5IHRo aXMgZG9jdW1lbnQgYnV0IHRoZSB0ZXh0IGNvdWxkIGUuZy4gZXhwbGFpbiB0aGF0IGZvciBhIGN1 c3RvbWVyIGl0IGNhbiBiZSBjb25mdXNpbmcgaWYgc2VwYXJhdGUgc2VydmljZSBtb2RlbHMgbW9k ZWwgcmVsYXRlZCBjb25jZXB0cyBpbiBkaWZmZXJlbnQgd2F5cy4gDQoNCltRaW5dOiBUaGF0IGlz IGEgZ29vZCBxdWVzdGlvbiwgSSBob3BlIHNvbWUgYnVpbGRpbmcgYmxvY2tzIHNwZWNpZmllZCBi eSBvbmUgc2VydmljZSBtb2RlbCBjYW4gYmUgcmV1c2VkIGluIGFub3RoZXIgc2VydmljZSBtb2Rl bC4NClVuZm9ydHVuYXRlbHkgd2UgZG9uJ3QgaGF2ZSB0b28gbWFueSBZQU5HIG1vZGVscyB0aGF0 IGFyZSB1c2VkIHRvIG1vZGVsIHNlcnZpY2UgaW4gdGhlIElFVEYuIFdlIGNvdWxkIGNvdmVyIHRo aXMgaW4gdGhlIG5leHQgdmVyc2lvbiBpZiBtb3JlIHN1Y2ggc2VydmljZSBtb2RlbHMgYXJlIG5l ZWRlZC4NCg0KVGhhbmtzDQoNCk1pY2hhZWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogT1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBRaW4gV3UNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDUsIDIwMTYgMjowMiBQTQ0KVG86IG9w c2F3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPUFNBV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAwLnR4dA0K DQpIaSwNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IEktRCB0aGF0IGRpc2N1c3NlcyB0aGUgc2Nv cGUgYW5kIHB1cnBvc2Ugb2Ygc2VydmljZSBtb2RlbHMgd2l0aGluIHRoZSBJRVRGIGFuZCBkZXNj cmliZXMgaG93IGEgc2VydmljZSBtb2RlbCBjYW4gYmUgdXNlZCBieSBhIG5ldHdvcmsgb3BlcmF0 b3IuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1vcHNhd2ctc2Vy dmljZS1tb2RlbC1leHBsYWluZWQvDQoNCkluIGFkZGl0aW9uLCB0aGlzIGRyYWZ0IGNsYXJpZmll cyB0aGUgcm9sZSBhbmQgcG9zaXRpb24gb2Ygc2VydmljZSBtb2RlbCBpbiB0aGUgU0ROIGFyY2hp dGVjdHVyZSBhbmQgQ2xlYXIgc2V2ZXJhbCBtaXNjb25jZXB0aW9uIG9uIHRoZSBzZXJ2aWNlIG1v ZGVsLg0KDQpZb3VyIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNClJlZ2Fy ZHMhDQotUWluDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCuWPkemAgeaX tumXtDogMjAxNuW5tDfmnIg15pelIDE5OjU1DQrmlLbku7bkuro6IExpdXNodWNoZW5nIChXaWxs KTsgQWRyaWFuIEZhcnJlbDsgTGl1c2h1Y2hlbmcgKFdpbGwpOyBRaW4gV3UNCuS4u+mimDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1l eHBsYWluZWQtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1LW9wc2F3 Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgUWluIFd1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZToJCWRyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZA0KUmV2aXNpb246 CTAwDQpUaXRsZToJCVNlcnZpY2UgTW9kZWxzIEV4cGxhaW5lZA0KRG9jdW1lbnQgZGF0ZToJMjAx Ni0wNy0wNQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTINClVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3Ut b3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1v ZGVsLWV4cGxhaW5lZC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAwDQoNCg0KQWJzdHJh Y3Q6DQogICBUaGUgSUVURiBoYXMgcHJvZHVjZWQgYSBjb25zaWRlcmFibGUgbnVtYmVyIG9mIGRh dGEgbW9kZWxzIGluIHRoZQ0KICAgWUFORyBtb2RlbGxpbmcgbGFuZ3VhZ2UuICBUaGUgbWFqb3Jp dHkgb2YgdGhlc2UgYXJlIHVzZWQgdG8gbW9kZWwNCiAgIGRldmljZXMgYW5kIHRoZXkgYWxsb3cg YWNjZXNzIGZvciBjb25maWd1cmF0aW9uIGFuZCB0byByZWFkDQogICBvcGVyYXRpb25hbCBzdGF0 dXMuDQoNCiAgIEEgc21hbGwgbnVtYmVyIG9mIFlBTkcgbW9kZWxzIGFyZSB1c2VkIHRvIG1vZGVs IHNlcnZpY2VzIChmb3INCiAgIGV4YW1wbGUsIHRoZSBMYXllciBUaHJlZSBWaXJ0dWFsIFByaXZh dGUgTmV0d29yayBTZXJ2aWNlIE1vZGVsDQogICBwcm9kdWNlZCBieSB0aGUgTDNTTSB3b3JraW5n IGdyb3VwKS4NCg0KICAgVGhpcyBkb2N1bWVudCBicmllZmx5IHNldHMgb3V0IHRoZSBzY29wZSBv ZiBhbmQgcHVycG9zZSBvZiBhbiBJRVRGDQogICBzZXJ2aWNlIG1vZGVsLCBhbmQgaXQgc2hvd3Mg d2hlcmUgYSBzZXJ2aWNlIG1vZGVsIG1pZ2h0IGZpdCBpbnRvIGENCiAgIFNvZnR3YXJlIERlZmlu ZWQgTmV0d29ya2luZyBhcmNoaXRlY3R1cmUgb3IgZGVwbG95bWVudC4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FXR0BpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg== From nobody Mon Jul 11 02:20:30 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391E5127078 for ; Mon, 11 Jul 2016 02:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 duy-uuzBxLR6 for ; Mon, 11 Jul 2016 02:20:25 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BC6128874 for ; Mon, 11 Jul 2016 02:20:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EdAQD6Y4NX/xUHmMZcGwEBAYJSIS1Wf?= =?us-ascii?q?AaFRIdgq22BOUEhhXcCgSU4FAEBAQEBAQEDYieCUTkGBy8BAQEBAQEBAQEBAQE?= =?us-ascii?q?BHAIPLxIBARkBAQEBAxIVBkwQAgEIDQQEAQELFgcHMhQJCAEBBAENBQgaiA4BD?= =?us-ascii?q?aVJmSMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYohEyEEhkYNIJ2gi8FiBWHJIl?= =?us-ascii?q?fAYYMkimFSJAPHjaBTjscgUxuAYg/AX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2EdAQD6Y4NX/xUHmMZcGwEBAYJSIS1WfAaFRIdgq22BOUE?= =?us-ascii?q?hhXcCgSU4FAEBAQEBAQEDYieCUTkGBy8BAQEBAQEBAQEBAQEBHAIPLxIBARkBA?= =?us-ascii?q?QEBAxIVBkwQAgEIDQQEAQELFgcHMhQJCAEBBAENBQgaiA4BDaVJmSMBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEXBYYohEyEEhkYNIJ2gi8FiBWHJIlfAYYMkimFSJAPH?= =?us-ascii?q?jaBTjscgUxuAYg/AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,345,1464667200"; d="scan'208,217";a="161610686" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Jul 2016 05:20:19 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 11 Jul 2016 05:20:01 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 11 Jul 2016 11:20:00 +0200 From: "Romascanu, Dan (Dan)" To: Zhoutianran , "opsawg@ietf.org" Thread-Topic: a new version of the automatic attachment drafts Thread-Index: AdHSL7Tm7cjwLHTRRWWWYvwrin0y4AGjPzDAAKV0qmA= Date: Mon, 11 Jul 2016 09:19:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75235990@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA75220B90@AZ-FFEXMB04.global.avaya.com> In-Reply-To: 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_9904FB1B0159DA42B0B887B7FA8119CA75235990AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "Unbehagen Jr, Paul E \(Paul\)" Subject: Re: [OPSAWG] a new version of the automatic attachment drafts X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 09:20:28 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA75235990AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tianran, Thank you for the reading and for the comments. Your observation is very correct and it relates to something that we failed= to explain in enough details in the I-D. The AA controller in the diagram = should not be regarded as a 'super-controller' across administrative domain= s, but rather as a policy function that applies to the network and may be i= nstantiated in different ways. The 'vertical' data model (6) in the diagram= does not carry the same information to AACs and AASs. There are two possib= le scenarios here: 1. The AA controller connects only to the AAS and configures the mapp= ing policies on the network devices. Clients are configured mainly by the h= orizontal interaction - this will be true also in most of the IoT scenarios 2. Both AAS and AACs connect to the AA controller function. The clien= ts get authentication and local security and local services information fro= m the controller (what services are available, how you configure to them). = Servers perform same functionality as in #1. The implementation of the cont= roller may be distributed, possibly with an 'orchestration' function in-bet= ween. This fits for example the BYOD use cases. I hope this clarifies both comments. I will make one slide to address the c= omments at the meeting, and include a more detailed description for the nex= t round of I-Ds. Regards, Dan From: Zhoutianran [mailto:zhoutianran@huawei.com] Sent: Friday, July 8, 2016 5:29 AM To: Romascanu, Dan (Dan); opsawg@ietf.org Subject: RE: a new version of the automatic attachment drafts Hi Dan, I am reading the framework draft. Here are some initial comments: 1. In figure 1, the AA controller has connection to both AA client and AA s= erver. I think it's not practical in many cases. AAC and AAS, IMHO, are usu= ally in different administrative domains. For example, AAC installed on a C= E, and the AAS installed on the PE. Usually, CE and PE are controlled by di= fferent domain controllers. It's hard to deploy a super controller for CE a= nd PE. Another example is, as you showed, the IoT. It's not practical to le= t all the end devices connect to the AA controller. Here, what scenario did you consider for this framework? The suggestion, if I am right, is to have the AA controller only connect to= the AAS. AAC can pull additional information from the path: AA controller-= >AAS->AAC. 2. If both AAC and AAS connect to the AA controller, that means the AAC and= AAS can be synchronized and configured by the management plane. So I guess= some of the control plane function between AAC and AAS can be reduced. Regards, Tianran From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (= Dan) Sent: Thursday, June 30, 2016 1:58 AM To: opsawg@ietf.org Subject: [OPSAWG] a new version of the automatic attachment drafts Hi, I have submitted two new Internet-Draft that describe the automatic attachm= ent functionality: https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-framewo= rk/ https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-lldp/ Principal changes: - addressing the comments received at IETF 95 we split the generic protoco= l-independent framework that describes the discovery and service mapping me= chanism in a separate I-D - we clarified terminology and re-drawn the principal building blocks - we connected the discovery and authentication mechanism with the MUD prop= osal Questions and comments are welcome. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA75235990AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tianran,=

 

Thank you for the read= ing and for the comments.

 

Your observation is ve= ry correct and it relates to something that we failed to explain in enough = details in the I-D. The AA controller in the diagram should not be regarded= as a ‘super-controller’ across administrative domains, but rather as a policy function that applies to the network and m= ay be instantiated in different ways. The ‘vertical’ data model= (6) in the diagram does not carry the same information to AACs and AASs. T= here are two possible scenarios here:

 

1.&= nbsp;      The AA controller connects only to the AAS and configures the ma= pping policies on the network devices. Clients are configured mainly by the= horizontal interaction – this will be true also in most of the IoT scenarios

2.&= nbsp;      Both AAS and AACs connect to the AA controller function. The cli= ents get authentication and local security and local services information f= rom the controller (what services are available, how you configure to them). Servers perform same functionality = as in #1. The implementation of the controller may be distributed, possibly= with an ‘orchestration’ function in-between. This fits for exa= mple the BYOD use cases.

 

I hope this clarifies = both comments. I will make one slide to address the comments at the meeting= , and include a more detailed description for the next round of I-Ds.

 

Regards,

 

Dan<= /p>

 

 

From: Zhoutian= ran [mailto:zhoutianran@huawei.com]
Sent: Friday, July 8, 2016 5:29 AM
To: Romascanu, Dan (Dan); opsawg@ietf.org
Subject: RE: a new version of the automatic attachment drafts

 

Hi Dan,

 =

I am reading the = framework draft. Here are some initial comments:

 =

1. In figure 1, t= he AA controller has connection to both AA client and AA server. I think it= ’s not practical in many cases. AAC and AAS, IMHO, are usually in different administrative domains. For example, AAC installe= d on a CE, and the AAS installed on the PE. Usually, CE and PE are controll= ed by different domain controllers. It’s hard to deploy a super contr= oller for CE and PE. Another example is, as you showed, the IoT. It’s not practical to let all the end device= s connect to the AA controller.

Here, what scenar= io did you consider for this framework?

The suggestion, i= f I am right, is to have the AA controller only connect to the AAS. AAC can= pull additional information from the path: AA controller->AAS->AAC.

 =

2. If both AAC an= d AAS connect to the AA controller, that means the AAC and AAS can be synch= ronized and configured by the management plane. So I guess some of the control plane function between AAC and AAS can be r= educed.

 =

 =

Regards,

Tianran

 =

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 30, 2016 1:58 AM
To: opsawg@ietf.org
Subject: [OPSAWG] a new version of the automatic attachment drafts

&nbs= p;

Hi,<= /o:p>

&nbs= p;

I have su= bmitted two new Internet-Draft that describe the automatic attachment funct= ionality:

&nbs= p;

https://datatracker.iet= f.org/doc/draft-romascanu-opsawg-auto-attach-framework/

https://datatracker.ietf.org= /doc/draft-romascanu-opsawg-auto-attach-lldp/

&nbs= p;

Principal= changes:

- addr= essing the comments received at IETF 95  we split the generic protocol= -independent framework that describes the discovery and service mapping mec= hanism in a separate I-D

- we c= larified terminology and re-drawn the principal building blocks<= /span>

- we conn= ected the discovery and authentication mechanism with the MUD proposal

&nbs= p;

Questions= and comments are welcome.

&nbs= p;

Thanks an= d Regards,

&nbs= p;

Dan<= /o:p>

&nbs= p;

--_000_9904FB1B0159DA42B0B887B7FA8119CA75235990AZFFEXMB04globa_-- From nobody Mon Jul 11 03:16:00 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65280127078 for ; Mon, 11 Jul 2016 03:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bjQJ1Lps1y4D for ; Mon, 11 Jul 2016 03:15:55 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1C5127077 for ; Mon, 11 Jul 2016 03:15:54 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 143D297FE6762; Mon, 11 Jul 2016 10:15:51 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6BAFqum006924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 10:15:52 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6BAFppW021708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Jul 2016 12:15:52 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 11 Jul 2016 12:15:51 +0200 From: "Scharf, Michael (Nokia - DE)" To: Qin Wu , "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt Thread-Index: AQHR1rQaqatqqP7izEmdMDgbK+d1g6AJuuFAgAMw/BCABdqxcIAADvog Date: Mon, 11 Jul 2016 10:15:51 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48911DD8@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D48906FBF@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 10:15:58 -0000 SGkgUWluLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuIElubGluZSBzb21lIGZ1cnRoZXIgY29t bWVudHMgW21zMl0uDQoNCj4gSGkgYWxsLA0KPiANCj4gSSBoYXZlIHF1aWNrbHkgc2Nhbm5lZCB0 aGlzIGRvY3VtZW50LiBTb21lIGluaXRpYWwgY29tbWVudHMgW21zXToNCj4gDQo+ICoqKiBQYWdl IDM6DQo+IA0KPiAgICBTZXJ2aWNlIE1vZGVsOiAgQSBzZXJ2aWNlIG1vZGVsIGlzIGEgc3BlY2lm aWMgdHlwZSBvZiBkYXRhIG1vZGVsLg0KPiBJdA0KPiAgICAgICBkZXNjcmliZXMgYSBzZXJ2aWNl IGFuZCBhbGwgb2YgdGhlIHBhcmFtZXRlcnMgb2YgdGhlIHNlcnZpY2UgaW4gYQ0KPiAgICAgICBw b3J0YWJsZSwgb3BlcmF0b3ItaW5kZXBlbmRlbnQgd2F5LiAgSXQgY2FuIGJlIHVzZWQgYnkgYSBo dW1hbiBvcg0KPiAgICAgICBieSBzb2Z0d2FyZSB0byBjb25maWd1cmUgb3IgcmVxdWVzdCBhIHNl cnZpY2UgYW5kIG1heSBlcXVhbGx5IGJlDQo+ICAgICAgIGNvbnN1bWVkIGJ5IGEgaHVtYW4gb3Ig YnkgYSBzb2Z0d2FyZSBjb21wb25lbnQuDQo+IA0KPiBbbXNdIEkgd291bGQgc3VnZ2VzdCBhIG1v cmUgY2FyZWZ1bCB3b3JkaW5nIHJlZ2FyZGluZyB0aGUgY29tcGxldGVuZXNzDQo+IG9mIHRoZSBt b2RlbCwgZS5nLiwgIkl0IGFpbXMgYXQgZGVzY3JpYmluZyBhIHNlcnZpY2UgYW5kIGFsbCBvZiB0 aGUNCj4gcGFyYW1ldGVycyBvZiB0aGUgc2VydmljZS4uLiIuIEFzIGRpc2N1c3NlZCBpbiBMM1NN IGluIHRoZSBwYXN0LCBmb3INCj4gY2VydGFpbiBzZXJ2aWNlcyAoZS5nLiwgZmlyZXdhbGxzLCBE b1MgcHJldmVudGlvbiwgLi4uKSB0aGUgc2VydmljZQ0KPiBtb2RlbCB3b3VsZCBoYXZlIHRvIGJl IGV4dGVuZGVkIC8gYXVnbWVudGVkLiBBbHNvIG5vdGUgdGhhdCB0aGUNCj4gc3RhdGVtZW50ICJh bGwgcGFyYW1ldGVycyIgY29udHJhZGljdHMgdGhlIHN0YXRlbWVudCBvbiBTTEFzIGxhdGVyIGlu DQo+IHRoZSB0ZXh0Lg0KPiANCj4gW1Fpbl0gV2hhdCB0aGUgc2VydmljZSBpcyBoYXMgYmVlbiB3 ZWxsIGRlZmluZWQgYW5kIGNsYXJpZmllZCBiZWZvcmUNCj4gc2VydmljZSBtb2RlbCBkZWZpbml0 aW9uIGluIHRoZSBzZWN0aW9uIDIuDQo+IFRoYXQgaXMgdG8gc2F5LCBGaXJld2FsbCBhbmQgRG9T IHByZXZlbnRpb24gYXJlIGp1c3QgYWRkaXRpb25hbA0KPiBmdW5jdGlvbmFsaXRpZXMgdGhhdCBh cmUgdXNlZCB0byBlbmhhbmNlIHRoZSBiYXNpYyBzZXJ2aWNlIHdlIGRlZmluZWQNCj4gaW4gdGhl IGRvY3VtZW50Lg0KPiBGb3Igd2hhdCB0aGUgc2VydmljZSBpcyBub3QgaXMgZnVydGhlciBjbGFy aWZpZWQgaW4gdGhlIHNlY3Rpb24gNSwgdGhlDQo+IGZpcnN0IGJ1bGxldC4NCg0KW21zMl0gSSBh bSBub3Qgc3VyZSBpZiBJIGNhbiBmb2xsb3cuIE15IHBvaW50IGlzIHRoYXQgdGhlIHdvcmRpbmcg ImRlc2NyaWJlcyBhIHNlcnZpY2UgYW5kIGFsbCBvZiB0aGUgcGFyYW1ldGVycyIgc2VlbXMgY29u dHJhZGljdGluZyBnaXZlbiB0aGUgdXNlIG9mIHRoZSB0ZXJtICJhbGwiIGlmIHlvdSBleGNsdWRl IFNMQXMuIEFsc28sIFNlY3Rpb24gNSBkb2VzIG5vdCByZWFsbHkgaGF2ZSBhIHdlbGwtZGVmaW5l ZCBkZWZpbml0aW9uIC0gZXhjbHVkaW5nIHNvbWUgZXhhbXBsZXMgZG9lcyBub3QgbmVjZXNzYXJp bHkgcmVzdWx0IGluIGEgcHJlY2lzZSBkZWZpbml0aW9uLiAoSSBhZ3JlZSB0aGF0ICJTZXJ2aWNl IiBpcyBjaGFsbGVuZ2luZyB0byBkZWZpbmUgYnV0IG1heWJlIHRoaXMgY291bGQgYmUgb25lIHJl YXNvbiB0byBmaW5kIGFuIGFsdGVybmF0aXZlIHRlcm0gdG8gInNlcnZpY2UgbW9kZWwiKS4gDQoN Cj4gSW4gYWRkaXRpb24sIHdlIGRvbid0IHRha2UgU0xBIGZpbmUgZ3JhbnVsYXJpdHkgZGV0YWls cyBjb21iaW5pbmcNCj4gY29tbWVyY2lhbCB0ZXJtcyBhcyBzZXJ2aWNlIHBhcmFtZXRlcnMsIHNv IEkgZG9uJ3Qgc2VlIHRoZXJlIGlzDQo+IGluY29uc2lzdGVuY3kgaXNzdWUsIGZvciBzb21lIG1p c2NvbmNlcHRpb24gb24gdGhlIHNlcnZpY2UgbW9kZWwNCj4gVW5kZXJzdGFuZGluZyBpcyBjbGFy aWZpZWQgaW4gdGhlIGRpZmZlcmVudCBzZWN0aW9uLCB0aGlzIGlzDQo+IGludGVudGlvbmFsLg0K DQpbbXMyXSBNeSBwb2ludCBpcyB0aGF0IFNMQSBwYXJhbWV0ZXJzIG1heSBiZSBhbiBpbXBvcnRh bnQgcGFydCBvZiB0aGUgY3VzdG9tZXItc2VydmljZSBwcm92aWRlciBhZ3JlZW1lbnQgb2YgYSBz ZXJ2aWNlIGFuZCBpdCBpcyBzdXJwcmlzaW5nIHRvIGZpcnN0IHNlZWluZyB0aGlzIG1lbnRpb25l ZCBhdCB0aGUgZW5kIG9mIFNlY3Rpb24gNS4NCiANCj4gW21zXSBJIGZpbmQgdGhlIHdvcmRpbmcg Iml0IGNhbiBiZSB1c2VkIGJ5IGEgaHVtYW4uLi4iIGNvbmZ1c2luZy4gSXMNCj4gdGhlIGFzc3Vt cHRpb24gdGhhdCBhIHVzZXIgd291bGQgbWFudWFsbHkgdHlwZSBpbiBhIHNlcnZpY2UgcmVxdWVz dA0KPiByZXN1bHRpbmcgaW4gYSB2YWxpZCBkYXRhIG1vZGVsLCBlLmcuLCBieSBtYW51YWxseSB0 eXBpbmcgaW4gTkVUQ09ORg0KPiBjb21tYW5kcz8gSSB3b3VsZCByYXRoZXIgd3JpdGUgc29tZXRo aW5nIGxpa2UgInRoZSBwYXJhbWV0ZXJzIGNhbiBiZQ0KPiBlbnRlcmVkIGJ5IHNvZnR3YXJlIG9y IGFsc28gbWFudWFsbHkgYnkgYSBodW1hbi4uLiINCj4gDQo+IFtRaW5dOiB3aGF0IHdlIHRyeSB0 byBjb252ZXkgaGVyZSBpcyBIdW1hbiBjYW4gcmVseSBvbiBDTEksc2NyaXB0IG9yDQo+IG90aGVy IGh1bWFuIHJlYWRhYmxlIGxhbmd1YWdlIHRvIGRlZmluZSBhIHNlcnZpY2UsIHJlcXVlc3QgdGhl IHNlcnZpY2UsDQo+IGJ1dCBzdWNoIHBhcmFtZXRlciB3aWxsIG5vdCBkaXJlY3RseSBpbXBsZW1l bnRlZCBieSBuZXR3b3JrIGVsZW1lbnQuDQoNClttczJdIFN1cmUsIGJ1dCB3aGF0IGlzIHRoZSBy b2xlIG9mIGEgc2VydmljZSBtb2RlbCBkZWZpbmVkIGluIFlBTkcgZS5nLiB3aGVuIHRoZSBodW1h biByZWxpZXMgb24gQ0xJIG9yIHNjcmlwdHM/IFRvIG1lIHRoaXMgd29yZGluZyBkb2VzIG5vdCBl eHBsYWluIHRoaXMgd2VsbC4NCiANCj4gKioqIFBhZ2UgMzoNCj4gDQo+ICAgIFRoZSBlbmNvZGlu ZyBhbmQgY29tbXVuaWNhdGlvbiBwcm90b2NvbCB1c2VkIHRvIGV4Y2hhbmdlIGEgc2VydmljZQ0K PiAgICBtb2RlbCBiZXR3ZWVuIGN1c3RvbWVyIGFuZCBuZXR3b3JrIG9wZXJhdG9yIGFyZSBkZXBs b3ltZW50LSBhbmQNCj4gICAgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMuICBUaGUgSUVURiByZWNv bW1lbmRzIHRoZSB1c2Ugb2YgdGhlIE5FVENPTkYNCj4gICAgQ29uZmlndXJhdGlvbiBQcm90b2Nv bCBbUkZDNDc0MV0gd2l0aCBkYXRhIGVuY29kZWQgaW4gWE1MIG9yIEpTT04NCj4gZm9yDQo+ICAg IGludGVyYWN0aW9ucyAib24gdGhlIHdpcmUiIGJldHdlZW4gc29mdHdhcmUgY29tcG9uZW50cy4g IEhvd2V2ZXIsDQo+IGNvLQ0KPiAgICBsb2NhdGVkIHNvZnR3YXJlIGNvbXBvbmVudHMgbWlnaHQg dXNlIGFuIEFQSSwgd2hpbGUgc3lzdGVtcyB3aXRoDQo+IG1vcmUNCj4gICAgZGlyZWN0IGh1YW4g aW50ZXJhY3Rpb25zIG1pZ2h0IHVzZSB3ZWIgcGFnZXMgb3IgZXZlbiBwYXBlciBmb3Jtcy4NCj4g DQo+IFttc10gSSBhbSBub3Qgc3VyZSBpZiB0aGUgSUVURiBzaG91bGQgc3VnZ2VzdCB0aGUgdXNl IG9mIE5FVENPTkYgb24gdGhlDQo+IG5vcnRoYm91bmQgaW50ZXJmYWNlIG9mIGEgInNlcnZpY2Ug b3JjaGVzdHJhdG9yIiwgd2hpY2ggc2VlbXMgdG8gYmUgdGhlDQo+IHNjb3BlIG9mIHRoaXMgZG9j dW1lbnQuIEFyZSB0aGVyZSBwb2ludGVycyB0byBydW5uaW5nIGNvZGUgdGhhdA0KPiBhY3R1YWxs eSBkbyB0aGF0PyBJIHdvdWxkIHJhdGhlciBwcmVmZXIgYSB3b3JkaW5nIHN1Y2ggYXMgIlRoZSBJ RVRGIGhhcw0KPiBzdGFuZGFyZGl6ZWQgTkVUQ09ORiBhbmQgUkVTVENPTkYgZm9yIGludGVyYWN0 aW9ucyAib24gdGhlIHdpcmUiDQo+IGJldHdlZW4gc29mdHdhcmUgY29tcG9uZW50cyIuDQo+IA0K PiBbUWluXTogWW91IGFyZSByaWdodCwgSSB0aGluayBSRVNDT05GIGlzIHJlY29tbWVuZGVkIG9u IHRoZSBub3J0aGJvdW5kDQo+IGludGVyZmFjZSBvZiBhIHNlcnZpY2Ugb3JjaGVzdHJhdG9yLCB5 b3VyIHByb3Bvc2VkIGNoYW5nZSBsb29rcyBnb29kLg0KPiBUaGFua3MuDQo+IA0KPiAqKiogUGFn ZSA3Og0KPiANCj4gICAgbyAgVGhlIG5ldHdvcmsgb3BlcmF0b3IgbWF5IHVzZSBmdXJ0aGVyIGRh dGEgbW9kZWxzIHRoYXQgaGVscCB0bw0KPiAgICAgICBkZXNjcmliZSBob3cgdGhlIHNlcnZpY2Ug aXMgcmVhbGl6ZWQgaW4gdGhlIG5ldHdvcmsuICBUaGVzZQ0KPiBtb2RlbHMNCj4gICAgICAgbWln aHQgYmUgdXNlZCBvbiB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIFNlcnZpY2UgT3JjaGVzdHJh dG9yDQo+ICAgICAgIGFuZCB0aGUgTmV0d29yayBPcmNoZXN0cmF0b3IgYXMgc2hvd24gaW4gRmln dXJlIDMgYW5kIG1pZ2h0DQo+ICAgICAgIGluY2x1ZGUgbWFueSBvZiB0aGUgcGllY2VzIG9mIGlu Zm9ybWF0aW9uIGluIHRoZSBzZXJ2aWNlIG1vZGVsDQo+ICAgICAgIGFsb25nc2lkZSBwcm90b2Nv bCBwYXJhbWV0ZXJzIGFuZCBkZXZpY2UgY29uZmlndXJhdGluDQo+IGluZm9ybWF0aW9uLg0KPiAg ICAgICBJdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgU2VydmljZSBPcmNoZXN0cmF0b3Igc2hvdWxk IGJlIGFibGUgdG8NCj4gICAgICAgbWFwIGZyb20gYSBzZXJ2aWNlIG1vZGVsIHRvIHRoZXNlIGRh dGEgbW9kZWxzLCBidXQgdGhleSBhcmUgbm90DQo+ICAgICAgIHRoZSBzYW1lIHRoaW5ncy4NCj4g DQo+IFttc10gV2h5IGlzIGl0IG5vdCBwb3NzaWJsZSB0aGF0IHRoZSBkYXRhIG1vZGVscyBhcmUg dGhlIHNhbWU/IEluDQo+IEZpZ3VyZSAzLCB0aGUgInNlcnZpY2Ugb3JjaGVzdHJhdG9yIiBpcyBh Y3R1YWxseSBhICJjbGllbnQiIChyZWFkIHRoaXMNCj4gYXMgImN1c3RvbWVyIikgb2YgdGhlICJu ZXR3b3JrIG9yY2hlc3RyYXRvcnMiLiBJbnNpZGUgYW4gb3BlcmF0b3IsIHRoZQ0KPiAic2Vydmlj ZSBvcmNoZXN0cmF0b3IiIGNvdWxkIGJlIG9wZXJhdGVkIGJ5IGEgZGlmZmVyZW50IG9yZ2FuaXph dGlvbg0KPiB0aGFuIHRoZSAibmV0d29yayBvcmNoZXN0cmF0b3IiLCBpLmUuLCB0aGVyZSBvdWxk IGV2ZW4gYmUgYSBidXNpbmVzcw0KPiByZWxhdGlvbnNoaXAuIEluIGdlbmVyYWwsIGFyY2hpdGVj dHVyZXMgY2FuIGJlIHJlY3Vyc2l2ZS4gSSB0aGluayB0aGlzDQo+IHN0YXRlbWVudCByZXF1aXJl cyBmdXJ0aGVyIGV4cGxhbmF0aW9uIG9yIHJld29yZGluZy4NCj4gDQo+IFtRaW5dOiBUaGUgY29u Y2VwdCB0byBzcGxpdCBPcmNoZXN0cmF0b3IgaW50byBzZXJ2aWNlIG9yY2hlc3RyYXRvciBhbmQN Cj4gbmV0d29yayBvcmNoZXN0cmF0b3IsIGlzIHRoZSBzZXJ2aWNlIG9yY2hlc3RyYXRvciBpcyBu ZXR3b3JrIGFnbm9zdGljDQo+IHdoaWxlIG5ldHdvcmsgb3JjaGVzdHJhdG9yIGlzIG5ldHdvcmsg YXdhcmUuDQo+IFNlcnZpY2UgbW9kZWwgY29uc3VtZWQgYnkgdGhlIHNlcnZpY2Ugb3JjaGVzdHJh dG9yIGNvdWxkIGJlIGRpZmZlcmVudA0KPiBmcm9tIHRoZSBkYXRhIG1vZGVsIGNvbnN1bWVkIGJ5 IG5ldHdvcmsgb3JjaGVzdHJhdG9yIHNpbmNlIG5ldHdvcmsNCj4gb3JjaGVzdHJhdG9yIG5lZWQg dG8gZGVjaWRlIHdoYXQgbmV0d29yayBkZXZpY2UgaXMgc2VsZWN0ZWQsIHdoaWNoDQo+IHByb3Rv Y29sIGlzIGVuYWJsZWQsIHdoaWNoIHRlY2hub2xvZ3kgaXMgdXNlZCwgd2hpY2ggbmV0d29yayBp bnRlcmZhY2UNCj4gb3IgcG9ydCBpcyBhc3NpZ25lZC4gVGhlIHNlcnZpY2Ugb3JjaGVzdHJhdG9y IGRvZXNuJ3QgbmVlZCB0byBjYXJlDQo+IGFib3V0IHRoZSB1bmRlcmx5aW5nIHRlY2hub2xvZ3kg b3Igd2hhdCBwcm90b2NvbCBpcyBhdmFpbGFibGUuDQoNClttczJdIFlvdSBtYXkgd2FudCB0byBh ZGQgdGhhdCBhc3N1bXB0aW9uIG1vcmUgZXhwbGljaXRseSB0byB0aGUgdGV4dCBhbmQgcG9zc2li bHkgYWRkIHRoYXQgdGhpcyBpcyBvbmx5IG9uZSBwb3RlbnRpYWwgYXJjaGl0ZWN0dXJlLiANCiAN Cj4gKioqIFBhZ2UgNzoNCj4gDQo+ICAgIG8gIFNlcnZpY2UgTGV2ZWwgQWdyZWVtZW50cyAoU0xB cykgaGF2ZSBhIGhpZ2ggZGVncmVlIG9mIG92ZXJsYXANCj4gd2l0aA0KPiAgICAgICB0aGUgZGVm aW5pdGlvbiBvZiBzZXZpY2VzIHByZXNlbnQgaW4gc2VydmljZSBtb2RlbHMuICBSZXF1ZXN0cw0K PiBmb3INCj4gICAgICAgc3BlY2lmaWMgYmFuZHdpZHRoLCBmb3IgZXhhbXBsZSwgbWlnaHQgYmUg cHJlc2VudCBpbiBhIHNlcnZpY2UNCj4gICAgICAgbW9kZWwsIGFuZCBhZ3JlZW1lbnQgdG8gZGVs aXZlciBhIHNlcnZpY2UgaXMgYSBjb21taXRtZW50IHRvIHRoZQ0KPiAgICAgICBkZXNjcmlwdGlv biBvZiB0aGUgc2VydmljZSBpbiB0aGUgc2VydmljZSBtb2RlbCwgaG93ZXZlciwgU0xBcw0KPiAg ICAgICB0eXBpY2FsbHkgaW5jbHVkZSBhIG51bWJlciBvZiBmaW5lLWdyYWluZWQgZGV0YWlscyBh Ym91dCBob3cNCj4gICAgICAgc2VydmljZXMgYXJlIGFsbG93ZWQgdG8gdmFyeSwgYnkgaG93IG11 Y2gsIGFuZCBob3cgb2Z0ZW4uICBTTEFzDQo+ICAgICAgIGFyZSBhbHNvIGxpbmtlZCB0byBjb21t ZXJjaWFsIHRlcm1zIHdpdGggcGVuYWx0aWVzIGFuZCBzbyBmb3J0aCwNCj4gICAgICAgYW5kIHNv IGFyZSBhbHNvIG5vdCBnb29kIHRvcGljcyBmb3Igc3RhbmRhcmRpemF0aW9uLg0KPiANCj4gW21z XSBJIHdvbmRlciBpZiBpdCBjb3VsZCBtYWtlIHNlbnNlIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4g U0xBIGFuZA0KPiBTZXJ2aWNlIExldmVsIE9iamVjdGl2ZSAoU0xPKSBvciBTZXJ2aWNlIExldmVs IFJlcXVpcmVtZW50IChTTFIpLiBXaGlsZQ0KPiBJIGFncmVlIHRoYXQgaXQgaXMgZGlmZmljdWx0 IHRvIHN0YW5kYXJkaXplIGNvbW1lcmNpYWwgdGVybXMsIHRoaXMgSU1ITw0KPiBwYXJ0bHkgY29u dHJhZGljdHMgdGhlIHBvc2l0aW9uaW5nIG9mIHRoZSB0ZXJtICJzZXJ2aWNlIG1vZGVsIiBlYXJs aWVyDQo+IGluIHRoZSBkb2N1bWVudC4gTWF5YmUgdGhlIHNjb3BlIG9mIHRoZSBkZWZpbml0aW9u IG9mICJzZXJ2aWNlIG1vZGVsIg0KPiBoYXMgdG8gYmUgbmFycm93ZWQgZG93bj8NCj4gDQo+IFtR aW5dOiBXZSBoYXZlIGNsYXJpZmllZCB3aGF0IHRoZSBzZXJ2aWNlIGlzIGluIHRoZSBzZWN0aW9u IDIgYW5kIE91cg0KPiBzZXJ2aWNlIG1vZGVsIGRlZmluaXRpb24gYWxpZ25zIHdpdGggc2Vydmlj ZSBkZWZpbml0aW9uLiBZZXMsIHdlIG5lZWQNCj4gdG8gZGlzdGluZ3Vpc2ggU0xBIGZyb20gU2Vy dmljZSBMZXZlbCBPYmplY3RpdmUvUmVxdWlyZW1lbnQsIGJ1dCBub3QNCj4gbmVjZXNzYXJ5IGlu dHJvZHVjZSBhbm90aGVyIG5ldyB0ZXJtLiBXZSBoYXZlIGNsYXJpZmllZCB0aGVpcg0KPiBkaWZm ZXJlbmNlIGluIHRoZSB0ZXh0IHlvdSBxdW90ZWQuDQoNClttczJdIFdlbGwsIEkgdGhpbmsgeW91 IHNob3VsZCBjb21tZW50IG9uIFNMQXMgaW4gU2VjdGlvbiAyIHRvIGF2b2lkIGNvbmZ1c2lvbi4N Cg0KTWljaGFlbA0KDQoNCg0KPiAqKiogcGFnZSA5Og0KPiANCj4gNi40LiAgU3VwcG9ydGluZyBN dWx0aXBsZSBTZXJ2aWNlcw0KPiANCj4gICAgTmV0d29yayBvcGVyYXRvcnMgd2lsbCwgaW4gZ2Vu ZXJhbCwgb2ZmZXIgbWFueSBkaWZmZXJlbnQgc2VydmljZXMgdG8NCj4gICAgdGhlaXIgY3VzdG9t ZXJzLiAgRWFjaCB3b3VsZCBub3JtYWxseSBiZSB0aGUgc3ViamVjdCBvZiBhIHNlcGFyYXRlDQo+ ICAgIHNlcnZpY2UgbW9kZWwuDQo+IA0KPiBbbXNdIFRoZSBhY3R1YWwgcXVlc3Rpb24gaGVyZSBp cyBpZiB0aGVyZSBjb3VsZCBiZSBjb21tdW5hbGl0eSBiZXR3ZWVuDQo+IHNlcnZpY2UgbW9kZWxz IGZvciBzaW1pbGFyIHNlcnZpY2VzLiBUaGF0IHByb2JsZW0gY2Fubm90IGJlIHNvbHZlZCBieQ0K PiB0aGlzIGRvY3VtZW50IGJ1dCB0aGUgdGV4dCBjb3VsZCBlLmcuIGV4cGxhaW4gdGhhdCBmb3Ig YSBjdXN0b21lciBpdA0KPiBjYW4gYmUgY29uZnVzaW5nIGlmIHNlcGFyYXRlIHNlcnZpY2UgbW9k ZWxzIG1vZGVsIHJlbGF0ZWQgY29uY2VwdHMgaW4NCj4gZGlmZmVyZW50IHdheXMuDQo+IA0KPiBb UWluXTogVGhhdCBpcyBhIGdvb2QgcXVlc3Rpb24sIEkgaG9wZSBzb21lIGJ1aWxkaW5nIGJsb2Nr cyBzcGVjaWZpZWQNCj4gYnkgb25lIHNlcnZpY2UgbW9kZWwgY2FuIGJlIHJldXNlZCBpbiBhbm90 aGVyIHNlcnZpY2UgbW9kZWwuDQo+IFVuZm9ydHVuYXRlbHkgd2UgZG9uJ3QgaGF2ZSB0b28gbWFu eSBZQU5HIG1vZGVscyB0aGF0IGFyZSB1c2VkIHRvIG1vZGVsDQo+IHNlcnZpY2UgaW4gdGhlIElF VEYuIFdlIGNvdWxkIGNvdmVyIHRoaXMgaW4gdGhlIG5leHQgdmVyc2lvbiBpZiBtb3JlDQo+IHN1 Y2ggc2VydmljZSBtb2RlbHMgYXJlIG5lZWRlZC4NCj4gDQo+IFRoYW5rcw0KPiANCj4gTWljaGFl bA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE9QU0FXRyBb bWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUWluIFd1DQo+IFNl bnQ6IFR1ZXNkYXksIEp1bHkgMDUsIDIwMTYgMjowMiBQTQ0KPiBUbzogb3BzYXdnQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbT1BTQVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXd1LW9wc2F3Zy0NCj4gc2VydmljZS1tb2RlbC1leHBsYWluZWQtMDAudHh0DQo+IA0KPiBI aSwNCj4gV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgSS1EIHRoYXQgZGlzY3Vzc2VzIHRoZSBzY29w ZSBhbmQgcHVycG9zZSBvZg0KPiBzZXJ2aWNlIG1vZGVscyB3aXRoaW4gdGhlIElFVEYgYW5kIGRl c2NyaWJlcyBob3cgYSBzZXJ2aWNlIG1vZGVsIGNhbiBiZQ0KPiB1c2VkIGJ5IGEgbmV0d29yayBv cGVyYXRvci4NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3Utb3Bz YXdnLXNlcnZpY2UtbW9kZWwtDQo+IGV4cGxhaW5lZC8NCj4gDQo+IEluIGFkZGl0aW9uLCB0aGlz IGRyYWZ0IGNsYXJpZmllcyB0aGUgcm9sZSBhbmQgcG9zaXRpb24gb2Ygc2VydmljZQ0KPiBtb2Rl bCBpbiB0aGUgU0ROIGFyY2hpdGVjdHVyZSBhbmQgQ2xlYXIgc2V2ZXJhbCBtaXNjb25jZXB0aW9u IG9uIHRoZQ0KPiBzZXJ2aWNlIG1vZGVsLg0KPiANCj4gWW91ciBxdWVzdGlvbnMgYW5kIGNvbW1l bnRzIGFyZSB3ZWxjb21lLg0KPiANCj4gUmVnYXJkcyENCj4gLVFpbg0KPiAtLS0tLemCruS7tuWO n+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTblubQ35pyINeaX pSAxOTo1NQ0KPiDmlLbku7bkuro6IExpdXNodWNoZW5nIChXaWxsKTsgQWRyaWFuIEZhcnJlbDsg TGl1c2h1Y2hlbmcgKFdpbGwpOyBRaW4gV3UNCj4g5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLQ0KPiBleHBsYWluZWQtMDAu dHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1LW9wc2F3Zy1zZXJ2 aWNlLW1vZGVsLWV4cGxhaW5lZC0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBRaW4gV3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiAN Cj4gTmFtZToJCWRyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZA0KPiBSZXZp c2lvbjoJMDANCj4gVGl0bGU6CQlTZXJ2aWNlIE1vZGVscyBFeHBsYWluZWQNCj4gRG9jdW1lbnQg ZGF0ZToJMjAxNi0wNy0wNQ0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdl czoJCTEyDQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtd3Utb3BzYXdnLQ0KPiBzZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMC50eHQN Cj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXd1LW9wc2F3Zy0NCj4gc2VydmljZS1tb2RlbC1leHBsYWluZWQvDQo+IEh0bWxpemVkOiAgICAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtDQo+ IG1vZGVsLWV4cGxhaW5lZC0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGUgSUVURiBo YXMgcHJvZHVjZWQgYSBjb25zaWRlcmFibGUgbnVtYmVyIG9mIGRhdGEgbW9kZWxzIGluIHRoZQ0K PiAgICBZQU5HIG1vZGVsbGluZyBsYW5ndWFnZS4gIFRoZSBtYWpvcml0eSBvZiB0aGVzZSBhcmUg dXNlZCB0byBtb2RlbA0KPiAgICBkZXZpY2VzIGFuZCB0aGV5IGFsbG93IGFjY2VzcyBmb3IgY29u ZmlndXJhdGlvbiBhbmQgdG8gcmVhZA0KPiAgICBvcGVyYXRpb25hbCBzdGF0dXMuDQo+IA0KPiAg ICBBIHNtYWxsIG51bWJlciBvZiBZQU5HIG1vZGVscyBhcmUgdXNlZCB0byBtb2RlbCBzZXJ2aWNl cyAoZm9yDQo+ICAgIGV4YW1wbGUsIHRoZSBMYXllciBUaHJlZSBWaXJ0dWFsIFByaXZhdGUgTmV0 d29yayBTZXJ2aWNlIE1vZGVsDQo+ICAgIHByb2R1Y2VkIGJ5IHRoZSBMM1NNIHdvcmtpbmcgZ3Jv dXApLg0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBicmllZmx5IHNldHMgb3V0IHRoZSBzY29wZSBv ZiBhbmQgcHVycG9zZSBvZiBhbiBJRVRGDQo+ICAgIHNlcnZpY2UgbW9kZWwsIGFuZCBpdCBzaG93 cyB3aGVyZSBhIHNlcnZpY2UgbW9kZWwgbWlnaHQgZml0IGludG8gYQ0KPiAgICBTb2Z0d2FyZSBE ZWZpbmVkIE5ldHdvcmtpbmcgYXJjaGl0ZWN0dXJlIG9yIGRlcGxveW1lbnQuDQo+IA0KPiANCj4g DQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUg SUVURiBTZWNyZXRhcmlhdA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gT1BTQVdHIG1haWxpbmcgbGlzdA0KPiBPUFNBV0dAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg== From nobody Mon Jul 11 19:25:04 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F7912D097 for ; Mon, 11 Jul 2016 19:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xPNDHyGNWkwx for ; Mon, 11 Jul 2016 19:24:59 -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 F2E2E12B008 for ; Mon, 11 Jul 2016 19:24:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNN32094; Tue, 12 Jul 2016 02:24:56 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Jul 2016 03:24:52 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.179]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 12 Jul 2016 10:24:44 +0800 From: Qin Wu To: "Scharf, Michael (Nokia - DE)" , "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt Thread-Index: AQHR1rQaqatqqP7izEmdMDgbK+d1g6AJuuFAgAMw/BCABdqxcIAADvoggAFATIA= Date: Tue, 12 Jul 2016 02:24:44 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48906FBF@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48911DD8@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48911DD8@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.112] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.578454F9.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.179, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9e5ebf30a8e8a38957296d47c8d1be8a Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 02:25:03 -0000 SGl5YQ0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBTY2hhcmYsIE1pY2hhZWwg KE5va2lhIC0gREUpIFttYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tXSANCuWPkemAgeaX tumXtDogMjAxNuW5tDfmnIgxMeaXpSAxODoxNg0K5pS25Lu25Lq6OiBRaW4gV3U7IG9wc2F3Z0Bp ZXRmLm9yZw0K5Li76aKYOiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13 dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQtMDAudHh0DQoNCkhpIFFpbiwNCg0KVGhh bmtzIGZvciB5b3VyIHJlcGx5LiBJbmxpbmUgc29tZSBmdXJ0aGVyIGNvbW1lbnRzIFttczJdLg0K DQo+IEhpIGFsbCwNCj4gDQo+IEkgaGF2ZSBxdWlja2x5IHNjYW5uZWQgdGhpcyBkb2N1bWVudC4g U29tZSBpbml0aWFsIGNvbW1lbnRzIFttc106DQo+IA0KPiAqKiogUGFnZSAzOg0KPiANCj4gICAg U2VydmljZSBNb2RlbDogIEEgc2VydmljZSBtb2RlbCBpcyBhIHNwZWNpZmljIHR5cGUgb2YgZGF0 YSBtb2RlbC4NCj4gSXQNCj4gICAgICAgZGVzY3JpYmVzIGEgc2VydmljZSBhbmQgYWxsIG9mIHRo ZSBwYXJhbWV0ZXJzIG9mIHRoZSBzZXJ2aWNlIGluIGENCj4gICAgICAgcG9ydGFibGUsIG9wZXJh dG9yLWluZGVwZW5kZW50IHdheS4gIEl0IGNhbiBiZSB1c2VkIGJ5IGEgaHVtYW4gb3INCj4gICAg ICAgYnkgc29mdHdhcmUgdG8gY29uZmlndXJlIG9yIHJlcXVlc3QgYSBzZXJ2aWNlIGFuZCBtYXkg ZXF1YWxseSBiZQ0KPiAgICAgICBjb25zdW1lZCBieSBhIGh1bWFuIG9yIGJ5IGEgc29mdHdhcmUg Y29tcG9uZW50Lg0KPiANCj4gW21zXSBJIHdvdWxkIHN1Z2dlc3QgYSBtb3JlIGNhcmVmdWwgd29y ZGluZyByZWdhcmRpbmcgdGhlIGNvbXBsZXRlbmVzcyANCj4gb2YgdGhlIG1vZGVsLCBlLmcuLCAi SXQgYWltcyBhdCBkZXNjcmliaW5nIGEgc2VydmljZSBhbmQgYWxsIG9mIHRoZSANCj4gcGFyYW1l dGVycyBvZiB0aGUgc2VydmljZS4uLiIuIEFzIGRpc2N1c3NlZCBpbiBMM1NNIGluIHRoZSBwYXN0 LCBmb3IgDQo+IGNlcnRhaW4gc2VydmljZXMgKGUuZy4sIGZpcmV3YWxscywgRG9TIHByZXZlbnRp b24sIC4uLikgdGhlIHNlcnZpY2UgDQo+IG1vZGVsIHdvdWxkIGhhdmUgdG8gYmUgZXh0ZW5kZWQg LyBhdWdtZW50ZWQuIEFsc28gbm90ZSB0aGF0IHRoZSANCj4gc3RhdGVtZW50ICJhbGwgcGFyYW1l dGVycyIgY29udHJhZGljdHMgdGhlIHN0YXRlbWVudCBvbiBTTEFzIGxhdGVyIGluIA0KPiB0aGUg dGV4dC4NCj4gDQo+IFtRaW5dIFdoYXQgdGhlIHNlcnZpY2UgaXMgaGFzIGJlZW4gd2VsbCBkZWZp bmVkIGFuZCBjbGFyaWZpZWQgYmVmb3JlIA0KPiBzZXJ2aWNlIG1vZGVsIGRlZmluaXRpb24gaW4g dGhlIHNlY3Rpb24gMi4NCj4gVGhhdCBpcyB0byBzYXksIEZpcmV3YWxsIGFuZCBEb1MgcHJldmVu dGlvbiBhcmUganVzdCBhZGRpdGlvbmFsIA0KPiBmdW5jdGlvbmFsaXRpZXMgdGhhdCBhcmUgdXNl ZCB0byBlbmhhbmNlIHRoZSBiYXNpYyBzZXJ2aWNlIHdlIGRlZmluZWQgDQo+IGluIHRoZSBkb2N1 bWVudC4NCj4gRm9yIHdoYXQgdGhlIHNlcnZpY2UgaXMgbm90IGlzIGZ1cnRoZXIgY2xhcmlmaWVk IGluIHRoZSBzZWN0aW9uIDUsIHRoZSANCj4gZmlyc3QgYnVsbGV0Lg0KDQpbbXMyXSBJIGFtIG5v dCBzdXJlIGlmIEkgY2FuIGZvbGxvdy4gTXkgcG9pbnQgaXMgdGhhdCB0aGUgd29yZGluZyAiZGVz Y3JpYmVzIGEgc2VydmljZSBhbmQgYWxsIG9mIHRoZSBwYXJhbWV0ZXJzIiBzZWVtcyBjb250cmFk aWN0aW5nIGdpdmVuIHRoZSB1c2Ugb2YgdGhlIHRlcm0gImFsbCIgaWYgeW91IGV4Y2x1ZGUgU0xB cy4gQWxzbywgU2VjdGlvbiA1IGRvZXMgbm90IHJlYWxseSBoYXZlIGEgd2VsbC1kZWZpbmVkIGRl ZmluaXRpb24gLSBleGNsdWRpbmcgc29tZSBleGFtcGxlcyBkb2VzIG5vdCBuZWNlc3NhcmlseSBy ZXN1bHQgaW4gYSBwcmVjaXNlIGRlZmluaXRpb24uIChJIGFncmVlIHRoYXQgIlNlcnZpY2UiIGlz IGNoYWxsZW5naW5nIHRvIGRlZmluZSBidXQgbWF5YmUgdGhpcyBjb3VsZCBiZSBvbmUgcmVhc29u IHRvIGZpbmQgYW4gYWx0ZXJuYXRpdmUgdGVybSB0byAic2VydmljZSBtb2RlbCIpLiANCg0KW1Fp bl06IEFzIHdlIGNsYXJpZmllZCBTZXJ2aWNlIExldmVsIEFncmVlbWVudHMgKFNMQXMpIGhhdmUg YSBoaWdoIGRlZ3JlZSBvZiBvdmVybGFwIA0KIHdpdGggdGhlIGRlZmluaXRpb24gb2Ygc2Vydmlj ZXMgcHJlc2VudCBpbiBzZXJ2aWNlIG1vZGVscywgYnV0IHdlIGRvbid0IHdhbnQgdG8gY292ZXIg YSBudW1iZXIgb2YgZmluZS1ncmFpbmVkIGRldGFpbHMgb2YgYXR0cmlidXRlcyBkZWZpbmVkIGlu IFNMQSBmb3IgdGhlIHJlYXNvbiBnaXZlbiBpbiBzZWN0aW9uIDUuDQogVGhhdCdzIHdoeSB3ZSBh ZGQgYSBjb25zdHJhaW50IGFmdGVyICIgZGVzY3JpYmVzIGEgc2VydmljZSBhbmQgYWxsIG9mIHRo ZSBwYXJhbWV0ZXJzICIgdG8gbGltaXQgdGhlc2UgcGFyYW1ldGVycyB0byBhYnN0cmFjdCBsZXZl bCBhbmQgb3BlcmF0b3IgaW5kZXBlbmRlbnQgd2F5LiBNYXliZSB3ZSBjb3VsZCBhZGQNCnNvbWUg dGV4dCB0byBtYWtlIHRoaXMgbW9yZSBjbGVhci4NCg0KPiBJbiBhZGRpdGlvbiwgd2UgZG9uJ3Qg dGFrZSBTTEEgZmluZSBncmFudWxhcml0eSBkZXRhaWxzIGNvbWJpbmluZyANCj4gY29tbWVyY2lh bCB0ZXJtcyBhcyBzZXJ2aWNlIHBhcmFtZXRlcnMsIHNvIEkgZG9uJ3Qgc2VlIHRoZXJlIGlzIA0K PiBpbmNvbnNpc3RlbmN5IGlzc3VlLCBmb3Igc29tZSBtaXNjb25jZXB0aW9uIG9uIHRoZSBzZXJ2 aWNlIG1vZGVsIA0KPiBVbmRlcnN0YW5kaW5nIGlzIGNsYXJpZmllZCBpbiB0aGUgZGlmZmVyZW50 IHNlY3Rpb24sIHRoaXMgaXMgDQo+IGludGVudGlvbmFsLg0KDQpbbXMyXSBNeSBwb2ludCBpcyB0 aGF0IFNMQSBwYXJhbWV0ZXJzIG1heSBiZSBhbiBpbXBvcnRhbnQgcGFydCBvZiB0aGUgY3VzdG9t ZXItc2VydmljZSBwcm92aWRlciBhZ3JlZW1lbnQgb2YgYSBzZXJ2aWNlIGFuZCBpdCBpcyBzdXJw cmlzaW5nIHRvIGZpcnN0IHNlZWluZyB0aGlzIG1lbnRpb25lZCBhdCB0aGUgZW5kIG9mIFNlY3Rp b24gNS4NCiANCltRaW5dOiBTdXJlLCB0byBhdm9pZCBjb25mdXNpb24gd2l0aCB0aGUgc2Vydmlj ZSBkZWZpbmVkIGluIHRoZSBtb2RlbCwgYXMgSSBtZW50aW9uZWQgYWJvdmUsIHdlIHVzZSB0aGUg ZGlmZmVyZW50IHRlcm0gZm9yIHRoZXNlIFF1YWxpdHkgcmVsYXRlZCBwYXJhbWV0ZXJzLg0KDQo+ IFttc10gSSBmaW5kIHRoZSB3b3JkaW5nICJpdCBjYW4gYmUgdXNlZCBieSBhIGh1bWFuLi4uIiBj b25mdXNpbmcuIElzIA0KPiB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgdXNlciB3b3VsZCBtYW51YWxs eSB0eXBlIGluIGEgc2VydmljZSByZXF1ZXN0IA0KPiByZXN1bHRpbmcgaW4gYSB2YWxpZCBkYXRh IG1vZGVsLCBlLmcuLCBieSBtYW51YWxseSB0eXBpbmcgaW4gTkVUQ09ORiANCj4gY29tbWFuZHM/ IEkgd291bGQgcmF0aGVyIHdyaXRlIHNvbWV0aGluZyBsaWtlICJ0aGUgcGFyYW1ldGVycyBjYW4g YmUgDQo+IGVudGVyZWQgYnkgc29mdHdhcmUgb3IgYWxzbyBtYW51YWxseSBieSBhIGh1bWFuLi4u Ig0KPiANCj4gW1Fpbl06IHdoYXQgd2UgdHJ5IHRvIGNvbnZleSBoZXJlIGlzIEh1bWFuIGNhbiBy ZWx5IG9uIENMSSxzY3JpcHQgb3IgDQo+IG90aGVyIGh1bWFuIHJlYWRhYmxlIGxhbmd1YWdlIHRv IGRlZmluZSBhIHNlcnZpY2UsIHJlcXVlc3QgdGhlIA0KPiBzZXJ2aWNlLCBidXQgc3VjaCBwYXJh bWV0ZXIgd2lsbCBub3QgZGlyZWN0bHkgaW1wbGVtZW50ZWQgYnkgbmV0d29yayBlbGVtZW50Lg0K DQpbbXMyXSBTdXJlLCBidXQgd2hhdCBpcyB0aGUgcm9sZSBvZiBhIHNlcnZpY2UgbW9kZWwgZGVm aW5lZCBpbiBZQU5HIGUuZy4gd2hlbiB0aGUgaHVtYW4gcmVsaWVzIG9uIENMSSBvciBzY3JpcHRz PyBUbyBtZSB0aGlzIHdvcmRpbmcgZG9lcyBub3QgZXhwbGFpbiB0aGlzIHdlbGwuDQoNCltRaW5d OiB3aHkgd2Ugc2hvdWxkIHRpZSBzZXJ2aWNlIG1vZGVsIGRlZmluaXRpb24gd2l0aCBZQU5HLCB0 aGUgc2VydmljZSBtb2RlbCBpcyBqdXN0IGEgc2VydmljZSB0ZW1wbGF0ZSwgeW91IGNhbiB1c2Ug aHVtYW4gcmVhZGFibGUgbGFuZ3VhZ2UgdG8gZXhwcmVzcyBpdCBvciB5b3UNCkNhbiB1c2UgbWFj aGluZSByZWFkYWJsZSBsYW5ndWFnZSB0byBleHByZXNzIGl0LCBpdCBkb2Vzbid0IG1hdHRlci4g VGhlcmVmb3JlLCBpbiBzb21lIGNhc2VzLCB5b3UganVzdCBuZWVkIGZpbGwgdGhlIHNlcnZpY2Ug cGFyYW1ldGVycyBpbiBzb21lIGtpbmQgb2YgZm9ybSBhbmQgc3VibWl0IHRoaXMgZm9ybQ0KdG8g dGhlIHNlcnZlciBmb3IgZnVydGhlciBwYXJzaW5nIGFuZCBpbnRlcnByZXRhdGlvbi4NCiANCj4g KioqIFBhZ2UgMzoNCj4gDQo+ICAgIFRoZSBlbmNvZGluZyBhbmQgY29tbXVuaWNhdGlvbiBwcm90 b2NvbCB1c2VkIHRvIGV4Y2hhbmdlIGEgc2VydmljZQ0KPiAgICBtb2RlbCBiZXR3ZWVuIGN1c3Rv bWVyIGFuZCBuZXR3b3JrIG9wZXJhdG9yIGFyZSBkZXBsb3ltZW50LSBhbmQNCj4gICAgaW1wbGVt ZW50YXRpb24tc3BlY2lmaWMuICBUaGUgSUVURiByZWNvbW1lbmRzIHRoZSB1c2Ugb2YgdGhlIE5F VENPTkYNCj4gICAgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBbUkZDNDc0MV0gd2l0aCBkYXRhIGVu Y29kZWQgaW4gWE1MIG9yIEpTT04gDQo+IGZvcg0KPiAgICBpbnRlcmFjdGlvbnMgIm9uIHRoZSB3 aXJlIiBiZXR3ZWVuIHNvZnR3YXJlIGNvbXBvbmVudHMuICBIb3dldmVyLA0KPiBjby0NCj4gICAg bG9jYXRlZCBzb2Z0d2FyZSBjb21wb25lbnRzIG1pZ2h0IHVzZSBhbiBBUEksIHdoaWxlIHN5c3Rl bXMgd2l0aCANCj4gbW9yZQ0KPiAgICBkaXJlY3QgaHVhbiBpbnRlcmFjdGlvbnMgbWlnaHQgdXNl IHdlYiBwYWdlcyBvciBldmVuIHBhcGVyIGZvcm1zLg0KPiANCj4gW21zXSBJIGFtIG5vdCBzdXJl IGlmIHRoZSBJRVRGIHNob3VsZCBzdWdnZXN0IHRoZSB1c2Ugb2YgTkVUQ09ORiBvbiANCj4gdGhl IG5vcnRoYm91bmQgaW50ZXJmYWNlIG9mIGEgInNlcnZpY2Ugb3JjaGVzdHJhdG9yIiwgd2hpY2gg c2VlbXMgdG8gDQo+IGJlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiBBcmUgdGhlcmUgcG9p bnRlcnMgdG8gcnVubmluZyBjb2RlIHRoYXQgDQo+IGFjdHVhbGx5IGRvIHRoYXQ/IEkgd291bGQg cmF0aGVyIHByZWZlciBhIHdvcmRpbmcgc3VjaCBhcyAiVGhlIElFVEYgDQo+IGhhcyBzdGFuZGFy ZGl6ZWQgTkVUQ09ORiBhbmQgUkVTVENPTkYgZm9yIGludGVyYWN0aW9ucyAib24gdGhlIHdpcmUi DQo+IGJldHdlZW4gc29mdHdhcmUgY29tcG9uZW50cyIuDQo+IA0KPiBbUWluXTogWW91IGFyZSBy aWdodCwgSSB0aGluayBSRVNDT05GIGlzIHJlY29tbWVuZGVkIG9uIHRoZSBub3J0aGJvdW5kIA0K PiBpbnRlcmZhY2Ugb2YgYSBzZXJ2aWNlIG9yY2hlc3RyYXRvciwgeW91ciBwcm9wb3NlZCBjaGFu Z2UgbG9va3MgZ29vZC4NCj4gVGhhbmtzLg0KPiANCj4gKioqIFBhZ2UgNzoNCj4gDQo+ICAgIG8g IFRoZSBuZXR3b3JrIG9wZXJhdG9yIG1heSB1c2UgZnVydGhlciBkYXRhIG1vZGVscyB0aGF0IGhl bHAgdG8NCj4gICAgICAgZGVzY3JpYmUgaG93IHRoZSBzZXJ2aWNlIGlzIHJlYWxpemVkIGluIHRo ZSBuZXR3b3JrLiAgVGhlc2UgDQo+IG1vZGVscw0KPiAgICAgICBtaWdodCBiZSB1c2VkIG9uIHRo ZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgU2VydmljZSBPcmNoZXN0cmF0b3INCj4gICAgICAgYW5k IHRoZSBOZXR3b3JrIE9yY2hlc3RyYXRvciBhcyBzaG93biBpbiBGaWd1cmUgMyBhbmQgbWlnaHQN Cj4gICAgICAgaW5jbHVkZSBtYW55IG9mIHRoZSBwaWVjZXMgb2YgaW5mb3JtYXRpb24gaW4gdGhl IHNlcnZpY2UgbW9kZWwNCj4gICAgICAgYWxvbmdzaWRlIHByb3RvY29sIHBhcmFtZXRlcnMgYW5k IGRldmljZSBjb25maWd1cmF0aW4gDQo+IGluZm9ybWF0aW9uLg0KPiAgICAgICBJdCBpcyBpbXBv cnRhbnQgdGhhdCB0aGUgU2VydmljZSBPcmNoZXN0cmF0b3Igc2hvdWxkIGJlIGFibGUgdG8NCj4g ICAgICAgbWFwIGZyb20gYSBzZXJ2aWNlIG1vZGVsIHRvIHRoZXNlIGRhdGEgbW9kZWxzLCBidXQg dGhleSBhcmUgbm90DQo+ICAgICAgIHRoZSBzYW1lIHRoaW5ncy4NCj4gDQo+IFttc10gV2h5IGlz IGl0IG5vdCBwb3NzaWJsZSB0aGF0IHRoZSBkYXRhIG1vZGVscyBhcmUgdGhlIHNhbWU/IEluIA0K PiBGaWd1cmUgMywgdGhlICJzZXJ2aWNlIG9yY2hlc3RyYXRvciIgaXMgYWN0dWFsbHkgYSAiY2xp ZW50IiAocmVhZCB0aGlzIA0KPiBhcyAiY3VzdG9tZXIiKSBvZiB0aGUgIm5ldHdvcmsgb3JjaGVz dHJhdG9ycyIuIEluc2lkZSBhbiBvcGVyYXRvciwgdGhlIA0KPiAic2VydmljZSBvcmNoZXN0cmF0 b3IiIGNvdWxkIGJlIG9wZXJhdGVkIGJ5IGEgZGlmZmVyZW50IG9yZ2FuaXphdGlvbiANCj4gdGhh biB0aGUgIm5ldHdvcmsgb3JjaGVzdHJhdG9yIiwgaS5lLiwgdGhlcmUgb3VsZCBldmVuIGJlIGEg YnVzaW5lc3MgDQo+IHJlbGF0aW9uc2hpcC4gSW4gZ2VuZXJhbCwgYXJjaGl0ZWN0dXJlcyBjYW4g YmUgcmVjdXJzaXZlLiBJIHRoaW5rIHRoaXMgDQo+IHN0YXRlbWVudCByZXF1aXJlcyBmdXJ0aGVy IGV4cGxhbmF0aW9uIG9yIHJld29yZGluZy4NCj4gDQo+IFtRaW5dOiBUaGUgY29uY2VwdCB0byBz cGxpdCBPcmNoZXN0cmF0b3IgaW50byBzZXJ2aWNlIG9yY2hlc3RyYXRvciBhbmQgDQo+IG5ldHdv cmsgb3JjaGVzdHJhdG9yLCBpcyB0aGUgc2VydmljZSBvcmNoZXN0cmF0b3IgaXMgbmV0d29yayBh Z25vc3RpYyANCj4gd2hpbGUgbmV0d29yayBvcmNoZXN0cmF0b3IgaXMgbmV0d29yayBhd2FyZS4N Cj4gU2VydmljZSBtb2RlbCBjb25zdW1lZCBieSB0aGUgc2VydmljZSBvcmNoZXN0cmF0b3IgY291 bGQgYmUgZGlmZmVyZW50IA0KPiBmcm9tIHRoZSBkYXRhIG1vZGVsIGNvbnN1bWVkIGJ5IG5ldHdv cmsgb3JjaGVzdHJhdG9yIHNpbmNlIG5ldHdvcmsgDQo+IG9yY2hlc3RyYXRvciBuZWVkIHRvIGRl Y2lkZSB3aGF0IG5ldHdvcmsgZGV2aWNlIGlzIHNlbGVjdGVkLCB3aGljaCANCj4gcHJvdG9jb2wg aXMgZW5hYmxlZCwgd2hpY2ggdGVjaG5vbG9neSBpcyB1c2VkLCB3aGljaCBuZXR3b3JrIGludGVy ZmFjZSANCj4gb3IgcG9ydCBpcyBhc3NpZ25lZC4gVGhlIHNlcnZpY2Ugb3JjaGVzdHJhdG9yIGRv ZXNuJ3QgbmVlZCB0byBjYXJlIA0KPiBhYm91dCB0aGUgdW5kZXJseWluZyB0ZWNobm9sb2d5IG9y IHdoYXQgcHJvdG9jb2wgaXMgYXZhaWxhYmxlLg0KDQpbbXMyXSBZb3UgbWF5IHdhbnQgdG8gYWRk IHRoYXQgYXNzdW1wdGlvbiBtb3JlIGV4cGxpY2l0bHkgdG8gdGhlIHRleHQgYW5kIHBvc3NpYmx5 IGFkZCB0aGF0IHRoaXMgaXMgb25seSBvbmUgcG90ZW50aWFsIGFyY2hpdGVjdHVyZS4gDQoNCltR aW5dOiBXZSBnaXZlIHR3byBvcHRpb25hbCBhcmNoaXRlY3R1cmUgaW4gdGhlIGZpZ3VyZSAyIGFu ZCBmaWd1cmUgMywgbGV0IHVzIGtub3cgaWYgdGhlcmUgaXMgYW55IHBvdGVudGlhbCBhcmNoaXRl Y3R1cmUgd2UgYXJlIG1pc3NpbmcuDQo+ICoqKiBQYWdlIDc6DQo+IA0KPiAgICBvICBTZXJ2aWNl IExldmVsIEFncmVlbWVudHMgKFNMQXMpIGhhdmUgYSBoaWdoIGRlZ3JlZSBvZiBvdmVybGFwIA0K PiB3aXRoDQo+ICAgICAgIHRoZSBkZWZpbml0aW9uIG9mIHNldmljZXMgcHJlc2VudCBpbiBzZXJ2 aWNlIG1vZGVscy4gIFJlcXVlc3RzIA0KPiBmb3INCj4gICAgICAgc3BlY2lmaWMgYmFuZHdpZHRo LCBmb3IgZXhhbXBsZSwgbWlnaHQgYmUgcHJlc2VudCBpbiBhIHNlcnZpY2UNCj4gICAgICAgbW9k ZWwsIGFuZCBhZ3JlZW1lbnQgdG8gZGVsaXZlciBhIHNlcnZpY2UgaXMgYSBjb21taXRtZW50IHRv IHRoZQ0KPiAgICAgICBkZXNjcmlwdGlvbiBvZiB0aGUgc2VydmljZSBpbiB0aGUgc2VydmljZSBt b2RlbCwgaG93ZXZlciwgU0xBcw0KPiAgICAgICB0eXBpY2FsbHkgaW5jbHVkZSBhIG51bWJlciBv ZiBmaW5lLWdyYWluZWQgZGV0YWlscyBhYm91dCBob3cNCj4gICAgICAgc2VydmljZXMgYXJlIGFs bG93ZWQgdG8gdmFyeSwgYnkgaG93IG11Y2gsIGFuZCBob3cgb2Z0ZW4uICBTTEFzDQo+ICAgICAg IGFyZSBhbHNvIGxpbmtlZCB0byBjb21tZXJjaWFsIHRlcm1zIHdpdGggcGVuYWx0aWVzIGFuZCBz byBmb3J0aCwNCj4gICAgICAgYW5kIHNvIGFyZSBhbHNvIG5vdCBnb29kIHRvcGljcyBmb3Igc3Rh bmRhcmRpemF0aW9uLg0KPiANCj4gW21zXSBJIHdvbmRlciBpZiBpdCBjb3VsZCBtYWtlIHNlbnNl IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gU0xBIGFuZCANCj4gU2VydmljZSBMZXZlbCBPYmplY3Rp dmUgKFNMTykgb3IgU2VydmljZSBMZXZlbCBSZXF1aXJlbWVudCAoU0xSKS4gDQo+IFdoaWxlIEkg YWdyZWUgdGhhdCBpdCBpcyBkaWZmaWN1bHQgdG8gc3RhbmRhcmRpemUgY29tbWVyY2lhbCB0ZXJt cywgDQo+IHRoaXMgSU1ITyBwYXJ0bHkgY29udHJhZGljdHMgdGhlIHBvc2l0aW9uaW5nIG9mIHRo ZSB0ZXJtICJzZXJ2aWNlIA0KPiBtb2RlbCIgZWFybGllciBpbiB0aGUgZG9jdW1lbnQuIE1heWJl IHRoZSBzY29wZSBvZiB0aGUgZGVmaW5pdGlvbiBvZiAic2VydmljZSBtb2RlbCINCj4gaGFzIHRv IGJlIG5hcnJvd2VkIGRvd24/DQo+IA0KPiBbUWluXTogV2UgaGF2ZSBjbGFyaWZpZWQgd2hhdCB0 aGUgc2VydmljZSBpcyBpbiB0aGUgc2VjdGlvbiAyIGFuZCBPdXIgDQo+IHNlcnZpY2UgbW9kZWwg ZGVmaW5pdGlvbiBhbGlnbnMgd2l0aCBzZXJ2aWNlIGRlZmluaXRpb24uIFllcywgd2UgbmVlZCAN Cj4gdG8gZGlzdGluZ3Vpc2ggU0xBIGZyb20gU2VydmljZSBMZXZlbCBPYmplY3RpdmUvUmVxdWly ZW1lbnQsIGJ1dCBub3QgDQo+IG5lY2Vzc2FyeSBpbnRyb2R1Y2UgYW5vdGhlciBuZXcgdGVybS4g V2UgaGF2ZSBjbGFyaWZpZWQgdGhlaXIgDQo+IGRpZmZlcmVuY2UgaW4gdGhlIHRleHQgeW91IHF1 b3RlZC4NCg0KW21zMl0gV2VsbCwgSSB0aGluayB5b3Ugc2hvdWxkIGNvbW1lbnQgb24gU0xBcyBp biBTZWN0aW9uIDIgdG8gYXZvaWQgY29uZnVzaW9uLg0KDQpbUWluXTogRG9uZSwgc2VlIGFib3Zl Lg0KDQpNaWNoYWVsDQoNCg0KDQo+ICoqKiBwYWdlIDk6DQo+IA0KPiA2LjQuICBTdXBwb3J0aW5n IE11bHRpcGxlIFNlcnZpY2VzDQo+IA0KPiAgICBOZXR3b3JrIG9wZXJhdG9ycyB3aWxsLCBpbiBn ZW5lcmFsLCBvZmZlciBtYW55IGRpZmZlcmVudCBzZXJ2aWNlcyB0bw0KPiAgICB0aGVpciBjdXN0 b21lcnMuICBFYWNoIHdvdWxkIG5vcm1hbGx5IGJlIHRoZSBzdWJqZWN0IG9mIGEgc2VwYXJhdGUN Cj4gICAgc2VydmljZSBtb2RlbC4NCj4gDQo+IFttc10gVGhlIGFjdHVhbCBxdWVzdGlvbiBoZXJl IGlzIGlmIHRoZXJlIGNvdWxkIGJlIGNvbW11bmFsaXR5IGJldHdlZW4gDQo+IHNlcnZpY2UgbW9k ZWxzIGZvciBzaW1pbGFyIHNlcnZpY2VzLiBUaGF0IHByb2JsZW0gY2Fubm90IGJlIHNvbHZlZCBi eSANCj4gdGhpcyBkb2N1bWVudCBidXQgdGhlIHRleHQgY291bGQgZS5nLiBleHBsYWluIHRoYXQg Zm9yIGEgY3VzdG9tZXIgaXQgDQo+IGNhbiBiZSBjb25mdXNpbmcgaWYgc2VwYXJhdGUgc2Vydmlj ZSBtb2RlbHMgbW9kZWwgcmVsYXRlZCBjb25jZXB0cyBpbiANCj4gZGlmZmVyZW50IHdheXMuDQo+ IA0KPiBbUWluXTogVGhhdCBpcyBhIGdvb2QgcXVlc3Rpb24sIEkgaG9wZSBzb21lIGJ1aWxkaW5n IGJsb2NrcyBzcGVjaWZpZWQgDQo+IGJ5IG9uZSBzZXJ2aWNlIG1vZGVsIGNhbiBiZSByZXVzZWQg aW4gYW5vdGhlciBzZXJ2aWNlIG1vZGVsLg0KPiBVbmZvcnR1bmF0ZWx5IHdlIGRvbid0IGhhdmUg dG9vIG1hbnkgWUFORyBtb2RlbHMgdGhhdCBhcmUgdXNlZCB0byANCj4gbW9kZWwgc2VydmljZSBp biB0aGUgSUVURi4gV2UgY291bGQgY292ZXIgdGhpcyBpbiB0aGUgbmV4dCB2ZXJzaW9uIGlmIA0K PiBtb3JlIHN1Y2ggc2VydmljZSBtb2RlbHMgYXJlIG5lZWRlZC4NCj4gDQo+IFRoYW5rcw0KPiAN Cj4gTWljaGFlbA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUWlu IFd1DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDUsIDIwMTYgMjowMiBQTQ0KPiBUbzogb3BzYXdn QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbT1BTQVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXd1LW9wc2F3Zy0gDQo+IHNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAwLnR4 dA0KPiANCj4gSGksDQo+IFdlIGhhdmUgc3VibWl0dGVkIGEgbmV3IEktRCB0aGF0IGRpc2N1c3Nl cyB0aGUgc2NvcGUgYW5kIHB1cnBvc2Ugb2YgDQo+IHNlcnZpY2UgbW9kZWxzIHdpdGhpbiB0aGUg SUVURiBhbmQgZGVzY3JpYmVzIGhvdyBhIHNlcnZpY2UgbW9kZWwgY2FuIA0KPiBiZSB1c2VkIGJ5 IGEgbmV0d29yayBvcGVyYXRvci4NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtDQo+IGV4cGxhaW5lZC8NCj4gDQo+IEluIGFk ZGl0aW9uLCB0aGlzIGRyYWZ0IGNsYXJpZmllcyB0aGUgcm9sZSBhbmQgcG9zaXRpb24gb2Ygc2Vy dmljZSANCj4gbW9kZWwgaW4gdGhlIFNETiBhcmNoaXRlY3R1cmUgYW5kIENsZWFyIHNldmVyYWwg bWlzY29uY2VwdGlvbiBvbiB0aGUgDQo+IHNlcnZpY2UgbW9kZWwuDQo+IA0KPiBZb3VyIHF1ZXN0 aW9ucyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUuDQo+IA0KPiBSZWdhcmRzIQ0KPiAtUWluDQo+ IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IOWPkemAgeaXtumXtDog MjAxNuW5tDfmnIg15pelIDE5OjU1DQo+IOaUtuS7tuS6ujogTGl1c2h1Y2hlbmcgKFdpbGwpOyBB ZHJpYW4gRmFycmVsOyBMaXVzaHVjaGVuZyAoV2lsbCk7IFFpbiBXdQ0KPiDkuLvpopg6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtIA0K PiBleHBsYWluZWQtMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMC50eHQNCj4gaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBRaW4gV3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiANCj4g cmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1l eHBsYWluZWQNCj4gUmV2aXNpb246CTAwDQo+IFRpdGxlOgkJU2VydmljZSBNb2RlbHMgRXhwbGFp bmVkDQo+IERvY3VtZW50IGRhdGU6CTIwMTYtMDctMDUNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gUGFnZXM6CQkxMg0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXd1LW9wc2F3Zy0NCj4gc2VydmljZS1tb2RlbC1l eHBsYWluZWQtMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC13dS1vcHNhd2ctDQo+IHNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLw0K PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LW9w c2F3Zy1zZXJ2aWNlLQ0KPiBtb2RlbC1leHBsYWluZWQtMDANCj4gDQo+IA0KPiBBYnN0cmFjdDoN Cj4gICAgVGhlIElFVEYgaGFzIHByb2R1Y2VkIGEgY29uc2lkZXJhYmxlIG51bWJlciBvZiBkYXRh IG1vZGVscyBpbiB0aGUNCj4gICAgWUFORyBtb2RlbGxpbmcgbGFuZ3VhZ2UuICBUaGUgbWFqb3Jp dHkgb2YgdGhlc2UgYXJlIHVzZWQgdG8gbW9kZWwNCj4gICAgZGV2aWNlcyBhbmQgdGhleSBhbGxv dyBhY2Nlc3MgZm9yIGNvbmZpZ3VyYXRpb24gYW5kIHRvIHJlYWQNCj4gICAgb3BlcmF0aW9uYWwg c3RhdHVzLg0KPiANCj4gICAgQSBzbWFsbCBudW1iZXIgb2YgWUFORyBtb2RlbHMgYXJlIHVzZWQg dG8gbW9kZWwgc2VydmljZXMgKGZvcg0KPiAgICBleGFtcGxlLCB0aGUgTGF5ZXIgVGhyZWUgVmly dHVhbCBQcml2YXRlIE5ldHdvcmsgU2VydmljZSBNb2RlbA0KPiAgICBwcm9kdWNlZCBieSB0aGUg TDNTTSB3b3JraW5nIGdyb3VwKS4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgYnJpZWZseSBzZXRz IG91dCB0aGUgc2NvcGUgb2YgYW5kIHB1cnBvc2Ugb2YgYW4gSUVURg0KPiAgICBzZXJ2aWNlIG1v ZGVsLCBhbmQgaXQgc2hvd3Mgd2hlcmUgYSBzZXJ2aWNlIG1vZGVsIG1pZ2h0IGZpdCBpbnRvIGEN Cj4gICAgU29mdHdhcmUgRGVmaW5lZCBOZXR3b3JraW5nIGFyY2hpdGVjdHVyZSBvciBkZXBsb3lt ZW50Lg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCANCj4gdG9vbHMuaWV0 Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT1BTQVdHIG1haWxpbmcgbGlzdA0K PiBPUFNBV0dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vcHNhd2cNCg== From nobody Wed Jul 13 04:13:39 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D370E12DDCA for ; Wed, 13 Jul 2016 04:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 aV8lnbKmT6uV for ; Wed, 13 Jul 2016 04:13:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D045C12DDB4 for ; Wed, 13 Jul 2016 04:13:22 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6DBDCT7006789; Wed, 13 Jul 2016 12:13:12 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6DBD6CQ006637 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2016 12:13:07 +0100 From: "Adrian Farrel" To: "'Qin Wu'" , "'Scharf, Michael \(Nokia - DE\)'" , "'opsawg@ietf.org'" References: <655C07320163294895BBADA28372AF5D48906FBF@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48911DD8@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Date: Wed, 13 Jul 2016 12:13:07 +0100 Message-ID: <011801d1dcf7$895f44d0$9c1dce70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFfs4zaDoqeb5eNCXm4VqxkJgAD4wOUmJYRAeZdkWIBbwAV2AI++0WnoLE6sCA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22448.006 X-TM-AS-Result: No--26.740-10.0-31-10 X-imss-scan-details: No--26.740-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wgPZZctd3P4BfjJOgArMOCZJ2J+Cmyj8kTzW aLWbt415AkeZ7COZjd0lnaqN6tzn2YqqaTsYvaNWE0Q83A2vD+sbh3PtTCkP/5iFs+5kvUgPzeq GkgTbqS+GnhlT2IJuFEu9yaCA0I5ADtBt+r/CzCpswYo64ufkVZOBXaF4TRYNIbxYwbCxGTRzLi ypTPAGO7REB7PxXa8LlefvKsn2vON7bpSjXj1TiZJEUO2qIzlLpfVcx39Kq+5cKZwALwMGs4QmE NBkUZwTjicdtTx1Pj1TvqQPS5aaaUIw4Xa9LAtMlTsGW3DmpUtEN0QsOsI68/7spkgIRsSyMLSk khBSIk6EFYMIPgvbME5GOprUX2+BVlA3jidwVHWsgaPSWrovRsnlJe2gk8vIZ5mgE5HjtBuzxmN f8i6uu9rtTKcRwDLZ1t84bFdwzLMbRA6RIxFrBaOuVibdZNTv+lX/RcQoG2EgOnjvjQ5gMR0hhG d4LdX+nvJjIv+n45K8CLx7qXKdUsfPSLfYB4kRlUgQqGVMqmygD0t7xcmluuyoRjfYVC+cg3YrK 4vdXSqTwe8eIyYTWLpaun5+C0Zj/lmiyIepCs3iHyvyXeXh5s63lapMoykSjNnoU1fopoukWBur +Zjr5OU04QQ9hMrB/MS/dgcUqtmjSJP27pLV4BMxKDqgAFSz1kqyrcMalqVElaZ44wdr5FA4MdR 4SP+UtNQuqM+VU4hy7VXpW/3hAbce09VUwcq0c+uqdl18mG8TcFr9nQa5pKwgydzPLF7nsUOKlG 2WJG468Nou0gejgUpQ034k9sWD6stk8qm1HFSeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 11:13:38 -0000 Hi Michael and Qin, Thanks for the constructive discussions. In line... > > I have quickly scanned this document. Some initial comments [ms]: > > > > *** Page 3: > > > > Service Model: A service model is a specific type of data model. > >=20 > > It describes a service and all of the parameters of the service in = a > > portable, operator-independent way. It can be used by a human = or > > by software to configure or request a service and may equally = be > > consumed by a human or by a software component. > > > > [ms] I would suggest a more careful wording regarding the = completeness > > of the model, e.g., "It aims at describing a service and all of the > > parameters of the service...". As discussed in L3SM in the past, for > > certain services (e.g., firewalls, DoS prevention, ...) the service > > model would have to be extended / augmented. Also note that the > > statement "all parameters" contradicts the statement on SLAs later = in > > the text. > > > > [Qin] What the service is has been well defined and clarified before > > service model definition in the section 2. > > That is to say, Firewall and DoS prevention are just additional > > functionalities that are used to enhance the basic service we = defined > > in the document. > > For what the service is not is further clarified in the section 5, = the > > first bullet. >=20 > [ms2] I am not sure if I can follow. My point is that the wording = "describes a > service and all of the parameters" seems contradicting given the use = of the term > "all" if you exclude SLAs. Also, Section 5 does not really have a = well-defined > definition - excluding some examples does not necessarily result in a = preciser > definition. (I agree that "Service" is challenging to define but maybe = this could be > one reason to find an alternative term to "service model"). >=20 > [Qin]: As we clarified Service Level Agreements (SLAs) have a high = degree of > overlap > with the definition of services present in service models, but we = don't want to > cover a number of fine-grained details of attributes defined in SLA = for the reason > given in section 5. > That's why we add a constraint after " describes a service and all of = the > parameters " to limit these parameters to abstract level and operator > independent way. Maybe we could add > some text to make this more clear. I think this is a language issue. I tend to agree with Michel that "all" is a risky word. Clearly we (well, OK, I wrote those words) meant "all of the parameters = that describe the part of the service we are describing". We did not = mean *all* and that should be clear from the discussions of = augmentations that operators might make to cover their own additions to = the base service. What we are trying to do is: - define a core, base service that all operators agree on - list *all* of the parameters of that core, base service - list all of the settings of those parameters necessary to define that core, base service. We can make that clearer. > > In addition, we don't take SLA fine granularity details combining > > commercial terms as service parameters, so I don't see there is > > inconsistency issue, for some misconception on the service model > > Understanding is clarified in the different section, this is > > intentional. >=20 > [ms2] My point is that SLA parameters may be an important part of the = customer- > service provider agreement of a service and it is surprising to first = seeing this > mentioned at the end of Section 5. >=20 > [Qin]: Sure, to avoid confusion with the service defined in the model, = as I > mentioned above, we use the different term for these Quality related > parameters. I agree with both of you here. Without doubt, SLA will form an important part of the commercial = agreement between operator and customer. However, with the exception of some high-level parameters of the service = (such as bandwidth) we find that SLA parameters vary widely between = operators. I'm aware that a number of organisations (most notably TMF) have spent a = lot of time parameterising and generalising SLAs. This may be something = we can try to do as well, but in my opinion it is both hard and an = extension to the service model work we are doing. > > [ms] I find the wording "it can be used by a human..." confusing. Is > > the assumption that a user would manually type in a service request > > resulting in a valid data model, e.g., by manually typing in NETCONF > > commands? I would rather write something like "the parameters can be > > entered by software or also manually by a human..." > > > > [Qin]: what we try to convey here is Human can rely on CLI,script or > > other human readable language to define a service, request the > > service, but such parameter will not directly implemented by network = element. >=20 > [ms2] Sure, but what is the role of a service model defined in YANG = e.g. when > the human relies on CLI or scripts? To me this wording does not = explain this well. >=20 > [Qin]: why we should tie service model definition with YANG, the = service model is > just a service template, you can use human readable language to = express it or > you > Can use machine readable language to express it, it doesn't matter. = Therefore, in > some cases, you just need fill the service parameters in some kind of = form and > submit this form to the server for further parsing and interpretation. I think we might go for "it can be used by a human via a user interface = such as a GUI, web form, or CLI" to cover the meaning. What we are really doing is distinguishing between human control (by = whatever means) and application (i.e., autonomous software) control. > > *** Page 3: > > > > The encoding and communication protocol used to exchange a = service > > model between customer and network operator are deployment- and > > implementation-specific. The IETF recommends the use of the = NETCONF > > Configuration Protocol [RFC4741] with data encoded in XML or JSON > > for > > interactions "on the wire" between software components. However, > > co- > > located software components might use an API, while systems with > > more > > direct huan interactions might use web pages or even paper forms. > > > > [ms] I am not sure if the IETF should suggest the use of NETCONF on > > the northbound interface of a "service orchestrator", which seems to > > be the scope of this document. Are there pointers to running code = that > > actually do that? I would rather prefer a wording such as "The IETF > > has standardized NETCONF and RESTCONF for interactions "on the wire" > > between software components". > > > > [Qin]: You are right, I think RESCONF is recommended on the = northbound > > interface of a service orchestrator, your proposed change looks = good. > > Thanks. > > > > *** Page 7: > > > > o The network operator may use further data models that help to > > describe how the service is realized in the network. These > > models > > might be used on the interface between the Service = Orchestrator > > and the Network Orchestrator as shown in Figure 3 and might > > include many of the pieces of information in the service model > > alongside protocol parameters and device configuratin > > information. > > It is important that the Service Orchestrator should be able = to > > map from a service model to these data models, but they are = not > > the same things. > > > > [ms] Why is it not possible that the data models are the same? In > > Figure 3, the "service orchestrator" is actually a "client" (read = this > > as "customer") of the "network orchestrators". Inside an operator, = the > > "service orchestrator" could be operated by a different organization > > than the "network orchestrator", i.e., there ould even be a business > > relationship. In general, architectures can be recursive. I think = this > > statement requires further explanation or rewording. > > > > [Qin]: The concept to split Orchestrator into service orchestrator = and > > network orchestrator, is the service orchestrator is network = agnostic > > while network orchestrator is network aware. > > Service model consumed by the service orchestrator could be = different > > from the data model consumed by network orchestrator since network > > orchestrator need to decide what network device is selected, which > > protocol is enabled, which technology is used, which network = interface > > or port is assigned. The service orchestrator doesn't need to care > > about the underlying technology or what protocol is available. >=20 > [ms2] You may want to add that assumption more explicitly to the text = and > possibly add that this is only one potential architecture. >=20 > [Qin]: We give two optional architecture in the figure 2 and figure 3, = let us know if > there is any potential architecture we are missing. Additionally, we tried to capture this in Section 5. > > *** Page 7: > > > > o Service Level Agreements (SLAs) have a high degree of overlap > > with > > the definition of sevices present in service models. Requests > > for > > specific bandwidth, for example, might be present in a service > > model, and agreement to deliver a service is a commitment to = the > > description of the service in the service model, however, SLAs > > typically include a number of fine-grained details about how > > services are allowed to vary, by how much, and how often. = SLAs > > are also linked to commercial terms with penalties and so = forth, > > and so are also not good topics for standardization. > > > > [ms] I wonder if it could make sense to distinguish between SLA and > > Service Level Objective (SLO) or Service Level Requirement (SLR). > > While I agree that it is difficult to standardize commercial terms, > > this IMHO partly contradicts the positioning of the term "service > > model" earlier in the document. Maybe the scope of the definition of = "service > model" > > has to be narrowed down? > > > > [Qin]: We have clarified what the service is in the section 2 and = Our > > service model definition aligns with service definition. Yes, we = need > > to distinguish SLA from Service Level Objective/Requirement, but not > > necessary introduce another new term. We have clarified their > > difference in the text you quoted. >=20 > [ms2] Well, I think you should comment on SLAs in Section 2 to avoid = confusion. >=20 > [Qin]: Done, see above. >=20 > > *** page 9: > > > > 6.4. Supporting Multiple Services > > > > Network operators will, in general, offer many different services = to > > their customers. Each would normally be the subject of a = separate > > service model. > > > > [ms] The actual question here is if there could be communality = between > > service models for similar services. That problem cannot be solved = by > > this document but the text could e.g. explain that for a customer it > > can be confusing if separate service models model related concepts = in > > different ways. > > > > [Qin]: That is a good question, I hope some building blocks = specified > > by one service model can be reused in another service model. > > Unfortunately we don't have too many YANG models that are used to > > model service in the IETF. We could cover this in the next version = if > > more such service models are needed. Agree with both of you. We're still playing with our first few service models so it is hard to = guess how this will pan out. But I suspect that the "building block" = approach will be what we end up with. Best, Adrian From nobody Thu Jul 14 01:14:34 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE6512DAEF for ; Thu, 14 Jul 2016 01:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5MdyrQ8EHa67 for ; Thu, 14 Jul 2016 01:14:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC9D12DAE7 for ; Thu, 14 Jul 2016 01:14:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSO00938; Thu, 14 Jul 2016 08:14:25 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Jul 2016 09:14:22 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 14 Jul 2016 16:14:14 +0800 From: Zhoutianran To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" Thread-Topic: a new version of the automatic attachment drafts Thread-Index: AdHSL7Tm7cjwLHTRRWWWYvwrin0y4AGjPzDAAKV0qmAAlMwpsA== Date: Thu, 14 Jul 2016 08:14:14 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA75220B90@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA75235990@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA75235990@AZ-FFEXMB04.global.avaya.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183C1C235NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.578749E1.0083, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e26fbe729c3486dbe037792d5a0b308b Archived-At: Cc: "Unbehagen Jr, Paul E \(Paul\)" Subject: Re: [OPSAWG] a new version of the automatic attachment drafts X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 08:14:33 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2183C1C235NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, Thank you for the reply. That makes me clear now. I was once interested on the cloud VPN solution. The customer provisioned v= irtual private cloud can automatically joins(attach to) the existing enterp= rise VPN. I think the scenario also fit in this framework. It might be one use case c= onsidered in your draft. Regards, Tianran From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Monday, July 11, 2016 5:20 PM To: Zhoutianran; opsawg@ietf.org Cc: Unbehagen Jr, Paul E (Paul) Subject: RE: a new version of the automatic attachment drafts Hi Tianran, Thank you for the reading and for the comments. Your observation is very correct and it relates to something that we failed= to explain in enough details in the I-D. The AA controller in the diagram = should not be regarded as a 'super-controller' across administrative domain= s, but rather as a policy function that applies to the network and may be i= nstantiated in different ways. The 'vertical' data model (6) in the diagram= does not carry the same information to AACs and AASs. There are two possib= le scenarios here: 1. The AA controller connects only to the AAS and configures the mappi= ng policies on the network devices. Clients are configured mainly by the ho= rizontal interaction - this will be true also in most of the IoT scenarios 2. Both AAS and AACs connect to the AA controller function. The client= s get authentication and local security and local services information from= the controller (what services are available, how you configure to them). S= ervers perform same functionality as in #1. The implementation of the contr= oller may be distributed, possibly with an 'orchestration' function in-betw= een. This fits for example the BYOD use cases. I hope this clarifies both comments. I will make one slide to address the c= omments at the meeting, and include a more detailed description for the nex= t round of I-Ds. Regards, Dan From: Zhoutianran [mailto:zhoutianran@huawei.com] Sent: Friday, July 8, 2016 5:29 AM To: Romascanu, Dan (Dan); opsawg@ietf.org Subject: RE: a new version of the automatic attachment drafts Hi Dan, I am reading the framework draft. Here are some initial comments: 1. In figure 1, the AA controller has connection to both AA client and AA s= erver. I think it's not practical in many cases. AAC and AAS, IMHO, are usu= ally in different administrative domains. For example, AAC installed on a C= E, and the AAS installed on the PE. Usually, CE and PE are controlled by di= fferent domain controllers. It's hard to deploy a super controller for CE a= nd PE. Another example is, as you showed, the IoT. It's not practical to le= t all the end devices connect to the AA controller. Here, what scenario did you consider for this framework? The suggestion, if I am right, is to have the AA controller only connect to= the AAS. AAC can pull additional information from the path: AA controller-= >AAS->AAC. 2. If both AAC and AAS connect to the AA controller, that means the AAC and= AAS can be synchronized and configured by the management plane. So I guess= some of the control plane function between AAC and AAS can be reduced. Regards, Tianran From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (= Dan) Sent: Thursday, June 30, 2016 1:58 AM To: opsawg@ietf.org Subject: [OPSAWG] a new version of the automatic attachment drafts Hi, I have submitted two new Internet-Draft that describe the automatic attachm= ent functionality: https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-framewo= rk/ https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-lldp/ Principal changes: - addressing the comments received at IETF 95 we split the generic protoco= l-independent framework that describes the discovery and service mapping me= chanism in a separate I-D - we clarified terminology and re-drawn the principal building blocks - we connected the discovery and authentication mechanism with the MUD prop= osal Questions and comments are welcome. Thanks and Regards, Dan --_000_BBA82579FD347748BEADC4C445EA0F2183C1C235NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan,

 

Thank you for the reply. That= makes me clear now.

I was once interested on the = cloud VPN solution. The customer provisioned virtual private cloud can auto= matically joins(attach to) the existing enterprise VPN.

I think the scenario also fit= in this framework. It might be one use case considered in your draft.=

 

Regards,

Tianran

 

From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Monday, July 11, 2016 5:20 PM
To: Zhoutianran; opsawg@ietf.org
Cc: Unbehagen Jr, Paul E (Paul)
Subject: RE: a new version of the automatic attachment drafts

 

Hi Tian= ran,

&n= bsp;

Thank y= ou for the reading and for the comments.

&n= bsp;

Your ob= servation is very correct and it relates to something that we failed to exp= lain in enough details in the I-D. The AA controller in the diagram should = not be regarded as a ‘super-controller’ across administrative domains, but rather as a policy function that applie= s to the network and may be instantiated in different ways. The ‘vert= ical’ data model (6) in the diagram does not carry the same informati= on to AACs and AASs. There are two possible scenarios here:

&n= bsp;

= 1.      The AA controller connects only to the AAS and configures the mapping poli= cies on the network devices. Clients are configured mainly by the horizonta= l interaction – this will be true also in most of the IoT scenarios

= 2.      Both AAS and AACs connect to the AA controller function. The clients get a= uthentication and local security and local services information from the co= ntroller (what services are available, how you configure to them). Servers perform same functionality as in #1. T= he implementation of the controller may be distributed, possibly with an &#= 8216;orchestration’ function in-between. This fits for example the BY= OD use cases.

&n= bsp;

I hope = this clarifies both comments. I will make one slide to address the comments= at the meeting, and include a more detailed description for the next round= of I-Ds.

&n= bsp;

Regards= ,

&n= bsp;

Dan

&n= bsp;

&n= bsp;

From: Zhoutianran [mailto:zhoutianran@huawei.com]
Sent: Friday, July 8, 2016 5:29 AM
To: Romascanu, Dan (Dan); opsawg@= ietf.org
Subject: RE: a new version of the automatic attachment drafts

 

Hi Dan,

 

I am reading the framework dr= aft. Here are some initial comments:

 

1. In figure 1, the AA contro= ller has connection to both AA client and AA server. I think it’s not= practical in many cases. AAC and AAS, IMHO, are usually in different administrative domains. For example, AAC installed on a CE, a= nd the AAS installed on the PE. Usually, CE and PE are controlled by differ= ent domain controllers. It’s hard to deploy a super controller for CE= and PE. Another example is, as you showed, the IoT. It’s not practical to let all the end devices connect to th= e AA controller.

Here, what scenario did you c= onsider for this framework?

The suggestion, if I am right= , is to have the AA controller only connect to the AAS. AAC can pull additi= onal information from the path: AA controller->AAS->AAC.

 

2. If both AAC and AAS connec= t to the AA controller, that means the AAC and AAS can be synchronized and = configured by the management plane. So I guess some of the control plane function between AAC and AAS can be reduced.

 

 

Regards,

Tianran

 

From: OPSAWG [ma= ilto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 30, 2016 1:58 AM
To: opsawg@ietf.org
Subject: [OPSAWG] a new version of the automatic attachment drafts

 

Hi,

 

I have submitted two new Intern= et-Draft that describe the automatic attachment functionality:

 

https://datatracker.ietf.org/doc/draft-romascan= u-opsawg-auto-attach-framework/

https://datatracker.ietf.org/doc/draft-romascanu-ops= awg-auto-attach-lldp/

 

Principal changes: <= /span>

- addressing the comments re= ceived at IETF 95  we split the generic protocol-independent framework= that describes the discovery and service mapping mechanism in a separate I= -D

- we clarified terminology a= nd re-drawn the principal building blocks

- we connected the discovery an= d authentication mechanism with the MUD proposal

 

Questions and comments are welc= ome.

 

Thanks and Regards,<= /span>

 

Dan

 

--_000_BBA82579FD347748BEADC4C445EA0F2183C1C235NKGEML515MBXchi_-- From nobody Thu Jul 14 03:49:34 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F78D12DA25 for ; Thu, 14 Jul 2016 03:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 Sj4rxhTbL4u8 for ; Thu, 14 Jul 2016 03:49:31 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D9412D9E5 for ; Thu, 14 Jul 2016 03:49:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HqAAC8bYdX/yYyC4dcGgEBAQGCUiEtV?= =?us-ascii?q?nwGhUSHYKs+gTpBIYV4AoEwOBQBAQEBAQEBA2InglE5BgcDLAEBAQEBASMCDy8?= =?us-ascii?q?SAQEZAQEBAQMSFQZMEAIBCA0EBAEBCxYBBgcyFAkIAQEEAQ0FCBMHiA4BDacMm?= =?us-ascii?q?QwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYrhEyEERkYNIJ2gi8FiBWHJolkAYY?= =?us-ascii?q?Rki2FS5AZHjaBTjsFF4FMbgGGbgF+AQEB?= X-IPAS-Result: =?us-ascii?q?A2HqAAC8bYdX/yYyC4dcGgEBAQGCUiEtVnwGhUSHYKs+gTp?= =?us-ascii?q?BIYV4AoEwOBQBAQEBAQEBA2InglE5BgcDLAEBAQEBASMCDy8SAQEZAQEBAQMSF?= =?us-ascii?q?QZMEAIBCA0EBAEBCxYBBgcyFAkIAQEEAQ0FCBMHiA4BDacMmQwBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEXBYYrhEyEERkYNIJ2gi8FiBWHJolkAYYRki2FS5AZHjaBT?= =?us-ascii?q?jsFF4FMbgGGbgF+AQEB?= X-IronPort-AV: E=Sophos;i="5.28,362,1464667200"; d="scan'208,217";a="183417226" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Jul 2016 06:49:29 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 14 Jul 2016 06:49:29 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 14 Jul 2016 12:49:22 +0200 From: "Romascanu, Dan (Dan)" To: Zhoutianran , "opsawg@ietf.org" Thread-Topic: a new version of the automatic attachment drafts Thread-Index: AdHSL7Tm7cjwLHTRRWWWYvwrin0y4AGjPzDAAKV0qmAAlMwpsAAFiu5Q Date: Thu, 14 Jul 2016 10:49:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7523B991@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA75220B90@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA75235990@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA7523B991AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "Unbehagen Jr, Paul E \(Paul\)" Subject: Re: [OPSAWG] a new version of the automatic attachment drafts X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 10:49:34 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA7523B991AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tianran, Thanks again for your reading and comments. The attachment of customer provisioned virtual private cloud to and enterp= rise VPN is indeed another use case to consider. I believe that I2NSF may h= ave looked at some aspects of provisioning policies and attaching virtual s= ervices to an existing enterprise network, the AA scheme can be a path to r= ealize this. Regards, Dan From: Zhoutianran [mailto:zhoutianran@huawei.com] Sent: Thursday, July 14, 2016 11:14 AM To: Romascanu, Dan (Dan); opsawg@ietf.org Cc: Unbehagen Jr, Paul E (Paul) Subject: RE: a new version of the automatic attachment drafts Hi Dan, Thank you for the reply. That makes me clear now. I was once interested on the cloud VPN solution. The customer provisioned v= irtual private cloud can automatically joins(attach to) the existing enterp= rise VPN. I think the scenario also fit in this framework. It might be one use case c= onsidered in your draft. Regards, Tianran From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Monday, July 11, 2016 5:20 PM To: Zhoutianran; opsawg@ietf.org Cc: Unbehagen Jr, Paul E (Paul) Subject: RE: a new version of the automatic attachment drafts Hi Tianran, Thank you for the reading and for the comments. Your observation is very correct and it relates to something that we failed= to explain in enough details in the I-D. The AA controller in the diagram = should not be regarded as a 'super-controller' across administrative domain= s, but rather as a policy function that applies to the network and may be i= nstantiated in different ways. The 'vertical' data model (6) in the diagram= does not carry the same information to AACs and AASs. There are two possib= le scenarios here: 1. The AA controller connects only to the AAS and configures the mapp= ing policies on the network devices. Clients are configured mainly by the h= orizontal interaction - this will be true also in most of the IoT scenarios 2. Both AAS and AACs connect to the AA controller function. The clien= ts get authentication and local security and local services information fro= m the controller (what services are available, how you configure to them). = Servers perform same functionality as in #1. The implementation of the cont= roller may be distributed, possibly with an 'orchestration' function in-bet= ween. This fits for example the BYOD use cases. I hope this clarifies both comments. I will make one slide to address the c= omments at the meeting, and include a more detailed description for the nex= t round of I-Ds. Regards, Dan From: Zhoutianran [mailto:zhoutianran@huawei.com] Sent: Friday, July 8, 2016 5:29 AM To: Romascanu, Dan (Dan); opsawg@ietf.org Subject: RE: a new version of the automatic attachment drafts Hi Dan, I am reading the framework draft. Here are some initial comments: 1. In figure 1, the AA controller has connection to both AA client and AA s= erver. I think it's not practical in many cases. AAC and AAS, IMHO, are usu= ally in different administrative domains. For example, AAC installed on a C= E, and the AAS installed on the PE. Usually, CE and PE are controlled by di= fferent domain controllers. It's hard to deploy a super controller for CE a= nd PE. Another example is, as you showed, the IoT. It's not practical to le= t all the end devices connect to the AA controller. Here, what scenario did you consider for this framework? The suggestion, if I am right, is to have the AA controller only connect to= the AAS. AAC can pull additional information from the path: AA controller-= >AAS->AAC. 2. If both AAC and AAS connect to the AA controller, that means the AAC and= AAS can be synchronized and configured by the management plane. So I guess= some of the control plane function between AAC and AAS can be reduced. Regards, Tianran From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (= Dan) Sent: Thursday, June 30, 2016 1:58 AM To: opsawg@ietf.org Subject: [OPSAWG] a new version of the automatic attachment drafts Hi, I have submitted two new Internet-Draft that describe the automatic attachm= ent functionality: https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-framewo= rk/ https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-lldp/ Principal changes: - addressing the comments received at IETF 95 we split the generic protoco= l-independent framework that describes the discovery and service mapping me= chanism in a separate I-D - we clarified terminology and re-drawn the principal building blocks - we connected the discovery and authentication mechanism with the MUD prop= osal Questions and comments are welcome. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA7523B991AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tianran,=

 

Thanks again for your = reading and comments.

 

The attachment of cust= omer provisioned  virtual private cloud to and enterprise VPN is indee= d another use case to consider. I believe that I2NSF may have looked at som= e aspects of provisioning policies and attaching virtual services to an existing enterprise network, the AA scheme can be a= path to realize this.

 

Regards,

 

Dan<= /p>

 

 

From: Zhoutian= ran [mailto:zhoutianran@huawei.com]
Sent: Thursday, July 14, 2016 11:14 AM
To: Romascanu, Dan (Dan); opsawg@ietf.org
Cc: Unbehagen Jr, Paul E (Paul)
Subject: RE: a new version of the automatic attachment drafts

 

Hi Dan,

 =

Thank you for the= reply. That makes me clear now.

I was once intere= sted on the cloud VPN solution. The customer provisioned virtual private cl= oud can automatically joins(attach to) the existing enterprise VPN.

I think the scena= rio also fit in this framework. It might be one use case considered in your= draft.

 =

Regards,

Tianran

 =

&nbs= p;

Hi Tianran,

 

Thank you for the reading and for the comments.

 

Your observation is very correct and it relates to something that we f= ailed to explain in enough details in the I-D. The AA controller in the dia= gram should not be regarded as a ‘super-controller’ across administrative domains, but rather as a policy function that applie= s to the network and may be instantiated in different ways. The ‘vert= ical’ data model (6) in the diagram does not carry the same informati= on to AACs and AASs. There are two possible scenarios here:

 

1.       The AA controller connects only to th= e AAS and configures the mapping policies on the network devices. Clients a= re configured mainly by the horizontal interaction – this will be true also in most of the IoT scenarios

2.       Both AAS and AACs connect to the AA c= ontroller function. The clients get authentication and local security and l= ocal services information from the controller (what services are available, how you configure to them). Servers perform = same functionality as in #1. The implementation of the controller may be di= stributed, possibly with an ‘orchestration’ function in-between= . This fits for example the BYOD use cases.

 

I hope this clarifies both comments. I will make one slide to address = the comments at the meeting, and include a more detailed description for th= e next round of I-Ds.

 

Regards,

 

Dan

 

 

From: Zhoutianran [mailto:zhoutianran@huawei.com]
Sent: Friday, July 8, 2016 5:29 AM
To: Romascanu, Dan (Dan); opsawg@= ietf.org
Subject: RE: a new version of the automatic attachment drafts

&nbs= p;

Hi Dan,

 =

I am reading the = framework draft. Here are some initial comments:

 =

1. In figure 1, t= he AA controller has connection to both AA client and AA server. I think it= ’s not practical in many cases. AAC and AAS, IMHO, are usually in different administrative domains. For example, AAC installe= d on a CE, and the AAS installed on the PE. Usually, CE and PE are controll= ed by different domain controllers. It’s hard to deploy a super contr= oller for CE and PE. Another example is, as you showed, the IoT. It’s not practical to let all the end device= s connect to the AA controller.

Here, what scenar= io did you consider for this framework?

The suggestion, i= f I am right, is to have the AA controller only connect to the AAS. AAC can= pull additional information from the path: AA controller->AAS->AAC.

 =

2. If both AAC an= d AAS connect to the AA controller, that means the AAC and AAS can be synch= ronized and configured by the management plane. So I guess some of the control plane function between AAC and AAS can be r= educed.

 =

 =

Regards,

Tianran

 =

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 30, 2016 1:58 AM
To: opsawg@ietf.org
Subject: [OPSAWG] a new version of the automatic attachment drafts

&nbs= p;

Hi,<= /o:p>

&nbs= p;

I have su= bmitted two new Internet-Draft that describe the automatic attachment funct= ionality:

&nbs= p;

https://datatracker.iet= f.org/doc/draft-romascanu-opsawg-auto-attach-framework/

https://datatracker.ietf.org= /doc/draft-romascanu-opsawg-auto-attach-lldp/

&nbs= p;

Principal= changes:

- addr= essing the comments received at IETF 95  we split the generic protocol= -independent framework that describes the discovery and service mapping mec= hanism in a separate I-D

- we c= larified terminology and re-drawn the principal building blocks<= /span>

- we conn= ected the discovery and authentication mechanism with the MUD proposal

&nbs= p;

Questions= and comments are welcome.

&nbs= p;

Thanks an= d Regards,

&nbs= p;

Dan<= /o:p>

&nbs= p;

--_000_9904FB1B0159DA42B0B887B7FA8119CA7523B991AZFFEXMB04globa_-- From nobody Thu Jul 14 11:30:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3BC12D188 for ; Thu, 14 Jul 2016 11:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 yusyqcfX6_9Y for ; Thu, 14 Jul 2016 11:30:45 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7A912D185 for ; Thu, 14 Jul 2016 11:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=687; q=dns/txt; s=iport; t=1468521045; x=1469730645; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=KGqR0SBvU6xjYSg35zZv5U9PlipAAnRC9yTpZuBXBX4=; b=e8BHxlUXs4U5D3H+Kb9jIqwxVYBKSFjSFsk92o+ptcIfHWy22qqqXMFY ypfb5BlEf+1aE5RMOk4Lt3KYUSWEq1hVnCYxZ8g+Gp6r5yGQrNvQmeZQc CeuNL1RJ1bTkUEsPhrhqfYXDpatfGGopAFIZggqxMKmzDQ4EqVOolFRwo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgAP2YdX/4wNJK1cgz5WgQK4ZoF7I?= =?us-ascii?q?oV3gTU4FAEBAQEBAQFlHAuEYzo/EgE+QicEDog1DsEfAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBARkFineKGwWTX4VAAYYRiEeBVY1ckBgBHjaDcYddfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,364,1464652800"; d="scan'208";a="297812221" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2016 18:30:44 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6EIUiPd012186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jul 2016 18:30:44 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 14 Jul 2016 13:30:43 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 14 Jul 2016 13:30:43 -0500 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" Thread-Topic: New Version of T+ informational note has been uploaded Thread-Index: AQHR3f3Uet6ZT7Knpk61nDwWPguQ0w== Date: Thu, 14 Jul 2016 18:30:43 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.1.7] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Andrej Ota , Thorsten Dahm Subject: [OPSAWG] New Version of T+ informational note has been uploaded X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 18:30:46 -0000 Hello all. A new version of the T+ informational note has been uploaded. For information:=20 Version 3 loaded last week has many revisions from the last round of comments. Version 4 loaded this week has some minor mods/clarifications on US-ASCII vs UTF-8. Would appreciate any further reviews. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-tacacs-04 Many thanks! Author team. From nobody Fri Jul 15 04:13:27 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A186E12D766; Fri, 15 Jul 2016 04:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, WEIRD_PORT=0.001] autolearn=ham autolearn_force=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 Lp7qat-rQgvA; Fri, 15 Jul 2016 04:13:24 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE8612D741; Fri, 15 Jul 2016 04:13:23 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 478B243AE9; Fri, 15 Jul 2016 13:13:22 +0200 (CEST) From: Stefan Winter To: Christian Franke , IETF OPSEC References: <20160321092737.6013.75371.idtracker@ietfa.amsl.com> <56EFBF2D.5090904@restena.lu> <5707B4D9.9010508@nowhere.ws> Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <3567108c-b59b-17ef-bb28-694b625ccb12@restena.lu> Date: Fri, 15 Jul 2016 13:13:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <5707B4D9.9010508@nowhere.ws> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="seBXAim4TodHeGsD5hKr6UBImAi1WmUI4" Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] [OPSEC] Fwd: New Version Notification for draft-winter-opsec-netconfig-metadata-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 11:13:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --seBXAim4TodHeGsD5hKr6UBImAi1WmUI4 Content-Type: multipart/mixed; boundary="BCnpPlfILn7qF9xRuN9kpUGnMPxG55rDD" From: Stefan Winter To: Christian Franke , IETF OPSEC Cc: "opsawg@ietf.org" Message-ID: <3567108c-b59b-17ef-bb28-694b625ccb12@restena.lu> Subject: Re: [OPSEC] Fwd: New Version Notification for draft-winter-opsec-netconfig-metadata-00.txt References: <20160321092737.6013.75371.idtracker@ietfa.amsl.com> <56EFBF2D.5090904@restena.lu> <5707B4D9.9010508@nowhere.ws> In-Reply-To: <5707B4D9.9010508@nowhere.ws> --BCnpPlfILn7qF9xRuN9kpUGnMPxG55rDD Content-Type: multipart/mixed; boundary="------------4B729FBA8836A69778853336" This is a multi-part message in MIME format. --------------4B729FBA8836A69778853336 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, > I have just read through your draft. In my opinion, it would be very > useful to have a standardized way to provide configuration profiles to > users. Looking through the draft and the yang file, I came up with the > following notes: Thanks for these! Answers inline: > Comments on the draft: > - it would be useful if subject alt match could be configured > for usage with e.g. EAP-TTLS The settings in the draft are generic in the sense that they apply to multiple EAP methods (and possibly non-EAP uses). The ServerSideCredential/ServerID in particular contains the abstract notion of "the name of the server". It is up to the EAP method to define which property of the incoming certificate, or what else, is matched against that (method-agnostic) name= =2E As an example, Microsoft's PEAP spec pinpoint the Common Name - i.e. the EAP method does not allow subjectAltName to be used for matching. There is no leeway to tell via config file that you'd /wish/ the subjectAltName is used if the EAP method's spec does not allow it. TTLS (RFC5281) by contrary does not specify whether Common Name or subjectAltName is used; this is left to the implementation. TEAP (RFC7170) in its 7.6 specifies that subjectAltName is to be used (with a fallback to NO validation) - the Common Name is not even consider= ed. EAP-pwd (RFC5931) has the notion of a server identity, but the EAP method does not make use of PKI certificates, and has neither a Common Name nor a subjectAltName to check against. It has its own provisions in the protocol to send a server name to the EAP peer. These examples illustrate that it's the EAP method's business to define what a "server name" is and how it's supposed to be checked. So, indicating this in config during provisioning time actually seems not very useful. I reckon I can collapse ServerName and ServerHandle BTW, they nicely coincide in this abstract thinking. > - how would the private key for a client certificate be stored, > also in `cert-data`? I don't see another suitable field Yes; the file format would be P12. > - which information does `allow-save` apply to? If it applies to > the private key of a client certificate, how would public > key authentication work without storing it? It applies to the Password and/or Passphrase elements, if present. It is up to the implementation if Passphrase allow-save leads to a) the encrypted private key stored along with the decrytion passphrase b) the unencrypted private key gets stored in a credential store (because storing the encrypted data and the key to it together does not provide material extra security over unencrypted storage in the first pla= ce) The question of an unencrypted private key in the config file does not arise - there are only three formats specified: PEM and DER do not carry private keys, an P12 requires a passphrase. > - can you provide a usecase for the `valid-until` field? Absolutely! Credentials expire after a while. If you bought a Wi-Fi access scratch card for two weeks, then the account will stop working after two weeks. BUT: your device does not know that. It has a saved connection and will try to authenticate with this username and password for eternity. On the client side, this bumping into walls drains battery etc. On the server side, over time more and more expired accounts build up and hammer the server with TLS negotiations which are bound to fail. The cryptographic operations make the server more and more busy over time, for no reason. This is a real-life problem. So, if you know about the longevity of the credential at provisioning time, it is very useful to tell the device about it. The device can then decide to delete the config at that point in time, or at least to watch the authn states in the future: consistent rejected auths past the valid-until time should lead to de-provisioning or asking the user to investigate his account. Writing all this, maybe it would be useful to beef this up in the sense of having an extra qualifier "Hard Expiry" (=3Ddevice can automatically delete credential at point in time) and "Soft Expiry" (=3Ddevice should merely start to become suspicious and watch out for continuous failed auths). That latter case could be a student account initially valid for one semester, but the student /may/ have re-enrolled, keeping the account active. > - it is not obvious to me how the current model applies to VPN or > E-Mail Server connections as named in the draft VPN needs more work for sure. And I tend to think it's better to forget about E-Mail; it's a rathole for gazillions of services and the spec would quickly become unmanageable. Concentrating at network connectivity is probably the best way forward. > - it is not clear to me how an anonymous identify for EAP-TTLS or > EAP-PEAP would be configured That would be AuthenticationMethod / EAPClientSideCredential / AnonymousIdentity while the actual user identifier is in AuthenticationMethod / InnerAuthenticationMethod / EAPClientSideCredential / (reference to ClientSideCredential) > - I think it would be useful to have some consideration, either in > this or another document, about how the files procuded according to > this model should be processed, i.e. requirements on how their > authenticity must be verified, how they should be displayed to the > users and in what configuration they should actually result. True. You will have noticed chapter 4 on Issuer Authentication, Integrity Protection and Encryption: "Decisions TBD" :-) UI is also worth considering; e.g. unauthenticated files should be presented with a warning that all the content could be a lie from someone you don't know (hiding or marginalising the ProviderInfo elements); authenticated ones could prominently display the name and logo of the provider, etc. > Yang related: > - there is a type leafref which should probably used when referring > to config parts by UUID > - there are types for ipv4 and ipv6 addresses that should be used > instead of string > - list IPAddress has dynamic and static as keys, keys need to be > unique, so how to enable both dhcpv4 and dhcpv6? Same thing e.g. > for DNS All of those are due to my ignorant misunderstanding of YANG :-) In particular the last one gave me headache and I submitted this rev knowing it's not good: The "IPAddress" field should be allowed to contain numerous occurences of DynamicAddress and/or StaticAddress. I don't want it to need a key for that, but YANG seems to insist on this. Same for StaticAddress: this can be an IPv4 XOR an IPv6 address, and should be allowed to occur multiple times. list leaf IPAddress "string" kind of got the job done, but lacks some sophistication. In short: I'm in need of a YANG expert :-) Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------4B729FBA8836A69778853336 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------4B729FBA8836A69778853336-- --BCnpPlfILn7qF9xRuN9kpUGnMPxG55rDD-- --seBXAim4TodHeGsD5hKr6UBImAi1WmUI4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXiMVSAAoJEMDeajWKOdxmPlQP/2lzPtkyQ9E8xvsC5ALxVH5d q9KUVVimb4qg9FcgpAlE8ITXDX/335VEMVJfrgnQEbQ/Ag9yOLo5STpEEriznkZ1 bmiCQ5xEGOt13LlcfdKWXzIXlPE+DTQvc9W+zTl3wx3ouQ+4C+2rQyXiIXfRypYS hdmLa/nbEHNRRqx8x1/1dwcJuwv+jUrTuDTKi9sO+sY7ngIuJSItBVVdkMjl8H6k Nv8WoqbOlMMVK6/hVQ+bpeMTdsL6g5FcAiJnrlxvBFsChJ6GG9w6EZtTnR0D+JQH yLQw3P+m3wCsVmkqf3AcG4sdnIfxFW7jqj5b5hhSrY94Ji4jd6KbS0PD2MwE/3Ff UKfDN/1vmNa0xr+M9t6Hmg44bEOoRLhYzIMoDrdRoTfiwdoOGCbyPQ3DVwrgArFf 19cns9Uko0Ix7THINOeo3WJQTQ8rDXnOqCrrSpuKgqAcJpWFJmQ4BJEU1BA7tbZH Qf2Dqwva5/VtRV89Smh7+btm+/2vQt/8d4fJTW8oShnrbvG83VnKpxUMz0vMqXF7 PK2wlEfTOd/WB//c/858SrrYRs3JsQYP8bVrit2AZSZtvt3VM4xezPFfBQTvPN0/ Wy1nTxRdam0iI2zTHKxeQ5oGHY0mRJXbkiWRb6cxFQ5Z1OlkCz3/ZHmy6GN82NTA ZrIR50S++884B+aXbBX9 =Vcqe -----END PGP SIGNATURE----- --seBXAim4TodHeGsD5hKr6UBImAi1WmUI4-- From nobody Fri Jul 15 08:25:02 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB76B12D7E6 for ; Fri, 15 Jul 2016 08:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 VMj5OIc6ImVC for ; Fri, 15 Jul 2016 08:24:57 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 21CE912D119 for ; Fri, 15 Jul 2016 08:24:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 2D4521BEF; Fri, 15 Jul 2016 15:24:56 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1br-aXfbP1me; Fri, 15 Jul 2016 15:24:56 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 78F811A36; Fri, 15 Jul 2016 15:24:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Fri, 15 Jul 2016 11:24:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <968F6E4B-B89A-4850-9F77-2CAF4152F5A0@deployingradius.com> References: To: "Douglas Gash (dcmgash)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] New Version of T+ informational note has been uploaded X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 15:25:02 -0000 On Jul 14, 2016, at 2:30 PM, Douglas Gash (dcmgash) = wrote: >=20 > Hello > For information:=20 >=20 > Version 3 loaded last week has many revisions from the last round of > comments. > Version 4 loaded this week has some minor mods/clarifications on = US-ASCII > vs UTF-8. >=20 > Would appreciate any further reviews. Many of my review comments have been addressed, which is good. There = still remains a number of issues. The Security Considerations section is in the middle of the document, = where it's typically at the end. That's a minor nit. The larger one is = that the Security Considerations section is pretty minimal. It should = describe operational issues with the protocol, and comments as to what = the security implications are for network management traffic to be sent = in the clear. The issue with the field names remains. I *suspect* the "user len" = field contains the length of the "user" field... but there is nothing in = the document which says so. The text still seems philosophical to me, instead of prescriptive. = For example in Section 3.6: After a packet body is decrypted, the lengths of the component values in the packet should be summed and checked against the cleartext datalength value from the header. Any packets which fail this check should be discarded and an error signalled. The values "should" be summed? Is that an RFC 2119 statement? Or = just a suggestion? What happens if an implementation chooses to ignore = this suggestion? And bad packets "should" be discarded? Why not MUST? How does an = error get signalled? What kind of error packet gets sent back? Perhaps something like this would be better: After a packet body is decrypted, the lengths of the component values in the packet are summed. If the sum is not identical to the = cleartext datalength value from the header, the packet MUST be discarded, and an error signalled. The underlying TCP connection SHOULD also be closed. Which (for me) clarifies the operation, makes the checks normative, = and adds a suggestion to close the TCP connection. After all, if they = key is wrong and packets can't be decrypted, there's no reason to keep = the TCP connection open. You can't decrypt any data in the connection, = so it will all be garbage. Alan DeKok. From nobody Fri Jul 15 08:38:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7589D12D09F for ; Fri, 15 Jul 2016 08:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 l2ZfoHB7eu61 for ; Fri, 15 Jul 2016 08:38:39 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBBA12D802 for ; Fri, 15 Jul 2016 08:38:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id B31121B5D; Fri, 15 Jul 2016 15:38:38 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JdfrN2tm3bn; Fri, 15 Jul 2016 15:38:38 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 02FBA1A36; Fri, 15 Jul 2016 15:38:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <968F6E4B-B89A-4850-9F77-2CAF4152F5A0@deployingradius.com> Date: Fri, 15 Jul 2016 11:38:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <968F6E4B-B89A-4850-9F77-2CAF4152F5A0@deployingradius.com> To: "Douglas Gash (dcmgash)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] New Version of T+ informational note has been uploaded X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 15:38:40 -0000 On Jul 15, 2016, at 11:24 AM, Alan DeKok = wrote: > The Security Considerations section is in the middle of the document, = where it's typically at the end. That's a minor nit. The larger one is = that the Security Considerations section is pretty minimal. It should = describe operational issues with the protocol, and comments as to what = the security implications are for network management traffic to be sent = in the clear. For example: Security Considerations This specification describes a protocol as originally designed in 199X, = and as such does not use modern security practices. A later document = will update TACACS+ to meet modern security standards. There are a number of issues with the protocol design and common = use-cases. The most significant are issues related to privacy and = authentication. The protocol includes an obfuscation mechanism referred = to in the original draft as Body Encryption. This obfuscation method = has not had security analysis, and should be assumed to be broken. = Portions of the protocol are sent clear-text, while others are sent = obfuscated. An attacker may be able to modify the clear-text portions = without detection. When the obfuscation mechanism is not used, the protocol is entirely = unauthenticated. Anyone capable of spoofing or intercepting traffic for = the source or destination of the TCP connection can masqeurade as the = client or server without detection. This attack would allow a malicious = after unrestricted access to the management devices allegedly = "protected" by this protocol. When the obfuscation mechanism is not used, the protocol is also = completely open. All traffic is visible to an eavesdropper, which can = leak information about the network. An eavesdropper may also be able to = intercept, and modify, packets without detection. etc. The section should list the possible attacks, and how to defend = against them. Alan DeKok From nobody Fri Jul 15 12:32:17 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8908412DBA8 for ; Fri, 15 Jul 2016 12:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 urSLkx-5lYMk for ; Fri, 15 Jul 2016 12:32:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919AB12DD38 for ; Fri, 15 Jul 2016 12:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2226; q=dns/txt; s=iport; t=1468611133; x=1469820733; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2gsu9uqp2Y5zsIvexdIG+vKXzfRAQMEaVlkImjfqgPo=; b=ChL19BgF9YfbwOu8In/QWxPNaQ5kKYMc69+ASW0PvCxSA+6c2MMd795S qbORWO6kKJRjzCUxTGLNfFvyks+x2K9Uohpl1/gn8ALZDJndvdAHlh0pm cLy5ctw3/CvqYjB/rO0DWVM4P5hPSEPTw9MYanRJkRYG9AGoOaOSGaCOE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyBQDjOIlX/5ldJa1cgz6BUrZlgg+Be?= =?us-ascii?q?4YaAoEvORMBAQEBAQEBZSeEXAEBBAE6PwULAgEIGB4QMiUCBA4FiCgIv1IBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAR2IIgiCTYQqFoMsgi8FmSEBjlqBa41Khl2JPQEfA?= =?us-ascii?q?TSDc26GUwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,369,1464652800"; d="scan'208";a="124610770" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2016 19:32:12 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6FJWCou006816 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Jul 2016 19:32:12 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 15 Jul 2016 14:32:11 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 15 Jul 2016 14:32:11 -0500 From: "Douglas Gash (dcmgash)" To: Alan DeKok Thread-Topic: [OPSAWG] New Version of T+ informational note has been uploaded Thread-Index: AQHR3f3Uet6ZT7Knpk61nDwWPguQ06AZ8eeAgAAD1QD//+1ytA== Date: Fri, 15 Jul 2016 19:32:11 +0000 Message-ID: <3FC29820-440F-4BE2-8977-29308216F7E6@cisco.com> References: <968F6E4B-B89A-4850-9F77-2CAF4152F5A0@deployingradius.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] New Version of T+ informational note has been uploaded X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:32:14 -0000 Thank you again Alan for more quality feedback! Regards, Doug > On 15 Jul 2016, at 16:38, Alan DeKok wrote: >=20 >> On Jul 15, 2016, at 11:24 AM, Alan DeKok wro= te: >> The Security Considerations section is in the middle of the document, wh= ere it's typically at the end. That's a minor nit. The larger one is that= the Security Considerations section is pretty minimal. It should describe= operational issues with the protocol, and comments as to what the security= implications are for network management traffic to be sent in the clear. >=20 > For example: >=20 > Security Considerations >=20 > This specification describes a protocol as originally designed in 199X, a= nd as such does not use modern security practices. A later document will u= pdate TACACS+ to meet modern security standards. >=20 > There are a number of issues with the protocol design and common use-case= s. The most significant are issues related to privacy and authentication. = The protocol includes an obfuscation mechanism referred to in the original= draft as Body Encryption. This obfuscation method has not had security an= alysis, and should be assumed to be broken. Portions of the protocol are s= ent clear-text, while others are sent obfuscated. An attacker may be able = to modify the clear-text portions without detection. >=20 > When the obfuscation mechanism is not used, the protocol is entirely unau= thenticated. Anyone capable of spoofing or intercepting traffic for the so= urce or destination of the TCP connection can masqeurade as the client or s= erver without detection. This attack would allow a malicious after unrestr= icted access to the management devices allegedly "protected" by this protoc= ol. >=20 > When the obfuscation mechanism is not used, the protocol is also complete= ly open. All traffic is visible to an eavesdropper, which can leak informa= tion about the network. An eavesdropper may also be able to intercept, and= modify, packets without detection. >=20 >=20 > etc. The section should list the possible attacks, and how to defend ag= ainst them. >=20 > Alan DeKok >=20 From nobody Mon Jul 18 01:39:42 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B3A12D1A1; Mon, 18 Jul 2016 01:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6jIC-SiKijqB; Mon, 18 Jul 2016 01:39: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 1BB1912D19B; Mon, 18 Jul 2016 01:39:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CST59505; Mon, 18 Jul 2016 08:39:34 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 18 Jul 2016 09:39:10 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 18 Jul 2016 16:39:06 +0800 From: Zhoutianran To: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" Thread-Topic: OPSAWG and OPS Area meeting agenda Thread-Index: AdHgz39Prr9k+14USMKH8SUb0SIL+g== Date: Mon, 18 Jul 2016 08:39:05 +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.200.217.77] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183C1F72DNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.578C95C7.0035, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a0955c849419699fd3c4a2d222148556 Archived-At: Subject: [OPSAWG] OPSAWG and OPS Area meeting agenda X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 08:39:41 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2183C1F72DNKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQoNCg0KVGhlIG1lZXRpbmcgYWdlbmRhIGlzIGhlcmU6DQoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85Ni9hZ2VuZGEvb3BzYXdnLw0KDQoNCg0KV2VsY29t ZSB0byBqb2luIHVzIGZvciB0aGUgZGlzY3Vzc2lvbi4NCg0KDQoNCkNvdWxkIHRoZSBzcGVha2Vy cyBwbGVhc2Ugc2VuZCB5b3VyIHNsaWRlcyB0byB0aGUgY2hhaXJzIGJlZm9yZSB0aGUgbWVldGlu Zz8NCg0KDQoNClRoYW5rcywNCg0KV2FycmVuICYgVGlhbnJhbg0K --_000_BBA82579FD347748BEADC4C445EA0F2183C1F72DNKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi All,

 

The meeting agenda is here:

https= ://datatracker.ietf.org/meeting/96/agenda/opsawg/

 

Welcome to join us for the discussion.

 

Could the speakers please send your slides to the chairs before the meet= ing?

 

Thanks,

Warren & Tianran

--_000_BBA82579FD347748BEADC4C445EA0F2183C1F72DNKGEML515MBXchi_-- From nobody Mon Jul 18 08:03:51 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F89A12DC0C for ; Mon, 18 Jul 2016 08:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.637 X-Spam-Level: X-Spam-Status: No, score=-3.637 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 F5WCXP0rmS3b for ; Mon, 18 Jul 2016 08:03:48 -0700 (PDT) Received: from COL004-OMC1S6.hotmail.com (col004-omc1s6.hotmail.com [65.55.34.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E296312DAAC for ; Mon, 18 Jul 2016 07:36:25 -0700 (PDT) Received: from COL125-W5 ([65.55.34.7]) by COL004-OMC1S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 18 Jul 2016 07:36:25 -0700 X-TMN: [orIQ4FnCj/lGaqzietS50SxKx7YqGqJO] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b947dc45-1f07-4ade-a949-f540a279957d_" From: Hui Deng To: "opsawg@ietf.org" Date: Mon, 18 Jul 2016 22:36:24 +0800 Importance: Normal In-Reply-To: <20160718143454.19715.32536.idtracker@ietfa.amsl.com> References: <20160718143454.19715.32536.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2016 14:36:25.0260 (UTC) FILETIME=[C2F666C0:01D1E101] Archived-At: Subject: [OPSAWG] FW: New Version Notification for draft-deng-opsawg-composed-vpn-sm-requirements-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 15:03:50 -0000 --_b947dc45-1f07-4ade-a949-f540a279957d_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQpCYXNlZCBvbiBzb21lIG9mZmxpbmUgZmVlZGJhY2ssIEkgaGF2ZSB1cGRhdGVk IHRoaXMgZHJhZnQsIHRoYW5rcyBhIGxvdCBmb3IgeW91ciBraW5kIHJldmlldyBhZ2Fpbg0KQmVz dCByZWdhcmRzLA0KREVORyBIdWkNCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ IFRvOiBkZW5naHVpMDJAaG90bWFpbC5jb207IGRlbmdodWkwMkBob3RtYWlsLmNvbQ0KPiBTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBv c2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0DQo+IERhdGU6IE1vbiwgMTggSnVsIDIwMTYg MDc6MzQ6NTQgLTA3MDANCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZGVu Zy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMS50eHQNCj4gaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBIdWkgRGVuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJ RVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQt dnBuLXNtLXJlcXVpcmVtZW50cw0KPiBSZXZpc2lvbjoJMDENCj4gVGl0bGU6CQlSZXF1aXJlbWVu dHMgb2YgQ29tcG9zZWQgVlBOIFNlcnZpY2UgTW9kZWwNCj4gRG9jdW1lbnQgZGF0ZToJMjAxNi0w Ny0xOA0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczoJCTcNCj4gVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1k ZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4dA0KPiBTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZGVuZy1vcHNh d2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20t cmVxdWlyZW1lbnRzLTAxDQo+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50 cy0wMQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoZSBvcGVyYXRvciBmYWNpbmcgZGF0YSBtb2Rl bCBpcyB2YWx1YWJsZSB0byByZWR1Y2UgdGhlIG9wZXJhdGlvbg0KPiAgICBhbmQgbWFuYWdlbWVu dC4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHJlcXVpcmVtZW50cyBvZiB0aGUgY29tcG9zZWQN Cj4gICAgVlBOIHNlcnZpY2UgbW9kZWwgZm9yIG9wZXJhdG9ycyB0byBkZXBsb3kgZW5kIHRvIGVu ZCBQRS1iYXNlZCBWUE4NCj4gICAgc2VydmljZXMgYWNyb3NzIG11bHRpcGxlIGF1dG9ub21vdXMg c3lzdGVtcy4NCj4gDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+IA0KPiANCj4g UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0 YXJpYXQNCj4gDQogCQkgCSAgIAkJICA= --_b947dc45-1f07-4ade-a949-f540a279957d_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPGRpdj48YnI+PC9kaXY+PGRpdj5CYXNl ZCBvbiBzb21lIG9mZmxpbmUgZmVlZGJhY2ssIEkgaGF2ZSB1cGRhdGVkIHRoaXMgZHJhZnQsJm5i c3A7PC9kaXY+PGRpdj50aGFua3MgYSBsb3QgZm9yIHlvdXIga2luZCByZXZpZXcgYWdhaW48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PkJlc3QgcmVnYXJkcyw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PkRFTkcgSHVpPC9kaXY+PGRpdj48YnI+PGRpdj4mZ3Q7IEZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzxicj4mZ3Q7IFRvOiBkZW5naHVpMDJAaG90bWFpbC5jb207IGRlbmdodWkwMkBo b3RtYWlsLmNvbTxicj4mZ3Q7IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMS50eHQ8YnI+ Jmd0OyBEYXRlOiBNb24sIDE4IEp1bCAyMDE2IDA3OjM0OjU0IC0wNzAwPGJyPiZndDsgPGJyPiZn dDsgPGJyPiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBv c2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0PGJyPiZndDsgaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBIdWkgRGVuZyBhbmQgcG9zdGVkIHRvIHRoZTxicj4mZ3Q7IElFVEYg cmVwb3NpdG9yeS48YnI+Jmd0OyA8YnI+Jmd0OyBOYW1lOgkJZHJhZnQtZGVuZy1vcHNhd2ctY29t cG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50czxicj4mZ3Q7IFJldmlzaW9uOgkwMTxicj4mZ3Q7IFRp dGxlOgkJUmVxdWlyZW1lbnRzIG9mIENvbXBvc2VkIFZQTiBTZXJ2aWNlIE1vZGVsPGJyPiZndDsg RG9jdW1lbnQgZGF0ZToJMjAxNi0wNy0xODxicj4mZ3Q7IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uPGJyPiZndDsgUGFnZXM6CQk3PGJyPiZndDsgVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12 cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4dDxicj4mZ3Q7IFN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4t c20tcmVxdWlyZW1lbnRzLzxicj4mZ3Q7IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50 cy0wMTxicj4mZ3Q7IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMTxi cj4mZ3Q7IDxicj4mZ3Q7IEFic3RyYWN0Ojxicj4mZ3Q7ICAgIFRoZSBvcGVyYXRvciBmYWNpbmcg ZGF0YSBtb2RlbCBpcyB2YWx1YWJsZSB0byByZWR1Y2UgdGhlIG9wZXJhdGlvbjxicj4mZ3Q7ICAg IGFuZCBtYW5hZ2VtZW50LiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgcmVxdWlyZW1lbnRzIG9m IHRoZSBjb21wb3NlZDxicj4mZ3Q7ICAgIFZQTiBzZXJ2aWNlIG1vZGVsIGZvciBvcGVyYXRvcnMg dG8gZGVwbG95IGVuZCB0byBlbmQgUEUtYmFzZWQgVlBOPGJyPiZndDsgICAgc2VydmljZXMgYWNy b3NzIG11bHRpcGxlIGF1dG9ub21vdXMgc3lzdGVtcy48YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0 OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbjxicj4mZ3Q7IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPiZndDsgPGJyPiZndDsgVGhl IElFVEYgU2VjcmV0YXJpYXQ8YnI+Jmd0OyA8YnI+PC9kaXY+PC9kaXY+IAkJIAkgICAJCSAgPC9k aXY+PC9ib2R5Pg0KPC9odG1sPg== --_b947dc45-1f07-4ade-a949-f540a279957d_-- From nobody Tue Jul 19 01:18:27 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1869212D0D3 for ; Tue, 19 Jul 2016 01:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 O5Oank5VwrG1 for ; Tue, 19 Jul 2016 01:18:24 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5929B12B02D for ; Tue, 19 Jul 2016 01:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8885; q=dns/txt; s=iport; t=1468916303; x=1470125903; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=U03aRQGCWqTZ2V/wtofaDVQ45xg0eeGpxBnG2DLNkG8=; b=IKahz8u6iDrR3I8nTqdPi4gl/mqIy2GN5xs4h89H7RuKNR+TxNRmtdg+ A7kpp8JX3mZYI8jT9SP7SKy8d2kSC4k9+r1FCJqFijJBLqY5o06A6CXF4 xOC0lZyKwHjnw5WvWYDiLmkDMMCaCeTK/t2vtSTxgRh7lG/Yvk1RN5A42 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBFgA34Y1X/xbLJq1bhBUqUrNihn4kg?= =?us-ascii?q?j+CbUoCgXwBAQEBAQFmJ4RdAQUBASFLCRIJAg4ELQMCAicfAw4GAQwGAgEBiCw?= =?us-ascii?q?OkhydHY4QAQEBAQEBAQEBAQEBAQEBAQEBAR6GKoF4CIJNh0GCWgEEjguLGYYTi?= =?us-ascii?q?EyBa06EC4MMI4VEkB5Ugj6BNzoyAYgPAQEB?= X-IronPort-AV: E=Sophos;i="5.28,388,1464652800"; d="scan'208,217";a="638637941" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 08:18:21 +0000 Received: from [10.61.101.65] (dhcp-10-61-101-65.cisco.com [10.61.101.65]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6J8IIPV031428; Tue, 19 Jul 2016 08:18:18 GMT To: Qin Wu , "opsawg@ietf.org" References: From: Benoit Claise Message-ID: Date: Tue, 19 Jul 2016 10:18:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C35573E153621186543E0806" Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:18:26 -0000 This is a multi-part message in MIME format. --------------C35573E153621186543E0806 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Qin, Explaining the difference between a service and network element YANG modules is the objective of https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ Abstract The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards-defining organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish YANG modules of configuration, state data and operations for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. A consistent terminology would help with the categorization of YANG modules, assist in the analysis the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG-related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG modules. Regards, Benoit > Hi, > We have submitted a new I-D that discusses the scope and purpose of service models within > the IETF and describes how a service model can be used by a network > operator. > https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/ > > In addition, this draft clarifies the role and position of service model in the SDN architecture and > Clear several misconception on the service model. > > Your questions and comments are welcome. > > Regards! > -Qin > -----邮件原件----- > 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > 发送时间: 2016年7月5日 19:55 > 收件人: Liushucheng (Will); Adrian Farrel; Liushucheng (Will); Qin Wu > 主题: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt > > > A new version of I-D, draft-wu-opsawg-service-model-explained-00.txt > has been successfully submitted by Qin Wu and posted to the IETF repository. > > Name: draft-wu-opsawg-service-model-explained > Revision: 00 > Title: Service Models Explained > Document date: 2016-07-05 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-wu-opsawg-service-model-explained-00.txt > Status: https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/ > Htmlized: https://tools.ietf.org/html/draft-wu-opsawg-service-model-explained-00 > > > Abstract: > The IETF has produced a considerable number of data models in the > YANG modelling language. The majority of these are used to model > devices and they allow access for configuration and to read > operational status. > > A small number of YANG models are used to model services (for > example, the Layer Three Virtual Private Network Service Model > produced by the L3SM working group). > > This document briefly sets out the scope of and purpose of an IETF > service model, and it shows where a service model might fit into a > Software Defined Networking architecture or deployment. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------C35573E153621186543E0806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Qin,

Explaining the difference between a service and network element YANG modules is the objective of https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/

Abstract

   The YANG [RFC6020] data modeling language is currently being
   considered for a wide variety of applications throughout the
   networking industry at large.  Many standards-defining organizations
   (SDOs), open source software projects, vendors and users are using
   YANG to develop and publish YANG modules of configuration, state data
   and operations for a wide variety of applications.  At the same time,
   there is currently no well-known terminology to categorize various
   types of YANG modules.

   A consistent terminology would help with the categorization of YANG
   modules, assist in the analysis the YANG data modeling efforts in the
   IETF and other organizations, and bring clarity to the YANG-related
   discussions between the different groups.

   This document describes a set of concepts and associated terms to
   support consistent classification of YANG modules.
Regards, Benoit
Hi,
We have submitted a new I-D that discusses the scope and purpose of service models within
the IETF and describes how a service model can be used by a network
operator.
https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/

In addition, this draft clarifies the role and position of service model in the SDN architecture and
Clear several misconception on the service model.

Your questions and comments are welcome.

Regards!
-Qin
-----邮件原件-----
发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
发送时间: 2016年7月5日 19:55
收件人: Liushucheng (Will); Adrian Farrel; Liushucheng (Will); Qin Wu
主题: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt


A new version of I-D, draft-wu-opsawg-service-model-explained-00.txt
has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:		draft-wu-opsawg-service-model-explained
Revision:	00
Title:		Service Models Explained
Document date:	2016-07-05
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-wu-opsawg-service-model-explained-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/
Htmlized:       https://tools.ietf.org/html/draft-wu-opsawg-service-model-explained-00


Abstract:
   The IETF has produced a considerable number of data models in the
   YANG modelling language.  The majority of these are used to model
   devices and they allow access for configuration and to read
   operational status.

   A small number of YANG models are used to model services (for
   example, the Layer Three Virtual Private Network Service Model
   produced by the L3SM working group).

   This document briefly sets out the scope of and purpose of an IETF
   service model, and it shows where a service model might fit into a
   Software Defined Networking architecture or deployment.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------C35573E153621186543E0806-- From nobody Tue Jul 19 01:28:18 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2021E12DC99 for ; Tue, 19 Jul 2016 01:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 9aVomgHN2phE for ; Tue, 19 Jul 2016 01:28:14 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B00B12DCB9 for ; Tue, 19 Jul 2016 01:28:13 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6J8Rllv025510; Tue, 19 Jul 2016 09:27:47 +0100 Received: from 950129200 (jplon-nat12.juniper.net [193.110.55.12]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6J8Rk2M025460 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2016 09:27:46 +0100 From: "Adrian Farrel" To: "'Benoit Claise'" , "'Qin Wu'" , "'opsawg@ietf.org'" References: In-Reply-To: Date: Tue, 19 Jul 2016 09:27:48 +0100 Message-ID: <0aaa01d1e197$6f51fb10$4df5f130$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AAB_01D1E19F.D11A5AB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFfs4zaDoqeb5eNCXm4VqxkJgAD4wJHGYOMoPGNGxA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22460.006 X-TM-AS-Result: No--24.515-10.0-31-10 X-imss-scan-details: No--24.515-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkBSN5j/GgtDwaUzlWzC7vTf0Wobj8GkNVpPtLhlThdPEOD0 si3Y505rVs0qZi5wAOFri5LTnk7sbdFpWCk/W2tmJrUxoq6hvw/omPrNi98UBGCD5SM8YvVFrRG iaFY8lpAgfgnqxlBKufaaEZAHJRdeJa+FAG1BTBPFlCgYxEaGE5vneaGguBFNEd+K6O5Nt50P65 UmIJNL5E1YH07L/xHx+6jKzF2NtOEBpTIFsSiyLZN65fjGjYMQF2epOtR1Cc8ep400rdpOCz6Zk u4ewpw65Sm5GHzQk3wXACn7S+dJhM7MWnfHypaG/O70vD0Lt8DtOBYS8HQz/A4AepdqPBUYrg1i kK3OBT/NIfPWJlKmQdbR7koIv19uOkjQDRo1OZQx0CRCwbrRs6jzyPtA+pd/m4O3uRMQfRhv/db XKjxcZBT03Vm9AeeLRVTzZpxbITmxpgqXoiq0QRhTGJQ1M8K9EAvNbbgHz74n+p552csI1V8UbS n1RTfD1rAakX1NXfPMfTK5B6eevbs5lGfHdzcVSDkh6bW+bcexc8j0PhSuLr/tumWFs8JCa9bfK kMaSYnplMBHei8yCXTUDQnHLiSgePGAeSn124KA6qv+vR34LFF5adRR2Ej1zO86RLKahv8nwf3k fmsrQzba6gSbbjl+gVo1o+4QhtKqDvek35mqXJ3bt4XlQMWjD+LwVja9M4EgOnjvjQ5gMSWdw9M yj4ex9dMkDbqNTiWX7nDC+4gKenNQXkvyemjfXTK4OtPUfQSjuF41aTJRXZ/paSZmLhGje5basi bx4KeIpPXxk07x2RMfL/qOWmMdPiAaQSjAgpmeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyIikvdS5 PcmKHyKEObJsxUWMg96SyBJTolk2H60POXqIn62rPtLsq0BBklVUZZyE3w= Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:28:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0AAB_01D1E19F.D11A5AB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Benoit, =20 I think that you mean to say "is *an* objective of". That is, the draft = you point at has a far wider scope and purpose. =20 No problem with that. =20 Doing our work in L3SM we repeatedly encountered confusion about what a = service model is and where it fits in the "hierarchy". So we wrote some = text. =20 Looking at our draft and Figure 1 in the yang-model-classification there = is not complete coherence. =20 Which way would like to go forward? Roll our text into yang-model-classification? Push forward separately? =20 Adrian =20 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise Sent: 19 July 2016 09:18 To: Qin Wu; opsawg@ietf.org Subject: Re: [OPSAWG] New Version Notification for = draft-wu-opsawg-service-model-explained-00.txt =20 Qin, Explaining the difference between a service and network element YANG = modules is the objective of = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classificat= ion/ Abstract =20 The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards-defining organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish YANG modules of configuration, state data and operations for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. =20 A consistent terminology would help with the categorization of YANG modules, assist in the analysis the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG-related discussions between the different groups. =20 This document describes a set of concepts and associated terms to support consistent classification of YANG modules. Regards, Benoit Hi, We have submitted a new I-D that discusses the scope and purpose of = service models within the IETF and describes how a service model can be used by a network operator. https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/= =20 In addition, this draft clarifies the role and position of service model = in the SDN architecture and Clear several misconception on the service model. =20 Your questions and comments are welcome. =20 Regards! -Qin -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B47=E6=9C=885=E6=97=A5 = 19:55 =E6=94=B6=E4=BB=B6=E4=BA=BA: Liushucheng (Will); Adrian Farrel; = Liushucheng (Will); Qin Wu =E4=B8=BB=E9=A2=98: New Version Notification for = draft-wu-opsawg-service-model-explained-00.txt =20 =20 A new version of I-D, draft-wu-opsawg-service-model-explained-00.txt has been successfully submitted by Qin Wu and posted to the IETF = repository. =20 Name: draft-wu-opsawg-service-model-explained Revision: 00 Title: Service Models Explained Document date: 2016-07-05 Group: Individual Submission Pages: 12 URL: = https://www.ietf.org/internet-drafts/draft-wu-opsawg-service-model-explai= ned-00.txt Status: = https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/= Htmlized: = https://tools.ietf.org/html/draft-wu-opsawg-service-model-explained-00 =20 =20 Abstract: The IETF has produced a considerable number of data models in the YANG modelling language. The majority of these are used to model devices and they allow access for configuration and to read operational status. =20 A small number of YANG models are used to model services (for example, the Layer Three Virtual Private Network Service Model produced by the L3SM working group). =20 This document briefly sets out the scope of and purpose of an IETF service model, and it shows where a service model might fit into a Software Defined Networking architecture or deployment. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. =20 The IETF Secretariat =20 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg =20 ------=_NextPart_000_0AAB_01D1E19F.D11A5AB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Benoit,

 

I think that you mean to say = "is *an* objective of". That is, the draft you point at has a = far wider scope and purpose.

 

No problem with = that.

 

Doing our work in L3SM we = repeatedly encountered confusion about what a service model is and where = it fits in the "hierarchy". So we wrote some = text.

 

Looking at our draft and = Figure 1 in the yang-model-classification there is not complete = coherence.

 

Which way would like to go = forward?

Roll our text into = yang-model-classification?

Push forward = separately?

 

Adrian

 

From: = OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit = Claise
Sent: 19 July 2016 09:18
To: Qin Wu; = opsawg@ietf.org
Subject: Re: [OPSAWG] New Version Notification = for = draft-wu-opsawg-service-model-explained-00.txt

 

Qin,

Explaining the difference between a service and = network element YANG modules is the objective of https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-mod= el-classification/

Abstract
 
=C2=A0=C2=A0 The YANG = [RFC6020] data modeling language is currently = being
=C2=A0=C2=A0 =
considered for a wide variety of applications throughout =
the
=C2=A0=C2=A0 =
networking industry at large.=C2=A0 Many standards-defining =
organizations
=C2=A0=C2=A0 (SDOs), open source =
software projects, vendors and users are =
using
=C2=A0=C2=A0 =
YANG to develop and publish YANG modules of configuration, state =
data
=C2=A0=C2=A0 =
and operations for a wide variety of applications.=C2=A0 At the same =
time,
=C2=A0=C2=A0 =
there is currently no well-known terminology to categorize =
various
=C2=A0=C2=A0 types of YANG =
modules.
 
=C2=A0=C2=A0 A consistent terminology =
would help with the categorization of YANG
=C2=A0=C2=A0 modules, assist in the =
analysis the YANG data modeling efforts in =
the
=C2=A0=C2=A0 =
IETF and other organizations, and bring clarity to the =
YANG-related
=C2=A0=C2=A0 discussions between the =
different groups.
 
=C2=A0=C2=A0 This document describes a =
set of concepts and associated terms to
=C2=A0=C2=A0 support consistent =
classification of YANG modules.

Regards, Benoit

Hi,
<= pre>We have submitted a new I-D that discusses the scope and purpose of = service models within
the IETF and describes how a =
service model can be used by a =
network
operator.
https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-=
explained/
 
In =
addition, this draft clarifies the role and position of service model in =
the SDN architecture and
Clear several =
misconception on the service =
model.
 
Your questions =
and comments are =
welcome.
 
Regards!
-Qin
-----=E9=82=AE=E4=BB=
=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=
=B6=E4=BA=BA: internet-drafts@ietf.org =
[mailto:internet-drafts@ietf.org<=
/a>] 
=E5=8F=91=E9=80=
=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B47=E6=9C=885=E6=97=A5 =
19:55
=E6=94=B6=E4=BB=B6=E4=BA=BA: Liushucheng (Will); Adrian =
Farrel; Liushucheng (Will); Qin Wu
=E4=B8=BB=E9=A2=98: New Version Notification for =
draft-wu-opsawg-service-model-explained-00.txt
=
 
 
A new version of I-D, =
draft-wu-opsawg-service-model-explained-00.txt
has =
been successfully submitted by Qin Wu and posted to the IETF =
repository.
 
Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =
draft-wu-opsawg-service-model-explained
Revis=
ion:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Service Models Explained
Document =
date:=C2=A0 =
2016-07-05
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Individual Submission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 12
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-wu-opsawg-=
service-model-explained-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-=
explained/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
https://tools.ietf.org/html/draft-wu-opsawg-service-model-explaine=
d-00
 
 
Abstract:
=C2=A0=C2=A0 The IETF has produced a =
considerable number of data models in the
=C2=A0=C2=A0 YANG modelling =
language.=C2=A0 The majority of =
these are used to model
=C2=A0=C2=A0 devices and they allow =
access for configuration and to read
=C2=A0=C2=A0 operational =
status.
 
=C2=A0=C2=A0 A small number of YANG =
models are used to model services (for
=C2=A0=C2=A0 example, the Layer Three =
Virtual Private Network Service Model
=C2=A0=C2=A0 produced by the L3SM =
working group).
 
=C2=A0=C2=A0 This document briefly =
sets out the scope of and purpose of an IETF
=C2=A0=C2=A0 service model, and it =
shows where a service model might fit into a
=C2=A0=C2=A0 Software Defined =
Networking architecture or =
deployment.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<= pre> 
 
Please note =
that it may take a couple of minutes from the time of submission until =
the htmlized version and diff are available at =
tools.ietf.org.
 
The =
IETF =
Secretariat
 
____________=
___________________________________
OPSAWG mailing =
list
OPSAWG@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/opsawg

 

------=_NextPart_000_0AAB_01D1E19F.D11A5AB0-- From nobody Tue Jul 19 01:40:44 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BB812DCD8 for ; Tue, 19 Jul 2016 01:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 FaArLGVfZ_UG for ; Tue, 19 Jul 2016 01:40:40 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA61F12DC99 for ; Tue, 19 Jul 2016 01:40:39 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6J8ebQH007956 for ; Tue, 19 Jul 2016 09:40:37 +0100 Received: from 950129200 (jplon-nat12.juniper.net [193.110.55.12]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6J8eZ04007911 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jul 2016 09:40:36 +0100 From: "Adrian Farrel" To: "'opsawg@ietf.org'" Date: Tue, 19 Jul 2016 09:40:37 +0100 Message-ID: <0ac101d1e199$3a03d2b0$ae0b7810$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AC2_01D1E1A1.9BCC8070" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHhmTA9zNfQcrkaQrOlQpjRSyXPVQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22460.006 X-TM-AS-Result: No--25.566-10.0-31-10 X-imss-scan-details: No--25.566-10.0-31-10 X-TMASE-MatchedRID: f/EOsHyrSe+KDa5m+5vWeEYmcTlfI8c1lnrMq7Sriu09wWQKVyZA23EN mofN9nrpYKXU5x6vEGN+TVY0aF/W6sZ7zUqB6kGE3FqOVb7PDELTBg/CbgV2T1Xzges/EJ9sQbj LwHiYPeUzZOzHbi+m0Pg65vLO7SlmQjDhdr0sC0wER9Ta+6BEXVt06oMfzUpKWltirZ/iPP6B0Y 6DmvPQh5DlCtvowkc107Km3/TzG2I7E753hz6GdX7siEtWY367GW6TfocNCnvAyhGgBjmG1mDbU AcMOUZ0Q/HdRjQFJJYdbDbNE/Qnuhpx19zqQvndZ6w5EEDrkXTzWqWqi0pBAbrfxlRjqBJ33EG3 VQNfzXvN34C5P95b+eXq6XOn2VcqJHcsIKJcneCWLCkl1lq7B5D+wzfBXGdBOymdv3651+gKyDz gjVbfWQhHQ/Rf450auWZmXgxTootl5bDgN7KH9p2ve5mkUhy0h8Ytn75ClDP0NSuQztbtQ9C9nq gpjKuWsxD28Qp5UOW2rpc7g/WvZUj7ejO32BAyQr2qXCJMSV9QXEq/7YCYyEENV4Lwnu7B4O6D2 PAgEXkmb7x6QT47vdJtJwTj77A2K+yUutjNcUzBVprK8rvWXzoSfZud5+GgMRGLWFpZnsg+UBbB 9UDbDu5f+SbQ7Vhgls1+C1BQP6RHW+94FA8JF8G0UNgaZpYqtF9GMNu1bqLkOOZ1bT6psa7BVPF MOQQusrZgdv+SJ0/88SAvS2rKrnRue7aQeqLEsyw+ZJnFumQTskidPjB12hON+Q7elv5YPSawiB LK6fcf9nvUckM1oVpzKEH0vVqv349mr5n4pjOeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyIikvdS5 PcmKOdv2S6/K/K9Lsq9ZdvO3uEuz57ZRT1QpowScCWZyXOvh9VofQ9ZEMw= Archived-At: Subject: [OPSAWG] BTW draft-wu-opsawg-service-model-explained now at rev -01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:40:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0AC2_01D1E1A1.9BCC8070 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable We only made a small change, but one thing we did was try to highlight a = distinction between the model on the interface between customer and = operator (a la L3SM) and the model on the interface between OSS/BSS/etc. = and network orchestrator (which is what we see as YANG models in BESS, = for example). =20 Have a look at Figure 3. =20 Adrian =20 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: 19 July 2016 09:28 To: 'Benoit Claise'; 'Qin Wu'; 'opsawg@ietf.org' Subject: Re: [OPSAWG] New Version Notification for = draft-wu-opsawg-service-model-explained-00.txt =20 Benoit, =20 I think that you mean to say "is *an* objective of". That is, the draft = you point at has a far wider scope and purpose. =20 No problem with that. =20 Doing our work in L3SM we repeatedly encountered confusion about what a = service model is and where it fits in the "hierarchy". So we wrote some = text. =20 Looking at our draft and Figure 1 in the yang-model-classification there = is not complete coherence. =20 Which way would like to go forward? Roll our text into yang-model-classification? Push forward separately? =20 Adrian =20 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise Sent: 19 July 2016 09:18 To: Qin Wu; opsawg@ietf.org Subject: Re: [OPSAWG] New Version Notification for = draft-wu-opsawg-service-model-explained-00.txt =20 Qin, Explaining the difference between a service and network element YANG = modules is the objective of = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classificat= ion/ Abstract =20 The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards-defining organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish YANG modules of configuration, state data and operations for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. =20 A consistent terminology would help with the categorization of YANG modules, assist in the analysis the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG-related discussions between the different groups. =20 This document describes a set of concepts and associated terms to support consistent classification of YANG modules. Regards, Benoit Hi, We have submitted a new I-D that discusses the scope and purpose of = service models within the IETF and describes how a service model can be used by a network operator. https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/= =20 In addition, this draft clarifies the role and position of service model = in the SDN architecture and Clear several misconception on the service model. =20 Your questions and comments are welcome. =20 Regards! -Qin -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B47=E6=9C=885=E6=97=A5 = 19:55 =E6=94=B6=E4=BB=B6=E4=BA=BA: Liushucheng (Will); Adrian Farrel; = Liushucheng (Will); Qin Wu =E4=B8=BB=E9=A2=98: New Version Notification for = draft-wu-opsawg-service-model-explained-00.txt =20 =20 A new version of I-D, draft-wu-opsawg-service-model-explained-00.txt has been successfully submitted by Qin Wu and posted to the IETF = repository. =20 Name: draft-wu-opsawg-service-model-explained Revision: 00 Title: Service Models Explained Document date: 2016-07-05 Group: Individual Submission Pages: 12 URL: = https://www.ietf.org/internet-drafts/draft-wu-opsawg-service-model-explai= ned-00.txt Status: = https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/= Htmlized: = https://tools.ietf.org/html/draft-wu-opsawg-service-model-explained-00 =20 =20 Abstract: The IETF has produced a considerable number of data models in the YANG modelling language. The majority of these are used to model devices and they allow access for configuration and to read operational status. =20 A small number of YANG models are used to model services (for example, the Layer Three Virtual Private Network Service Model produced by the L3SM working group). =20 This document briefly sets out the scope of and purpose of an IETF service model, and it shows where a service model might fit into a Software Defined Networking architecture or deployment. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. =20 The IETF Secretariat =20 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg =20 ------=_NextPart_000_0AC2_01D1E1A1.9BCC8070 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

We only made a small change, but one thing we did = was try to highlight a distinction between the model on the interface = between customer and operator (a la L3SM) and the model on the interface = between OSS/BSS/etc. and network orchestrator (which is what we see as = YANG models in BESS, for example).

 

Have a look at Figure 3.

 

Adrian

 

From: = OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian = Farrel
Sent: 19 July 2016 09:28
To: 'Benoit Claise'; = 'Qin Wu'; 'opsawg@ietf.org'
Subject: Re: [OPSAWG] New Version = Notification for = draft-wu-opsawg-service-model-explained-00.txt

 

Benoit,

 

I think that you mean to say "is *an* objective of". That = is, the draft you point at has a far wider scope and = purpose.

 

No problem with that.

 

Doing our work in L3SM we repeatedly encountered confusion about what = a service model is and where it fits in the "hierarchy". So we = wrote some text.

 

Looking at our draft and Figure 1 in the yang-model-classification = there is not complete coherence.

 

Which way would like to go forward?

Roll our text into yang-model-classification?

Push forward separately?

 

Adrian

 

From: = OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit = Claise
Sent: 19 July 2016 09:18
To: Qin Wu; = opsawg@ietf.org
Subject: Re: [OPSAWG] New Version Notification = for = draft-wu-opsawg-service-model-explained-00.txt

 

Qin,

Explaining the difference between a service and = network element YANG modules is the objective of https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-mod= el-classification/

Abstract
 
=C2=A0=C2=A0 The YANG = [RFC6020] data modeling language is currently = being
=C2=A0=C2=A0 =
considered for a wide variety of applications throughout =
the
=C2=A0=C2=A0 =
networking industry at large.=C2=A0 Many standards-defining =
organizations
=C2=A0=C2=A0 (SDOs), open source =
software projects, vendors and users are =
using
=C2=A0=C2=A0 =
YANG to develop and publish YANG modules of configuration, state =
data
=C2=A0=C2=A0 =
and operations for a wide variety of applications.=C2=A0 At the same =
time,
=C2=A0=C2=A0 =
there is currently no well-known terminology to categorize =
various
=C2=A0=C2=A0 types of YANG =
modules.
 
=C2=A0=C2=A0 A consistent terminology =
would help with the categorization of YANG
=C2=A0=C2=A0 modules, assist in the =
analysis the YANG data modeling efforts in =
the
=C2=A0=C2=A0 =
IETF and other organizations, and bring clarity to the =
YANG-related
=C2=A0=C2=A0 discussions between the =
different groups.
 
=C2=A0 =C2=A0This document describes a set of =
concepts and associated terms to
=C2=A0=C2=A0 support consistent =
classification of YANG modules.

Regards, Benoit

Hi,
<= pre>We have submitted a new I-D that discusses the scope and purpose of = service models within
the IETF and describes how a =
service model can be used by a =
network
operator.
https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-=
explained/
 
In =
addition, this draft clarifies the role and position of service model in =
the SDN architecture and
Clear several =
misconception on the service =
model.
 
Your questions =
and comments are =
welcome.
 
Regards!
-Qin
-----=E9=82=AE=E4=BB=
=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=
=B6=E4=BA=BA: internet-drafts@ietf.org =
[mailto:internet-drafts@ietf.org<=
/a>] 
=E5=8F=91=E9=80=
=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B47=E6=9C=885=E6=97=A5 =
19:55
=E6=94=B6=E4=BB=B6=E4=BA=BA: Liushucheng (Will); Adrian =
Farrel; Liushucheng (Will); Qin Wu
=E4=B8=BB=E9=A2=98: New Version Notification for =
draft-wu-opsawg-service-model-explained-00.txt
=
 
 
A new version of I-D, =
draft-wu-opsawg-service-model-explained-00.txt
has =
been successfully submitted by Qin Wu and posted to the IETF =
repository.
 
Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =
draft-wu-opsawg-service-model-explained
Revis=
ion:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Service Models Explained
Document =
date: =
2016-07-05
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Individual Submission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 12
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-wu-opsawg-=
service-model-explained-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-=
explained/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
https://tools.ietf.org/html/draft-wu-opsawg-service-model-explaine=
d-00
 
 
Abstract:
=C2=A0=C2=A0 The IETF has produced a =
considerable number of data models in the
=C2=A0=C2=A0 YANG modelling =
language.=C2=A0 The majority of =
these are used to model
=C2=A0=C2=A0 devices and they allow =
access for configuration and to read
=C2=A0=C2=A0 operational =
status.
 
=C2=A0=C2=A0 A small number of YANG =
models are used to model services (for
=C2=A0=C2=A0 example, the Layer Three =
Virtual Private Network Service Model
=C2=A0=C2=A0 produced by the L3SM =
working group).
 
=C2=A0=C2=A0 This document briefly =
sets out the scope of and purpose of an IETF
=C2=A0=C2=A0 service model, and it =
shows where a service model might fit into a
=C2=A0=C2=A0 Software Defined =
Networking architecture or =
deployment.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=

 
 
= 
Please note that it may take a couple of minutes from the time of =
submission until the htmlized version and diff are available at =
tools.ietf.org.
 
The =
IETF =
Secretariat
 
____________=
___________________________________
OPSAWG mailing =
list
OPSAWG@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/opsawg

 

------=_NextPart_000_0AC2_01D1E1A1.9BCC8070-- From nobody Tue Jul 19 02:28:44 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8460C12DD8F for ; Tue, 19 Jul 2016 02:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 lOGHbkihd-Sj for ; Tue, 19 Jul 2016 02:28:41 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF7612DD93 for ; Tue, 19 Jul 2016 02:16:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ExAgAs741X/xUHmMZbHQGCUyEtVoECj?= =?us-ascii?q?SSrO4F6KYVxAoEyOBQBAQEBAQEBA2IcC4RgAxIbXgEVFSYwHwcBBBsGFIgOAZ9?= =?us-ascii?q?BhROYXgEBCAEBAQEBFA6GK4kOgyqCLwWXdYEvAYM2hVeHP4RZgyOFUJAeHjaDc?= =?us-ascii?q?4d/AX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2ExAgAs741X/xUHmMZbHQGCUyEtVoECjSSrO4F6KYVxAoE?= =?us-ascii?q?yOBQBAQEBAQEBA2IcC4RgAxIbXgEVFSYwHwcBBBsGFIgOAZ9BhROYXgEBCAEBA?= =?us-ascii?q?QEBFA6GK4kOgyqCLwWXdYEvAYM2hVeHP4RZgyOFUJAeHjaDc4d/AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,388,1464667200"; d="xml'?pptx'72,48?scan'72,48,72,217,208,48,145?jpeg'72,48,72,217,208,48,145,145?rels'72,48,72,217,208,48,145,145"; a="196674609" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 Jul 2016 05:16:55 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 19 Jul 2016 05:16:55 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 19 Jul 2016 11:16:53 +0200 From: "Romascanu, Dan (Dan)" To: "opsawg@ietf.org" Thread-Topic: auto attachment presentation Thread-Index: AdHhnkkGSG4+NjNNR0eV6e6td9jjqw== Date: Tue, 19 Jul 2016 09:16:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7524094E@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/mixed; boundary="_004_9904FB1B0159DA42B0B887B7FA8119CA7524094EAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [OPSAWG] auto attachment presentation X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:28:43 -0000 --_004_9904FB1B0159DA42B0B887B7FA8119CA7524094EAZFFEXMB04globa_ Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA7524094EAZFFEXMB04globa_" --_000_9904FB1B0159DA42B0B887B7FA8119CA7524094EAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please find attached an updated auto-attach presentations - Slides in the right order (!) - Links to the open source implementations Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA7524094EAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please find attached an updated auto-attach presenta= tions

 

-     &= nbsp;    Slides in the right order = (!)

-     &= nbsp;    Links to the open source i= mplementations

 

Regards,

 

Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA7524094EAZFFEXMB04globa_-- --_004_9904FB1B0159DA42B0B887B7FA8119CA7524094EAZFFEXMB04globa_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="ietf_96_auto-attachment_01.pptx" Content-Description: ietf_96_auto-attachment_01.pptx Content-Disposition: attachment; filename="ietf_96_auto-attachment_01.pptx"; size=78010; creation-date="Tue, 19 Jul 2016 09:13:44 GMT"; modification-date="Tue, 19 Jul 2016 09:13:44 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAZRHAA7wEAANQPAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM l99u2jAUxu8n9R0i31bE0PXfKkIv2vVq3ZDaPoCbHMCbY1v2gZW330mgNEVpGU2s9AbJOOf7fj4I fznDy6dcRQtwXhqdsEHcZxHo1GRSTxP2cH/TO2eRR6EzoYyGhC3Bs8vRwZfh/dKCj6ha+4TNEO0F 5z6dQS58bCxo2pkYlwukpZtyK9I/Ygr8qN8/5anRCBp7WGiw0fAaJmKuMPr+RF+vSH5bmLLoavVg 4ZUwmRcC5QavrXGg/FaNsFbJVCCdji90tkXWW1PFVFk+42fS+kNCZ/UOxc5rqKrBuu4XtdPJDKKx cPhT5ITOrUVuHXg6dWkUv69Ug2omE5lCZtJ5TiJxVSxXr5ZxLqR+PsRbMF4R4a3wSD89rywGbZNV tP+LaU0ThmMfgqMgndiH4GvnBMedE5x0TnDaOcFZ5wTnnRAUd9zYGevbdt8I7/o3LiT8DUKwEd5F gJSowMvP5ldiKbPTUTwquMOlgtb7ji/SuyjK2PghlmaO60RYLZo3YSs5K0YfZQqTFKvzfpQpTHY0 YwqTJs2YwuRLM6YwidOMKUwGNWMKk0rNmL61nVUt3E+D/meE6uompxGqjHSaQh3s35jnkbGo7ll6 OwGHEjZDY928tXGkYXF/w63BD4oZOYOsxpuXM/noHwAAAP//AwBQSwMEFAAGAAgAAAAhAGj4dKEF AQAA4gIAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskttKAzEQhu8F3yHMfTfbKiLSbG9E6J3I+gBj Mrsb3RxIptK+vaHgYWEtgr2c0z9f8s96s3ejeKeUbfAKllUNgrwOxvpewXP7sLgFkRm9wTF4UnCg DJvm8mL9RCNyGcqDjVkUFZ8VDMzxTsqsB3KYqxDJl0oXkkMuYeplRP2GPclVXd/I9FMDmomm2BoF aWuuQLSHWDb/R1s6YjTIKHVItIipkCW25S2ixdQTKzBBP5Z0PnZUhRrkPNDqvEA87NyLRzvOoHzV qtdI/W9Ay78Dha6zmu6D3jnyPGOCnHZ8M8XIMibKZexo+6kfuj4nEO2ZvCFz2jSM8ZNITi6z+QAA AP//AwBQSwMEFAAGAAgAAAAhABRrO4W/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRl My54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14 j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQi yxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEp PHPBYuooa5Byfue52MryPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQCgWcZ6GwEAAOoCAAAg AAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHPUksFqwzAMhu+DvUPwPXHTwRijSS/b oLBdRvcAwlYSU8cysrK2bz9vo5BCYQx22VE2+vR/Qqv1YfTFO3JyFBpVVwtVYDBkXegb9bZ9Ku9U kQSCBU8BG3XEpNbt9dXqFT1IbkqDi6nIlJAaNYjEe62TGXCEVFHEkH864hEkl9zrCGYHPerlYnGr ec5Q7Rmz2NhG8cbeqGJ7jHnyz2zqOmfwgcw0YpALI/SQSexd2GUocI/yjU05swUB4ZwOuXIo3Vda S0Zbhk5KpixkIEwlxQT7voRJqAQRMEPpvY36hHwhm9M+HgQ5gFf6stbyH2h1DCPuiXe/dKv/0i15 Z/EZjjTJacONqio9e0/zoq7yxX1uXZ9daPsBAAD//wMAUEsDBBQABgAIAAAAIQCI8NgiGwEAAOoC AAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHPUksFqwzAMhu+DvUPwPXGbwRij SS/boLBdRvcAwlYSU8cysrK2bz9vo5BCYQx22VE2+vR/Qqv1YfTFO3JyFBq1rBaqwGDIutA36m37 VN6pIgkEC54CNuqISa3b66vVK3qQ3JQGF1ORKSE1ahCJ91onM+AIqaKIIf90xCNILrnXEcwOetT1 YnGrec5Q7Rmz2NhG8cbeqGJ7jHnyz2zqOmfwgcw0YpALI/SQSexd2GUocI/yjU05swUB4ZwOuXIo 3VdaS0Zbhk5KpixkIEwlxQT7voRJqAQRMEPpvY36hHwhm9M+HgQ5gFf6slb9D7Q6hhH3xLtfui3/ 0i15Z/EZjjTJacONqio9e0/zoq7yxX1uXZ9daPsBAAD//wMAUEsDBBQABgAIAAAAIQAUazuFvwAA ADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9 iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0Izugt DsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0Hwx xdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjK8j6oplZfc5sPAAAA //8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1 LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiP g3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLL EMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8 c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhABRrO4W/AAAANwEAACAA AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNi54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgie RD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgO zXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sG cZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MryPqimVl9zmw8AAAD//wMAUEsD BBQABgAIAAAAIQBHt2QILQEAAGUDAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTcueG1sLnJl bHPEk8FKAzEQhu+C77Dkvsl2LSLSbS8qFPQi9QHGZLobmk2WzGxtfXqjUtliSz0UPCaTfPlm+DOZ bVqXrTGSDb4SI1mIDL0Oxvq6Ei+Lh/xGZMTgDbjgsRJbJDGbXl5MntEBp0vU2I6yRPFUiYa5u1WK dIMtkAwd+lRZhtgCp2WsVQd6BTWqsiiuVRwyxHSPmc1NJeLcXIlsse3Sy6fZYbm0Gu+C7lv0fOAJ 1SRSdNavEhRijfyNpeRcW276V6lDq6DnkAMz6EYB5GR+jj8Fk0zuN4zRgxPqsHL578rOmc7sevyb 9Oic0uSswUfYhp53FpWQUg32abgoZYrJsXGOz2l2JAEpAJ9hXdObZd18JTWFE4GQhoW8lGNZSIYo 6/ddZ7/nq/Y+x/QDAAD//wMAUEsDBBQABgAIAAAAIQC+G0RyLwEAAMwCAAAgAAAAcHB0L3NsaWRl cy9fcmVscy9zbGlkZTgueG1sLnJlbHO8kl9LwzAQwN8Fv0PJe5O2ggxZuxcVBvoi8wMcybWNS5Ny udrt25sNJhsMRBAfL+F+97s/y9VucNknUrTB16KUhcjQ62Cs72rxvnnOFyKLDN6ACx5rsccoVs3t zfINHXBKir0dY5YoPtaiZx4flIq6xwGiDCP69NMGGoBTSJ0aQW+hQ1UVxb2ic4ZoLpjZ2tSC1uZO ZJv9mCr/zA5tazU+Bj0N6PlKCdUnEjnrtwkK1CF/Y+d5lhYRF0V19CyTaYdRHeJSf8ieB3dKeg0m +TztGMmDE+q6ePUP4jEN2wADUxorUuqA26O+CVoZgpZzCmkTGvyUhzHC3OUwcciBGXSftwQDzoG2 6ne9lX/ZW3TW4Avsw8Qni1pIqc7e43lQyXRTh6mrixtsvgAAAP//AwBQSwMEFAAGAAgAAAAhAKd0 L9lPAQAAdwcAAB8ACAFwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzIKIEASigAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvNXdToMwFAfwexPfgfReStmnZrAbY7ILE6PzATo4fERo m7ZOeXsbNpEty/Gm2Q1JD3D6y5+2rNbfbRPsQZtaioSwMCIBiEzmtSgT8r59uluSwFguct5IAQnp wJB1enuzeoWGW/eSqWplAtdFmIRU1qoHSk1WQctNKBUId6eQuuXWDXVJFc8+eAk0jqI51eMeJD3p GWzyhOhN7ubfdsrN/H9vWRR1Bo8y+2xB2AtTUNPUObiGXJdgE9IPzaG6CJ2U0MsINvGpsHzXwJvt GpflYBkVMYlXCBJHjCEWPtNAEHMMwWKfCutW7Ghl9EPaXxmG8GpAkkARzGcQPeKZGwv6b3GOisft cngCZc29s85AR8oM+0DMazj7Gr5etFSjfTuUMMXsSlFMMQRzZ7u/o1RpMGdRDCVMMfWJQHbMBEPc Xwmx/EXQk99l+gMAAP//AwBQSwMEFAAGAAgAAAAhAMOwyBV4AgAAdQ0AABQAAABwcHQvcHJlc2Vu dGF0aW9uLnhtbOyX3Y7aMBCF7yv1HSLfVmzID0mICCu1FdJKWwkt7AN4kwGidZzINhT26Tt2THGJ Ku0D5C7O8RzPfIwds3g8N8w7gZB1ywsSPEyJB7xsq5rvC/K6XU0y4klFeUVZy6EgF5Dkcfn1y6LL OwESuKIKQz204TKnBTko1eW+L8sDNFQ+tB1w1HataKjCodj7laC/0b5hfjidJn5Da05svPhMfLvb 1SX8bMtjg8v3JgKYyUMe6k5e3brPuLlV/JuSpCfYHN8kqFXLlUQ6ZIllS1b9olKBeKqepbp749VV QcIgTuMsSmJkJ3L9BucGxF8u/P+Eu1ZPVW8yS5zoUEeb4KucuObRUI6d6Hggp6Ejz4Zy5MjJUHbN 04GcpE50NpDTwJHnWu6xuBA2H155Lsg8iOPpFHuyvBQkyWaZGahLh50oSwHA47OtnbcKpA37O1OH XT0MwAp29MjUFs5qoy4Mlgua47v1Wtinl7XwGNXND3zyujHZuVPYiQUdzmmoeC4IZkbZHjcOIx7a bOnb5uO6IhapmJkC9Jl/F++6gdBb1dwOMfqAS+FeWB95qfoGM4vpLCQ6BVgw8d5B6L2JuwUbkOay ZXW1qhkzA73P4AcT3oniaurc99ndLLOqp7ntaInsvjV8wpQujuZA7wSgvVDKO6GUNxyYIf5uNLc8 tBE+hjc08SzVCY98DBTLJ7rx6dty5HNiGorlE9/4BFEaJGMD6V2lqVhAMwdQFmbmeBhPIE3FAkpu gMIwwwYajyDsIE3FAkodQGkcjWe0+XBpKhZQdgOk6eD9YzykT0xTsYDmDqBklo6HtOkgTcXcZIdX TLzeuv8yln8AAAD//wMAUEsDBBQABgAIAAAAIQCxTuYK7wIAAHgIAAAVAAAAcHB0L3NsaWRlcy9z bGlkZTEueG1spFXLbtswELwX6D8QPKUHRU4CFK1gOWiSNijQJkaUfMCaoizBFEmQlGP367ukLDty rcZNfbBey+HO7OxyfLmqBVlyYyslU3p2OqKES6bySs5T+vT4LfpEiXUgcxBK8pSuuaWXk/fvxjqx Iie4WtoEUlo6p5M4tqzkNdhTpbnEb4UyNTh8NPM4N/CMqLWIz0ejj3ENlaSb9eaY9aooKsZvFGtq Ll0LYrgAh5nbstK2Q9PHoGnDLcKE1b2UJsiMZSL3V6sfDef+Ti5vjc701ITPd8upIVWOelEioUZZ aLz5sAkLjxLD8CbeWz7vkCBZFaaejCFBbmSVUhR/7f9xESR85QhrX7LdW1beH4hl5dcD0XG3AWaw 3dSzahn9See8o/NYOcHJ2ZZVGwq49IdiC0ukQp6efkuP3S07MM/Zw+uSuLVGZZgzAW0T2n4PknRL LMoa9HKrK5WvPfcZXj0OJBId9KVxqqgcKZR0GQOBqJ9H+AuQL4OFdZlbCx70Q5aQBAyD1RLgDc1l 9JRRklfG7SR1E78B+rRiBJwDVnqDEVVgJ+Te/MFhBHuASO6elVmQMUrrsLLdBmGrwV2Ird214IAN tqmtm+R8iW62e0CzV/LdR8IE2iWY6RQMPLzM4faqzxSDUROUvtMZb1svDDvionNE1sxcMMW5Vx1b pCv5m0xhm1lrCuwitHjno/8xh5CZZg88b5gvF2K+2SE93fYV93W/AUke0DCWgWx6FWwlDjp31his yCHkKTSCPMkZL2HO5b9C218pxdmKU2Rr8EObnPRwD+Xpe2QH1qTUyvkQqLd+KSq5uBYVWxCT+Llo vufBJ75B2j5GxxsoXGQ63SKlLTzPI8Dei9q2iwqDw9Q3WDQavZqkL9Muyb8y/tADe6VIffKHcYdI X2xG0pb0yRGshcj1MYQHEgvDzk36HPH4GJgIR0g2NCjCvGhPRLztDkkmzE/Q98swurApHDfX4ZXG 0x6T86G7EI+Bh+tvAAAA//8DAFBLAwQUAAYACAAAACEAzojdag0KAAD9PAAAFQAAAHBwdC9zbGlk ZXMvc2xpZGUyLnhtbOxb627cuBX+X6DvQOhXC+xkdL8M4izsSbzYwskGdnb/MxLHI0QjqpRmbLco 0Gfpo/VJ+h1S0twzvm22SSYBbFkij8jD79yPXv54OyvYQqg6l+WJ5bywLSbKVGZ5eX1i/frhfBBb rG54mfFCluLEuhO19eOrP//pZTWqi4xhdlmP+Ik1bZpqNBzW6VTMeP1CVqLEs4lUM97gT3U9zBS/ AdVZMXRtOxzOeF5a7Xx1n/lyMslT8Vqm85koG0NEiYI3WHk9zau6o1bdh1qlRA0yevbakl5hZ+lV kdHvuvqghKCrcvGTqq6q90o/frd4r1iegV8WK/kMbLGG7YN2mP6zxDBcDDemX3eU+Oh2omavXvIR 9sZuTyww/45+YhIfiduGpeZmurybTn/ZMTadvtkxeti9ACvoX0q7MjvasR2v28+lnJeZyNilSHH4 14VgjtvvkSZubbCjVmsmdW/utxZFbui7ABO24ntBHITR+jZDP7Yj12K0Vy/y4sCh5/0W+KhSdfOT kDNGFyeWohXS8ixiFl9c1I0Z343TjDerwZ6buwIHyUdFeSkmODsw1tUzNWLFuFBswYsTi6cpYOGY R1OeCXM7sPGvXVA/Qy9PEyTKk7woetotAZKGbdpmne14fdSTCTbST7Y/tzAzWXQz9JtluZw8y0up dhEosKv2zWa8YZBhTDVqbs9kdkfkPuI38K2aYizBEYCSl+lUQkjTRplDK+rmiiaCHg5G/8AMXlxD h/SDRJm954pf4kkBDJ1Yohz8etWuAZOAyu6luDSo3I9NQMOI2oe8ITgSHUjqu4UBHgeBC5l+qlkp IYMkmrTZlREkhUZ+qylr7ipIbUOk2nHmISaULUVaUovzbpkdb/S2t3mgiBFqY7ssy1Wj5ZfVs2Zc CA4etSLevPowFex03sjBadPwdEqajY1lmYqqIew3GmKa7h5uLsnTdvVhPIyvvciPCznP2NOk3LOD JPZwVCTEgRs5UUDsXSozN45tzwWkSMxd13NdP9YHsFQYnfy2cp7SsjSed8o4zl0WeXYO4aP39LJp xLa5NUJezGdvZWbuwfoYUYYymM9Im2rBj7vbYGJPRbN05QUapwZER41ifeUaxe81CkztmbxlHiGx 1xiMpB5motU0q8bcqByjIAh1G2bcC2PHgX3Ttg5CEEbJuhQ4ABtg2Bq7MPEgMkZ8O0obQqA+a+f4 qJQkAESiW9RSt3ZKi90oDr1Y/33OlbBW1LuWm4q00Hne2lBjAujBs2i5sVSCvRPNjVSfvpBaC7rD PS/kTTrlqhmxq/kM1vGa/W1epuQ1Mn/twPXhP+CYA+gyN07MMft2EicbLo0X2rb/gFOeYKljWmq7 0G6d+7XfynEf9dHXro/C+0BW29NeRz0Usm4UJnEExQfr6/uem8QbwcYRstqJJ83Xu9gmWjg65b1f DKcbTi7Fv7BxrVPemtBwTaM+3oS6geM4rgGqFydhYmsLuXQkHTuJfAciQ46kHzphqCXjM/Hi85nQ EpmQJxhQRBWbodLuyKH+B7wP7Sf0MQQEnqKCNxtW9N7zd8Ug2XVvnNkaXRNO7A/wnvTW12KBdM7a +3C6u0NGtpsTjwl3YK7XEavDj16hPh6xQRDbgKwJfeIwQmiz4fQdEbsSzj4JO98VYh14kAay20k5 HVf04H2oN4Dw3LWRwtTOQOAEvvaHlzr2mJI7puS6xNwyK7a0/k6f/v7Qmn9gVYOwTcs9XptGQRBE sO4amjtCKzy0Q7gH2voDucmBLNL/UwD9MPtvB5D/3v7vst9vyoxdmUrGQ8zpOmEc22PMKRm8dXsK UDwTBKLQRYhiMOChJLCZSzxiYJlH/kMxsJVIc54rk7aiBhzPt6NQi/nSQkURbnV6wAnCJAy7Ks1X kEkjRTDj6gKZ8DiISM5zFN1KFLcG7Q3y9j/Oz1Gv0RWLCU9RtThVOS8sVvFS1vgTmcQzO0Siye3/ 40CqvEmn53yWF1ChHmlKJJZqAdptxP9xTqkmffvE+u+//0NSSxqAstuoYugfm6UM7YYjqXVAIV3l s6rIJ3cMVWBl6rNI5stUZHNUXdnHO8aRbERhmJJxDSogqSwn+fXcjGVywkqTK2SZDhJqFKAylKWz ASrRutzLGkm8yhd5NucFq4WiYKLGPcZBDdnGlsKaQtyKZ75F5l/OiQc1HYFgCFQHU1mxIUPuFXV8 UdV0Eo1MZQHO8+ZAwGcYFPluQugsFigHwuZ/Gyh9ndeppM4Hja6cBC+f5ADRJtAEhRstEu+Dp2+T XahKahkFg0hki7z8pBkH2S2RWjF3W/kk8aRBfMHzgn8EEFdlkkEJyLlKBfvLhfvb+3c/sLfvL65+ YKJJX/yVrSPyQEpgXRc91ofpawUXYtIMLvPracNOlZI3zHlahcDxQhRBUWElN9ZLkB7YqBA4vu2H FIJpPzbxw1i/EIpqj/kqsEK9QL0+i7T0I8qiq00Ox9IoMbGv+JpicMcgg6g+E0wjJ99DswUlVo1b vy0ST6tAhG7guzb8ES0SNpp+Nlw6x49cNAYYkQgciMSBxO5RJMREA/PYf/T0/qP0trxq2+PGdLnV 8IcONiMYV43iK5YC5pHMoFTM0TpeJ+VaEjoeXi0sr5CmHiM6PdL3bFLk1W/kYtGdticQ8hCEQZsK CULXgScGgssYyEEPDQyNEZgDfQR1u+h+teZVe0xIUdJ7Vtpf9ujJ7R6b/e1ya9SmgmcUuZpuLE4m 1+ytgd+w4wHsIq3pQNX7Hr13u5v27lHi+9JNe82t6WPr7Y7ZvWnaAx96vPYX5WIFXSu5ur7wsR+4 y1JIS+K+wN0H18hx/M2ksuOiNpK0Ls+BYP0IV+OAfH9wpRbBQ3p2Wfx4PFxDD94GJTR0ojlEC7L2 Nla1a4ieCAgPeehHuHbG6bP+8ncI174Ssle7AtFanUIlPxNcQ/TRw5PecAZioPUI175w9106A5/p ot+q17jPVa9xwsSBAu0iuwRAXMdm7CTkDWhN6qJjxxQL9+c67l2zM17hahfslp+42cH/+zbD6jy5 czBP3mUg79ayigdSXutkjX/w8I8pcAzGvHaVW0TcnXqiqOfxldswRON/BwMHzc/+Rs4rdiLbazXU EQZo5vrjYOD1XlYPg6VT9TQYoOmdmtxbxyqB168BtuJY2a4TJVgAOVZHHAAHXYZdl7i+uErwehem wwLQ8UwqAW6KF7Q5P99DJXfTyT5iYeO7sN8fCzqJ0n3eivYdfD9JH7/gis1VfmL98+wsCd1xfDY4 c/zzgf86iQan52EwOA883x+fxadj782/kKmqHH+UKqFR+3P3RTBubn2FO8tTJWs5aV6kcjZEegsl 22Elb4SqZK6/6HXs9rNg/UWWbvkIIifQOgnrxdp0+qNbLeU/2i9100K95dUvC51LwwfIjVD4pBO3 KtSYyUhi6HII7R1f+P4PAAD//wMAUEsDBBQABgAIAAAAIQDfKiPjrggAADE3AAAVAAAAcHB0L3Ns aWRlcy9zbGlkZTMueG1s7Fvbbts2GL4fsHcgdLVdpNb5YDQdEqcZCqxdUGcPwEl0LEyWNIp2kg0D 9hjb6+1J9pHUwbLl1XGSAlmdi0SRSIrk//H7j3r93d0iIyvGq7TITw3rlWkQlsdFkuY3p8ZP15cn oUEqQfOEZkXOTo17Vhnfvfn6q9fluMoSgt55NaanxlyIcjwaVfGcLWj1qihZjmezgi+owL/8ZpRw eotRF9nINk1/tKBpbtT9+T79i9ksjdlFES8XLBd6EM4yKjDzap6WVTNauc9oJWcVhlG9e1N6g5XF 0yyRf6vymjMmr/LV97yclldcPf6wuuIkTbBfBsnpAttijOoHdTP1b45muBhtdL9pRqLjuxlfvHlN x1gbuTs1sPn38jc60TG7EyTWN+Pubjz/caBtPH870HrUvAAzaF8qV6VXtL0cu1nOdSoyRqx2Vbop RdcfiviXiuQF1imXr5cXf1g1g8k1y+HLORH3JXZGyKHqdvqh2o+mfYU9VZsl7s6L5F4u/Gf8VTfp OKvEVNxnTG0Ipk3HGBy/sP0ZlQhl+clPU4MkKRdqj0i1EJOMUWC53kbxZlLkMSvFkmbkbCkKciYE jefkfZGw7DX2SEBE9cAsT64opx93ji/XS8eYCRbRzBiXekt3b6zbbOxHFuMw3WBznd7mqi1Yx8v6 /sglbyDFDx3Px9HEoh03iiLLl8N1oLEt37Rd4ElCx/I93wpdJYRupJJX4ntWLIi8ODU4ZmbIIejq h0rU66ybqOVKSUnJVlIgsmGWf2QzHANg1FY91eFnk4yTFc1ODRrHOGGWfjSnCdO3PRM/9VzaHmpb 1YBy5FmaZe3Y9QCSWLbH1vOs26sNmM2wkLaz+V8T051Z00O9uci7zos0L/jQABlWVb9Zt9cbpDem A0YDZcJFNimwI5AHzeN5Ab6LBdcS24Y49pnQ7AYQbhvtwGUtpYei0dtGowIHiE8fZIwrOatjr0+g 0fEDJ4ww7BGOkh6OcOzOwB7k6G/D0ZNn42A4+q7r2uaRHRuO0mx6ZEdYF3vAMWjgeA0L7Ly4I0q1 tmAkUu1D5dXG0QNY0vdd23a0jedaruO4tlYBjaVnBb5rRTgOUmk7fuQ4qgEYpdH+D9LZdJwXl5C9 1BLSRNHqu7FaWuV0yylMuerXJeXMWFNVEi9VKS2my7S2B7RlJh9say0ubz/MMCOETArOyAcmbgv+ y2eyxcAL2mZv5Bv0yOZw+Tqh6YV2pLTgsHzDwFa8JOXru77jNGbEC5DvgFVygMjPzk6mjMPf7Alb m9TKrsavbfPngBd988+ff8HQSn+DgUazf/78m1y8/3bgpTgZzYnYgxsg3D52wifCThhFXuRo6Jim G7oKGZ09L6nBc2pqiGzHAY9o6++Lgc7bPCFT7bCDOPAzIM0nhRCwOslSuDDP/aLHYDW+y6e1Pz+R l1sRijZEMRWcpjdzAc7Nc/hIBSeWApFSbW1nkL7APyq8AbdVuXfKVwUY86R5AltfPdEE1h+h7zq0 AzcqqNNmddTDDl1QpzbXXMcOTVwD2x34Qwe3oJbbMMhujZilOVMe26AXK31WcgvdGlpwQZWCK7I0 kUpS/TPkY2rXNlsuEC/QDqzfOLAYbrmQ4Rjl7rrNbcyu79dW3UvwLMt7+njInd7D5R32lfdwdz+3 cyLuGiU32/aVQblxA+D2Il+tYQYeKfSBirW1QZQhJHfhlLbzOpIbvG4jGZz6ZEj2Qse1HO0HDyLZ B+4C0PwRyTIwpBXYF4jk1uNtkXzGeXG7zsydB1zjGZv1UGINLMur7VEvgDPhbQQJncj0EIvfC45V rT1a5aE56j9p1g69wNubZjUa1rgSyhzxxwtazTXBJrjSimHOaCLNgTrCzFMVUjUktS9YYpCMIXgm r5QaETTN9m195OeZ1k46lvkgfm4d592o7lzpw1HthlDA8JxksHEY1gEMaBssvAfLHmG9FsU/mh1D BnQbL9gN6y6CcDis18jah30KO7hvBPfI2vc/4f4dcX3E9SccwzaWsRvXXXTjcFxrukZmWca8BoF9 pOtNm+Vohey0Qnbn2O3Wqm4Cu7ABlNVcZzUPj+x6ZmTbPvxPaXLYkefBx1OmZRO5d5Brd8DJLzJy /zQB14/FUqC8R/owghcZuUKBBtsI0qkQ0rMUWNit8dkKv7M1ZVTscOFbVmA7kSYwLwwCO9hI2wAQ tlTXL1L4B4TWZQAflVjkmt70Y7DPKN7WCGvF29lcjxOvZ4auZ+qYzaB4X/TZfoR45YFmZESulwgX Z+TdRS8M/oyybg2TVtadHfI4WfeOsmPZprfJ45YsrMJZl67jF5CBldndE10PJ4sqyRVPF6lIV6z6 XCcbwVCdUbsobnOiw2CKX9uEu1LhD0izu65lWxCsVNY2mDkKla/UpRMiB2FYKHMpY98NTc3nsLl2 pNISzExNTIWyBiNeKnV4LI+rC/9eeHmc1ZXB1hUglopVt4g83JawLUkqugTEdqPQQny0Z0jaHkoI AjDgSySgpzEkZTYUBQIijeu8PRVUF+v28/fPqIFaAKyTUh8DD2UlyzWtwNUZfhuZfNfdkPyRlY5F u00hed6W03fpT8kaWlN2NeRI7igcHli2GwWe5+q8OxJFZhBuhBw9+LS+ZENJRiES8/CC8L7dmvJY Qy7LCOo8t04r/19ryFE6slEK1cfiI3SkiWIoE/48QGf5luXjO4e+jkSplB3VwZYvtIyu+45F2e11 0CVjnEwvPoyuUHAS35OBSrvHKU1l5jafRME2wociMisto2BLnp4av5+fR749Cc9Pzi338sS9iIKT s0vfO7n0HNednIdnE+ftHzCjS8sdx5ypr6/eNV+R4ebWl1uLNOZFVczEq7hYjFAwhMDDqCxuGS+L VH0FZpn1p2SqCAdFtSaM/0hTGeaLuamEZjNbmdGsv+6KM/6elj+ulI+Mj9YE4/h2BbdKxLEkz6Fp 10SuHV+F/QsAAP//AwBQSwMEFAAGAAgAAAAhAPpvcisyAwAAGwkAABUAAABwcHQvc2xpZGVzL3Ns aWRlOC54bWysVm1v2jAQ/j5p/8HK9xASAoMIqAotU6WuRaX9AZ7jkAzHtmzzpmn/fWeHtCstA9Z9 SRz77nzP48d36V9sSoZWVOlC8IEXNpoeopyItODzgff0OPG7HtIG8xQzwenA21LtXQw/f+rLRLMU gTfXCR54uTEyCQJNclpi3RCScljLhCqxgU81D1KF1xC1ZEHUbHaCEhfc2/mrU/xFlhWEXgmyLCk3 VRBFGTaQuc4Lqeto8pRoUlENYZz3q5SGgIzMWGrfWj4qSu2Ir74qOZNT5ZbvVlOFihT48hDHJdDi BbuFnZn75GAGg2DPfV5HwskmU+WwjxPAhjYDD8jf2ic44YRuDCLVJHmZJfn9O7Ykv37HOqg3gAye N7WoKkRv4bRqOI+FYRRFz6gqUwyut4IsNOICcFr4FTxyt6qDWcw2vMyR2UpgxthQO7tq0fFR22vg 1JFlNiORbi3w7/B2kzhh2szMllFHCKSNEwgOD6CfYatQyv2nmYfSQhnHEdKlGTOKQcs7Gs3wgWIr Z3RbaNMHTgwcyS4Q5ekUK/xwMJ7FhxPYGZKuM4RhReFhIuOayLHgBmSGpgwTmguWUoVaH6O1SEEU NfMHGLUk7Wkrbn+Be+cEFnaaTTt2rNYy60a9MOpA4lZscTtq9zou0T9FZA/LHm7NxMfOyiaZs4Iv xqwgC6QSe6PUTepkZ0/IbmaPy9YWDcUlxXBfFSYLqhoFNVlVVgSxpSUzvhJQeQjmS19IjddzHy+N 8LExmOR+puCeroVa7CngHD2dnHCwt8lRme3LttKcE95RyR/Kqj69/0ojY6l8je6cVF/BPCvvPUKP nNrJoUFU50X+NwTr9RoES2m3GTnNhoHEc6oD+x2SH43clOwDebh7bIZoL8RR1f2luLkaVzc/KBG3 GqqmdD1pqYqB93M06nWicXfkj8J44sdXvS/+5aTT9iftVhyPR93Lcev6lwc+YZwQRV2fvan/F2Dy TY8uC6KEFplpEFEGVbMPpFhTJUXh+n3Y3P00rDAbeFHc7vWiKI6rcuFyc2W6zhYg1H2cMPUNy/uV kw0UCUPV2E1J6AuWBTB9MbHYof//BgAA//8DAFBLAwQUAAYACAAAACEA/sumnIsEAADMDgAAFQAA AHBwdC9zbGlkZXMvc2xpZGU0LnhtbLRX204jORB9X2n/odRP7EPnzi0ijMhtFokZsgSkfTVud9qL 27ZsJyFarbT/MH84X7JldzcQmAAbMjyExF2uqnPq0lUnn+5zAQtmLFeyFzVrjQiYpCrhctaLbq7H 8VEE1hGZEKEk60UrZqNPp7/+cqK7ViSAt6Xtkl6UOae79bqlGcuJrSnNJD5LlcmJw59mVk8MWaLW XNRbjcZBPSdcRuV98577Kk05ZUNF5zmTrlBimCAOPbcZ17bSpt+jTRtmUU24vebSKSKjU5H4/1Zf G8b8N7n4bPRUT0x4/HUxMcAT5CsCSXKkJaqXD0qx8FOiGH6pP7s+qzSR7n1q8tMT0kVscN+LkPyV /8RLpMvuHdDikD6e0uzyB7I0G/1Aul4ZQA8ejHpUBaKXcFoVnGvuBIPmA6pClODVC0XvLEiFOD38 Ah79uqiUecxevc7ArTQy47yqUq54GPio5C1yGshy932VrDzwW/wfDklXWDd1K8ECIeg26aJy/ED6 BfEZymR8M40g4cYFjsDmbiAYwVwuaXSngwxFmYXUqBzOR9djON4/QW4chqZUyGQyIYZcbdTrcZIu eoDOV57i14LKzYS2K0IHSjpMN5gIQlmmRMIMtD5GL08wOaoI/B9mPYMSC/Ns7lTKHaTo25QSgcE6 bOBfBEJONb1iyZz64upFWLB4XHBQRMfr2Elwplpw57AvwLOQvAz05/4bgcYOk7p4Lm9ZRmaYGUIk Orb6Nm60gEunwC0VWKYx0o7BeTy0azaLAIco44dPhYUoGd4q795G5FN33ousnG1C5nnOBJd3A8Hp HZiu7zrmPAm547PXV5tP5QL7Gp5NTr+0yAx2YOxlT4vn3ZaxqoilRM63NL6V0XhLYx9CqrQly9mW lreDSbBGY+IcoVmcGnzVLJW524EHoaG60/el6Kvd9fu/3wCLjRlOscOWHq7r3VlhbcrJdtmbnlXD Q2bGReTip2yG5tBovIvLVwkAz4DLGFxcDCfwxIQfU8AqMfdNFBsQEAnTSR8kwz70LIprFL1sfW+/ 4wQxHOejMM+ASsExk3OphJqt1iB+1NB4LsNLgQhImKWG64AOLT5Hro2izFr2c5vsSLDAc8ItVTjH voJ2By19yswCh1ALVMmUz+b4IsHY7pTgiVFOUSUsZowfvB1HG/h69Bk2rEACSnlyN1veAdiQz3uk dlcjNZybRiM4arRqzbP+bz/V7CMBLiMOeK7LEHsGvtwMYfzQZfaqo5urCxj+PpjAZZGOuK8Ewrz4 zdUA/qztN44BZ2Qm/aLzCoAtau9M8JkMSbjkDsdedJMtqrLHwnik7g/6F+xJtQTENWzUWut+4Mj/ gTE0TKPVuoK7w4XF+VaHLWJueC/6u98/PmgNjvpxv9kZx53h8WF8Nj7Yj8f77U5n0D86G7RH/0R4 p9npUsNCZp9XGx4evtiqck6Nsip1NaryerGe1bVaMqMVjlu4oTUb5Zq3IDhJtY877U77sLMfunVw LczTlbOIoFq8qDBfiL5chGjgeIHdbBCONJaCn0NR9FHEQ8eF7T8AAAD//wMAUEsDBBQABgAIAAAA IQC2KzNPRAoAABdIAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTYueG1s7FzbbuM2Gr5foO9A+Kp7kbFE nY3JFDlMigKdaTBJH0CV6VioLHkp5dTFAn2M3dfrk/T7SYmybHnGcZLBZqJcJI5FUST/j//xo97+ cLfI2I2QZVrkhyP7jTViIk+KaZpfHY5+vTw7CEesrOJ8GmdFLg5H96Ic/fDuu3+8XU7KbMpwd15O 4sPRvKqWk/G4TOZiEZdviqXIcW1WyEVc4V95NZ7K+Ba9LrIxtyx/vIjTfFTfL3e5v5jN0kScFsn1 QuSV7kSKLK4w8nKeLsumt+UuvS2lKNGNurszpHeYWXKRTelvubyUQtCn/OZHubxYnkt1+ePNuWTp FOs1Ynm8wLKMxvWFupn6N0czfBiv3X7V9BRP7mZy8e5tPMHc2N3hCIt/T79xUzwRdxVL9JdJ+20y /6WnbTJ/39N63DwAIzAPpVnpGW1OhzfTuUyrTDDbzEo3jXHrz0Xye8nyAvOk6evpJR9vms5oztT9 cs6q+yVWpqKu6nb6olqPpn2JNVWLVd0dF9N7mvhv+EudxJO8OLquilla0WNWL2RldVHdZ0ItFKYT T1R7CbFkMSFX5Ae/XgC5fxyOeGhhXaeprNQqsnJRnWQiBtrrha7evb8psmvCEStmrJoLdlLkiVhW 13HGaATsqKriZM4+FFOR0UgqNR71TJFPz2MZf9rh0XoWGC5WoJkuPmp5bJeK20jlk0iwE68gGacj GbV+q2BbXVxanDWY+aHj+djXWA/HjaLI9qm7FnHc9i3uYtEId7bv+XboKgm2PS1lWf0oigWjD4cj iZGNqIv45ueyllbTRE2XxEywKElq1DDLP4kZ9hAAztWdSnOIk0yymzg7HMVJgu1p60vzeCr0156F n3os5g4lDNUh9TxLs8z0XXdAWmmzby2Pur1agNkMEzE3W58bmL5ZNHeoJxd5e/MizQvZ10GGWdVP 1u31AumFaYHRwJ3JKjspsCKQR5wn8wLKMqmkltjmPsA6szi7ArpNoy0I1WN4MBq9TTQqcEBrai2A fknhtarvC2h0/MAJI3Q7wJFUywDHdg/soBz9TTh6tDf2hqPvui63Bu3Y6CitTQftCNdkBzgGDRwv 4b4dF3dMmVYDRkZmHyav9qweoCV93+Xc0Q6ia7uO43JtAho30Q58146wHchoO37kOKqB8QHjSWOQ d7LZ5HydQfZkJchF0ea78VqMcbqVMfzA8l/XsRSjFVNFeCmX5Dud7e+9fdZnYwxemhTso6huC/n7 jl6Z6XJP6we9oB3+Rr5BR9nsL18ntLyQR8oK9ss3DLjSSyRf3/Udp3EjGu/u/1i+PV6JJIhsOOxG Pn1u+tHRwYWQCFY7wgbCVQSgf226P3s86Pu//vwvHK30DzhocfbXn/9jpx/+2fNQ7IxmR+ygGyDc LnbCJ8JOGEVe5GjoWJYbugoZrT9PqsFzatUQcceBHtH4fzXQeZ9P2YWO9qE48NMjzQZHTwIhYPUk SxHCPPeDHoPV5C6/wLYhd/2EPmolDz8eS6DSGya/cVHJOL2aVxQZ54iRCslsBSJl2szNUPoV/lE3 I2xV4Z2KVQHGfNpcga+vrmgF1u2hGzqYjhsT1EagdcqEhy5Up3bXXIdifbWrWvCHDr6CWTY5lO0W MUtzoSK23iiWYlZ2C9sa2ghBlYErsnRKRlL90xdj6tA2u14gc6ADWL8JYNHd9YJyOSrcdZuvMbpu XFu2D8G1LO/Y475weoeQtz9W3iHc/drBSXXXGLnZZqwMlZs0ADYftiHZJFH6kNymUwzgVpHc4HUT ydCpT4ZkL3Rc29FxcC+SfeAugJofkEyJIW3AXiGSTcRrkHwkZXG7qpnbCLjGMxbroYo1sG2v9ke9 AMGEt5YkdCLLQyJ/JziWtfUwxkPrqM+qWR56gbezmtVoWNGVOtw5jcu5VrBTfCLMxJO5iKfkDtTp aZmqlOqIVPtCTEcsE0ie0SfVuorTbNfWg36ereYyH6SfTeC8HdVtKL0/qt0QBhiREyUb+2EdwIHm 0MI7aNkB1itZ/MHt6HOgTb5gO6zbDML+sF5R1j78U/jBWns1yaGOsvb9L4R/A64HXH8hMDS5jO24 brMb++Naq2uUpSnn1QvsQV2v+yyDF7LVC9leY+fGq24Su/ABlNdcVzX3z+x6VsS5j/iTXA4eeR5i POVaGuWMWrsDnfwiM/dPk9n9VIB+kV9RDFPJImPnYHGItSSdSiH1Ui1M0hjLCvQ/uKTNjfNphN/6 mpQV21/4th1wJ9IKzAuDgAdrZRsAgpO5fpHC3yO1Tgl80LjYZXzVzcE+o3iNE2bE2/pcjxOvZ4Wu Z+mcTa94nZe8tx8hXtrQgo3Z5TXSxRn76bSTBn9GWRvHxMi69UMeJ+vOVnZsbnnretwmYhX2OoWO r6ACS9XdA82MI0YmO5fpIq3SG1F+rZ2NZKiuqJ0WtznTaTClX03BXZnwB5TZifsRebAHECEPrCBc j6QiB2lYGHOSse+GltbnsDpbSmlTjEwNTKWyejNeqnQ40ONq4t8Lp8fZLYe2ZoDYKldtELm/L8ED BDuW9iU4vIYoVHF8W+rilu1zbsD5GikC32uCAEMBHzyBKk10+b5jfbSL+KTV3tO4ijU7uEsTeEZD Z3C2qvu6UHuo8rM9NwDPqFF+YcTXADYov4Eb3PDVc0P5b/kCxE/TBrmlqqOGpHC4Jzs4CmzP1/bY 5pENJ6wbPHsInX1SumSQQZyyXBW6bTfIA1WdimB1OV1Xr79VqjoYKmuMqy4WH2GKLXCurBqWju24 geLAr5hiMLJ49KpzOisHZ1R4UOd2sjX63jOaSFiyLuGOt0SPx8WCKIiDZKeCBM/iHoI+6LhW+nYQ EeOuiRJepSOm2W/fviNGxeR1m6f5lcblf6gfBnD56tAaTJodRmHgr+GLhzYCVaQ6yOh5nNs6WT0Y vZWDY1h0rMfrO58F2v+a1tNEcYPG/a2e48Ho1URjG/SccAOXLnLZfk2eeJ0c9aaScVrQAWd2cfpx fA4GZ3LPeqjrz2f7HJMaaz1xfSDE4ODBWokjuamJtoNS+tpE2BeeFSNaa9cVc7qHRvdXSl5gcQNL 0BR1x60vxgedVLtidemtfGallDSc7G1UbIMFwx0xvFBmt7DYnzXS8c5xKK7hbdevSAjdyPbs2kp9 gQr1uCMB8uo3c6D97GyV4t+S+rcRVeG8DGR/Ko3og/GrZNLP0Dg2In77qUJ+H+dI7LqS31sZwulM l1jS33z5T512WQVwuQvOgWec9qN7q3crqQF2keBdMZ38/A5e0d5DwCmkmkKynSqi6nHNi19QxMEb LYg+T3Sda5kejv59fBz5/CQ8Pji23bMD9zQKDo7OfO/gDMbHPTkOj06c9/9BvW9pu5NECvWOmZ+a d+Xgy4330yzSRBZlMaveJMVijJNNYEiMl8WtkMsiVe+6sa36hTnqtJDtRjjWFAaaSYTxYmyKed2M lnZL/Q6bJJMf4uUvN2rp8WqeSkjoJHy1BOGGgiQ0bZvQ3PHum78BAAD//wMAUEsDBBQABgAIAAAA IQALaU40wwQAAMUOAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTcueG1svFfvTiM3EP9eqe8w2k8gXbJJ CP9WJKf8AYSUI+kFWvWj8TpZH17btZ1AWp1079B36IP1STr2ZoEEIjjgmg/Jxjsez/xm/JuZo4+3 uYA5M5Yr2Yrq1VoETFKVcjltRZcXJ5WDCKwjMiVCSdaKFsxGH9s//3SkEytSwN3SJqQVZc7pJI4t zVhObFVpJvHdRJmcOPxrpnFqyA1qzUXcqNX24pxwGS33m5fsV5MJp6yv6Cxn0hVKDBPEoeU249qW 2vRLtGnDLKoJu1dMaqNndCxS/2v1hWHMP8n5qdFjPTLh9fl8ZICniFcEkuQISxQvXyzFwl+JYvgQ r22flppIcjsxefuIJOgb3LYiBH/hv3ETSditA1os0vtVmg2fkKXZ8RPScXkAWnB3qPeq8OixO43S nQvuBIP6nVeFKMGtA0WvLUiFfnr3C/fo+bxU5n326nUGbqERGedVLeWKlwGPUt4ipgEsd9tV6cI7 foW/YZEkwrqxWwgWAEGzSYLK8QvhF8RnKJOVy3EEKTcuYAQ2dz3BCObyEkbXHmOUZxYwh+Hcgzp2 TNsjBMdhbJYamUxHxJDPGxV7R0mCJqD1pan4WGC5GdGdEtGekg7zDUaCUJYpkTIDjbfhy1PMjjIE G6D1aK0lWXN3Hy9gyLT6Xq3mnwO8Zb4dNBqHuB6Bz7rmfu2w3ggSD7PJR81HuUSiDJo/TuKd78yc mnAHE/R6TInAPNiv4ScCIceafmbpjPp724rw+MIAVF8E3ut4z7irCbiMgTbqC6NuJe5FRENY8cvH fi6WkL4q0wYN4LkWzBNUYBaYWaQ8QGiZ9AxrYWnNgMtrGJAFZkGfW6qQgRcwMsopqgRsDQb9Efz7 7W84Oz4+hoNao1rvdLdDClNl2INl8gdsjTNlMLOIy6BreDrFI7dBMnejzPVqor+3w32mhVqwFH4o rEMsJmDVzFAGWJoYkDnhglwhRXG5evSrwjbsDz7A8NfxqqqnsQp39tlTfA5nAmPcE5xeg0l8sTBn adiNipHAvIhr+7JpsW6u4Pes+hWWe/FZU+6y2VWVqjwmeD8rxDlCs5iQihCpTtdMeJYRV4y4o8f1 y/Q2vHZC4fh/8Hp01ma8bHq9htYrytJbs21T3JtPYYYp5luyub3hjmahH8PeiRHL7MMXlUa1Wa1V HTHV6Z9rLr5TQoSC9X0ZHsqTa99zIcQQGPIBr6ZswiUSERKCZ/t72V/ol+e5/xXh29BKPM0ar3f6 9875KaTEEciR+QRWVANaIassQjWwzMyxK0ZalBM+nZlQdVYC994GnVX6kDJLDb/ypU0h2mjRsnJZ xN9PC44XbTlsfbrsf8BK9s/2DzVqpKzlvh4MR+POb6fgKx9wx3LgofpjyeTeNsew7XcBuRsukKCn HjmHviAhmu+ole97GZ7Vdkevj7vP0ISWYwpeiIHFtlaH6WFmeCv6q9s93Gv0DrqVbr15Umn2D/cr nZO93crJ7k6z2esedHo7x18j3FNvJtSwELizcrLDxUfTVM6pUVZNXCglxVgWa3XDjFYIMU5m9dpy vJsT7Keatb3dOraR+2WvilaGPrq0Fl0oJy4qzCeih/NwIXGQxID1wpLGWHkUUPRexPuOk9p/AAAA //8DAFBLAwQUAAYACAAAACEAPb5d+SEIAACBGAAAFQAAAHBwdC9zbGlkZXMvc2xpZGU1LnhtbMxZ 7W4bNxb9X2DfgZgFFglgSbZiu7Y2dmErcWEgdYzKWWB/UhxKw4ZDTkmOZLUokHfon/YF+mB5kp7L mZE8klx/pAtsfljSDD/uPffcey6Z19/c5prNpPPKmpNkr7ubMGmETZWZniQfbi46RwnzgZuUa2vk SbKQPvnm9B9fvS4GXqcMs40f8JMkC6EY9HpeZDLnvmsLafBuYl3OA366aS91fI5Vc93r7+4e9nKu TFLPd4+ZbycTJeQbK8pcmlAt4qTmAZb7TBW+Wa14zGqFkx7LxNktk07hmRjplD59ceOkpG9m9q0r RsW1i6+vZteOqRR4JczwHLAkvfpFPSz+NBiGL7216dNmJT64nbj89DUfwDd2e5IA/AX9xSQ+kLeB ieqhWD0V2fstY0X2dsvoXrMBLFhuSl5VHm2602/cuVFBS7a39KoayjH1nRUfPTMWfpL7lXviatYs Rj7T8kXGwqIAMoGWqsdVLyMezXgPTCNY4fbcpgtyfIzP+JAPtA+jsNAyAgKz+QCL4w/g15wYKk3n wyhhqXIhYsR8HoZacnC5hjGcDm1OjPHsNQAJiEe9ijTpNXf8+3sXI+f4ANvC4sY8fK3wux/FVw2K Q2sCNmbXmguZWZ1Kx/pfhqlKwYgG9nvgJITWiLV/8DWSLrJr73B3l75HSBuOHfX7x3ieMGLawe7h MUbFmDUrRberyDZINIGi7Qzy/KwMdqICm8DrkeAasd/fxb+EaTMqxPcyLQXl6kmC7SsDgG4VbFrj b4n1Xpd9/vTbTSbXg/0AbyIa4fTsjAmY76zWiFXGPf00MtrNgmVjGzJGg7SiwKIs0q81Xj2w1TaK eulQg2H6H0yFz59+3+DqA2vW5hsbWOE4zAX+TBmWc7NggnvpuzB0GA3+cmvPzkaMu2dCXPqSa70g 61I1mUgXgUxzZZQPDvV4JllqSR1g84V1TN7yvNByJzqApwHTZcqsYZwN3+5EnwICTla1XtPD67dd 9qHacQej4+BrfMD6ZaBTNl7csaXafPXawY7LKigZdynRIJWFtgvs78sCYVuu5EB+t9oGmCMiGUbU PjDlYa9nC1syn9m5THcYWfnEkEgHwYxFgOrZpb152vyaLEuv2qyBe1qC2lpH01Ak4e4MyrvMBUKg AvyO592nOrGlUN8ACl9Op9JTnQBYT1yzdgzmZRws2rARnAHx6oxeeTGqckNww4oSbvM0VWRATKGq gyFzJs7mcc2Ch2wAut3xvvOvafg3CBg/nxaNbeUAqdpapFKhKEXPUsD+U6NTI3k5aSresK51o034 7sBAbOaB5dBfX8N/ZyLwHSPACyMyZ436CUlMBRTxmKhp6fATeUhBQ9XiU0mazQrIvHyq9dsgHdlc Mjt5JqNgVJ3klUVsUppKFMYyzKU0oMOGp60QPituwKQUMm0t1OICmieg5d7F1lGZFJDRV5LTcXmF hh2BpAmk3OgoH2p41oH7gr22C5aKLfNfdmvvuPhIgRKaOxWiThAnJg599ty6j6hGXjhVxBIR6Wak TEE3qDNFyTnItUwfyZk1g2reUyFq5TepFVmRKj6FIVS8S5x+qHJiUyenEAais4cmoP+IstBZyQIU nXHhrMf7rUq3w8ZlYFA/Eou4SmG1EosVz6KnvCjQeERfyRoD7hEilEU5X5ApUQBNUBwQtCV2zhcQ MvIMBqLZiD0CGZbywFluU6nZi8OX656mFvuRn4I7V6WnRyQwbFUZAT3oD99iOzTCNi3G3k+8NfT/ H+h3M7es9CASNU2DtiMb6aBneinEzyY8hWQNr0etVXO1zdNa3HwldUuhHrUrbVWcc9AJB3IWqUa0 gsjdpVUt+102jN0u4utiGWyqNfVo0NO6aGfWqZ/QO0fVDDJ2oVjw86dfsSikfK4grWBocKVEd+Et MS23PlCy07bPwYA9rxVa412N5PMs2NLHeCENipf1LZf+N+w5pxNJa5/7lGa707GXj3mLBK7Zs2qN GtWj01AjeVURqU5Ank2pVywRPxQdEW9TItW0pROIl6KMRZwqQ/PIVc3k3QKybK1WJZO9mFMrQQej 2HsS9/iMK83HdBZA8xy7aEyo6FjbnL/sslE8THmG1pxqFIv1qrGeaxIVlFiw7584LVL2KTpfULtR 2V/z8Y4tdXFN6YSiUKmpby9QzdUY/J8rRAC9Dcqqdbj+qk4x1lBtbXbFbp26U6AtkQ44KePP6ngT U+D8v+/frKrPWhndzp94n/D3VNj72oNN4rRM2V6s/lLjX3XZdQUfidh86fJavb2Pycu168QV2pYp +8/1FfNWl9QY1BwtfUDb53AmtjNFN5wQxRmuinACxTM1g0qiz6DJ1PyDxjh3Rl1EWB+VU0tL1qWL DmY/WHDsBQ+Bi0em6HK52rFgX0ZeyFswj0o1OCodLIdAwd1uy8ZWUO6L5XKHdYNbs5/WVm4nwBpr 1vcjgG7qls14hasx6tmu0MpRJnMP9a1USmS46IM4OfljqepDAm8uYGJXhGyqg0pnChzmSFy0tR+R dVjrsn81umCxUYpdHIb7AhdybfQenUIITQurB5FeTti8RYy3as0VM+7i3nlcTxbx5hd18yT5+fz8 +LA/PDrvnO/tX3T23xx/3Tm7ODzoXBy82t8fnh+dDV+9/SXBnL39gXAy1q/L5lYeDzduwnNFbaid hK6wea+6Uu8VuIlwBdhKt+p7u/XV/IyjuekfHxzuHR8eHDV3jrASAEQbo7X42tyWC+2+48X7WeQD /hMAVB3GRwWoSyhg6GoI+Y5b9j8BAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAA cHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzhI/BCsIwEETvgv8Q 9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62 IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFp zoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277 AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRk o+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLB RRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn 6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA 1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5y ZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvg NdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1I E+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoa pJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9z bGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCR pl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgG TxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylO VkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8D AFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQxMC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tj BcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZ w5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMi n39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+ AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc4SP wQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB 3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOv Ipo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33ku alneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDg RfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSw b5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtka xPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwME FAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0Ny54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBv dpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnF ZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6d pTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEA ACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc4SPwQrCMBBE 74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/h dj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTW VbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U2 6mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTb BtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj 5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/ dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgA AAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0My54 bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrF kxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZI vjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSw mHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAPpRe/SkBwAAIy8AACEAAABw cHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsWl1u40YSfl9g70Awj4Ei8Z8SRg5s2ZoM 4EyM2DlAi2xZjFskl2w5dhYLzB1yg9wi2bc9ypwkVdXdFGlLE3ktA7ZhwJDI7maxu76vfq13394s hXXNqzor8rHtfDOwLZ4nRZrll2P7p4tpL7atWrI8ZaLI+di+5bX97cE///GuHNUi/Z7VklcWyMjr ERvbCynLUb9fJwu+ZPU3RclzmJsX1ZJJuK0u+2nFfgHZS9F3B4Owv2RZbuvnq12eL+bzLOHHRbJa 8lwqIRUXTML+60VW1kZauYu0suI1iKGnO1s6gPMl5yLF79ml+vyRz60svQEtDQaOffCOjeicfCIq 65qJsT27dOz+wbs+PgKL9RU+XJcXFed4lV+/r8rz8qzCm+Tj9VkFMkGkbeVsCfpFATShl9FtDsuU 4M7jl0YSG93MqyXuCNRjwQ4BxVv8hIfYiN9IK1GDyXo0WfywYW2yONmwum9eAEdrXoqnUie6fxzX HOcik4JbZ4IlfFGIFLhCKqITqsdAi+VpkVzVVl7AmVEV6qigHCMYz4+vKheWvC1BSxLF6nVqEnaW N+tr0q/ZdKMVP4iAdKQaN/JDL+7qJ3bdYYjzqCXH8b0B3OBe1oLKqpbvebG08GJsVzyRRAR2fVpL tdQsIfTVRsqRvDkq0lsEYwbfgDlYHDy/KKpfbUt8yOuxPXR8H94t6YZ2altVe2bWmZFiUgDl4AmW JyBnbCeyor3kYG2HK1nMM70j9Up8uajlubwVnGgB4LERqBU+YEOCocHzvPfTORj8Uk4EZ+AQNIXk wURkyZUlC4unmbS03RMM4B5AJGpJkq5IJM/TM1axH9uS3x9pbcKbAS6jE7hURNpOJ6+hE3K5zSYX RT6WTaggW5s2bRG5hIx7IKkcYA8SjNRrrK7DKj9wg2HoaT0YozWUeUasQlo8iEhgcZa4JkbS8R9J LNQe8aruEAtIRrRVH+aV5DEewOVznhR5agl+zcUO4oljDxB/sciq3aUTGR4gfVqsKrnYefO+YuPO cEyz+UbpEEb2atK+MeljJrsBghTyWJNOJXixX8HDMjHXpk0wkkX/H6YdegH83TFt1/G8JmB4YeC4 wfO37E68IFM1UYEixLVw0JSZuATvL2wcS/kc/Tiq00H3hmN1IbJ0mglBN5jurdMgeaOyI5nlUiVG UbAOpU3ORMGiJQdsW72JJsCX4EbUtQ5b+C6y/LlIKWv6d3RyPDwaHsY9343cnh8fT3pHg/ikFw9j 92TiHU6DE/8/EFQpaUiBaTJb8ml2uar4DysVujvBD0LUpuDnDPuDCHJNJ1y7C9gD7me/VhEYq5gW BSbW7VBHlvxYu5hDkkBI/mvFKniDtg0VkR4S9jzH9U0ytdk44mHwqo3D5FvPzzz2y8nQcPIcTJ5b H1fL2R1mktd7LDOhmgTRm8hJxH+Q4w6DwPsyOV+751alwPOjZuO5j8P4yJsMo17gHIHnDsKwFzvg uf2J5x3G/vHhycm08dw1Mi8HdqDH3cVhf/70x1efP/25B29N1Ykq3uHStAQSUX3PSgsKfgiSEop3 iHljO72Cq9mli2NQAcsbuEqv4IolCXQZYIW+MCMwr0aaNZ4ZgZJHTflmBDImNRKYEYgWaiQ0I2Cr C5HlV5D44JdtzQvxnRowV5ihUO/mlN0WK/khhcr1zgjFVtfxIz/2Qn8IdegIexTVh1QX72Cr5unO WkiQ1mt1abZ1Leiqkatzvq1rQT/NWh0Ht64FzTVrtWfauhZ02qwN72mmezbQdrM2+pu1gEOzlroM HY135UattcO/kQvNuEauQ9noFwR3gDNdlZYqNPDyhnoCNZKACnq6RUvTOZhOBjHeWeBRLtjsHFJB 6lcg3lK1ITg7zY8qYB7giu24XN/CkgX0FqDnd7bKE2h66NZZmRxhiwzbP8lZohNFOhIkgjCmZ2er j9B3pDy15c2gVQJyr3iFPctdc1IQgqLbmSttlNLDOXSoxvbXy597QiIIkNmxOxOcqYmkvjOR1Dix LX/tahV6g9BtuKfiJatOx7bnu0M8WJaDuwNV9cyAScefWv+gStW/uIPBtIBUHrNopabDKmPCtspM JospW2YCGmYe2FKyYFXNYeO6UJqtJjBCw2P786fflf5aOKoo/RQ45ttwzHtbcMx7X8SRzMHF2khh FQFW6O8arNw4gDoHXLIunV42Vr/dw8qNn8rm9ogVAqRdl7fGyjRzW2C5MRUnrwOs+4blPpmD3CNY iJAGy2+BpbuorxWsDZaFTvdJotkewUKENFjBGix3EEREtbUbfEWW9b//3veCLwErBEhjFbawChyf nN6rxGpTeoHpzLM3LERIgxW1wBpGDgXcN7C+1GfeKaffoxdEhDRY8RoslaZ3ksFX5AVfrGUhQhqs YQusOA6pOfhmWc/JshAhKKI79XE5KuSCV021DJXjmYJU15DtXy00JbheYroXqlx7ksKsVckqZ/0i K1nzs5j910IvTT+bq0fT6XrTz5aCzYvwly9P0fl4aQTaXCQ5sRtTLvfGoC2VCWVLbwyCkLWlGoh8 1Sp9Y9CWDBwyOupDvCloS9YbBtGbk6YmfpNptpNLSDzX/wjDf/qaH7cf/AUAAP//AwBQSwMEFAAG AAgAAAAhAH6m3XQ8BAAAURAAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWzM WNuO2zYQfS/QfyDUZ0f3i4W1g/UtL5vdRbz5AK5E20KoS0natVMUyG+1n5MvyQwlWt7UbRetUfjF S1HD0Zk5M+Th3rzdl5zsmJBFXY0s941jEVZldV5U65H18WkxSCwiFa1yyuuKjawDk9bb8Y8/3DSp 5PkdPdRbRcBHJVM6sjZKNalty2zDSirf1A2r4N2qFiVV8CjWdi7oL+C75LbnOJFd0qKyuvXiNevr 1arI2KzOtiWrVOtEME4V4JebopHGW/Mab41gEtzo1S8hqUMD0apCcWYRbSZ2MOFaY4g8W/KcVLSE iSe0IEte5Ey/ks2TYAyNqt070SybR6FX3O8eBSly9NCttOzuRWemHyswg4H93fK18UTT/UqU4xua QiLIfmQBXwf8hUU0ZXtFsnYy62ezzcMZ22wzP2Ntmw8AguNHgeqmjejP4XgmnDYR7jGq1pTC0rs6 +yRJVUOcGH4bXna/M84wZnTfbEib9UwJ7a0zbd/rlJglUqfVYD0mI0rCxGkz4rm+E3jhy7zEcewF aIDZcYPYcVqL06hb102q9pM6P2BWn+GvZoWmXKqlOnCmsw05oSkghx/gllPsGFYNPi6hY0o15YxC R3XMqPGUF9knomrC8kKR91QqJojS1SPR5Q2AUMB855JV+SMV9MOp53cTnRGawpchHQYhDFt+/pol 37C03D633/TQFVSyoeFfESW3zy1RUNlQdobb1xPm+rEbdYz5SRLBnvCSsQjo0pRqxuLQQ2usIMO9 Dr6tH5OPs4whTXzHXSgcUlJxpzunqHLofj2kfA1sQeVBF4OD7T3sdprlnK2ABJyUNXT5ouBcP+AW x6ZckB3lsFHscWcABotKtTNx6Byh6v0QjTXwEz8QhvEPww4f+oGh10MNwhgzQ64PL4Ls8Po93qEb 6Da7PrwIssMb9HiPZXh9gBFlBzg8AZx4iW6L6wOMKDvAUQ/Y8xLo3KssYUTZAY5PAMeBf6U9hyg7 wEkPGNFeadMhyg7w8ARwFMZ677++GkaUeqs25z2iv8BxD+fl/3XiB+bEn1HFyCOnGdvUPAfN4V/i 5M8ViJzPILEpX8G5pE//9mBG5aqzh4OlTiTqEy2ges1y9ozuVdUK9DWK5V/j+Ww4Gd4mg8CLvUGQ zKaDiZPMB8kw8eZT/3YRzoPfrE435hCqKkq2KNZbwR62ykLeXogzkFDnxJk7tJ0YLhNu1MswwIDL LyvEQkPLoq5RAJ4SE1yCmBUoGM3Mz1sq4AuGnH/QZloM/q2A6sm5bEYikxF9hyL32/L5u7xoEf+f pSrPwfXZ1GgprK8Xl6vbWZRM/OkwHoTuBOo2jKJB4kLdBlPfv02C2e18vjjWrcTbYwXoXluuX7/8 /tPXL39coFa1fG5vrDDEe62+FXDxnjYPO71rw0Ue6gjEK0w1cHWHQkDT3gR9mH8FjL8BAAD//wMA UEsDBBQABgAIAAAAIQBpol8hHgEAAMcHAAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlk ZU1hc3RlcjEueG1sLnJlbHPE1d1qwyAUB/D7wd5Bzv1ikrbpBzW9GYPCrkb3ABJPPliionYsbz8p DBIojkLAm4CK5/z4K+Z4+hl68o3GdkoyyJIUCMpKiU42DD4vby87INZxKXivJDIY0cKpfH46fmDP nd9k205b4qtIy6B1Th8otVWLA7eJ0ij9Sq3MwJ0fmoZqXn3xBmmepgU10xpQzmqSs2BgzsL3v4za d/6/tqrrrsJXVV0HlO5OC2r7TuA7H9XV+bLcNOgYJMl03k4Hu8Tzgd6XrWLKViHZNqZsG5Jl+ZI0 568Zzg7yNkNv3yzkWJTx6K3KQ7JsyYAelQUzK2LKimBmcUMLpraJmdommJp/6+M9rVkasq1j0tYh 2T6mbP8no7Pfb/kLAAD//wMAUEsDBBQABgAIAAAAIQAFb6JO3wIAAAUIAAAhAAAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDYueG1srFXRbtowFH2ftH+wvOc0BAKECKggQF/agkb7AW5iSFTH zmzDYNOk/tb2Of2SXTtJ27VMqra8gGPfe3zPucf28PyQM7SnUmWCj7B31sKI8lgkGd+O8O3Nwgkw UprwhDDB6QgfqcLn448fhkWoWHJJjmKnEWBwFZIRTrUuQtdVcUpzos5EQTmsbYTMiYZPuXUTSb4C ds7cdqvVc3OScVzly/fki80mi+lMxLuccl2CSMqIhvpVmhWqRiveg1ZIqgDGZv9Zkj4WwFZnmtEl Z0eMbKjcw6SHx8A+XrMEcZLDxI2JQjbMrKjiRlJqRnx/IYt1sZI24Xq/kihLDECViN1qoQqznxzC YOC+St/WSCQ8bGQ+HpIQtECHEYaWHc0vJJGQHjSKy8n4eTZOlydi43R+ItqtN4AKnjY1rEpGb+m0 azqlDt4TqzKUQOqliO8V4gJ4Gvolvfh6X4MZzga+SNEL4au4ctHqUccr0NSKpQ9TkRwN8Tv4t5Mk ZEqv9ZFRKwiUTUIAhx+QnxHja8qd2zX4OtcRowR8X4mnxxHL4nukBaJJptEVUZpKZF0ApwAgh6CO huZUkJQnKyLJ55fIF1NbNwlhZyi6rhCGpYR/F7JTCzkjmqIVIzFNBUuggraBBM/Viv2TpokGyt/g WBC2wWBEcIlniVtpTQP+S+MNnAfj7u/9+WwwHUwCx2/3244fzCJn2grmTjAI2vOoM1l05/4PXDU6 Aao6y+ki2+4kXe40ftMqEPRUq7yB2+rDBeD1npsCNZj0Ztvi121ZCGHs8LIxnSYas9Gy7MyXHZGw Q92c+qA0cACaVaRbK7JmWULR9S6/e6WL34Qu8MAA9Elp7IFo2LezXjDtRIO+0/Wm4Ntur+cEHvjW jzqdSeDPJvP54sm3yjDnUN177fr48PPT48OvBrxqb5LyiYGheYfs3cDkFSmWe3vVweMLPorsVAHP bXXhPocYjPr5Hv8GAAD//wMAUEsDBBQABgAIAAAAIQCC6ChQcgUAAIMbAAAhAAAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDUueG1s7FnZbttWEH0v0H8g2GdF4k4JlgNry4tjG5XyAVfklcWG W8kr2UpRIL/Vfk6+pDNDXpHaElr2Q4Dqxaaow8NZj4bDq/fPUaiseZYHSdxXtXcdVeGxl/hB/NhX P80mLVdVcsFin4VJzPvqhufq++tff7lKe3no37JNshIKcMR5j/XVpRBpr93OvSWPWP4uSXkM3y2S LGICPmaPbT9jT8AdhW2907HbEQtitbw+a3J9slgEHh8l3irisShIMh4yAfbnyyDNJVvahC3NeA40 dPWuSWKTgrfiKZk9z56S+/kfqkLgbA2nNfUa/Pemoa/ELIITwyRKWRbkSUzf5Oks4xwx8fpDlk7T h4wuuFs/ZErgI0F5odouvyhh9DEGGBy09y5/lEys97zIousr1oNoKM99FZK2wb9wEevxZ6F4xUmv Oust749gveX4CLotbwAWbG8K+U4Ljw7d0aU7s0CEXNG2XhVQBpfeJt7nXIkT8BPdL9zz7taSDH1G +nSplKFHqhJXfEnxkPgcYkrBEs+DxN+g43P4TydZL8zFVGxCSAEcr0ONEsB6Pl/8XoS2dhq8rcPB SdYDU+APJCtk2Ac8bn2aQh9EYhhyBn1ShlpcD8PA+6yIROF+IJSPLBc8UwRFIUcDroBdQCpLSh77 DyxjYETF/GFAXrIe3BlclP7AYRHw02E3tmHHnD+EzOPLJPTBAh0poUJlfM/KAMZThXKFWpIJO5EI jNZeSZqWAw1OdalZhqVpBppUVafZMTuaC+KCNWobXccmm+ulhylGL2REZIYVFnvLBNRiXlDWs1cm W4lYdkt9EcQ+NDge4t3nqztQMTKkqAUl/9JXdRMtnUs3a7VBhzrYURJKrxqxdg5ZkQrtADONirWr mWRBE1bNPWRFqpLVrFg1w9FsBDeiJeRuCJCrpLVqtK7ukg3n0iJXSWtXtLruggmvsBa5SlqnRuuY BtXhudYiV0nrVrTI2TxlR2KLXCVtt0ZrW86rUoZcpDb1niBFw5tA1W2li+5+vsKh4JDA5TsKB+37 YhUzpYoNk1hAr+4IGanG+UKG3b1k4aKUsUJi8GeVwoQHU4oYam2RkNMypmuO6TrWd2TM6FoaNAci mugYyVA9UQe/VJU6FZQ1ABxKMakrGbbQFisBgJUSUcOSkmyxEgBY2fd1LFblFisBgJXNfBIrAYCV HXoSKwGAlW13EisBgJW9dBIrAYAtGkROAhRfEsmtbz9HB1EbwR/ZtPT7+4KxZMq9JPaVkK95eKRB 9+mpL15AP1sGWXP28pe/seJMklUmlo2NN4uObE4fLI6yw2zyptOZJXVttj+dkcXni1oxHxfTGQrc nyuWwdhZahxFm0blxhpnm1ZHB3NhEjs1q2kOKN9lVuurl1kN5uXLrNZXjf/jrGZLTTs2q9FodL6s HUoZ6eTZUnZqXquk7DKvYcx355/LvHZip/PdJ579geoyr+EKrXga3I/NzzqvOVLbRkzwnYdQGyfM 84WtmNd8AQvE3cdRrXimOvk8Snfd337ByWphSR/o+X4Bu2jcLP/ljEfdQffGbZm6o7dMdzRsDTru uOV2XX08NG4m1tj8Wy2XrD64KoKIT4LHVcbvV0JF9p21AKwnjy0+tW6748D6XbOr5wuwAS9/2zEa VoTFjn2SJLhcra85nbdIzELA6Hz446P9YOf5kuS8bUS6MiLTMPC5creK5ntxoRXEawsWXu8A9dHQ /GCP8pLQbOt2ZLsDY9h1WpY2gLq1bLvlalC35tAwblxzdDMeT7Z1m6PnMVjXtFy/ff3nt29f/32D WqW9fPF6Bw7xHRBpQ5h9ZOn9mp5C4dUXVOqQTqXwsgvigdAKghzy5dn1fwAAAP//AwBQSwMEFAAG AAgAAAAhAJf+4h0SBAAAtBEAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWzs WN1ymzgUvt+ZvoOGvXYNGDBmYnfiv960SWbtPoACItAKxEqyY7ezM32t3cfpk+yRQI7jkrW99WVu Eiw+fdL5zo8Ounq3KShaEy5yVg4t561tIVLGLMnLh6H1aTnvhBYSEpcJpqwkQ2tLhPVu9Oa3qyoS NPmAt2wlEXCUIsJDK5OyirpdEWekwOItq0gJ71LGCyzhJ3/oJhw/AndBu65tB90C56XVzOenzGdp msdkyuJVQUpZk3BCsYT9iyyvhGGrTmGrOBFAo2c/35LcVmCtfGS3958tpHF8DSOONQLT4wVNUIkL GFg+MjRhpQQa/UpUS06IApXr97xaVHdcz7hZ33GUJ4qhmWl1mxcNTP8sAQYP3YPpD4YJR5uUF6Mr HIESaDO0wGFb9Rcm4YhsJIrrwfhpNM5uW7BxNmtBd80CsIPdouDrqrboZ3NcY84yl5QgZ2dVDcUw 9QOLvwhUMrBTmV+bF9+sDZmyWdFXGWpkV1QNrn6p9TB4AZpqseRmzJKtMvwe/utBHFEhF3JLiRYE to0jIIc/ID/FKqpJ2fm0gKgu5IQSDFHfiCdHE5rHX5BkiCS5RB+xkIQjqe0SivIK1JHgnIaSlMkd 5viPfeb3Y71vHMHKsGmzQ3isJXxZyJ4RsokmdEdxTDJGE9iEq1gh7oxoZ8oqvkI2YJpaEIEQHsYH L2ir5DqIMs/vQ77qUHMC21bPWl8TcJ7dC2HcQirsPN/1B0GvEaJm0gLUbjaatHpNrU3X1NFpg6OE pEpetX83rBcF9fcA8Oi2YL19rAEAtteCtfexBgBY72es82wPBgBY/xjWAAAbHMMaAGD7x7AGANjw GNYAADs4hq0BSusmnZRjdDbBTAQMu7T5xexSEaSTSzzLLli5Xk2va5bUgXtGQi9IzMoEUbIm9AR6 nWVn0C+znJ/OrhPiDPY5W3GZnbx5r87Ik90xz9NWdjhFLlrXvP+qa1qTi9U17T99VKhKox/2z4y2 uhZ44WthgxPhtbBFr4Vt1wi9FrYTGjbfFLYpluRZt6ZL8f+vanUTnEjoUQ/6Nu2glwvcOU1xCl8w 6nPkW382HYwH12HHc/tuxwunk87YDmedcBC6s0nveu7PvL+spjNPwFSZF2SeP6w4uV2pbx440g46 4Lbe2hl07T58rznB00EMe1DTL3veBMYtc8ZU/77fRvu/1kbXjkklrz3z5wpzWME01Ue66nOcc1lF +kaRBc0Tgm5Wxf2BLsEldIH7AKBulebIwXyONLu4nQbhuDcZ9Du+M4a49YOgEzoQt96k17sOven1 bDbfxa1Qlpewu1PD9cf3v3//8f2fC8SqriT1nQA8qpsD/SVH+Udc3a51uwZ3JRBHEz1Uwe0I6KGg TxDFYW5bRv8CAAD//wMAUEsDBBQABgAIAAAAIQDCro6VigQAAKUQAAAhAAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDMueG1szFjbbuM2EH0v0H8g1GevLVmWZCPOIr5tH7JJUGc/gJHoWFjq Uop27RYF9rfaz9kv6RlS8iVNUW/WCPJiS9RweObMGXKki/ebTLK1UFVa5EPHfddxmMjjIknzx6Hz 6X7WihxWaZ4nXBa5GDpbUTnvL3/84aIcVDK55ttipRl85NWAD52l1uWg3a7ipch49a4oRY5ni0Jl XONWPbYTxX+D70y2vU4naGc8zZ16vjplfrFYpLGYFPEqE7m2TpSQXAN/tUzLqvFWnuKtVKKCGzP7 GJLeloi2EvHPgicOM4ZqjSHXuUTs8VwmLOcZBuYipsUZGQplnlblvRKC7PL1B1XOyztlJt2s7xRL E3JST3ba9YPazNzmMMNF+8n0x8YTH2wWKru84AOwwTZDB0nb0i8m8YHYaBbbwXg/Gi9vn7GNl9Nn rNvNAkCwWxT5Lm1E/w7Ha8K5T7UUzN1FZU05pl4X8eeK5QXipPBtePHNunFGMZP7csks9Zpc1Xb2 oeGjsa8Mpw3QHROh53XdrqHD9ztBv/OElDAMPR+DjKhxu4HXCXtmkcYTFrGuy4HejIpkS5Q+4B+Z 43m8LKBSTTP4QFZ6rrcSecb1WrpAxLh8RBlJqIAPErH4BUPV70MHS2LNB5P4mIMBLmW9bD0T6T72 CLL5AJTgB04kp3oUeevTHPWY6bEUHAvV0enLsUzjz0wXTCSpZh95pYVihkJULzCSd23WMC5Fntxx xQnezvOHUY0IK4OFJnpDCGXmv9MPvm0p3JP27iSPxbKQKAbmkUtUS5PnFymB2HdQNtB0I5wXCcLr d4IQ4jiqkmNB9DodNwprHmyRnSKIB+vzOUFkXF2bAk3zBDsNXVJOH1Y32E4NkgOZYEu0j6tCpsks lZJszW4qxlKxNZdQ34a2IKQzzbUdCQHbKAFJ3hmbZB/4wTO7klWa1Sv5gQA9kq5F6vdCoADdJ8B1 o1eESxhruN093L6LMj8VbvCKcAljDdffw3W7oUsoTqOXIiMfB1k8SPB51UAga7y9A7yRF1GS3x5e AlnjDfZ4PS8CvW8RL4Gs8YYHeEO/e3q5vaYeCGSNN9rjJbCn19tr4iWQNd7+Ad6gF77NeiOQdic+ 6CLMmU/osSfvDncT1st7ADqSTQtQHfUAOA6++Zz3m3N+wrU4OufNofq953yi0dqgWVpyuWjOe3us USNs6KKLuWHOtmmmu2g6laZPM6dqcxabG8PrAh079d5/hNNJf9S/ilq+F3otP5qMW6NONG1F/cib jrtXs97U/9Op29AEoeo0E7P0caXE7Uo7pLKjdKBxeq4lc/vtTogXFDfYEw8MNP287VevScusKKjt O2zA/HM0YAutbGZ+XXGFFZrk/E839i3JOS8jQcPIHG2UYDer7OEJL6bp/17B4gUYrp+lxjS+aB3P qdtJEI26437Y6rkj6LYXBK3IhW79cbd7FfmTq+l0ttNtRZHnQHeqXL9++eunr1/+PoNWTcdsX4Bx SW/K5h1Aqo+8vF2b7QwfB6AjtLQYKvE5AFIh070J+Wg+L1z+AwAA//8DAFBLAwQUAAYACAAAACEA W0i2f0wDAADiCgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbKxWW47aMBT9 r9Q9WOl3JrwJETCCAPMzD1SYBXgSh6Tj2KltUmhVabbVLmdW0msnYR6lEhR+8nCuj+899+TY/ctN SlFOhEw4G1j1i5qFCAt4mLDVwLpfzmzXQlJhFmLKGRlYWyKty+HHD/3MkzS8xlu+VggwmPTwwIqV yjzHkUFMUiwveEYYfIu4SLGCV7FyQoG/AXZKnUat1nFSnDCrnC8Omc+jKAnIhAfrlDBVgAhCsYL8 ZZxkskLLDkHLBJEAY2a/TUltM6iWP3yxkAkSObzWrSHUHSxoiBhOYWCZKEoQsIN8zhQgmQCZLQUh OpTlVyJbZHNh5t3mc4GSUOOU8y2n/FCGmVcGYfDgvJu+qpCwt4lEOuxjD8hAm4EFPdvqK0zCHtko FBSDwctoEN/tiQ3i6Z5op1oAMtgtCu3Oior+LqdRlVPQUd9VVYRimHrNg0eJGIc6dflFecFtXoHp mjV8FqOCeaWZLeOKj4aPKl4Cp4YstRnzcKsLf4C7GcQelWqhtpQYQiBt7AE4XIB+irWwCbPvFyDs VPmUYBB+SZ4a+jQJHpHiiISJQjdYKiKQSQZ+A4DsAzsKmlNCEhbOscCfXyNfjU3e2IOVIekqQ3gs KPw3kc2KyFJNaE5xQGJOQ0iioVFBfRVpR9KahCCKivkzMAoNQDSnO+pOZFjL1hAs3zAMPJv+FZdq SVPGEU1dkIDDP0pJTugB8IbpI+CXcSIOR2/qPh6BPuNroeKDk28dC59Ee9HBSc6q7Val7QlW5I2w DSH/L+zCL0IFv/N38HxMIwtMVovd/NTGNrS5nOQfEVi+du4f3emkN+6NXLvV6Dbsljvx7XHNndpu z21M/eZo1p62flqliYVQqkpSMktWa0Hu1np7gM6/M4t9NlTvObUu7G71zoteIQc9/bxtaVdtmXGu re614xgpndqYSImiM1/XWMAKVXPOaEXnZaRTMbKgSUjQ7Tp9eMdL+zQnLgQLpyeA3kuN8Z8z63bS ccdNv9e12/Ux6Lbd6dhuHXTb8pvNkduajKbT2U63UlfOILtD5fr89OvT89PvM2jV7JLF8Qke9VHL bHpU3ODsLjebDJwsQUe+GcrgLAl2qkNfQjRGdTYd/gEAAP//AwBQSwMEFAAGAAgAAAAhAGMv2mL0 BAAADhIAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWzMWEly20YU3acqd+hC 1jTZmIkS5RInb2RJFdIHaAJNEXFjCNCkyaRS5Wslx/FJ8n8DzclwCEpaZENB4OuHP77/iZv320SQ DS/KOEsHBn3XMwhPwyyK0+eB8Wk+7fgGKSVLIyaylA+MHS+N97c//3STB6WI7tkuW0sCHGkZsIGx kjIPut0yXPGEle+ynKfw3TIrEibh3+K5GxXsC3Anomv2em43YXFq1OeLNuez5TIO+TgL1wlPZUVS cMEk2F+u4rzUbHkbtrzgJdCo06cmyV0O3maL3+ZbgyhYsYEb1LgFz8OZiEjKErgxylIJDORLLFdk xHK0Q2HKfF5wjuh086HIZ/lToY4+bJ4KEkdIVVMY3fqLGqb+TQEGF92z48+aiQXbZZHc3rAAIkK2 AwMSt8NPOMQCvpUkrG6Gh7vh6rEBG64mDeiufgBYsH8o5DyvPPreHVO7M4+l4ITuvaqgDI7eZ+Hn kqQZ+InuV+6FDxtNhj4jfb4iVfglUtW46ksVD40vVUy1oftI2I4HtaXCYXpWzzmLidXr+Ra1DIKR odQ1a8SxxxVzHsjtMIt2GNEF/IXEsTRcZVCoiyrOopQzuROQZhaIjaBgEGHiGTpJQBGwIOLLX+FW +cfAAJPApoV2fI+HHMP1EQ9EmAUQB/iAo4JhI/K082kGjZjIkeAM6Guf5O1IxOFnIjPCo1iSj6yU vCAqbtC2YBmyS/UMRcnT6IkVDI3aM38YqhCzAJ4M8dU+w2WV7R/nHIJ42gVPgoV8lYkIjDCRFXpF 5/fKCogjqF9dJO2TbzmegwnFZmjKvkMpBUSVfcd3LAqlgJWoy0i5XdWhjoTOvmqt41TVKT/LtIXV V1EeAeDSrOv1uCr8Y6wGANZqwNrHWA0ArN2AxWrb26ABgHUuYTUAsO4lrAYA1ruE1QDA+pewGgDY /iVsBWjqIThJgGHfLK/sKdRU1VLlSU/Bk1XHVh/6kapwr2jjGQ+zNCKCb7hoQa966wr6+Sou2rOr hriCfZqtC5h+bY23sTCvoY+Xjeww5t5UzWytZnNM9bGUqYC8XMqqYYYTBCQcRsGKiaUBOwAInEqk GmooOepipioexRdvaVlqmm7Uthxa9flh5J+MN9vt0577aoEjCSvu1YoRpxFsO3iJpi3WD7AUqmwe aRo90SmciYiFTkR5q6n0jG7Fd6KnZxpZ8/WpjU8lrfhOtPFMR2s+annUbUvY/w+t1Xy+6aPUtzLw hO9Mj2s+0/TBvJfwnWm25vNsNbaut+9M12s+JGudkBN/z7Rf87mO97J8/D/mA3S23ibUgoGb0Y/3 Kkcr0ZhJfqJESjtfq0SR/E6HaLUt4K+NRiGCHj940LgPKRVQQ3AJP47wB86f3mTcH/bv/I5tembH 9sejzrDnTzp+3zcnI+tu6kzsv4x614/AVRknfBo/rwv+uJZKYU5WYFhUm1Zg2u/2PPglSN3D5AQb UHTedkC4Oi3TLMM1+3hEODjUXpuYpSyqzPy+ZgU8oR4S9MIafE1y3jYino7ITMQRJw/rZHEWF/ct 4gJvGoC6MTQXBug1odnX7dj1h9ao73UcOoS6dVy341OoW3tkWXe+Pb6bTKb7ui3R8xSsw3prU67f vv79y7ev/7xBrSolqd4ywCW+lFAlKIqPLH/cqKkLb2GgjkbqVg7vXSAeCD1AkEO/x7n9FwAA//8D AFBLAwQUAAYACAAAACEApwGSrqQCAACzBgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQ3LnhtbKxV727aMBD/PmnvYHmfsxCgECKgIhD6pWvR6B7gmjgkqmNntmGwaVJfa3ucPsnODmm3 rpMqjS/gXO7O9/tjZ3y+rzjZMaVLKSY0eN+hhIlUZqXYTOinm6UXUqINiAy4FGxCD0zT8+nbN+M6 0jy7hIPcGoI9hI5gQgtj6sj3dVqwCvR7WTOB73KpKjD4qDZ+puAL9q643+10Bn4FpaDHevWaepnn ZcoWMt1WTJimiWIcDM6vi7LWbbf6Nd1qxTS2cdV/jmQONaK95SDuKHFpaoeBgE4RebrmGRFQYSB2 GTao6xvFmF2J3YWq1/VKudyr3UqRMrO1xxrqH18c09yjwDRc+M/KN20niPa5qqZjiJACsp9QVOpg f7EIIrY3JG2C6VM0La5fyE2L5IVsv90AJ3jc1KJqEP0Np9vCWYBhZMUhZYXkGVMkeATYVAF2uZTp nSZCImTLRIM0vdq1fS18u1NdkIb6zKDxvqKIwHOK/CG4wIF1DNlkt2jrNdLteDT7WGYHy8kt/rsg RFybtTlw5rhCRBDlqKAV5dswWYzi0Sz0+t1h1+uHi7kXd8LEC0dhN5n3ZsuzpP+dtkMhVFNWbFlu topdbw3aASKFAqMN8MAw4V3EOHdl5pwBHqijPGYajPzOEO0aDMbItMHp3QxOO5GtQMHHZ10sRRDh sIizBYXLRpB/y9JrZVlKaVCM34XpnkKY3KhGmc9bULhDK04raqPkf4nDTspIv2VkzcuMkattdfuM l94peMHrEFu/SI3j3TFyOt8uBmHcm4+G3lkQo2/PBgMvDNC3/XmvNwv7i1mSLB99qy1ygdO91q4P 9z/ePdz/PIFXnWWbmxGX9uZ0lx9XH6C+3uExhgg/FeijuQvV+HE4Xg5PKbZH+7GZ/gIAAP//AwBQ SwMEFAAGAAgAAAAhAHFWtUJmAwAAGQsAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 MTAueG1srFbJbtswEL0X6D8Q6tmRd8tC7CDecsmG2umdkehICCWqJO3aLQrkt9rPyZf0kTKz1QGc xBdZpmYeZ968GfLwaJVxsmRSpSLvebWDqkdYHok4zW963tVsUgk8ojTNY8pFznreminvqP/502ER Kh6f0rVYaAKMXIW05yVaF6HvqyhhGVUHomA5vs2FzKjGX3njx5L+AHbG/Xq12vYzmubexl/u4i/m 8zRiIxEtMpbrEkQyTjXiV0laKIdW7IJWSKYAY72fh6TXBbIFMXq28oi1k0us1Lw+Uo+mPCY5zbAw SzVnBASRbzBOI8rJjK20NVPFTDJmHPLliSymxaW03ufLS0nS2KBtUDx/82FjZv/mMMOL/8L9xiHR cDWXWf+QhmCFrHoeirc2TzjREEGQqFyMHlej5GKLbZSMt1j7bgNE8LAp6l6UGf2fTt2lU5JSe8iq NKVwPRXRrSK5QJ4m/TK96HzpwEzOBr5ISFkCbfjd2JUfLR/OXoFTS5ZeDUS8Nolf49cu0pArPdVr ziwhCJuGAMcD9HNqFM7yytUUCs/0kDOKDtiQp/tDnka3RAvC4lSTM6o0k8QGg34A5CHY0SjOBpLl 8SWV9OtT5JOBjZuG2BlBuwjxWlL4OpENR+QzTZFLTiOWCB4jlLrBhhIdde8i11DlESFTNEGpdg+6 hGhcZd7CuBkjQGHUBG2i28Y/ykX4kj8Q/cF6GJHbcqhn9UBVbLXLh9vSJvUGCUxZJNDXnC0Z3wHe VuQN8LMklbujN0pGd+ZrIhZSJzsH33wrfDrfio65s9dOaLpOGFHNnjWAJeSjDRBrNP9PHBWUz530 7QiwQ8aMog9NmzmOCTPnf3XGo+6gexxUmvVOvdIMRsPKoBqMK0E3qI+HjeNJa9z87W1GXoxUdZqx SXqzkOxiYQ6TF0MLo2Xb0Kp1/WoHh2Kt/ahXxGDc91uWlivLRAgzGJ9OJiuljxZmrmVZme8LKrGD K857BtMro2i/jLQdI1OexoycL7LrF7y09jGxcekC9FZq7PzZs25H7WDQGHY7lVZtAN222u1KUINu m8NG4zhojo7H48mDbpXJPEd0u8r1/u7Pl/u7v3vQqj1Ty8sWXs31zB6OXJ7R4mJphyYupNDR0C4V uIJCFcb00cRguCtt/x8AAAD//wMAUEsDBBQABgAIAAAAIQCAeiIxpwQAAH0RAAAhAAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1srFhbctpIFP2fqtlDl+abgB4gQRmnzMP5cWzX2FlA W2qMKnqN1BCYqanKtmaWk5XMua1uQA6eYKIfW4jbp+/j3NO3uXi/SRO2FmUV59nYst/1LCayMI/i 7HlsfXq87gQWqyTPIp7kmRhbW1FZ7y9//eWiGFVJdMO3+UoyYGTViI+tpZTFqNutwqVIefUuL0SG 7xZ5mXKJj+VzNyr5F2CnSdfp9QbdlMeZpdeXp6zPF4s4FLM8XKUikzVIKRIu4X+1jIvKoBWnoBWl qACjVjddktsC0RZx+LixmDIr13hhW5eIPHxIIpbxFC/u41CuSsG+xHLJprwgP5RNVTyWQpB1tv5Q Fg/FfamW3q7vSxZHBKUhrK7+QpupjxnM8NB9sfzZIPHRZlGmlxd8hIywzdhC4bb0F4v4SGwkC+uX 4f5tuLw7Yhsu50esu2YDeLDbFDUv6oi+D8cx4TzGMhHM3kVVm3IsvcnDzxXLcsRJ4dfhhbdrA0Yx E3yxZHX6JUFpu/pLlQ9jX6mcGkd3mbD9oeME4C0i9wKwrPciK30vGHh4ySg3/cHAdwO1iUHCJjV0 MZKbSR5tKaVP+I/K8Sxc5mDqE63go6SSD3KboM54Xic2PGI8eUYrJWABH0Vi8TteVX+OLfAdWz6Z yHf2KHITBynmIyQCf7A04dSJIut8ekAnpnKaCA54HZK8nCZx+JnJnIkoluwjr6QomUoc+haeEbpU eyhIkUX3vOTk1A75w0SHj50Ru4lZpYHq8XrRXVN00wb3CQ/FMk8iOOEQKprFFPgsCqADLbQLuGwI cx4RBrbj+/26aKY7GjzwbJvIojNRN9f/EOHV6qe8vFHdGGcRpIUeqZRPq1vop1p1wAkXpNA7avaQ LR4dIlIN5fV9smKn4Dn7CDSIxnP3eEPbU+Q/CY8s4TQxdJ0QiMbz9ni269vUYqc5SE2wAyQUDdg/ AAzQvecBEooGHOwBoQZw8CwPCUUD+geAvqcqd0bIhKIBgz0goZ1elEYOCUUDDg8AB33/zKIQynFN alc7PKMdj9SPh8LhEkN+VjhIryGYEN4lTxZaQ5QkoavP05C+i6OiPiv2R2xDRIIejpZ6kxMOE6UG x06QN2mI3ehROoE0Hc7UELuhSQSi8c7UELtB1xY0ZNiyhDTwWlCQBl4LAtLAa0E/GngtyEcD73X1 IHHCIbIbXRStzp9wSDTUgFM1JhycVG+eYvpGiWZcioYSeW0oUSS/0yG7PgRfFSKlf2YOM7NnQy7U BzUpLnAXofvEX/58NpwMr4KO5/hOxwtm086kF8w7wTBw5lP36ro/9/629GgdIVQZp+I6fsb15W4l LeryRjkwFh4bOO1ht+fj4mUP9omHD7S83QNiYMpynec01B4eEWqS+9kjYiHLujJ/rHiJHcyg+YNJ 8y3FaTcjvsnIQxJHgt2u0qcXeRm0QVhc7AF9NDU/OEDfkpodb2eDYOJOh36nb0/AW1zIOoEN3npT 170KvNnVfH69421FkWfw7lS6fvv6z2/fvv7bAlfVbaC+1OORfgNQU0pSfuTF3VrJGX70AI+m6lWB nzmQDzLdmxCG+dnk8j8AAAD//wMAUEsDBBQABgAIAAAAIQCRK7wTsAMAAPkLAAAiAAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbLRW247aMBB9r9R/sNJnGhKSEBBQcd2Xvamwffcm ZhPVsVPbUGhVqb/Vfk6/pGMnZndZqrJd+hJCPHM8c87M2L13m4KiNREy56zveG+bDiIs4WnO7vrO zWLWiB0kFWYpppyRvrMl0nk3eP2qV3YlTc/xlq8UAgwmu7jvZEqVXdeVSUYKLN/ykjBYW3JRYAV/ xZ2bCvwZsAvq+s1m5BY4Z07tL47x58tlnpAJT1YFYaoCEYRiBfHLLC+lRSuPQSsFkQBjvB+HpLYl ZAvEqEWuKBmydLFxkLEXa1jxnAFQkMxpihgu4MMHMM0TTJGxR8AYWpCNMmayXAhCtANbn4lyXl4L 4325vhYoTzVajeK49UJtZv4yMIMXd8/9ziLh7mYpikEPd4EdtOk7IOJWP8EJdyEIlFQfk/uvSXZ1 wDbJpgesXbsBRLDbFPQvq4yepuPbdPZI8XbpVT4YMM558lEixiFhzUOVZ3K5tqg6eb1PmaFKE6X1 cBAXOShXSVR7VaaGJustDdU2/h1BUeR3gmZFk98Oolb8mCu/GbbNumYsjEMv9EOziUWCTSrosqs2 I55uNdO38AuC6qLpOwTr5CtYKtVcbSkxegBruAspwQOMKdaNRljjZg6NVqgxJRgasdZODcY0Tz4i xRFJc4UusFREIEMBtCVA9kAcBbVRQxKWXmOB3z9EPhvVocPOELeN16Sgmf2zjq2nOupquqY4IRmn KYTia2xoBCvYP0mqidtTFNoCatbWw/HKBmEbBoup/0PCRk2vE+v1/yUs1Buia7pT8IVCa7qNzvKR 0CC3KaPqYbc0bD2jtuYk4TCmKFkTegS8kfoZ8IssF8ejt6pWOZqvGV8JlR0dfPBc+Hx5EB3m6Ulb LLAtNsGKPOosQ8hLOytVMFW+wFGI6dKpe8rMFjMl9WQ1Lw/HpelnOyTsUDOT6+kYW8Lxp8+vr+3p pDPqDONG4Lf9RhBPxo1RM5424k7sT8et4SycBt+ceoKnkKrKCzLL71aCXK30Ibk3DWFmHZqGXsdt tuHQ96L7eoUYtPtpZQmtLDPO9cR9OPJMKb1UmKUSlTKfVljADlacv0y854hzWkYiy8ic5ilBl6vi do8Xc0K+lBe4VAL0QWrM/Dlx3U6ieNQad9qN0BtB3YZR1Ig9qNtg3GoN42AynE5nu7qVOnMG0R1b rr++/3jz6/vPE9SqOayrSyS86munOXWpuMDl1doMTbhwQx2NzacSrthQKtr03kRj2Cv74DcAAAD/ /wMAUEsDBBQABgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsWU9v 2zYUvw/YdyB0b2MndhoHdYrYsZutTRvEboceaYmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3Sf JluHrQP6FfZISrIYy0jSBtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tfrXmIJD4PaBK2vXvD/pUN D0mFkwAznpC2NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK9GEYy6s8JQnMjbmIsYJXEa4EAh8B 3ZitrNZq6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hMDDRp4qww2GBS1wg5k10m0CFmbQ/4 BPxoSB4pDzEsFUy0vZr5eStb11fwZraIqSVrS+v65petyxYEk1XDU4Sjgmm932hd2ynoGwBTi7he r9ft1Qt6BoB9HzS1spRpNvob9U5OswSyj4u0u7VmreHiS/TXFmRudTqdZiuTxRI1IPvYWMBv1NYb 26sO3oAsvrmAb3S2u911B29AFr++gO9fa603XLwBRYwmkwW0dmi/n1EvIGPOdivhGwDfqGXwOQqi oYguzWLME7Us1mL8kIs+ADSQYUUTpGYpGWMforiLGR0JqhngTYJLM3bIlwtDmheSvqCpansfphgy Yk7vzcvv37x8jt68fHb8+MXx45+Onzw5fvyjpeUs3MVJWF74+tvP/vz6Y/TH829eP/2iGi/L+F9/ +OSXnz+vBkIGzSV69eWz3148e/XVp79/97QCvi3wqAwf0phIdIccoQMeg27GMK7kZCTOt2IYYVpe sZ2EEidYc6mg31ORg74zwwxX4DrEteB9ARWkCnhz+tAReBCJqcpc7mh2K4od4B7nrMNFpRVuaV4l Mw+nSVjNXEzLuAOMD6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgckoQopOf4hJAKez2g1LHrHvUFl3ys 0AOKOphWmmRIR040zRft0hj8MqsSEPzt2GbvPupwVqX1Djl0kZAVmFUIPyTMMeNNPFU4riI5xDEr G/w2VlGVkIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pacfguqR7Xb99gsdpFC0UkVzduY8zJyh0+6EY7T KuyAJlEZ+4GcQIhitM9VFXyPuxmi38EPOFnq7vuUOO4+vRrco6Ej0jxA9MxUaF9CtXaKcEyTy4p8 5oq8LWhlSuyeqMPLcCerb5eLgP77i+8Onib7BOJ9cQe6rL2Xtdf7z9feZfl81oo7L7JQf3WfYxtk 0y7HS7vlMWVsoGaM3JamYZawYQR9GNTrzEmRFKenNILHrMA7uFBgswYJrj6iKhpEOIVmu+5pIqHM SIcSpVzCIc8MV9LWeGjYlT0iNvXhwdYDidUeD+zwmh7OzwgFGbPthOYgmjNa0wTOymztWkYU1H4b ZnUt1Jm51Y1optQ53AqVwYeLqsFgYU3oRBD0L2DldTira9ZwSMGMBNrudhPO3WK8cJEukhEOSOYj rfeij+rGSXmsmFsBiJ0KH+kD3ylWK3FrabLvwO0sTiqzayxhl3vvXbyUR/DcSzpvT6QjS8rJyRJ0 1PZazdWmh3yctr0xnG/hMU7B61I3f5iFcEnkK2HD/tRkNlk+92YrV8xNgjpcWVi7Lyjs1IFUSLWD ZWRDw0xlIcASzcnKv9oEs16UAjbS30KKtQ0Ihn9MCrCj61oyHhNflZ1dGtG2s69ZKeVTRcQgCo7Q iE3FAQb361AFfQIq4ZrCVAT9Andq2tpmyi3OWdKVb7IMzo5jlkY4K7c6RfNMtnCTx4UM5q0kHuhW KbtR7vyqmJS/IFXKYfw/U0XvJ3BlsBZoD/hwpSsw0vna9rhQEYcqlEbU7wtoHEztgGiBe1mYhqCC i2XzX5BD/d/mnKVh0hpOfuqAhkhQ2I9UJAjZh7Jkou8UYvVs77IkWUbIRFRJXJlasUfkkLChroHr em/3UAShbqpJVgYM7mT8ue9ZBo1C3eSU882pIcXea3Pg7+58bDKDUm4dNg1Nbv9CxIpd1a43y/O9 t6yInpi3WY08K4BZaStoZWn/liKcc6u1FWtB49VmLhx4cVFjGCwaohQufpD+A/sfFT6zXyn0hjrk B1BbEXx00MQgbCCqr9jGA+kCaQdH0DjZQRtMmpQ1bdY6aavlm/UFd7oF3xPG1pKdxd/nNHbRnLns nFy8SGNnFnZsbceWmho8ezJFYWicH2SMY8znrfIXKD56CI7egbv+KVPSBBN8XxIYWs+ByQNIfsvR LN36CwAA//8DAFBLAwQKAAAAAAAAACEAPrVnsgCAAAAAgAAAFwAAAGRvY1Byb3BzL3RodW1ibmFp bC5qcGVn/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCADA AQADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIE AwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJico KSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6 /8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNE RUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEA PwD+/iiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK8T/aN+M1v+z78EPiN8X5NAl8X3/g/ QTL4Y8E22pJo95498c6xeWnh/wAAeALDVZLLUk03UfHXjbVtA8JaffNp2oC1vNZgnNjd+X9nkipU jShKpJScYRcmoU51akrfZp0qUZ1KtST92FOnCdSpJqEIyk0nUISqThTjyqU5RinOcKcE5NJOdSpK NOnFXvKc5RhBXlKSim17ZRXxz8Af2y/Avxd+D37OnxA8aWB+FXjz9oDxr4q+DFv8Lmu9V8bSeGv2 h/hlpfxTvPi98IZfFmleGtNtLhvAd58D/izaL4t17SPCGla5F4TjaK2sNV1zSNEufLfF/wDwUy+B Wg/FX9nr4c+FtA+MHxM0n48/ET46/C5vHHw9/Z8/aZ8a6N4L8Y/APxR4l+HXjHTNTfwR8DfFWmSH T/iZ4S17w3rt5qmueHNL8OeHLCb4n3eoXPw5MPiGbadOUKsaDSlUnWdCnGnKNZVqy+xQlSc4V201 KLoynGcGpxbg1Jw3y0ViKkalKjy05udanUo8katTGUoOoqsYSpN1cuzCly1FGUauAx1OSU8JiI0/ 0Yor4/0D9vP9lnxP8c3/AGddF+IWuXXxIbxX4z+H+m3s3wn+Mdh8JvE3xI+HOjX2v/EH4YeCf2g9 R+H9p8AfHfxT8C6TpHiC58YfDLwZ8TNd8eeGn8KeMrTWfD1neeDPFNvpHg+if8Fif+CfHiez0298 K/F74geLY/EfgxviF4Et/CX7Ln7WfinU/iz4PsX02LxVrHwQ0fQPgdqOrfHMfDKbVIYPjTY/B+y8 bal8Dp7PW4PjBZ+CJvDuvppmSqQcIVFOLp1cNDGU6iknCphKlGviKeKhJPlnhp0MLia8K8W6UqOH r1VJwo1JR0lTqRlVhKnOMqNelha0ZQkpUsTXqyoUcNVTV6detXjKjSoySqVKsZU4Rc00fpxRXxn8 Rf8AgoF+yb8LdJ+H/iPxV8SdauvCXxI8HeEPiNpHjnwP8JvjN8Uvh94Z+G/j+5itPA/xJ+LnxA+G Pw98X+C/gR8OPFkzXh8P+Pvjdrvw+8IapDofiq6tNZltvCHimbR/H/FX/BSvwB4f+IX7bPw0XwF4 +0nVf2N/hFcfFnUPHPxC+FP7Uvg/4IeJtN0nwLr/AI38SHW/jJo37Mfjfwp4Z0TSrfRo10bUvB5+ K/iD4i6W+r6v8MfB3jKTw9qGmG6ylQlUhWjOlOi8bGrTnCUalOWXW/tCM4Nc8ZYG8Vi4tKWGcoqs oOSTnDp4qWFhh7VnjZYOOE9nKMo4h5i1HAOlNPknHGtpYWaly17r2TkfpZRXyRF+3B+zn/wuDQvg HN4w126+KGrJ4NtdSHhz4WfGjxR8LfB3iXx/4ZHi7wZ4I+IHx50v4bN8GPhp478Y6DJY6p4M8A/E /wAa+CPH/iqx8QeD5dJ8KSzeNfCtvq3rvxm+N/w8+AnhS38YfEa68VfYdQ1i18PaHoPw/wDht8Sf jJ8RPFevXVrfaiNG8EfCj4PeEvHnxP8AHOqWujaVrPiPVLHwf4Q1u50bwroPiHxXq8dl4c0DWdUs XUjKlHmqLkh7aeH9o2vZuvTlCE6Ual+SVSM6lOLjGTd6kF9uN5pSVb2apXnKthaGOpQUZe0ng8TC dTD4pU2lP6vWp0qs6VXl5JxpVHGT5J29aor84df/AOCnXwDtvGf7ImieCNE+L/xR8H/tdS+OYvDf jzwB+z5+014ttfB03guK9sLrTPGGj+EfgZ4lufCnijTfF+nX/hf4i+DviHd/D/xT8Hl03WNe+I+l aHpOi6pJa6fwc/4KQ/Bn4o2H7TOr614U+NXw20n9mf4qax8NtXv/ABh+zr+07oqeNzb3+iaH4aTw BF4p+BfhSbx98SPGXifWYfDmgfBD4ZJ8Qfidf6lfeFotN0bU5PG/hWPUoUk608Pe1anQx2JnCXuW pZbi8vwGPSlPljKthMXmuBpV8PFvEU/bSqSpezoYidJ392nNXlGrisHgqfInNzxGY4fGYrAwUYpy 5cXRwGKdCq17GpUpxoxqOtWo06n6F0V8UJ/wUO/ZOf4SH4zDxx44Xw7/AMLTf4HL4Kk+AP7Q0X7Q Unxmjt21F/hTB+yvL8Kk/abn+Ia+HY5fGx8HwfCOTXv+FdQzfEj7D/wgUMviNPmbXP8AgrR8CfBH 7RWs+GPHviqTR/2dbv8AZN+B37QnhTx1p/wQ/aA1rxj4cvfH3xa/aA+HvxI1j466fofhHWL34DfC /wCGUPwv8Jab488S/GrwT8L9K+D3jPVdW0H4r+LNF1S80/Q9O0p051KlOlCEnOrVVCHuuzrzyued UaDdv42JyyCxmFpfHiKFWhVpKVKrCbbVqOIrtrkwtOFWor++4PO8Lw9UlCO81hs2xcMJimtMNUp1 4VXGdGcF+uFFfBXxO/4KdfsP/Bv4keKvhT8SfjXL4b8V+AfFfg3wT8Rr1vhh8Y9W8AfDHxJ8SPDP hTxb8NLL4o/FrQ/h9qfwp+Gdt8TNJ8a6BB8NdX8d+NPD+jfEHxC2seEPB2oa34t8MeJ9E0feX/go b+yifhTN8YZPGPxCttBh+KcfwO/4Qe+/Z2/aP0/9oK4+McumQ6/D8MLH9le++Etv+01qPjmbwnOn jyHw1YfCS51WX4cLP8R47ZvAttc+IYs4NVIKpBqdN+yaqQ96D9vVwNGhaSvF+2rZpllKlr+8q5jg acLyxeHVRP3Zwpy0qVKca1OD0nOlPDYrGwqwi/elTng8FjMXGcU4yw2ExVdN0qFWcPteivhHxD/w Us/Y28M+E/hn4wvfiN4z1K3+MOi/FPXPh14V8I/AD9orx58Vtfi+Bvibw/4Q+NOjyfBXwR8J/EPx g0Txl8I9f8SWlr8S/APiHwNpPjjwPbaX4w1XxL4e03SPAXji+8PUPD3/AAUS+DXjL9p/4X/s6+CN E+JXjnRvjF8ANE+Pnw/+N3gr4OfHrxd8Idc0LxTd6dN4X2/Erw58INT+Emn+FdW8NX6axL8QdY+J +m+HtJ1iTT/BOqraeKdX06xmuEZ1K9HDwhKVaviK2EpxUXZ4uhhM2x08NKduSniHh8izh0qNSUKm IrZficLQjUxUPYtVJKjQniKj5KNOn7aU31o/2hgcqnWhH4qlKhj8ywWHxVSnGUMI8RGpiZUqUZ1I /ftFfN37Qv7WvwM/ZdTwnH8XNd8ZLrPjn/hI5fCXgz4X/B34zfH74ka5pfg2wtdS8ZeJbP4YfAP4 f/Ez4h/8IZ4NtdQ0n/hL/G83hiLwh4Xude8OWGva3p994j0K21D46sf+Cgsvxa/by+Cn7NnwD16y v/g54m/Z28OftIeIviXN+yr+0t8VPDXxa8MfEuLWL/4c2Xwz/aE8Iah4M+A/wd8PL4c8P3evXfxQ +Ic3xH8M+LvEOp2Hwl8O6ZpvxDsNUso4ov6xiMPhqN6k6+Iq4dzgnOlQnRy3Nc2qvEzhzextgMkz SvCDTq13g6tHD061dKm6qp0MPWxVZOnSo4b6376cZVqLzDA5Xz0Iu3tYRzDM8Bhq1VfuMK8TCri6 tChGdWH6rUV8k/Hz9uX9mX9mXxXZeCvjD438SaT4hm8Jj4ga7B4R+EPxn+K+nfDf4cNq8+hJ8Tvj X4g+Evw+8ceH/gP8LptUsdYtoPiX8aNU8B+BbhfDXi+5h8QSWng7xRPpGN4i/wCCg/7I/hT40Xfw A1z4oanb/ErS/iJ4E+E3iKG1+Fvxg1XwN4L+IfxV8OeDvFHwo8MfEH4u6T4AvvhH8PLv4saf498L 2PwquPHHjjw/p/xK8U3d/wCCPA93r3jPQPEGgaXVJPEOhGgnWlias6GGVJe0eIr08XTy+pRoKHM6 tWnj61HBTp0+accXVp4aSVacYMqRlSVV1YukqGHeLrOonBUcIqUK7xVVysqeHVCrTrOtO1NUqkKj lyTi39n0V+XnxK/4KYfC6L9pf9nP9mr4K69b+LvFXj39rbxH+zx8WrvxB8KvjJYeDbew8EfBD41+ O/iDp/wg+Md/oXhf4OfEH4h/Dj4g+A/BnhL4kaV4K8YfEif4dy6rrPhrxr4b0PxI8M2k/qHRBe0w 1LFwtLD158tCqtYV4/VcHjIVqMl7tXD1cPjsPOlWg5U6ilLkbUbt1ouhiPqtX3cRHDrEVaX/AC8o J4/MstlRxENJUcTTxWVYuNXD1FGpTiqcpJe0SCiiikSFFFFABRRRQAUUUUAFfBH7dn7J3xJ/bCj/ AGcfAfhv4w6j8EPht8Ofj94c+PnxQ8XeDLTwXq/xV1DVfhDpWra/8E9C8CaF8VPhf8WPhHeQWPxn l8H/ABB8SXvj/wAKaxa2lt4B0+y0nRL7UNWXUtC+96zdY1nSPDukar4g8QarpuhaDoWm32sa3res X1tpmkaPpGmWst7qWq6rqV7LBZ6fpun2cE13fX13NDa2lrDLPcSxxRu4zqOEPZ15z9l9TxGFzCnX 5/ZPDYjLsTSx2FxUat4+ynhcTh6WIhVUounOnGaaauXDnl7WjGHtFi8PisBVpOmqqr4fMMNVwOKw 7pyjLm+sYfEVaOi51z3puM1GS/Ebw7/wTv8A2vPgJq2o6p8Iviz8Pv2kLfwL+3f/AMN1fCaD9p3x Ta/CPxP40134xfAD4p/BT9pz4d/EXxH+zh+zHF8Pfhvby+KvibrXxw+HPjH4e/A3xPDr3iLWta8J eMPA2jSvL4/1T0H4Sfsaftb/AAX8Pfssa1Yyfs5/EP4j/Cn9rT9tb4ufFfRrvx58TPht4J1D4Z/t g/E/40+M2v8A4eeIIfhN8T9dbx14CsPiF4dnXwR4k8N2ugeIryz1rQz8StHhSx8S3P0Vq/8AwVM/ 4J96Z4v/AGf/AAlaftd/s4eJY/2mNW8WaJ8K/Fnhf4+/BPWPBer6n4SZ7G4tBr0XxCjF/PrHihR4 D0CDw5ba9cah47ki8LvFbai4Svoc/tUfswr8TfG3wVP7R3wGHxk+Gfhe88b/ABH+Ep+L/wAPR8Tf h/4L07TdN1jUPF/jbwGfEP8AwlPhTwvYaRrGkarea/r2lWGlWum6rpt9Pdpa31tLLtGq6dCFKTj9 XoUsPChFxhTp4fLsiwGWYaeCpezVOMMDhsvy3AxxT1q4anz4iFfDVcRVrVJrXxjUJ805069Os3Fy dWWNxWL4irYbFVpNynVxVbMuKs7xFOVXmWMxeKVOvDE06NOhH86fh3+w/wDtQ6J4v+E3wg8UXfwE g/ZS/Z7/AGvvjH+1v4B+J3h/xv8AEHU/2i/iG/xA1v4x+MfBvwp8Y/DC/wDhTofgjwE/hXxZ8ctY i8Y/FvSvjl8Rr/4j+GvA9np03w58N3PxF1u58J9D+zv+wV8YPhJpX/BOux8SeJPhtezfsjfsMfHj 9mT4kNomseKLmPW/HnxQtv2a4dA1fwQb/wAHaa2peEbNvg54nOsX+vJ4a1m3W+0E2WgagbrUBpf0 B8B/+Cjf7Lf7TnhD4XeN/gL8QPCXxP0L4nfF3Wfgo58L/Fv9n6+1HwH410jw3498Ww2XjHSl+MIv 76/17w54Avdf8P8AhD4dwePviNqHhjWNJ8av4Kt/BFp4o8SeG/ZvDv7X37Jvi/UPi/pHhP8Aag/Z 38T6r+z5aaxqHx80zw78a/hrrWofBCw8Oy6pB4gvfi/Zab4mubn4a2mhT6HrUOsXPjOLRYdMl0fV I714H0+7EOUcPFYXEYBQaWPp1ZYtWaxOMqR4YxPD+IzGrHRyrPh3OqVKviqdOFKap4LEzTrxq1K2 9KvVhiYYykoucvYU8MoRUqNGlVzjN6+FwNBRvGMf7Yr5wsPhpylXjKpPDU7YalhaNL8KPjf/AMEn P27/AIg/so/Dj9lXSfih8ONY8L+H/wDgnT8JP2UbaGD9sn9s/wDZ18AfCX42+CvBnijw18TPiFcf Cb4A+DLPwx+2b4K+Lcd34H0S00j9oe58I6f8OtI8HzXlt4E8XWnibxR4S1r9APj5+yJ+0r8Qbj9v 7wP4Li+Bs/w1/bP/AGK1+DeheMPFHxG8feH/ABz8P/jVo/wn+JXww0uy1bwJpXwc8WaB4i+F2uL4 x0bWb/xtZ/ELR/Fnhk2Gp2Vv8NvFYuLW5h+2LD9rv9k/VfBvxS+IumftPfs8aj8Pvgbrl/4Y+Nnj uw+NXw2vPBvwe8S6VNFban4e+KXie38SyaJ8Ptc064nhgv8ASfFt9pF/ZzTRRXFvG8iKfXPA3jzw P8T/AAf4d+IXw08ZeFPiH4B8YaVa674S8ceBvEWkeLfB/ijRL1PMstY8O+JdAvNQ0XW9Ku4/ntdQ 0y9ubS4T5opnHNdGMrTzBYxYlqosbicXmeKUIqlGcs+WNrQqclFQp06dV1q9fCV4RjWxSw8PrFfG UqMoOKGJlQxmWZhRcI4jLJx/s+XxQhVwCyPD4i0W3GpaGT5fRxdF81KlUxGJrxpUMbjJYh/n98D/ ANn/APax/Z2+OPxHtPA9v+zx4n/Z6+PfxP8ABHxm+InjjxX43+JOm/Gb4ca5o3wN+HHwj8a/D/wX 8KNI+Gd14I+JeleJrr4Q+HtV8LfEXXPjP8MLzwXB4w1lNW+Gnj2TwjYx+MPQ/wBvP4K/tE/G7wL8 M9F/Z/8AE1paweHPilb+Jvix8OJ/2kPjv+x1cfGP4fx+CvGej2fhCy/al/Zn8M+NPjX8JJNB8e6v 4M+Ic3/CH+GL2Pxzb+DpPAfiG7sPDmv6o8vs3hz9rb9lTxhdfGKy8JftNfs+eKb39niHVLj4/wBp 4c+M/wAONbuvgZb6G2sprU/xit9M8SXMvwyh0d/DniFNUl8apoiae2hayt20J0u9EE+iftW/sueJ fCXxV8feHP2kvgHr/gX4E6lrujfG/wAaaJ8Yvh5qvhL4N6x4Xge68TaV8VfEdj4in0f4eal4dto5 LjXbHxdeaRdaRBG8uoRW8aswjE1XiKNCdWUfZUMPg8VSrSjTnFZdl8cFh8C+atGpS+oYTC4bAYKj UjFRUIxxEqssxxNfGV8MNh1gnKhRpSp+1hi8rlR/eRnPGYulip4+acXGus2xEswrYytUjNYinVnR qUo0aVGhCH5n/s6/sJftW/s0/DL9jLT9EufgZ8SPHfwF/aW/a/8AH/xN0vxb8a/jrb6Pqnws/as+ IHxh8Spqfhb4t+M/ht8Zfil42+J/gXTfHnhu4vbH4o6fPL8QNVtNft9b+K9hdzw+K7zv/H/7L/7b s3gz9tL4cfCvxF8IvCOjfGH9o3wp8ePhV470T49fGn4XfEfxl4N1fWvhZd/G74C+PNb8AfB2fxN+ zdceKvDHgzxd4I8M/tD/AAX8e/FDxvotn4ts/Eek+BPDHiDRIpZvrH9l79sLwB+1h4q/aMsfhZee D/Ffw9+CHxG8CeB/CnxZ8AfEPRfiN4N+L2leN/gR8K/jUni7w9qnh2z/ALEtNPsJfiVL4TSHTde8 UW19J4fk1capbNqDaRp3pfh/9p39mzxZ8T5fgj4V/aE+B3ib4zwad4k1eb4ReH/ix4C1n4nw6T4N 8U6t4G8YapL4B07X7nxXHp3hTxroOueD/El6+ki20LxTo2reH9UltdW068tIXVhUeL+tTjJYnH5a lGFWKr+1y3HxyPP6NKthsWq6xFKE8ky3Mq2HzCniJV4RxeBzqnisvrYvAOrKNOVV8vsp5rHN3WhL 2dNZnjf7XgsRSq4eVONCpisNnmYYPDww0qUaEJUcTl0cNmWGo42H47fBf/gm5+1v8E47v4w6Dc/B fXfjd4b/AG8NT/a28BfCX4i/tV/tVfGfwZrXgLxt+xl4Y/ZL8W/C/wAfftg/Gv4b/ET9oK68YeHV XxB4r8K/EjUPhb420nU7fQtA8PD4e+DdF8QJp3w++hfix+xd+078cdP/AGz/ABJ431f4D6F8Qv2r f+CYmi/sh2Wk+FfEHxBuPBng/wCM0WrftXapd/atY1fwONc1T4Y6La/Hbwbo1v4+i0W18VeLLjQf E3iKT4S+Co7nSvDA+vtb/b0/Yw0fQPj7r9t+1N+zz4kP7Luj6zrHx+0Twt8b/hTrHiH4Tf2Ld3+l z6V8RNNj8YRf8IHrN1r+m3fhixsfGk3h/wA/xLG2ivLFepLHHp/BL9tb9lP9oX4e+HviX8Kv2gPg 34n8P6/8Mbr4vzQ6X8VvhxrWo+G/AejyQWXi3W/FUfhzxXrdlo9j4B1yV/C/jzUmv5tG8LeJ7W70 TU9TivIChiVeGJoyg5xqUsHleCjCcqs5ywuTz4cx3DeHnCvUqSqVsJVyrJ8bOpiq88Q44nA4jFyr U51cS6/TQr1svxNKrCMaWJrYylTlelGH1nMcr4kyniiEKtCEYUqeLhnWJwEvYUqWHdShj44KFJ4e OFp4b4j8Vf8ABP74ya54T/as0G08S/DKO8+Of7Wv/BP348+EpLjWfFSW2neEP2UtN/Yss/iHpviJ 4vBk0tp4k1mX9nLxu3guz0yHV9L1GPVPCp1zWPDrX2rrofnP7Q//AATM+M/xJ8afFj4reF/EPhnU PEtx+37pX7Wvw18D6Z+0p+0p+ym/i7wBffsQfDr9kXxb4J8WftG/s2aHH8Y/gr4ug1LRvEvjbRtU 8A6T8TPDuu6Tpej+EfFWlTWHjPW38J/rZqfx9+BWi6MfEesfGn4S6T4eHwuvPjide1P4jeDrDRh8 FdPjsZb/AOMB1S61mKxHwusYtU0yW8+IHn/8InbR6jYvNqyLd25k4qz/AGx/2RNR+Etr8fdP/ao/ ZwvvgTfX+uaXZfGqz+OHwyuvhLean4Z0/WdW8Sada/EeDxO/g64v/D+leHPEOp65Zxay9xpOn6Fr N7fx29tpd9JBtVr1b1nNqEoUqVOvzQg1TpYfF8K4OPtYVYzgorG8CZPg5+1i4vEYfG4eS9rWqQjz 4WSp4LDYKjaphY0Vh6KUpN1aSyatScY1qUo1Ob+ycwlivaUZwqwo1aWMpzhH2dQ+LP2df2EfF/wp +KH7LvxMh8FeA/hPYfDP4eftx6d8W/A1l+1L+0N+17rur/E39qX4k/AXxdpXjDS/j1+0R8PvCnxL +JR1i3+E+u61491Dx1ZeGb/QNd1uw0Tw9ZeKNMhn1qOn+yb+x1+0z+y7f/sKWgT4FeN9A+EP7Fdn +yh+0LdH4j+P/DmsaBq+ha14R8T6P46+DNmPg1rtl8UdOvb/AETVtF1Lw543vvgtc2dnc6drtrrd 5NFc6BJ9QfCr9tv4U/Eb4g/G/wAJaj4h+HvhHw38OfjZ8Hvgn8LfH178UvDd3on7QOufGv8AZ4+F X7QHgpvADTwaVYXmra9p/wATH0bwt4c8O6x4xvPFlnoDeJNJujBqJ0zT/qfxr438GfDXwj4j8f8A xF8XeGPAPgPwdo9/4i8XeNvGuv6V4V8I+FfD+lwPdanrviPxJrt3YaNoej6daxyXN/qep3trZWkC PNcTxxqzA9pLCfUsRyqhRwVGhVw8Kjn7KhgsRlWf1aWDqe2nKpQorJOPcwp/Vqk6WJwODxWBjH6r VwtCURp1sNWwGlWGY+wxb9nyOrXnLNqWbYTG0pUEvazlm+BhiY1bVIYyvQrU8UsTGeJp1Pij9pb4 NftLx/tD/Cb9qT9lbRfgX498a+E/g58XvgH4y+G/7QnxK8e/CPwtdeFPiT4j+G/jvRPHHhTx74A+ Dfx41Sy8ReFfFXw0tdP1vwhceAbaw8d+HfEReXxl4avvCWlxatw/7Gn7C3jX9lf4ieBdY1Pxr4X8 Z+G/CX7EHwo/Zx1HVLC21bQ9a1r4neFPiv8AE/4leNfEeneEZ7fUtL8NfD3UJ/H6ReENITxhq+pa JawjQZrdrTTbbU77uPhj/wAFHf2avH1j+1J4/wBZ+LPwN8E/s6/s3/Ej4a+BLL9prU/jv4Bm+Cvx D034mfBj4RfFPSPFdr8QLubSPA2hWL618V4PAOm28Xi7xFBrWqaVDdWupxXerpodj9W+C/jh8Ffi RbaHe/Dv4v8Awu8e2fifwJb/ABR8NXfgvx/4T8U23iH4ZXd6+m2nxF0OfQ9WvotW8CXWoxSafb+L rB7jw/Nexvax6g06NGMKdNYT6hUsovAxxOMwPtbXwlDiHJeIsfiaXLK0qKxWB4rz3OK9Gso4qE6y niHGhleGw+EKy9rCvGSSjmVLL3iJ0+X/AG5Zfj+HKmX15VFze1lQqZLkOX0ZQl7NUeXDqHtsZOdX 8pf21f8AgnR8SvjP+0x45+OHgrwro/xo8DfGz4B+BPgf8U/hH4l/4KMft0/8E9dNsIfh1rnxMuIb +5u/2PPCHxK8PfHjw3488N/FfV9A1vwf8V/Bemy+D30Az6D4l1jTPHOuaJpHaeNv+CfPxL1Xw9+1 v4b8Iat8NtF0n42/tffsCfHT4aaffeIfGFxH4c+G37J1j+xfYeL/AA94nvZPCV9er4ovbb9nHxhB 4PjtG16y1cah4Wl8Q6/oUuoaydF+y7H9tb9mg+Dvij8UfEnxk+EfgT4L/CvWfAum6p8cvFvxz+Ak fwi1jTviV4I8C+O/A3iez8ZaD8U9etvC+h+KtM+Inhq28NQ/E+D4f+IfFDX2n654Y0DWfBfiPwf4 p8R73ij9sX9kbwRafCDUPGn7U/7OPhCw/aEttOvPgHe+KPjf8MtAtPjhZ6v/AGKdJu/hBc6r4ntI fiXbaoPEnh06dP4MfWor3+39F+zNL/alj5+2D9pgalN4eDjWeJwErcrVSrXnm2D4tyvDYmlDlVTE U8Xg/b4SliKbxtPDVsdhrqnKcKd1Jy9ssVNJShhqlpyXNT9hh6WBw2IxFKU+ZUqSo4HARxM8NKnh qrp0a9eM6zhWf50eC/2HP2vPDHxM/Z48GS6j+zg/7Mv7NH7evx1/a48O+MY/GHxOuPjt8QvCPx10 D9qO+j8H614Ab4ZWXw/8D+I/hn4w/aKl0N9RsfiP430z4p+GrCPxQsXwl1TSW8IeJv2lryOL9oD4 DT/GO5/Z2g+Nvwjm/aBsvDi+Mbz4FxfEnwbJ8Y7TwiyW8i+Kbn4YprJ8bQeHGju7WRdbl0RdMKXN uwuts0Zb1ys6cmsLRoxfPTjOc/bN808RWpUcNllWrUmrQlVjHK6VCs6cYXxFGtOqniZ15yiq/aYq daSUakaKw6oxXLTw9GtjsxzuNKFP4oQniM8xeIpKTdqGIowpcuHhRiiiiikIKKKKACiiigAooooA K8K/ae8F6R8SP2dvjZ8PPEHw78ffFnQfHnwz8X+Dda+G/wALPEPhLwl8R/GOleJtGutF1DRfBHif x544+Gvg7QfEtxa3sraTqviPx54V0uyu0jnuNXtwg3e60VnWpqtRq0XKcFVpzpOdN8tSKqRcXKEm mozineLs7NJ2ZrQrTw9ajXp256NWnVhe9uenNTjezi7Xir2afZp6n4p/C/wx+3lplp+xP8TfjR8G fjJ8Y9d+FH7QX7RnhjWdI8R+Kf2OtF/aX8K/s8/EXwt4k8F/CL4kfHMfD74p+DP2XvFPizw5FFpZ +Idt8BfF2oapdeFr/RtY0fwXrvjWLxPoUfjXhL9nn9v/AMTft5/s3+PfiR4A+J+gfCX4GftlftY/ EnXbbSdU/YD8O/skaV8K/il8NP2m/C/wy8Y/A7SPh14dt/25fFnj3xrL448B6p+0E3x48SaVbXPx Y8U+KfEmkeEPFWhiw1zwN/QjRXUq0lio4tqMqkaUqbhNN0ajlQwVFVqtO9p4mE8HLFRxDftVisZj Kjk4zo06HKqMIYLF4CmvZ0cW8TeUNKuHp4nD5vhJUMLUs/Y4alhs2dCjQtKlCGXZbeMpUa8sT+GH hv8AZv8A2o/FXwv/AGN/hTqvwV8a/CbWP2Y/28PjV4m8U/EG88c/BDV9G1X4U+K/hF+2n4d8J/Hj 4Zf8It8UvEHiO80WTWvjJ8O7SPwr4x8MeDfidp+tahdm78BHw/pF74gHzNd/sXftd/En9mPw58EE /Y+k+BPin9lz/glZ+2D+xZaa/N8S/gHqWh/tUfE34wfCvwV8OvB2gfBefwd8TfEes6Z8G/E/if4c H4s+Itf/AGjrH4G+J9L8T6p4BhuPCV3O/jrUvDn9NFFcsaUI4fGYVrno49ReKUn71StDJsZkdPER nHlnSnHC5hj6k6dGVPC4mri6lLGYfEYGNHB0vQp4ypSxmU46EYKvksMNRwH8T2UcPh+IZ8R+wrUv acmJjVxbo4Z1MQqmIw+Ew1OWArYTHVcXjcT+GXxr/Y58cR/ED4qa7pX7P3xu1fwDqH7G3/BPD4c/ D8fsgeMv2XPAfxd8NfHX9lb49/Hf4jaHq/gqx+PvxN+HnwlA+B8et/DXWrWD4hx6t8P9f0K4k8Ja d4f8b2MWu+GY/wBPP2YX/aNl/Ze+E7/tJ22jj9pZ/hvYH4iWs48O21ofGhs5fIi8VD4e3Os+CrbX 3i/s8ePR8OLrU/AsPiZteHgGa78LrozP9I0V0YqrUxlLH0a0nbMMVisZVkm+anXxtTF1MRUoqTlC NSr9ajSqVpwqYivh8DllDEVq1LL8LCnwUaUKFTCThFWweCy3AQpv+HVoZVleV5ThvbKPLKT+rZTS nKMJU6MMRisfWoUqLxdSJ/Khp/7GH/BST4oaT8VJvij8Kfi3baxff8Eh/wBtf9kOx8GeNPEP/BOf wf8AB3R/j98VbL4LN4E+GH7KHhz9lqw8NeLNL/ZmvLnwx4l034Ya7+1L4y1Lxr4b0PSbW18Z6Z4A vri+1fxv9g/tH/sO/HXU/HvjLxd8KvghomveDvDH7On/AASoXS/hfpfiH4Z+E9N+MviP9h/9rj4q /GXx78BrCz1bXdN8OaXqtn8NtQ8Nad8P9U8eQ6N8K5ta1DQdCbxboulWmuav4b/e6irp4irS+oOk 1TqZdisPjcPUUYylLF4TN+I88w+IxEZqVLEzp5lxPmFdxrU506vs8Mq9Oqvrf1vevP6zh8Thq8I1 KWLpYyhiH78KksPjp8IvEUadSlKE8NH2PBmVYWjUw0qNfD0KuMlQq08S8HiMH+bP7A3wx+LHhT4m /t6/Fn4mfs+N+zbp37Sv7Svg34veAfAl54p+FnifxFdaHH+zN8DfAuv6/wCNm+EPiPxV4S0vx9qP jrwj4pbxtYWfiHxHaP4kTUb3SPF/jfRLrTvF+tfKfh39hz436dZ/BSSx+G+n+EPE+jf8FfP27f2o /Gfi3StZ8BRa3onwa+O3hn9tvwp4G+K02oaX4kg1DWb7X9F+Jvwc0ufw9p17c+O7PSrjStM13RdM tPDOpR6J+6VFc1SFOrSpUJU0qNLJctyBU4OcFLLss/sRUqcpRmpqVaOQ4KOI5JwpyU6/sqdFug6G sMVWhRrUk4SdbFYrGSqzpU51I4jF5NxDkc5qMoujNxwvEuPrRdalVlPF0sNVxDrQWJpYn+cf9h39 g/8AaK8DeHfBXw7+N2jftrWvjv8AZ2/Yr+Mv7L3w58S+P/Ef/BMFf2KdRk8daV4G8Ma9ZfCmf9mD wx4N/bO1vw1411XwN4Y8eeD5f2j/AAVYX+mado1zffEHHxG8h9X9H+Kf7M37U3xq/Z6/Yem0T9nb xX8KvidpXwu1T9hD9qrwH458f/BmbxH4Z/Zf+Mvhn4eeGfjT8SdH8RfDD43+IfBXi3SPD+r/AAn0 DxJ4K0rTvFF78QbzSNYuGXwPoeuXOqaND++NFbVKrrVcXVxEYV5Y9YJY3ngorE/VcXxJicTz+y9m 4f2vQ4tz/Lc2VF0licvx9WnSVCu3iXycij9W9jKrh/qTx/1L2Vas3hFjaGTUoRpSq1Ks5LAV+H8p x2BdaVWVPG4RTryxFKpVoz/m28Lf8E8/2o/D3wZ+K0etfCey8W6r+zz8VP2SPhT+zJ8FZ/GvwvW2 /aE/Yl/YM/ah1z48fD/TLfVW1Ox8KeBfFHxR8I+MIND0zwt8R9b8M6bH47+EngiLx7qHh/wnc/2x Ze5Wv7KHx8+LXxb0z4/+Kf2cJvhR4f8AH3/BTf4E/tN6p8B/HHin4KeIfF/gDwN8E/2Vta+Dtz8a /iT/AMIB498efC+4+Jnir4h6V4V1Gx0T4Y/ED4larp/hjQvhvr89/beKLfxNpfhf916Kik5U6mHq ynUrVMNm+XZ9GdWpNzqZvgsy4ZzbE4ytOMoTqf2xjuFcuxGa4VyWBnXrY3FYHDYHGVqWIoOrCFWG MgoqmsZl+OyipyOTVPKsXlecZNhcBShVlUpqOUZfnVfDZZi5wqZksPhcBhcdjcdg8M8PU/DLQ/2O P2lvh/8A8FVfjD+3PZeDH+JHwt8c/Gnwz4D034a674l8AeV4Q+G3jH9lH9m/4c+JP2uPgzHeeJNL k8OfEXwf4++GOu/C34r+HvGO/wAW+NvghNq8nwr0+0vLX+xfi593f8FCfhJ8Q/jF+zpHpPwx8HQf E3xR4E+Nf7OHxub4R3GseHtAHxg0P4FfHj4e/FrxF8M7PV/GN9pvgqz13xTovhC9tvCreN9R0zwd N4rj0O38S634c0mW68R6T9v0UoOVPD5RQpycXkdTKqmW17RnWpSyatgsXgVU9op0sTGGYYOWPnHE UqqnUxmJwdllVPA5fgtKslWrYmrOEbY3BfUcZSi5whiKcsHUy2rVc4TjiKGIq5bKhgXVwlfDulDB 4fE4ZUMweJxmI/mb8e/saftneNPHHxO/aY8I/AX4t/s63s3/AAUj8F/tbaB8H/gn42/YP1z9o7xD 4F1T9gbQf2btd8beHf8AheA+KP7G0Hxw0L4natrWu+OdD+ImuNZzWsPj7U/hx8X9e1x/BviTxf2H xE/YN/adsP2dPgzq/wCy14e/aF0b45+PPG/7WXwi+Pf/AA1N4z/ZD0f41+Avgf8At9+KdT1v44fF u4f9lbWbH9mSa8+GvxW0DwN8ePBXgv4UzX2pyaReeIbOz0V/HGr6tob/ANGlFKEaUaMcO6NKpRjh sBl/JVhzp5Xg8nyjIcTldm7RwWc5Zk9DDZwqfJXxNLEYqhRr4bDTo0KFzrVZzo1PaTp1aDlVp1aU nCaxsa2b4nBZlJJ8lTHZXis5xWKwFWcJU44iMKuJpYl1cZ9a/BDXf2Mvjh8Hfj9r/wAavhn+zvef E74U/Bn9uf4O/F74ZfAvwj4y+EGj+K/iJ8HPDf8AwTG8Hfsa2uv/AAyj+Jfj7wb8O9K8X/CD4hTX l1pug/FXxf8AC+4vvDfhjxHqfhjXvtk/hez8VeVftKfsdftK/EX4rePPiND8Dv2v/AnwZ/a2/Y68 G/Ar4l/s/wD7D/iX/gk9qPjD4a/YPHfx18R+Pfh98aLv9uHQl8KJbeNtK+OEPiGbXP2U/ifqunQ/ E+P4krrNx4mjsvAPxP8AEv8ASJRWlScq7w7xcpYx0JUOZ4iUm8VSpcO0uG6tHGOnKm8RHG4SjDE4 2rN/Wa+LXIsRDLksAppSWHVJYanHC+wwGCy+h7B1IuhTy3NKebYCrQbqSdCtg8TTUaHsXChCMpVf YvF8uJj+UXwX+Fv7Qfwx/b08TTfDjwH+0b4U/Zd8b+FNS1T9oPxD8efGH7LXi74UfE/4s+Efhz8I Phv8L/if8AV+H/xJ8W/tR+HPiTr3h/wdHoXxU0z4neGPBPwd1bSvDN/4g0XwrpPje9tNV8Ufq7RR TnVqVIUY1JOpKjSVFVJfxJwjOpKmp2tCMKMJxw2Go0oUsPhMHQw2DwtGjhsPRpQ56VGFBONJONNu HLTXwU1CjSoqMFbTm9l7WrKTlUrYipWr1Zzq1ZyZRRRWZqFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABXyV+0FoPw51T4h/Da9+LHwt1L4neDLXwN8VtPS3tPgz4r+MlvpXiPU9X+Fkmlu1h 4V8I+LZ/D2oXmm6drqadrFzFpqhYLyKHUI33g/WtFS4pzpyaTUHVunFSuq2Gr4WVuZOKnGFeU6cp RnGNSMHKE4pxdwm4O65k7WTjJxae61Wtrq0kmnKLaUot3X5zSa/+0V4I1z4HeDtPj+Kpt4bH4awe J7C50pvFXh19F1Xx3c2WsaXr3iLSP2ffiilz4g8KeBVis/FGr69+0l8PZZLmzttbsG19ppdQ1/3X 4YXXxqPjWw1Lxn4h8Wap4e8Tan8brO68L6t4L8O6Lofg6w8JePodM+Gt5pmpaX4Y0rxGJvEPhdJ7 r7R4m1/WrPxFbzrqWj2tokIlf6korTnespNzqOri6kqk3KpKSxUoPll7Rz5/ZRhalOblUhKdSpTl CU2YqCSjGKUIRp4WChTjyRX1anKD5VGyhGrKUZzjFK6hGE3ONz81dL+H3xM+Hnib4jfEXwp4F0m3 8U+Jov2nH8Ka14S+GdzpPiuXVLn4p3er6UPi1d3F5qC/EuPUNAsotf8AhFeSr4W09ZLY+HTZa0Ne 0vUK9P8AD2pfGvxXcadoGifEH4y2vgy9+ITWS/FDxZ8IfC/g74lv4fg+F+va1qlpc+GfFnwe8OaD o+i23jmz0LTdI8Tar8MbdtTN/faNb3WozC01Fftuis+X9yqN5KEMPHD0nGUoygo16lZSvdrT2jgv ZqlOUYr21StealpNuVSdVWU6mIq4iponFurTjBxS0b+HmXtJVIxk3KlClL3l8BjX/wBo/wAO/DfU tU17xH8VfE+v618NfhT4kR9K+HvhjR9V8GeNNa8UX2neL9G0mx0D4F/EzUn02x0k6ddeIdHvvhr8 TvF2lwJc3tjBp9vdCXTammfET49v4c+B95rV58XDrF/4q8UWXi7QNA+GOqx6x4k8Pr8Q20zwxqni PxHrv7K6eGNGRfDNvAZtO8QaL+zHLqGm6ldeIrjXtDNpFbw/oPRWkZWmpyUZWxKr25VFezTqXw/L Z03Bwmqd5052UfaWddUqtKai54zUb0+ZWXK2+X/ZoULpt86bqxeKfLOP71qKtS9rCt8N6l42+K9v 4J+KWoy638d2+I1jr6WieE9I+Flvp3hTwdpsnxBn0vTL74eeKU/Zq+J11490ubwr9hvvEFzplj8a 9ZhsJLi9g0Tw9cGWTSsHSNe/ae8U+CPCs7eI/iH4T1ex+H/x58Taje2/w60O71fxN4j8JeM9Nsvh PoWuReNPgv4Re2/4STw5d3Fy+nWHw1+HXiPxLa273On6boVxDOY/0CorOCcIpOTlKKlyyeqjJ4Sv h4vllzOcYVKsMVGNaVVutSj7SVSHIqejknKL5Fyquqko6r2lJSi3Rk48qjzpOMp0o00o8vs4U5+0 lV+T7D4kfE//AIWFb+D9T0fxxHLqPxU0O7guLb4Y69J4OsvhRdfCOwvtRjufHqeGZfCto8fxHXUb Z7S+8SnxnbXTR2kkSaUYwPrCiitLrlUeVKzXvatuMKGHw8E27tyccOq1aTf73FVsRXUYe15I5KLT i3Jy5aMKbv8AamquIrTqyStHmnKv7OKUVyYejh6V5+z52UUUVJQUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFcV498bWPgHQ017Uow9jHexrqEzyyww6do9pbXWr+I9ZlMFre3Ew0Tw1pesavFY 21rLcapcWUOlwGGW8W4i+H/F3/BUP9ln4S+CdQ8fftA6l8RvgTolhqmoWNxF4y+Cvxs1W90mG08c eHvhtZHxWfB/w48Q6b4Z1XXfGviK203wzpFzqVyfF2j2uoeNfBl74k8D6dqPiOz+q4Z4G4y40k6f CHC2fcUYh5jhspp4LIMrxmb5jicyxdNVcNgsFluBpV8fjq9Wm1JQweHr21UuWSaMcXiKGAorE42t TwuHa5nXrzjTowgo4mcqtSrJqFKjBYSuqlapKNKnNUqdScamIw8av6K0V+e/gX/goP4PbSPGWpft BfDzX/2cptE1HxA3gbTtV8U+C/itrfxn0Cw8QePItIj+E/gP4S6v4n+L/jX4i/8ACC+DtN8e+Mfh v4f+GOqXPhuDxdpui+Htd8d3Ol+ILvTOh1f/AIKOfsraF4aXxXqWp/HaPTJfEY8M2lnbfsdfti6j 4n1KaSyS/tPEWj+CtN+A134y1n4d6nFLHb6N8VNK0G8+Get6k66PpHi291Y/Yq9yv4ReJ1LG1MBh +BeJM4q08TDBrEcNZbX4qyzEYqdONSNDBZxw2s1ynH1eWSUoYHG4hwqKdKfLVp1IRyjj8FJJ/WaM VJ1FB1JqmqipQdSc6XtOX2tJU4yqe1p89KVOLqRm4JyPuevjj9o/4Laj8aPiR8MNHTS/B8ui2vw7 +M1vqXiDx38L5/iZo3h+91fU/hNbadLoajxJ4WtPC/j2S3i1S88K+IJ7+9ltY9M1doNF1BFuXteS uf8Agpr+xXZ+OPDnw1n+KviIePPE/wAO/hf8V7LwtH8EPj7Pq2leAvjJ490n4X+ANc8ZwW/wvlHw 9e/8f67pHhjXdH8eP4b13wRqF9EfHOmeG7YPOjPFn/BTb9jPwLr3gzwp4u+IPxA0DxT8SIPifefD nwxf/s4ftMp4j+IWm/CCxsNR8aa14D0JPg8+q+MvD8lpqlk/gnxB4btNT0T4pyyva/C+/wDGN1b3 EMUQ8HvFmtiMHCHhb4i1q1WhjcdhaEOCeJpVMVhaGUY3GYrF0IQyznrYbB5bHEZpXrU1KlSwWFq4 mtKOGp1KiazTA0lVmswwcFT+q06s3iaCVJ5h7L6nGbc7QljVWpLCc1nX9tTdDmc4X1n8U/G3Tf2i 9M8E6K/xPvfh1ZTtot+3iPQmvvDFxp1v8LL2/s/ENp4ktP2bdP0UG48Xx6TBJeX/AO0xq2rSazLq Fle+CLa3nWy0rBfxb8UfiX4R8PaNq3hz4jz32gwfso3njFNb+FXibwjHN8SdL+Ofhi/+Jd5pcupe FNDTWrHSNJ0tNU1TUPDJvfBtlpcTajYXK2i3My+86f8AtW/s/Xfgy3+Ieo/Eew8F+DJbGPULzXvi jo/iX4RW3h23fQtO8RunjOH4o6L4Qu/At7aaXqth/aOm+MrfQtR0vUpm0PUbW11uC406Lz5f29v2 am+w/wDE3+Lif2n42Hgax8z9l/8Aahi+03DW4vE8bJ5vwcT/AIso9oWuo/2hW2/Ad7eK4nT4jtHb XDR+bhOAOP8AE1VKhwTxfj62X4rDyxvsuGs5rTjjcBUxNZwxEaWCl9XnL2tSpiqU0puphcLUi6Uc LySJ4vAqlzQxOGo0KlGlGjKNen7ONKlKnjak6c3O0ubD4Vw51LlhgniXNVfaTqp/x0m1XTdZ+MOm w+EPHWvzfFv4BaZ4B8EXHhPwZ4i8VaZc+MLC7+KVpLo2v6toWn32m+CUkPjvw/cQ6541uvD/AIaa 0bUbh9ajTStQ8htnH8c7XxZfSXGveLJfCOm+P7D4e2ngSLwX4ebwvdeBpPgrZare+LV15fCw8ZXc 1v4/mm0+01y38Uw+Ho5bZ9Du9Mu7ssY+dvf+ClH7F+leMfhx8PtZ+Lmo6B41+K+u/F/w74K8N+I/ hP8AGnw7qdxqfwE8QP4Y+Lp8Qw638O7AeBtM8F6tFP8Abte8ct4c0K+0u1vNf0fUtR0CzutThqT/ APBTj9hux8X+APA+s/HO38Ma38TPDfiPxd4XuvGPw/8Air4M8KQ+HfB/hrQvFXi3U/GHjzxX4F0f wN8OI/C+n+JdE03xDB8RPEfha60XxhfL4A1GC28dQ3PhyHtXg74r1qdSEfDLxEqfXMszLF+7wVxJ OFXK8ox+aLMcxhT/ALNlGWHyl5PxHluY46N6OD/s/NY1pYfEZbjJRqrmOChUre0xmEpTy6q6WIUs RShUwWKxeHy/CQp4lympUJzq08rrUKNTklOvUhB+1p4mlTh5r4G8SftCeEfgvHpXg3/hbWvv4d+G vwh0rUoPHPwru/A2rfDrxH/a1po/jHR/hraJ8CNS1/xxpeheFVurgagfAPxwnsrnTtNnR/E0t5dW E29a2n7QXi6HwV41bxL450Hxd4Z+EX7Qk0fiDSvh7LJqniC9g8WeA7zwP4N8Uad8TfgH8NlS+1qP TiLiHRPhP4H1TxHb6K9z4VurW3e7vZ/Wvhv+3t+y58Z9H+K+rfB34h3PxJb4M+PfEvwr8babonhL xfo13H8S/Cs9/Zaj4O0i78baJ4V0PV7mfUdOuLCw8QWmsN4LuZTFdHxNHpsgvgvgz9uv9nrxJp7z +K9b8SfBLVLSx8KNqmk/HTwhrfw40xPEniwQ28PgHwh8UNQt7j4H/Gnxxomuy/8ACI+JNJ/Z++KP xZtdK8XKugHUZr26sVu4xXhv4i0MTmTxXBHFeGx+WYhxzDBYrIszpZvllfOsJVjh54vLK2HjmFLB yhmWHWErYjB+xqfWcHh8Xi8VUx2H9qLFYSM6FP21BqdRU/YKpH2dZYCrhqdSi1GV6dedSEY1Upxv XVWWEoUJUaqhymofEz422Px5t7YweP7L4d20F1c+JrTXPDgj8B2GnQ/CW/8AEMmr6drkn7P2g6Dp 9hB4vTTrPztd/auu9Tg1AX+n6t4a0+1cpo/jWjfFf9pqbwFPcL4u8fa/4muPE3hX/hIbNPAWu6b4 n8C+Dr/wn4iurPXtIs0/YXl13VNO8Z+NNLm0lrix+B/xS0HSLHSPsNv4+huLi+1+009I/wCCsv7K /jHwHJ8Z/DujfFLxJ+yefBniHxvq37VA8K+GtP8AhPYeEPC+g+PdT8YXt/8AD/xL4x0b9pi7Og3v gO78KXWk6b+z9qWqazr3iDw//wAI1Ya9oEuta5our8N/20/2RtIT4d/8M6fDLxI/wv8Ai3qdjPce O/h/+zb8T/hl4JMereG9K1vRfGFtd618KvB3h/x54cs9LvvsXjbxJ4b1fVP+Fdapaw+EvE8dr4uu 7Tw23q4vwU8WcBLGUsb4fcUYZ4aH1bHVJ5XiPZ5NmeU1cVjsyyfPaz/c8P8AEVHC0p0Mdw7m9XB8 QUaioYavlsKlfDUZ80c2yxwwdSGYYWrCvTn7Cca1J0swUcJzSqYGcHKOPqR9pCrKjhXUdJey5uar Ubqel2Gs/tI6m2j67ceJPFFlH4d8EfAbUrrw/o/w5gTQvH/iHxP411nSviUmsv41+GPh7x7aHTvC 1lp2pX+laNp/w91Twxc339o6hp1hYvDpw+4a+KT+278PLbxT4/vr22tL/wCAHhQfDLw74X+PXw71 uf41WfxD+KPjfxF470Dxb4K0fwH8G9B8deING0X4UyeELZPHPjvX7uy0rRr658TJrljoWieBda8R S+efD3/grB+wx8WIPhtf/DX4j/E3xroXxak0+PwV4u8Pfsr/ALWWoeBJm1HxVP4MjPibx9F8D/8A hC/AEdnr8Bj1qXx/r3hmLw9pc9l4j199N8OahYarc88fCLxSxNDF4vL/AA64wzPL8HUw08djsk4f zLPsBluIzXLZZ7h8uzHM8ow2NwuAzKlllOtXxGS42vQzDKlg8dh8ZgsHiMFjaFG54/BYeUKeJx2H o1J4dSprEVoUPb0cKqWHrYmgqsoqvSjiJezxOJpOpCGLlLDVavtqbpw/RmivlZP20v2eV0FPFOqe I/HHhbw5ceM5vAmma347+B/x1+H2meINYh1Lwrpj6p4Vu/G/w28Pw+LfAj/8JjpWrwfE/wAMtq3w 1ufClh4v8aW3iyXwh4A8d654c4nX/wDgoP8As6aX4b8W67pl18VdZn8OWGjTaVZt+zn+0rpdj411 LxJEy6Rp/grXrr4OPpvjC203UDHp3xJ1nwc3iTTvgzL9qk+LEnhBdPvVh87C+GfiNjKip4bgLjKt J4qGCbjwznKp08VPEUcJGhWqywapUan1nEUKEo1pw5KtanCfK5xT6o1qMml7ehG83T5p16VOEZxc 1NTqVJxp0+R0qvtHOUVTVKo5uKpza+36K+BIv+CivwT1rwl4C8V/DnSfFHxnXxXoekeNPFWk/C3V /hida+FHws1i6tbK0+NXjrQvib8RPhh4kuPhNq8l3HqPgbXfBuh+KvEPxV8LlPGPwt8J+MfDMi6m PVfhB+1Lp3xc1uTRv+FVfEv4bu+uW2m6M/xDuPhrLL4s0DXPCuveMvBPxC8Nw/Df4h/EeGHwb4y0 Twn4naxs/GN54P8AiHo13ptvbeJfAGjjUbeULNvDrjTIsvxmZ51kOIyrDZfWlQx1PH4jBYbMMJWj jaeXyp18pq4qOa05LFVaMfewaTpVqOJTeGq060ubDZjgsXDD1MNXjXp4qlRrUJ04zlCpSr0qtalN S5eVRnSozn7zjyqVLms69D2n1NRRRXxJ2hRRRQAUUUUAFFFFABRRRQAUUUUAcT8RvA9p8R/BfiHw dd6tqvh1tb0rULGx8S6Fb+HrzW/DGo3djc2ll4i0jT/GOg+LPBmqaho8twL220jxr4S8WeDNWeL+ zfFnhbxH4futR0a9/Lyb/gkX8NLP4bQfC24/aU+Jdr8H9Ef+1Lb4czfspf8ABIaD4baRJZ6xe+Kv 7Rg8ISf8Ezl8L2D2viC91HxH9rj0+JoNYu73WPMW9uJ7h/15riPibpWta98N/iDofhvStG13xFrP gjxXpWg6H4j8Raj4P8PazrWo6Df2el6Vr3i3R/DXjPVvC+jajfTQWmqeItL8H+LNR0Sxmn1Oy8Na 7c20Wl3X6FwL4hcW8HTjlvDuaYDLMJmOd5bmWJnjMh4XzT2WY4VPCYTM6eI4iy7FRweIwWHrVY0c RHE4WFGE6jlVpwlOZlUweDxtSisf7V0Ir2FSUJ1/cwtWopYiMaVKS9omrydPkl7R6csm7P8AMnwN +yN4a8b65dar4G/4KHftI6j4q8X/AA78DX2u3Vp8Af8AgmFp3im9+HltOnj74faL40F5/wAE1rLW 9PtdJu/Hx8Y+HvBfixbPUdCvPFl1rttoljc6td3U3mOgfsy/s8+Bvjp4k/Zk8O/8FIfih4F+Ovij WI/i/wCIfhpp/wABf+CUnhDW/HXjb4pWev69eeKg6f8ABNbTNM8ffFTxRonwj1bxZ4rt7C+1v4ir 4W8H6d4v8U2dv4eTRNVm8/n/AGFP20PEuqeN9f8Aib8BP2SfiDqvj8+BtR1SyvP20hpnh7w94l8D Xmv+I9N1vwo0H/BGS68e6jHZfELxNqfxE8JWXxd+Ifxdm+HPiOLTV8A6j4f060ns7zM/Z+/4J7ft efs1fBD4V/s/fDT4S/C2w8B/C261gpewf8FUPi74X8deMtH1w+N7i+8OeIfiD8Ov+CR3gjxf4dsP 7U8bSavFq/wo1b4beMEufD2hWJ8TvoU/ifSPEn9gt5dh8uzyo/FvgPGY2tRynDZbk+By76M+HwU6 v9jzxM82zHOcZySzOnw9isJheHsPwzLIcm/tGrjaeOw3FuWZdllX638o3Xc6UVlmJVOVGNWdedTO OfDYrD4XC0FSWFi5Rr/Wr42OGrLGUPqeGlQw1f23LWq1PqPW/wDgkf4G8TeJk8a+JP2mPiz4g8ZR 2/h6zTxbrf7Kv/BI3VvEyWnhHWLbxF4UtU16/wD+CZ9xqq2/hjxBZ2eu+HoBdiLRdYtLbU9NW2vY Ip1i03/gkR8P9G8S2PjPSP2kvippXjDS9Z8UeI9N8Wab+yj/AMEi7HxLp3iHxvOlz4016x121/4J nRapaaz4vuY47jxRqlvdR32vzxpLqs93IqsPla1/4Jq/HG08ZeJfFcX7Fv7Dn2Pxp8PdZ+H3jTwo f2xbL+z/ABlb+KfGEXjLxlrHi7xgv/BFZfi54n/4Te9W6t/GXgPXPiTffBrxJc6nqnjHU/hjP8Sr 6XxxXCeMP+CSvxg8ReHPhP4N8L/sk/snfCDwZ8IPjzoX7SWh+CvhH+3jd+GPBXiL4qeH/Co8GWus eOPBt/8A8EXtc8L+JoLzQVjs9ahuNIhn1yCKGx1W6utLhisEvCY3MZuhga/0i+DMJgp4X6u5R4I+ jjWwmGwdTLq9Krga+Hh4iRqatUcseGw1DE4KphMRVnLEKlSlh6mtWnSm67eU16svijKriM4/2iWF wqqZfzN4Kbi44mc8K5VF/scVUxFH28Zckv0hsf8Agm7qOl/EaH4w6Z+23+0jp3xbtvCk3gO3+KVj 8Af+CVlp8RoPA9xqsuuz+DIfG9v/AME34/E0XhSbW7ifWJvDqamukSarNLqD2bXcjzN51N/wSB8B T6ro2tN+1D8bY9Q0D4tan8fdLa1/Zu/4JS2dpF8eNXFgL/43XGm2n/BN2DTdR+L7nS9Pkg+Juo2l 342sprWKex1y2mBkP57ePf8Agjt+0L8RfhLD8F9b+DfwNsfCKfDH4LfCe41Hw9+3h4T0Px5feF/g R4o0Txb4LtZ/iNZf8EKV8cQaPLqnh3Rn1P4eadrtj8IormzbXfD/AMO9A8VXd94guvqTSP2KP2v/ AAVYWth8Iv2cf2U/git544Txz8Qrj4X/ALdl3plz8Y7y9msrjxhY/E8+IP8AgjD4kg1Sb4iT6R4f k8aeNtAg8NfFW6Hh7So9G+IOiQi+jvebE/2jluGpV8i+kN4aV82r1sTlU6a4M+j5lOBw/D2EweH/ ALPli8zp8WYjGuOJnmWe4KGT4XKMZh8HClzzxTpZviI4SeZ1ZuNXJcb7GWFoYmrKeLzSpUljZ4Wr Rr4SNF0HCpKjSVDBwxNWtSp1qdWtB+yoUV7f2pP+CQnw7juLa7j/AGj/AIox3dlp/wAQtJs7lP2T v+CRKXFppXxbi1OD4raZbTL/AMEzRJBp/wATYNb1mH4hWcTJbeNItX1OPxJHqSX90Jcq/wD+CO/h y/8Ajx8K/wBpdf25/wBtjSPjJ8Fbf4lW/wANvEPhbR/2DvB2g6EfjHea/qXxVvbv4d+E/wBhrRfh r4l1f4g6t4o1vWvFeueKvCOt6zrOuXcet3l9Jqtjp95a/OHxY/4J5ftcfE3xF8SPF8P7Pn7KmmeJ PiT8ItY+Dupah4x/by8VfHPU7TQ/EXieHxDrN7cfEH45/wDBIT4gfHLxdpn2ZbjRtI+DHj/4v+LP 2X9JtntLv/hQl3eafbyV5b8Uv+CR37RXxa+HviP4Za58E/gT4d8L+Lfhz+zn8Mtfh+HX7felfDyS /wBD/Zk8Wav448CXHk+E/wDgh3pmmW8uoeJNau59T0O206HwT4b0mDS/Cvws8J/Dnwlo+l6Faejl GOzqr9Rr476THAeTf2lh6uS5zClwf4A4zH4Hh/iP2WA4swdWGH40pYTM8Nisnz3iOnjsop5isHny hmGXYytSw2cPEzvFRpSpY+msoxeLvF4qjSq181VHH47D/wBm1sIsQ6mHk6M3XpyaxU6VeeHqZZQq xhPnpOl986H/AMEifAHhjXtE8U+Gv2k/ip4e8T+GvEPjHxd4c8R6H+yj/wAEi9J17w/4r+Itja6X 8QfE+iavYf8ABM631DSvEPjrTbGy07xjrVhcQal4nsbO1tNbub63t4Y03PAH/BLDRfhPD4ut/hZ+ 1p8cPhpb/EDw94f8JePIPAH7M/8AwSa8Gw+NvCnhPRLjw14V8MeLovDv/BNbTU8SeHvDPhy7uvD/ AIf0XWVvdN0bRLm40rTra2sJpIG/MP8Aa8/4JMftv/tGfCDxp8NvAnwp/Yr+HmreNPHPgfxdNrPx J/bA+Kfxs8J6Dp/gvx3F4uXw7oPgLTf+CbHwib7Pqnhfwx8Hvglc3Gu+Kddtx8EfgV8MvCM+mXms WeueKNb9j8Rf8E3P2yNU/aB8QftPeGfA/gT4e/GDWfg5Y/BHS9e0r/gqX8RPiVD4K8Iw+NL7xvqc nhQftH/8Eefjnqk93rF3rXiTQRZ+NdY8Z6B4Z8Ka/Po3gfRfCzaN4Uu/D5WhisfkdJ4z6TXhrWzH NKea4PG5JjuBvAatl+Fjk2J4ezbhv+18wXFWJjXyvNs7zriHHUZZfl2bYzJK/DOOzOtlUsbnGV0c U5OMMU3HKsbNU6OHxkcZDE5spSx9TGVKWIo0o1KEKyrYfCUaGNji6nso151YYZOnOnVqQ9s0L/gk r+yt8RbDXfBXhn9p1/HWl/CnV1+GXiXwloX7LH/BF/xPYfDbX9Gs9f19fh9rug6f/wAE0b638Hav pNh8XvFGtr4Tv7TTr2xs/ifr+pCwih8a6jNqev4j/Yr/AGdP2Q0XX/F3/BRzWv2YI/HUC6auteI/ hb/wRs+CieMbb4eeEFRLBdR1P/gnd4aXxDB4H8A6MqLaia7j8M+ENJVRHZaNYgRcFf8A7Ef7Zusf G3wX8cNc+Bv7Nes6v8PrvWp/CGgXv7eRjTwvaa54I0zwbd6Z4J+KFh/wRWsv2i/hnDJc2N34u1DU /hd8bPBPiTxNrusXei+Mtc8SfDrTPC/gXw/5n4f/AOCa37ZXgr4lfHv4s+AfB/gjwl41/aJ1bwdq XjfVp/8Agp74n+I9/Z2/w/8Ahb4g+FXhDS9L1r4z/wDBGD4l+JNTi0nTtY03xNPrnjnW/GXjHXvF nhLQLnxL4m1nQ7zxdoHil0c0x+YyrUuIPHngjE5dX4fwuZVMnngvo9VaOM4hxWb4SjmGQY/O62Lx qwn1fDUXxRPNaXCOdYTEVcNhMii54qc88wmDpU4ypulkta9HFOnRqOrm0JYfBvDYtUsRRjHDyc6l CMcLgZ0PaYT20cTUqQnQowqU19/fEr9kjWtN8J654s+KP/BSD9q+78IMumTeIdT8Q/Bz/gmT4g0+ 4iug3hvTbjUY2/4Jyai15ALbX59LS5lhmhtNM1O+SSSHTprxq8gt/wBiL4U/Afwp4J0Dw/8At1/H H4feBdXtJ7/wDo/w+/Zl/wCCWdr4PlsJr/Q7qW90Cy8Df8EzJdEtLS8v9c0O/S5t44Ib6W6h1CF5 hBLPD8V/Cj/gkf8AtDfCnW/EmvL8Cf2e/iReeNviB8YPiT42f4tft1+HfHF94j8QfHC70a+8d21v 4kuv+CGlr4w8D6FqlxoyrqmifDHxH4HsvGFhe3Gi/EVPGmiWWhabo/2hdfs3ftmzvpT2/wCzJ+zR p8ej6fBpVjpdv/wVI/aRuvCljp9prFvrNnb+H/AOr/8ABMTU/h/4IMU1tHa31x4A8LeFLvxFaR2g 8VT67daVo11p3i46GFySWGyrKPFvw/4iyarip4rHSy/h36MXDGDaw2FqYXK4yy7HZxmHscXhZvFT jjowzJTwGOoYSnhcvqyx9ShcJVsROpOvluKpSw06lDB1atbOa9Svh6kqFR1oxhF/UlNur7XCe2r8 1aKf1iUIe0r7Phn/AIJx/DXX4fiN4J8JftofF3U9OuPiD4u8Z/FLQNF/Zr/4JMy6Dq/xW8feHPE3 w4+IfirxbBbf8E1P7G1/4ieKfCl/4w+H3xB1q+N/4m1DQ9R8QeEPFVy9lf3+mzch4l/Zl/Zv+Fvx P+LCeMf+Cp2rfDr4z634L0f4t/HNPEvg7/gjV4R+J+r/AA78D6dd+FtA+JvxYXVP+CfWn+K7/wAF +ENJ1i/8OaP408YCXQ9A07VLvSLLUrS2vZreX581X/gm/wDtlazrfg/UdV+Df7Keu2Hhb482vx8k tPEf7W/gvVdTu9Z0Tw/ofhnwn4Y0/W4f+CHunPosHh7RdCtdOg+L8VleftVpapbf2T+0Rol5ZQXt e461+yv+37qWt63q2l/D/wCFPh+1vfN13wzo83/BT34k/EUfD74qSXWnyw/Gfw14s+Nf/BIL4ofE jW/GOnWGlaf4f0fwh8SvG/j74H6N4dtLXStM+EdpDZ2Zt+yrXqwxkPbeM3hznGEzHK5U8dSp4T6O 2W/VcRTx+VVPqeMzLFUczqZlQxGIwVHNaeHpZDChRhg8NVrY2WY5dh8Ljt2+ZuP1HHKNPERnSlKp nEkoV8wxCxDhBLSccLP6xPEOVOdeeKrVfqntlUwU/T/Dn7CvgT406B8Pdb8K/wDBQD4w/FPwn4M8 Raf8bvhFrujfBL/gkv4y8LeH/FPi+4vvFWmfGP4V6za/8E49Q0W01nxJf6lq2t2vxH8F3QutU1W5 1i6TWptQ/tFh9Z/swfseeHf2X18ZR6V8TPGXxGt/GPi+f4hSWfib4Z/sn/C6w0jx9q9rqll4y8cQ af8Asqfs2fs52XiXxh4+tL+0t/Fvib4i2/jbWpotD0xdHvdGE+uf2z1X7L/ww8a/Dn4caDH8TNO0 DSPiPJ4ds9B8V2Hhj4g3nxV0m4utG8VeOdcHiWTx/d/CL4ARa9rvjS58YX/i3xLDpHwT+Gvhzw9r esXnhbwx4fPh7RNM1C9+lK/ljjjxK4szB8R8HVczyPF8NrOMbQp/2fwxwFhniqWCzqtjMNi6Oc8M 5Dg1VliMTF4ypjcrxcMNmDxOJqRnVw2NrRq+ngsFQVPCYmVGdPEqhRk4zq4h+xn7GpFwVKrXrKHs vrOJhCDlN0vbVlGTdScpFFFFfkp6YUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQ SwMEFAAGAAgAAAAhAAnyq354AQAANQMAABEAAABwcHQvdmlld1Byb3BzLnhtbIxSsW7CMBDdK/Uf LO+QEJVAIwJL1YmhErS7ZV+CJce2bAOBr+8laRpoMzDZvrv37r3zrTZ1pcgJnJdG53Q2jSkBzY2Q uszp5/59sqTEB6YFU0ZDTi/g6Wb9/LSy2UnC+cMRJNA+Yzk9hGCzKPL8ABXzU2NBY64wrmIBn66M hGNnJK5UlMRxGlVMavqDd4/gTVFIDm+GHyvQoSNxoFhA8f4gre/Z7CNs1oFHmhZ9J2mN5nQjW321 Fps31gbjQGyhCMRfcVTzNIlpdJvbG9umXl/StE1F/3m8kgIGWr5T4uY1XD1nCtYrlvmaNB8zw38Q eMYtMYYvI2Hs94OzmXGylJrUOZ0sEkouOV3Me1F86FMeUc/Wh8ZHeycIxKngAI27UmKNz2ky6/z0 JV1wuez5BhJUcGupEXRvWJsAfg91GCTcqPnrGt2Oub4Pj7tGJHruFf72wOIRCaWTYmcZx+UkHEe2 wP3EgfNmau0V/xmRp24dvgEAAP//AwBQSwMEFAAGAAgAAAAhANwxL/HyAQAAXgQAABEAAABwcHQv cHJlc1Byb3BzLnhtbKyTzY6bMBCA75X6Dsh3BxsIEBSyssGRKrWrPbQP4IKTWDIY2c5mq6rvXvOT VaK97CFcGLBn5pvPsH1661TwKoyVui8BXiEQiL7RreyPJfj1cw9zEFjH+5Yr3YsS/BEWPO2+ftkO xWCEFb3jzqe+mMAX6m3BS3BybijC0DYn0XG70oPo/dpBm447/2iOYWv4xTfoVBghlIYdlz1Y8s1n 8vXhIBtR6+bceYC5iBFqIrEnOdhrteEz1W7nuEPa+SHtSV/8cOPtmRsztfCewLi2JIbTPtUSpabQ z1sps9tyv8E6HwavXJXAiBb49dDnLRuGQry579aN+T4KzkaW4C+rcJrRuoY5ziOYEJpBwqoKMpqg mMWE0jj7N/bHSaG4FWbsMMv3rz4M3MnGaKsPbtXoLpzNhYO+CDNoOcnDaD6Bkdia4+934v0e+WuG vmk2zeB577GjfU2jFGUQZ3kCE8YopNkmhxmj6zxOGatzcsUebf4QreSVM8o+BH52jBfDE503ffXr w/kgF+aP0rO0YpuEwBTFFUxwEkG68SOkNY4zhDAi0bv0VtqGm/Zbx4+CtdLV3PEHzrAIH9nvDdcx JiiNCPRaCUziaAPJ+J1QSvJ1mkZojdHVcCsO/KzcxFgP8oF4UXQHeC/59ld6Mbv/AAAA//8DAFBL AwQUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAHBwdC90YWJsZVN0eWxlcy54bWwMzEkOgjAYQOG9 iXdo/n0tQ1EkFMIgK3fqASqUIelAaKMS491l+fKSL80/SqKXWOxkNAP/4AESujXdpAcGj3uDY0DW cd1xabRgsAoLebbfpTxxT3lzqxRX69CmaJtwBqNzc0KIbUehuD2YWejt9WZR3G25DKRb+HvTlSSB 5x2J4pMG1ImewTeqgiCitMCny+WIaUgDXHo0xnFU1tW5qf0qLH5Asj8AAAD//wMAUEsDBBQABgAI AAAAIQDusUGrfwIAAK4FAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJxUTW/bMAy9D9h/EHzaDomTNdvaQHFRpC06oGmDxe3OmkTHQmXJkBS3 3a8fZSVOsmQDOp8okn4kHz/o+UulSAPWSaMnybA/SAhoboTUy0nykF/3ThPiPNOCKaNhkryCS86z 9+/o3JoarJfgCEJoN0lK7+txmjpeQsVcH80aLYWxFfP4tMvUFIXkcGn4qgLt00+DwZcUXjxoAaJX d4BJRBw3/n9BheEhP/eYv9aYcEZz45nKZQXZydfhKU23b/rDWOGy08GIplGkF3WtJGceKclmklvj TOHJfZs8mZtnsHMjtafpriMSAg6ran+7bovO7nXPcQugyaI0z+TDaHzykaZHHOmcWba0rC5ddvYZ XbZPulBSACZI07VE74xHxYCmUaA3UgjQayuq9950NpsqWbf+G5EuOFMwRYaygikHCN0p6A2w0P05 k9ZltPHjBrg3ljj5C/s/SshP5iDwOkkaZiXTHvkNbvHRyqp23mY5DgJioy2+W3HXbVeWo2zYOqDw T8eI1VZLcukVuDeEQBYxnYMQQRnLxNj7BMQQ9wW2xB/h42yXjza1yEbMcj0zB0R0lFysvMH1kJww 7xkvw14QU+AOirB2YQQdwe0jGvyzsU9EQIMr5MhuzR0axiEBsXexBZsazaHGYe28QrNiemvbiqn2 NxJ/IzMjQB3/oWR6idELayry7Sq/JmFaO7xd5CqU8pc8rxqjVqG2UKrHpN+cyAK5WUVm7vCCkIWH em8Oupy+x3Emt9LtkbDX8j+afCv1k3uoc3PJPGxWZF9JFyWzIPCWbexbBb3B7bAqgExbwsTG59AQ js1jPL/ZcNQf4NfelY0unIvNoc1+AwAA//8DAFBLAwQUAAYACAAAACEArNMTXn4BAACxAgAAEQAI AWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfJJd T8IwGIXvTfwPS++3rjARllEU0CtNiMyPeNe0L1DZ2qUtIv/ebsCEaLxsz+nTc942G32VRfAJxkqt hohEMQpAcS2kWg7Rc34f9lFgHVOCFVrBEO3AohG9vMh4lXJtYGZ0BcZJsIEnKZvyaohWzlUpxpav oGQ28g7lxYU2JXN+aZa4YnzNloA7cdzDJTgmmGO4BoZVS0QHpOAtstqYogEIjqGAEpSzmEQE/3gd mNL+eaBRTpyldLvKdzrEPWULvhdb95eVrXG73UbbbhPD5yf47fFh3lQNpapnxQHRTPDUSVcAncyn ga8ezPpxJyK34/Dp7iXDrVwbuQHmtKFOq93NBywWBiDiOtqsG+NRrmdeMOse/fMsJIjxjgqj/YQ5 y/BvrbYb+JT109Kk11jatb+2Gcf+bhCBL5jux3FUXruTaX6PaCcmSRhfhSTJSTftkpR03utcZ+fr wvuN8pDuf2IvjK9DMsjjQeqhSXJCPAJok/j8k9FvAAAA//8DAFBLAQItABQABgAIAAAAIQAZRHAA 7wEAANQPAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAGj4dKEFAQAA4gIAAAsAAAAAAAAAAAAAAAAAKAQAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhABRrO4W/AAAANwEAACAAAAAAAAAAAAAAAAAAXgcAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUz LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAKBZxnobAQAA6gIAACAAAAAAAAAAAAAAAAAAWwgAAHBw dC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAIjw2CIbAQAA6gIA ACAAAAAAAAAAAAAAAAAAtAkAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU0LnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhABRrO4W/AAAANwEAACAAAAAAAAAAAAAAAAAADQsAAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGUyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAA CgwAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhABRrO4W/ AAAANwEAACAAAAAAAAAAAAAAAAAABw0AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU2LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhAEe3ZAgtAQAAZQMAACAAAAAAAAAAAAAAAAAABA4AAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGU3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAL4bRHIvAQAAzAIAACAAAAAAAAAA AAAAAAAAbw8AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh AKd0L9lPAQAAdwcAAB8AAAAAAAAAAAAAAAAA3BAAAHBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1s LnJlbHNQSwECLQAUAAYACAAAACEAw7DIFXgCAAB1DQAAFAAAAAAAAAAAAAAAAABwEwAAcHB0L3By ZXNlbnRhdGlvbi54bWxQSwECLQAUAAYACAAAACEAsU7mCu8CAAB4CAAAFQAAAAAAAAAAAAAAAAAa FgAAcHB0L3NsaWRlcy9zbGlkZTEueG1sUEsBAi0AFAAGAAgAAAAhAM6I3WoNCgAA/TwAABUAAAAA AAAAAAAAAAAAPBkAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbFBLAQItABQABgAIAAAAIQDfKiPjrggA ADE3AAAVAAAAAAAAAAAAAAAAAHwjAABwcHQvc2xpZGVzL3NsaWRlMy54bWxQSwECLQAUAAYACAAA ACEA+m9yKzIDAAAbCQAAFQAAAAAAAAAAAAAAAABdLAAAcHB0L3NsaWRlcy9zbGlkZTgueG1sUEsB Ai0AFAAGAAgAAAAhAP7LppyLBAAAzA4AABUAAAAAAAAAAAAAAAAAwi8AAHBwdC9zbGlkZXMvc2xp ZGU0LnhtbFBLAQItABQABgAIAAAAIQC2KzNPRAoAABdIAAAVAAAAAAAAAAAAAAAAAIA0AABwcHQv c2xpZGVzL3NsaWRlNi54bWxQSwECLQAUAAYACAAAACEAC2lONMMEAADFDgAAFQAAAAAAAAAAAAAA AAD3PgAAcHB0L3NsaWRlcy9zbGlkZTcueG1sUEsBAi0AFAAGAAgAAAAhAD2+XfkhCAAAgRgAABUA AAAAAAAAAAAAAAAA7UMAAHBwdC9zbGlkZXMvc2xpZGU1LnhtbFBLAQItABQABgAIAAAAIQDV0ZLx vgAAADcBAAAtAAAAAAAAAAAAAAAAAEFMAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0MTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABK TQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHNQSwECLQAUAAYA CAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABSTgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDIueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAA AAAAAAAAAABaTwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHNQ SwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAABiUAAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDEwLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAA NwEAACwAAAAAAAAAAAAAAAAAa1EAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5 LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAc1IAAHBw dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh ANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAe1MAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQ3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAA AAAAg1QAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAi1UAAHBwdC9zbGlkZUxheW91dHMv X3JlbHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwA AAAAAAAAAAAAAAAAk1YAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAPpRe/SkBwAAIy8AACEAAAAAAAAAAAAAAAAAm1cAAHBwdC9zbGlk ZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQB+pt10PAQAAFEQAAAhAAAA AAAAAAAAAAAAAH5fAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAUAAYA CAAAACEAaaJfIR4BAADHBwAALAAAAAAAAAAAAAAAAAD5YwAAcHB0L3NsaWRlTWFzdGVycy9fcmVs cy9zbGlkZU1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEABW+iTt8CAAAFCAAAIQAAAAAA AAAAAAAAAABhZQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1sUEsBAi0AFAAGAAgA AAAhAILoKFByBQAAgxsAACEAAAAAAAAAAAAAAAAAf2gAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQCX/uIdEgQAALQRAAAhAAAAAAAAAAAAAAAAADBuAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWxQSwECLQAUAAYACAAAACEAwq6OlYoEAACl EAAAIQAAAAAAAAAAAAAAAACBcgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1sUEsB Ai0AFAAGAAgAAAAhAFtItn9MAwAA4goAACEAAAAAAAAAAAAAAAAASncAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQyLnhtbFBLAQItABQABgAIAAAAIQBjL9pi9AQAAA4SAAAhAAAAAAAAAAAA AAAAANV6AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWxQSwECLQAUAAYACAAAACEA pwGSrqQCAACzBgAAIQAAAAAAAAAAAAAAAAAIgAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDcueG1sUEsBAi0AFAAGAAgAAAAhAHFWtUJmAwAAGQsAACIAAAAAAAAAAAAAAAAA64IAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYACAAAACEAgHoiMacEAAB9EQAA IQAAAAAAAAAAAAAAAACRhgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1sUEsBAi0A FAAGAAgAAAAhAJErvBOwAwAA+QsAACIAAAAAAAAAAAAAAAAAd4sAAHBwdC9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQxMS54bWxQSwECLQAUAAYACAAAACEA+c8JOYMGAABcGwAAFAAAAAAAAAAAAAAA AABnjwAAcHB0L3RoZW1lL3RoZW1lMS54bWxQSwECLQAKAAAAAAAAACEAPrVnsgCAAAAAgAAAFwAA AAAAAAAAAAAAAAAclgAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQSwECLQAUAAYACAAAACEACfKr fngBAAA1AwAAEQAAAAAAAAAAAAAAAABRFgEAcHB0L3ZpZXdQcm9wcy54bWxQSwECLQAUAAYACAAA ACEA3DEv8fIBAABeBAAAEQAAAAAAAAAAAAAAAAD4FwEAcHB0L3ByZXNQcm9wcy54bWxQSwECLQAU AAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAAAZGgEAcHB0L3RhYmxlU3R5bGVzLnht bFBLAQItABQABgAIAAAAIQDusUGrfwIAAK4FAAAQAAAAAAAAAAAAAAAAAPYaAQBkb2NQcm9wcy9h cHAueG1sUEsBAi0AFAAGAAgAAAAhAKzTE15+AQAAsQIAABEAAAAAAAAAAAAAAAAAqx4BAGRvY1By b3BzL2NvcmUueG1sUEsFBgAAAAAzADMARA8AAGAhAQAAAA== --_004_9904FB1B0159DA42B0B887B7FA8119CA7524094EAZFFEXMB04globa_-- From nobody Tue Jul 19 04:51:49 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FF812D1B8 for ; Tue, 19 Jul 2016 04:51:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 tyr2BG_cLYTe for ; Tue, 19 Jul 2016 04:51:46 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929B112D1DA for ; Tue, 19 Jul 2016 04:51:42 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id x25so7544396qtx.2 for ; Tue, 19 Jul 2016 04:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BTHQYMDtsswJP4fkKExYE8hxS0T7BzRH8ogsnR+4S4o=; b=lVhEeCPefx6Uyi04yjG3te7CldEAgKfCo76vk8G9lHw9/8Ba0aUykMy1EJlD2YHfCw bJY0uVwEyKVBhHmwnyOzPRQwRapyRYip2e0YCPoYjmAwRP/E4N8bI70MZcGDuW55vADi HN7IUZDJDcn7g9qyfxSMk4WKoS6SrGaAZBNNGAPHC/M7stLsgoHtMcifRXL2W//8T9vE 9PtvNUhGZBAopLHKNeZFadUT+Ug+PXttsnPK1F4xphzZAwyXE3Xlcnxx4n2nWWU4TW/P 3mQwiKWrA+ADanv29PPKlYtPjoEiFgbndmo8y87b1mDWHgjDvcSsLHijsOrdBAhiuRAg l/Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BTHQYMDtsswJP4fkKExYE8hxS0T7BzRH8ogsnR+4S4o=; b=jKJRzSky/WrRaRk4g6fp9RdWtsmzOrxKR2EB1CN7oAqdp/xUQlB9yC6GLTbJMzPOUD D/1PFUcFBooC4rbAHk5OISFnqHwovXbQYLAwzv6v6O40DLdEAIsVnAv8xXcan7zJqpdU WLYuVomvGDU11YEgAf9TrfX9N+UuADj7VUhFzfIKxcrNVS+SA04NELVbwmvRYa0Ngui6 L0VdzU3RZv+DYDlhIELcGKwePrRR2L0scaQKu0EQ6yX5XdyYm0/w1zUIx/Wc6G05KQXZ 35vnQW+aQArmUp5NcFrMaRLQieuiaqn3ud781/0R6Bq9rKvQMKbi9a/rf/J895JRAgIm ISGQ== X-Gm-Message-State: ALyK8tJSlPkt/h+U7f3OExUt8/AIYTHUumdaKAs9jM3JTbxLhv35t7FYRvZv9+UjF6O8FDhpXre5Up7u4YoEKttA X-Received: by 10.237.52.225 with SMTP id x88mr55711994qtd.24.1468929101693; Tue, 19 Jul 2016 04:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.176.199 with HTTP; Tue, 19 Jul 2016 04:51:12 -0700 (PDT) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA7524094E@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA7524094E@AZ-FFEXMB04.global.avaya.com> From: Warren Kumari Date: Tue, 19 Jul 2016 13:51:12 +0200 Message-ID: To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] auto attachment presentation X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:51:48 -0000 I've posted these. Thanks Dan (and everyone), W On Tue, Jul 19, 2016 at 11:16 AM, Romascanu, Dan (Dan) wrote: > Hi, > > > > Please find attached an updated auto-attach presentations > > > > - Slides in the right order (!) > > - Links to the open source implementations > > > > Regards, > > > > Dan > > > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Jul 19 08:53:40 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A69712DB5C; Tue, 19 Jul 2016 08:53:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iLN2AM0WLOtM; Tue, 19 Jul 2016 08:53:30 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1524412DC62; Tue, 19 Jul 2016 08:43:49 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6JFeIE7005393; Tue, 19 Jul 2016 08:43:47 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0b-0016f401.pphosted.com with ESMTP id 2494s94wyw-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Jul 2016 08:43:46 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Jul 2016 18:43:44 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Tue, 19 Jul 2016 18:43:44 +0300 From: Tal Mizrahi To: "Sashank Dara (sadara)" , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAA== Date: Tue, 19 Jul 2016 15:43:43 +0000 Message-ID: <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_30883664facc48a5b1c4030c8ee9c81eILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-19_10:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607190167 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:53:36 -0000 --_000_30883664facc48a5b1c4030c8ee9c81eILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_30883664facc48a5b1c4030c8ee9c81eILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

To summarize my take on t= his thread:

The proposed mechanism ha= s two significant vulnerabilities that (in my understanding) are currently = not addressed:

1.&nbs= p;      A man-in-the-middle can replace the POT of packet A with the POT of= packet B.

2.&nbs= p;      It is possible to replay POTs within a certain time window, whose l= ength is determined by the timestamp resolution.

 <= /p>

Sashank, thanks for agree= ing to look into it further. I am looking forward to your insights on this.=

 <= /p>

Regards,

Tal.

 <= /p>

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 <= /p>

 <= /p>

 

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-o= f-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (in= dicating the path through 1,3,5,6) to packet B, will the verifier accept pa= cket B and believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is pro= grammed to just validate the POT meta data against {1,3,5,6} then yes it ac= cepts it. 

If the verifier is programm= ed to consult a policy database to cross check if the reconstructed path {1= ,3,5,6} is as per the policies then no , it drops it . 

 

But I see your point , that= the parameters used in POT data donot consider the path or node-ids etc . = We shall discuss this internally and get back.

 

Also, We shall get back wit= h more concrete numbers of the timestamp resolution and cache sizes (or oth= er better approaches). 

 

Thank you so much for all t= he inputs. 

 

 

 

From: Tal Mizr= ahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brock= ners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,<= /span>

 <= /p>

I really appreciate the q= uick and detailed responses.

 <= /p>

>>>Lets take correct path taken = by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g= . the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only = constructs the path the packet took accurately, it is upto

>the application to dete= rmine whether it violates any policies (I.e missing any function) 

>The bottom line is , an= attacker taking a different path cannot get away with it !

>The whole intent of = 220;proof-of-transit” is to prove the path packet has taken exactly.&= nbsp;

>POT does not define whe= ther it good/bad path. It is upto high level applications on what

>do with “reconstr= ucted” path. 

 <= /p>

 <= /p>

 <= /p>

I want to ask a simple qu= estion:

If the attacker attaches = the POT of packet A (indicating the path through 1,3,5,6) to packet B, will= the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 <= /p>

 <= /p>

>>Hmmm… Let’s say we = are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could use = as much precision as we want to reduce the number of values to be cached !

 <= /p>

My point is that assuming= reasonable resources are used, the mechanism is vulnerable to a replay att= ack.

In order to prove me wron= g, can you present concrete numbers of the timestamp resolution and the cac= he size?

Otherwise, you may consid= er using a sequence number + sliding window (e.g., as in IPsec).

 <= /p>

 <= /p>

Thanks,=

Tal.

 <= /p>

 <= /p>

 <= /p>

 

 

 

 

>[SD] Ok. This is an interesting attac= k.  

> 

>Lets take correct path taken by Packe= t A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Pack= et B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values fro= m Path1 and reattach them to Path2 ,

>the reconstruction for PacketB w= ould result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/= policy db information for any policy

>violations. POT does not enforce a pa= rticular path to be taken.

 

So packet B skipped node 5 (e.g. the fi= rewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only cons= tructs the path the packet took accurately, it is upto the application to d= etermine whether it violates any policies (I.e missing any function) 

The bottom line is , an att= acker taking a different path cannot get away with it ! The whole intent of= “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whether= it good/bad path. It is upto high level applications on what do with ̶= 0;reconstructed” path. 

 

 

Hmmm… Let’s say we are talk= ing about traffic at 10 Gbps, which is roughly 1 million packets per second= . That would mean the verifier has to store a million values of RND-2.

Moreover, every time a packet arrives, = the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we could use as m= uch precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 =

 

We have two consecutive packets, A and = B:

- Packet A that went through the correc= t path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also terminates packet A.<= /span>

There is no replay here, because the ve= rifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the veri= fier, even though it did not go through the correct path.

 

Is there a way to mitigate this attack?=

 =

[SD] Ok. This is an interesting attack. &= nbsp;

 =

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B= i.e. Path2 -  (1,2,3,6).

 =

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/poli= cy db information for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular= path taken by the packets. 

 =

Do you mean that there is a one-second-= vulnerability for replay attacks?

One second is practically forever.

 =

[SD] Not really , the verifier could cach= e the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such= , if the verifier caches those values. 

 =

Effective replay prevention is typicall= y performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to incorporat= e such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high le= vel sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that’s reason we recommend using &n= bsp;( Timestamp(/ sequence number) + RND )

 

 =

 =

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. = More inline with [SD] .. 

 =

 =

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 =

[SD] This is valid scenario and we have c= ertain in-built mitigation techniques and recommendations for the same. 

There are two scenarios here =

 =

Partial Replay of POT data (Replaying = intermediate CMLs)=

 =

Attacker cannot reuse few intermediate no= de’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker tries t= o replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and particip= ates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never = on wire , so attacker cannot just observe the packet traces to reuse and replay it. <= /p>

 =

Total Replay of POT data (Replaying co= mplete RND-2)

 =

Another trick, attacker could do is by co= mpletely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Atta= cks” , we recommend that the RND-2 (generated per packet) be a combin= ation (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to re= play one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 =

There is still a small window , where the= attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is= 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within= such a small time at such a high packet rates. 

 =

Also , the verifier could cache, if neede= d, certain number of previously used RND-2 to mitigate replay attacks. 

 =

Hope this clarifies. 

 =

--_000_30883664facc48a5b1c4030c8ee9c81eILEXCH02marvellcom_-- From nobody Tue Jul 19 09:07:30 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D52B12D5EC; Tue, 19 Jul 2016 09:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 SnzIgZCxWA0D; Tue, 19 Jul 2016 09:07:20 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7D712B02E; Tue, 19 Jul 2016 08:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=79104; q=dns/txt; s=iport; t=1468943992; x=1470153592; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lIjuQX46C8AOUd/eGZ08IsOQk0iVFbr5NfQYPIQwx7Y=; b=TRoMrbVll0ErV1BLo0JsNHd6kDYfOQb/q5Y6hgmfFmX0BZ4oHoQWK4i+ p2b4GD92s6JBLzGOoNRa8Tr4u9vNHLHUVB+AZKA4E2Azz/vikxjQ4f+zk OXHtgbLvUDVXTADkLoVQrv83LE3eY7Puw5csv2gDY7358fJJi1tWUE0q5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAgCDTY5X/40NJK1dgnFOVnwGuGWBe?= =?us-ascii?q?iKFeAKBMDgUAQEBAQEBAWUnhFwBAQUaEzoSEAIBCBEEAQEhAQYHMhQJCAIEAQ0?= =?us-ascii?q?FCBMEiBEOvGoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqhE2EdoUlBYgii0GFQ?= =?us-ascii?q?QGGEoJ7gnOCWoIJjTWQHQEeNoILHIFMboZjKxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,390,1464652800"; d="scan'208,217";a="298164813" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2016 15:59:50 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6JFxobi005835 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 15:59:50 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 10:59:49 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Tue, 19 Jul 2016 10:59:49 -0500 From: "Frank Brockners (fbrockne)" To: Tal Mizrahi , "Sashank Dara (sadara)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddw Date: Tue, 19 Jul 2016 15:59:49 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.244.97] Content-Type: multipart/alternative; boundary="_000_e45909b5c7924e11a1702c2aee1253eaXCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:07:25 -0000 --_000_e45909b5c7924e11a1702c2aee1253eaXCHRCD008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) ; Frank Brockners (fbrockne) ; draft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_e45909b5c7924e11a1702c2aee1253eaXCHRCD008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal,

 = ;

thanks for the summary. We’ll provide more details on 2. Per my = earlier point – 1. is an interesting discussion, given that we don’t claim to provide integrity protection for the packet p= ayload. Or in other terms – to be exact: What POT provides is a proof= that the POT-header/meta-data transited all the required nodes. There is n= o association (and thus proof) provided for the additional data carried along with the POT-header – neither head= er nor payload. As a consequence, attacks which change the packet payload w= on’t be detected/mitigated. We’ll explicitly state this in the = security considerations in the next rev of the document.

What we could consider is linking the RND number to CRC across the pac= ket payload or similar – but that way we’d restrict the applicability to deployments where the packet payload isn’t chan= ged across the path (which might not apply to certain deployment – e.= g. WAN optimization / compression schemes).

Do you think it is worthwhile to provide a solution for a deployment w= hich is expected to not alter the packet payload?

 

Thanks,

Frank

 

From: = Tal Mizrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sadara@cisco.com>; Frank Brockners = (fbrockne) <fbrockne@cisco.com>; draft-brockners-proof-of-transit@too= ls.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,<= /p>

 

To summarize my take o= n this thread:

The proposed mechanism= has two significant vulnerabilities that (in my understanding) are current= ly not addressed:

1.&= nbsp;      A man-in-the-m= iddle can replace the POT of packet A with the POT of packet B.<= /span>

2.&= nbsp;      It is possible= to replay POTs within a certain time window, whose length is determined by= the timestamp resolution.

 

Sashank, thanks for ag= reeing to look into it further. I am looking forward to your insights on th= is.

 

Regards,

Tal.=

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 

 

 

From: Sa= shank Dara (sadara) [mailto:sadara@cisc= o.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 =

I want to ask a simple question:

If the attacker attaches the POT of packet A = (indicating the path through 1,3,5,6) to packet B, will the verifier accept= packet B and believe that its path was indeed (1,3,5,6)?

 =

[SD] If the verifier is = programmed to just validate the POT meta data against {1,3,5,6} then yes it= accepts it. 

If the verifier is progr= ammed to consult a policy database to cross check if the reconstructed path= {1,3,5,6} is as per the policies then no , it drops it . 

 =

But I see your point , t= hat the parameters used in POT data donot consider the path or node-ids etc= . We shall discuss this internally and get back.

 =

Also, We shall get back = with more concrete numbers of the timestamp resolution and cache sizes (or = other better approaches). 

 =

Thank you so much for al= l the inputs. 

 

 

 

From: Ta= l Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate th= e quick and detailed responses.

 

>>>Lets take correct path tak= en by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (= e.g. the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier on= ly constructs the path the packet took accurately, it is upto

>the application to d= etermine whether it violates any policies (I.e missing any function) <= o:p>

>The bottom line is ,= an attacker taking a different path cannot get away with it !

>The whole intent of = “proof-of-transit” is to prove the path packet has taken exactl= y. 

>POT does not define = whether it good/bad path. It is upto high level applications on what

>do with “recon= structed” path. 

 

 

 

I want to ask a simple= question:

If the attacker attach= es the POT of packet A (indicating the path through 1,3,5,6) to packet B, w= ill the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 

 

>>Hmmm… Let’s say = we are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could u= se as much precision as we want to reduce the number of values to be cached !

 

My point is that assum= ing reasonable resources are used, the mechanism is vulnerable to a replay = attack.

In order to prove me w= rong, can you present concrete numbers of the timestamp resolution and the = cache size?

Otherwise, you may con= sider using a sequence number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.=

 

 

 

From: Sa= shank Dara (sadara) [mailto:sadara@cisc= o.com]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 

 

>[SD] Ok. This is an interesting at= tack.  

> 

>Lets take correct path taken by Pa= cket A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be P= acket B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values = from Path1 and reattach them to Path2 ,

>the reconstruction for Packet= B would result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topolo= gy/policy db information for any policy

>violations. POT does not enforce a= particular path to be taken.

 

So packet B skipped node 5 (e.g. the= firewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only c= onstructs the path the packet took accurately, it is upto the application t= o determine whether it violates any policies (I.e missing any function) 

The bottom line is , an = attacker taking a different path cannot get away with it ! The whole intent= of “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whet= her it good/bad path. It is upto high level applications on what do with &#= 8220;reconstructed” path. 

 =

 

Hmmm… Let’s say we are t= alking about traffic at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of = RND-2.

Moreover, every time a packet arrive= s, the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.=

Am I missing something here?<= span lang=3D"EN-US" style=3D"font-size:10.5pt;color:black">

 

[SD] Second level precision is only an example, we could use a= s much precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A a= nd B:

- Packet A that went through the cor= rect path and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 Now the attacker performs a ‘mix = and match’ attack, by taking the correct POT from packet A and attach= ing it to packet B.<= /o:p>

The attacker also terminates packet = A.

There is no replay here, because the= verifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the v= erifier, even though it did not go through the correct path.<= /p>

 

Is there a way to mitigate this atta= ck?

 

[SD] Ok. This is an interesting attack= .  

 

Lets take correct path taken by Packet= A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packe= t B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/p= olicy db information for any policy violations. POT does not enforce a particular path to be taken.

 It just reconstructs the particu= lar path taken by the packets. 

 

Do you mean that there is a one-seco= nd-vulnerability for replay attacks?

One second is practically forever.

 

[SD] Not really , the verifier could c= ache the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerabil= ity as such, if the verifier caches those values. 

 

Effective replay prevention is typic= ally performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to inc= orporate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high= level sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential anal= ysis of CML values (across packets) becomes very easy  and predictable= .

that’s reason we recommend using=  ( Timestamp(/ sequence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our wor= k. More inline with [SD] .. 

 

 

Right, I am referring to the former. The inte= grity check is not the issue.

Let’s say we have:

- Packet A that went through the correct path= and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 

The attacker can ‘launder’ packet= B by replacing the (incorrect) POT of packet B with the correct POT of pac= ket A (and drop packet A).

Thus, packet B is verified correctly, even th= ough it did not go through the correct path.

 

[SD] This is valid scenario and we hav= e certain in-built mitigation techniques and recommendations for the same. =

There are two scenarios here 

 

Partial Replay of POT data (Replayi= ng intermediate CMLs)=

 

Attacker cannot reuse few intermediate= node’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker trie= s to replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and = participates in the reconstruction of RND-3.

Verifier’s share of RND-3 is nev= er on wire , so attacker cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying= complete RND-2)=

 

Another trick, attacker could do is by= completely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply A= ttacks” , we recommend that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D “Time Stamp + RND number”)=

So in case a passive attacker tries to= replay one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved fr= om RND-2.

If the retrieved timestamp is older th= an current timestamp we drop/raise a flag ! 

 

There is still a small window , where = the attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearl= y impossible for the attacker to replay.

For example , if the Time Stamp chosen= is 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay= within such a small time at such a high packet rates. 

 

Also , the verifier could cache, if ne= eded, certain number of previously used RND-2 to mitigate replay attacks. 

 

Hope this clarifies. 

 

--_000_e45909b5c7924e11a1702c2aee1253eaXCHRCD008ciscocom_-- From nobody Tue Jul 19 09:49:22 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA4412B03A; Tue, 19 Jul 2016 09:49: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 R7Cp2HxAzyZB; Tue, 19 Jul 2016 09:49:15 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB27512D0AB; Tue, 19 Jul 2016 09:49:14 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6JGAewc025121; Tue, 19 Jul 2016 09:14:35 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 2494s955ea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Jul 2016 09:14:34 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Jul 2016 19:14:31 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Tue, 19 Jul 2016 19:14:30 +0300 From: Tal Mizrahi To: "Frank Brockners (fbrockne)" , "Sashank Dara (sadara)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tA= Date: Tue, 19 Jul 2016 16:14:30 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_fe81bb4d38414067bbd78f65f8f7aae7ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-19_10:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607190172 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:49:18 -0000 --_000_fe81bb4d38414067bbd78f65f8f7aae7ILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank, The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_fe81bb4d38414067bbd78f65f8f7aae7ILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Frank,

 <= /p>

The POT replacement attac= k (1.) is not an attack on the integrity. It is an attack on the path verif= ication.

This simple attack can ca= use the verifier to accept a packet that did not go through the firewall SF= (even though it should). I believe this is exactly the problem you were aiming to address in this draft.

 <= /p>

Thanks,=

Tal.

 <= /p>

From: Frank Br= ockners (fbrockne) [mailto:fbrockne@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-tra= nsit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,<= /o:p>

 

thanks for the summary. W= e’ll provide more details on 2. Per my earlier point – 1. is an= interesting discussion, given that we don’t claim to provide integri= ty protection for the packet payload. Or in other terms – to be exact: = What POT provides is a proof that the POT-header/meta-data transited all th= e required nodes. There is no association (and thus proof) provided for the= additional data carried along with the POT-header – neither header nor payload. As a consequence, attacks w= hich change the packet payload won’t be detected/mitigated. We’= ll explicitly state this in the security considerations in the next rev of = the document.

What we could consider is= linking the RND number to CRC across the packet payload or similar –= but that way we’d restrict the applicability to deployments where the packet payload isn’t changed across the path (which might not ap= ply to certain deployment – e.g. WAN optimization / compression schem= es).

Do you think it is worthw= hile to provide a solution for a deployment which is expected to not alter = the packet payload?

 <= /p>

Thanks,=

Frank

 <= /p>

From: Tal Mi= zrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,

 <= /p>

To summarize my take on t= his thread:

The proposed mechanism ha= s two significant vulnerabilities that (in my understanding) are currently = not addressed:

1. &n= bsp;     A man-in-the-middle can replace the POT o= f packet A with the POT of packet B.

2. &n= bsp;     It is possible to replay POTs within a ce= rtain time window, whose length is determined by the timestamp resolution.<= o:p>

 <= /p>

Sashank, thanks for agree= ing to look into it further. I am looking forward to your insights on this.=

 <= /p>

Regards,

Tal.

 <= /p>

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 <= /p>

 <= /p>

 

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com<= /a>]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (in= dicating the path through 1,3,5,6) to packet B, will the verifier accept pa= cket B and believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is pro= grammed to just validate the POT meta data against {1,3,5,6} then yes it ac= cepts it. 

If the verifier is programm= ed to consult a policy database to cross check if the reconstructed path {1= ,3,5,6} is as per the policies then no , it drops it . 

 

But I see your point , that= the parameters used in POT data donot consider the path or node-ids etc . = We shall discuss this internally and get back.

 

Also, We shall get back wit= h more concrete numbers of the timestamp resolution and cache sizes (or oth= er better approaches). 

 

Thank you so much for all t= he inputs. 

 

 

 

From: Tal Mizr= ahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,<= /span>

 <= /p>

I really appreciate the q= uick and detailed responses.

 <= /p>

>>>Lets take correct path taken = by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g= . the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only = constructs the path the packet took accurately, it is upto

>the application to dete= rmine whether it violates any policies (I.e missing any function) 

>The bottom line is , an= attacker taking a different path cannot get away with it !

>The whole intent of = 220;proof-of-transit” is to prove the path packet has taken exactly.&= nbsp;

>POT does not define whe= ther it good/bad path. It is upto high level applications on what

>do with “reconstr= ucted” path. 

 <= /p>

 <= /p>

 <= /p>

I want to ask a simple qu= estion:

If the attacker attaches = the POT of packet A (indicating the path through 1,3,5,6) to packet B, will= the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 <= /p>

 <= /p>

>>Hmmm… Let’s say we = are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could use = as much precision as we want to reduce the number of values to be cached !

 <= /p>

My point is that assuming= reasonable resources are used, the mechanism is vulnerable to a replay att= ack.

In order to prove me wron= g, can you present concrete numbers of the timestamp resolution and the cac= he size?

Otherwise, you may consid= er using a sequence number + sliding window (e.g., as in IPsec).

 <= /p>

 <= /p>

Thanks,=

Tal.

 <= /p>

 <= /p>

 <= /p>

 

 

 

 

>[SD] Ok. This is an interesting attac= k.  

> 

>Lets take correct path taken by Packe= t A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Pack= et B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values fro= m Path1 and reattach them to Path2 ,

>the reconstruction for PacketB w= ould result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/= policy db information for any policy

>violations. POT does not enforce a pa= rticular path to be taken.

 

So packet B skipped node 5 (e.g. the fi= rewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only cons= tructs the path the packet took accurately, it is upto the application to d= etermine whether it violates any policies (I.e missing any function) 

The bottom line is , an att= acker taking a different path cannot get away with it ! The whole intent of= “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whether= it good/bad path. It is upto high level applications on what do with ̶= 0;reconstructed” path. 

 

 

Hmmm… Let’s say we are talk= ing about traffic at 10 Gbps, which is roughly 1 million packets per second= . That would mean the verifier has to store a million values of RND-2.

Moreover, every time a packet arrives, = the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we could use as m= uch precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 =

 

We have two consecutive packets, A and = B:

- Packet A that went through the correc= t path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also terminates packet A.<= /span>

There is no replay here, because the ve= rifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the veri= fier, even though it did not go through the correct path.

 

Is there a way to mitigate this attack?=

 =

[SD] Ok. This is an interesting attack. &= nbsp;

 =

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B= i.e. Path2 -  (1,2,3,6).

 =

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/poli= cy db information for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular= path taken by the packets. 

 =

Do you mean that there is a one-second-= vulnerability for replay attacks?

One second is practically forever.

 =

[SD] Not really , the verifier could cach= e the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such= , if the verifier caches those values. 

 =

Effective replay prevention is typicall= y performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to incorporat= e such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high le= vel sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that’s reason we recommend using &n= bsp;( Timestamp(/ sequence number) + RND )

 

 =

 =

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. = More inline with [SD] .. 

 =

 =

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 =

[SD] This is valid scenario and we have c= ertain in-built mitigation techniques and recommendations for the same. 

There are two scenarios here =

 =

Partial Replay of POT data (Replaying = intermediate CMLs)=

 =

Attacker cannot reuse few intermediate no= de’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker tries t= o replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and particip= ates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never = on wire , so attacker cannot just observe the packet traces to reuse and replay it. <= /p>

 =

Total Replay of POT data (Replaying co= mplete RND-2)

 =

Another trick, attacker could do is by co= mpletely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Atta= cks” , we recommend that the RND-2 (generated per packet) be a combin= ation (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to re= play one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 =

There is still a small window , where the= attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is= 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within= such a small time at such a high packet rates. 

 =

Also , the verifier could cache, if neede= d, certain number of previously used RND-2 to mitigate replay attacks. 

 =

Hope this clarifies. 

 =

--_000_fe81bb4d38414067bbd78f65f8f7aae7ILEXCH02marvellcom_-- From nobody Tue Jul 19 11:00:27 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B209A127077 for ; Tue, 19 Jul 2016 11:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 MV8lcIiunTpz for ; Tue, 19 Jul 2016 11:00: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 0E7CC12D0A7 for ; Tue, 19 Jul 2016 11:00:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNY43237; Tue, 19 Jul 2016 18:00:14 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 19 Jul 2016 19:00:12 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.179]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 20 Jul 2016 01:59:59 +0800 From: Qin Wu To: "adrian@olddog.co.uk" , "'opsawg@ietf.org'" Thread-Topic: [OPSAWG] BTW draft-wu-opsawg-service-model-explained now at rev -01 Thread-Index: AdHhmTA9zNfQcrkaQrOlQpjRSyXPVQATMNeg Date: Tue, 19 Jul 2016 17:59:59 +0000 Message-ID: References: <0ac101d1e199$3a03d2b0$ae0b7810$@olddog.co.uk> In-Reply-To: <0ac101d1e199$3a03d2b0$ae0b7810$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.219.38] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA853A855Dnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.578E6AAF.002E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.179, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 689addb9b55b97693dd935507905f369 Archived-At: Subject: Re: [OPSAWG] BTW draft-wu-opsawg-service-model-explained now at rev -01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 18:00:27 -0000 --_000_B8F9A780D330094D99AF023C5877DABA853A855Dnkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXhhY3RseSwgdGhpcyB3YXMgd2hhdCBJIHN0cmVzc2VkIGluIHRoZSB0b2RheeKAmXMgbWVldGlu ZywgdG8gY2xhcmlmeSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBtb2RlbCB3aGljaCBpcyB1 c2VkIGJldHdlZW4gY3VzdG9tZXIgYW5kIHNlcnZpY2Ugb3JjaGVzdHJhdG9yIGFuZCB0aGUgbW9k ZWwgdXNlZCBiZXR3ZWVuIE9TUy9CU1MgYW5kIG5ldHdvcmsgb3JjaGVzdHJhdG9yLg0KRXZlbiB0 aGUgbW9kZWwgdXNlZCBiZXR3ZWVuIGN1c3RvbWVyIGFuZCBzZXJ2aWNlIG9yY2hlc3RyYXRvciBh bmQgdGhlIG1vZGVsIHVzZWQgYmV0d2VlbiBzZXJ2aWNlIG9yY2hlc3RyYXRvciBhbmQgbmV0d29y ayBvcmNoZXN0cmF0b3IgZG9lc27igJl0IG5lZWQgdG8gYmUgc2FtZS4NCg0KLVFpbg0K5Y+R5Lu2 5Lq6OiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEFkcmlh biBGYXJyZWwNCuWPkemAgeaXtumXtDogMjAxNuW5tDfmnIgxOeaXpSAxNjo0MQ0K5pS25Lu25Lq6 OiAnb3BzYXdnQGlldGYub3JnJw0K5Li76aKYOiBbT1BTQVdHXSBCVFcgZHJhZnQtd3Utb3BzYXdn LXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkIG5vdyBhdCByZXYgLTAxDQoNCldlIG9ubHkgbWFkZSBh IHNtYWxsIGNoYW5nZSwgYnV0IG9uZSB0aGluZyB3ZSBkaWQgd2FzIHRyeSB0byBoaWdobGlnaHQg YSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSBtb2RlbCBvbiB0aGUgaW50ZXJmYWNlIGJldHdlZW4g Y3VzdG9tZXIgYW5kIG9wZXJhdG9yIChhIGxhIEwzU00pIGFuZCB0aGUgbW9kZWwgb24gdGhlIGlu dGVyZmFjZSBiZXR3ZWVuIE9TUy9CU1MvZXRjLiBhbmQgbmV0d29yayBvcmNoZXN0cmF0b3IgKHdo aWNoIGlzIHdoYXQgd2Ugc2VlIGFzIFlBTkcgbW9kZWxzIGluIEJFU1MsIGZvciBleGFtcGxlKS4N Cg0KSGF2ZSBhIGxvb2sgYXQgRmlndXJlIDMuDQoNCkFkcmlhbg0KDQpGcm9tOiBPUFNBV0cgW21h aWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwN ClNlbnQ6IDE5IEp1bHkgMjAxNiAwOToyOA0KVG86ICdCZW5vaXQgQ2xhaXNlJzsgJ1FpbiBXdSc7 ICdvcHNhd2dAaWV0Zi5vcmcnDQpTdWJqZWN0OiBSZTogW09QU0FXR10gTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQtMDAu dHh0DQoNCkJlbm9pdCwNCg0KSSB0aGluayB0aGF0IHlvdSBtZWFuIHRvIHNheSAiaXMgKmFuKiBv YmplY3RpdmUgb2YiLiBUaGF0IGlzLCB0aGUgZHJhZnQgeW91IHBvaW50IGF0IGhhcyBhIGZhciB3 aWRlciBzY29wZSBhbmQgcHVycG9zZS4NCg0KTm8gcHJvYmxlbSB3aXRoIHRoYXQuDQoNCkRvaW5n IG91ciB3b3JrIGluIEwzU00gd2UgcmVwZWF0ZWRseSBlbmNvdW50ZXJlZCBjb25mdXNpb24gYWJv dXQgd2hhdCBhIHNlcnZpY2UgbW9kZWwgaXMgYW5kIHdoZXJlIGl0IGZpdHMgaW4gdGhlICJoaWVy YXJjaHkiLiBTbyB3ZSB3cm90ZSBzb21lIHRleHQuDQoNCkxvb2tpbmcgYXQgb3VyIGRyYWZ0IGFu ZCBGaWd1cmUgMSBpbiB0aGUgeWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbiB0aGVyZSBpcyBub3Qg Y29tcGxldGUgY29oZXJlbmNlLg0KDQpXaGljaCB3YXkgd291bGQgbGlrZSB0byBnbyBmb3J3YXJk Pw0KUm9sbCBvdXIgdGV4dCBpbnRvIHlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24/DQpQdXNoIGZv cndhcmQgc2VwYXJhdGVseT8NCg0KQWRyaWFuDQoNCkZyb206IE9QU0FXRyBbbWFpbHRvOm9wc2F3 Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVub2l0IENsYWlzZQ0KU2VudDogMTkg SnVseSAyMDE2IDA5OjE4DQpUbzogUWluIFd1OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3 Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT1BTQVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMC50eHQNCg0K UWluLA0KDQpFeHBsYWluaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSBzZXJ2aWNlIGFuZCBu ZXR3b3JrIGVsZW1lbnQgWUFORyBtb2R1bGVzIGlzIHRoZSBvYmplY3RpdmUgb2YgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1jbGFz c2lmaWNhdGlvbi8NCg0KQWJzdHJhY3QNCg0KDQoNCiAgIFRoZSBZQU5HIFtSRkM2MDIwXSBkYXRh IG1vZGVsaW5nIGxhbmd1YWdlIGlzIGN1cnJlbnRseSBiZWluZw0KDQogICBjb25zaWRlcmVkIGZv ciBhIHdpZGUgdmFyaWV0eSBvZiBhcHBsaWNhdGlvbnMgdGhyb3VnaG91dCB0aGUNCg0KICAgbmV0 d29ya2luZyBpbmR1c3RyeSBhdCBsYXJnZS4gIE1hbnkgc3RhbmRhcmRzLWRlZmluaW5nIG9yZ2Fu aXphdGlvbnMNCg0KICAgKFNET3MpLCBvcGVuIHNvdXJjZSBzb2Z0d2FyZSBwcm9qZWN0cywgdmVu ZG9ycyBhbmQgdXNlcnMgYXJlIHVzaW5nDQoNCiAgIFlBTkcgdG8gZGV2ZWxvcCBhbmQgcHVibGlz aCBZQU5HIG1vZHVsZXMgb2YgY29uZmlndXJhdGlvbiwgc3RhdGUgZGF0YQ0KDQogICBhbmQgb3Bl cmF0aW9ucyBmb3IgYSB3aWRlIHZhcmlldHkgb2YgYXBwbGljYXRpb25zLiAgQXQgdGhlIHNhbWUg dGltZSwNCg0KICAgdGhlcmUgaXMgY3VycmVudGx5IG5vIHdlbGwta25vd24gdGVybWlub2xvZ3kg dG8gY2F0ZWdvcml6ZSB2YXJpb3VzDQoNCiAgIHR5cGVzIG9mIFlBTkcgbW9kdWxlcy4NCg0KDQoN CiAgIEEgY29uc2lzdGVudCB0ZXJtaW5vbG9neSB3b3VsZCBoZWxwIHdpdGggdGhlIGNhdGVnb3Jp emF0aW9uIG9mIFlBTkcNCg0KICAgbW9kdWxlcywgYXNzaXN0IGluIHRoZSBhbmFseXNpcyB0aGUg WUFORyBkYXRhIG1vZGVsaW5nIGVmZm9ydHMgaW4gdGhlDQoNCiAgIElFVEYgYW5kIG90aGVyIG9y Z2FuaXphdGlvbnMsIGFuZCBicmluZyBjbGFyaXR5IHRvIHRoZSBZQU5HLXJlbGF0ZWQNCg0KICAg ZGlzY3Vzc2lvbnMgYmV0d2VlbiB0aGUgZGlmZmVyZW50IGdyb3Vwcy4NCg0KDQoNCiAgIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2V0IG9mIGNvbmNlcHRzIGFuZCBhc3NvY2lhdGVkIHRlcm1z IHRvDQoNCiAgIHN1cHBvcnQgY29uc2lzdGVudCBjbGFzc2lmaWNhdGlvbiBvZiBZQU5HIG1vZHVs ZXMuDQpSZWdhcmRzLCBCZW5vaXQNCg0KSGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IEkt RCB0aGF0IGRpc2N1c3NlcyB0aGUgc2NvcGUgYW5kIHB1cnBvc2Ugb2Ygc2VydmljZSBtb2RlbHMg d2l0aGluDQoNCnRoZSBJRVRGIGFuZCBkZXNjcmliZXMgaG93IGEgc2VydmljZSBtb2RlbCBjYW4g YmUgdXNlZCBieSBhIG5ldHdvcmsNCg0Kb3BlcmF0b3IuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC8NCg0K DQoNCkluIGFkZGl0aW9uLCB0aGlzIGRyYWZ0IGNsYXJpZmllcyB0aGUgcm9sZSBhbmQgcG9zaXRp b24gb2Ygc2VydmljZSBtb2RlbCBpbiB0aGUgU0ROIGFyY2hpdGVjdHVyZSBhbmQNCg0KQ2xlYXIg c2V2ZXJhbCBtaXNjb25jZXB0aW9uIG9uIHRoZSBzZXJ2aWNlIG1vZGVsLg0KDQoNCg0KWW91ciBx dWVzdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQoNCg0KUmVnYXJkcyENCg0KLVFp bg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQoNCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXQ0KDQrlj5HpgIHml7bpl7Q6IDIwMTblubQ35pyINeaXpSAxOTo1 NQ0KDQrmlLbku7bkuro6IExpdXNodWNoZW5nIChXaWxsKTsgQWRyaWFuIEZhcnJlbDsgTGl1c2h1 Y2hlbmcgKFdpbGwpOyBRaW4gV3UNCg0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMC50eHQNCg0KDQoN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwt ZXhwbGFpbmVkLTAwLnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFFp biBXdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCg0KDQpOYW1lOiAgICAg ICAgICBkcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQNCg0KUmV2aXNpb246 ICAgICAgMDANCg0KVGl0bGU6ICAgICAgICAgU2VydmljZSBNb2RlbHMgRXhwbGFpbmVkDQoNCkRv Y3VtZW50IGRhdGU6IDIwMTYtMDctMDUNCg0KR3JvdXA6ICAgICAgICAgSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQoNClBhZ2VzOiAgICAgICAgIDEyDQoNClVSTDogICAgICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwt ZXhwbGFpbmVkLTAwLnR4dA0KDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLw0KDQpI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LW9wc2F3 Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMA0KDQoNCg0KDQoNCkFic3RyYWN0Og0KDQogICBU aGUgSUVURiBoYXMgcHJvZHVjZWQgYSBjb25zaWRlcmFibGUgbnVtYmVyIG9mIGRhdGEgbW9kZWxz IGluIHRoZQ0KDQogICBZQU5HIG1vZGVsbGluZyBsYW5ndWFnZS4gIFRoZSBtYWpvcml0eSBvZiB0 aGVzZSBhcmUgdXNlZCB0byBtb2RlbA0KDQogICBkZXZpY2VzIGFuZCB0aGV5IGFsbG93IGFjY2Vz cyBmb3IgY29uZmlndXJhdGlvbiBhbmQgdG8gcmVhZA0KDQogICBvcGVyYXRpb25hbCBzdGF0dXMu DQoNCg0KDQogICBBIHNtYWxsIG51bWJlciBvZiBZQU5HIG1vZGVscyBhcmUgdXNlZCB0byBtb2Rl bCBzZXJ2aWNlcyAoZm9yDQoNCiAgIGV4YW1wbGUsIHRoZSBMYXllciBUaHJlZSBWaXJ0dWFsIFBy aXZhdGUgTmV0d29yayBTZXJ2aWNlIE1vZGVsDQoNCiAgIHByb2R1Y2VkIGJ5IHRoZSBMM1NNIHdv cmtpbmcgZ3JvdXApLg0KDQoNCg0KICAgVGhpcyBkb2N1bWVudCBicmllZmx5IHNldHMgb3V0IHRo ZSBzY29wZSBvZiBhbmQgcHVycG9zZSBvZiBhbiBJRVRGDQoNCiAgIHNlcnZpY2UgbW9kZWwsIGFu ZCBpdCBzaG93cyB3aGVyZSBhIHNlcnZpY2UgbW9kZWwgbWlnaHQgZml0IGludG8gYQ0KDQogICBT b2Z0d2FyZSBEZWZpbmVkIE5ldHdvcmtpbmcgYXJjaGl0ZWN0dXJlIG9yIGRlcGxveW1lbnQuDQoN Cg0KDQoNCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KT1BTQVdHIG1haWxpbmcgbGlzdA0KDQpPUFNBV0dAaWV0Zi5v cmc8bWFpbHRvOk9QU0FXR0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vcHNhd2cNCg0K --_000_B8F9A780D330094D99AF023C5877DABA853A855Dnkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDUgOSAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0K CXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAx O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWluZ0xpVSI7DQoJ cGFub3NlLTE6MiAyIDUgOSAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTo rr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJs YWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjku MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6Ymxh Y2s7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8g Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmi hOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9 DQpwLkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0ZWQsIGRpdi5IVE1MUHJlZm9y bWF0dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLm1oDQoJe21zby1zdHls ZS1uYW1lOm1faDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQ2hh cg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5 bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5FeGFjdGx5LCB0aGlzIHdhcyB3aGF0IEkgc3RyZXNzZWQgaW4gdGhlIHRv ZGF54oCZcyBtZWV0aW5nLCB0byBjbGFyaWZ5IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIG1v ZGVsIHdoaWNoIGlzIHVzZWQgYmV0d2VlbiBjdXN0b21lciBhbmQgc2VydmljZQ0KIG9yY2hlc3Ry YXRvciBhbmQgdGhlIG1vZGVsIHVzZWQgYmV0d2VlbiBPU1MvQlNTIGFuZCBuZXR3b3JrIG9yY2hl c3RyYXRvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV2ZW4g dGhlIG1vZGVsIHVzZWQgYmV0d2VlbiBjdXN0b21lciBhbmQgc2VydmljZSBvcmNoZXN0cmF0b3Ig YW5kIHRoZSBtb2RlbCB1c2VkIGJldHdlZW4gc2VydmljZSBvcmNoZXN0cmF0b3IgYW5kIG5ldHdv cmsgb3JjaGVzdHJhdG9yIGRvZXNu4oCZdA0KIG5lZWQgdG8gYmUgc2FtZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93 dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2T O2NvbG9yOndpbmRvd3RleHQiPiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9y Z10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrl rovkvZM7Y29sb3I6d2luZG93dGV4dCI+5Luj6KGoIDwvc3Bhbj4NCjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndp bmRvd3RleHQiPkFkcmlhbiBGYXJyZWw8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPuWPkemAgeaX tumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5k b3d0ZXh0Ij4gMjAxNjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjc8L3Nw YW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjE5PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4N CiAxNjo0MTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiAnb3BzYXdnQGlldGYub3JnJzxicj4NCjwvc3Bhbj48 Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBbT1BTQVdHXSBCVFcgZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkIG5v dyBhdCByZXYgLTAxPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBvbmx5IG1hZGUgYSBzbWFsbCBj aGFuZ2UsIGJ1dCBvbmUgdGhpbmcgd2UgZGlkIHdhcyB0cnkgdG8gaGlnaGxpZ2h0IGEgZGlzdGlu Y3Rpb24gYmV0d2VlbiB0aGUgbW9kZWwgb24gdGhlIGludGVyZmFjZSBiZXR3ZWVuIGN1c3RvbWVy IGFuZCBvcGVyYXRvcg0KIChhIGxhIEwzU00pIGFuZCB0aGUgbW9kZWwgb24gdGhlIGludGVyZmFj ZSBiZXR3ZWVuIE9TUy9CU1MvZXRjLiBhbmQgbmV0d29yayBvcmNoZXN0cmF0b3IgKHdoaWNoIGlz IHdoYXQgd2Ugc2VlIGFzIFlBTkcgbW9kZWxzIGluIEJFU1MsIGZvciBleGFtcGxlKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGF2ZSBhIGxvb2sgYXQgRmlndXJlIDMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFkcmlhbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gT1BTQVdHIFs8YSBo cmVmPSJtYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvcHNhd2ctYm91bmNl c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFkcmlhbiBGYXJyZWw8YnI+DQo8 Yj5TZW50OjwvYj4gMTkgSnVseSAyMDE2IDA5OjI4PGJyPg0KPGI+VG86PC9iPiAnQmVub2l0IENs YWlzZSc7ICdRaW4gV3UnOyAnb3BzYXdnQGlldGYub3JnJzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW09QU0FXR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13dS1vcHNhd2ct c2VydmljZS1tb2RlbC1leHBsYWluZWQtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlbm9pdCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGF0IHlvdSBtZWFuIHRv IHNheSAmcXVvdDtpcyAqYW4qIG9iamVjdGl2ZSBvZiZxdW90Oy4gVGhhdCBpcywgdGhlIGRyYWZ0 IHlvdSBwb2ludCBhdCBoYXMgYSBmYXIgd2lkZXIgc2NvcGUgYW5kIHB1cnBvc2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vIHByb2JsZW0gd2l0aCB0aGF0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Eb2luZyBvdXIgd29yayBpbiBMM1NNIHdlIHJl cGVhdGVkbHkgZW5jb3VudGVyZWQgY29uZnVzaW9uIGFib3V0IHdoYXQgYSBzZXJ2aWNlIG1vZGVs IGlzIGFuZCB3aGVyZSBpdCBmaXRzIGluIHRoZSAmcXVvdDtoaWVyYXJjaHkmcXVvdDsuIFNvIHdl IHdyb3RlIHNvbWUNCiB0ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5M b29raW5nIGF0IG91ciBkcmFmdCBhbmQgRmlndXJlIDEgaW4gdGhlIHlhbmctbW9kZWwtY2xhc3Np ZmljYXRpb24gdGhlcmUgaXMgbm90IGNvbXBsZXRlIGNvaGVyZW5jZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hpY2ggd2F5IHdvdWxkIGxpa2UgdG8gZ28gZm9yd2FyZD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbGwgb3VyIHRleHQg aW50byB5YW5nLW1vZGVsLWNsYXNzaWZpY2F0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UHVzaCBmb3J3YXJkIHNlcGFyYXRlbHk/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFkcmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gT1BTQVdHIFs8YSBocmVmPSJtYWlsdG86 b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlbm9pdCBDbGFpc2U8YnI+DQo8Yj5TZW50OjwvYj4g MTkgSnVseSAyMDE2IDA5OjE4PGJyPg0KPGI+VG86PC9iPiBRaW4gV3U7IDxhIGhyZWY9Im1haWx0 bzpvcHNhd2dAaWV0Zi5vcmciPm9wc2F3Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPUFNBV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3Utb3Bz YXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiPlFpbiw8YnI+ DQo8YnI+DQpFeHBsYWluaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSBzZXJ2aWNlIGFuZCBu ZXR3b3JrIGVsZW1lbnQgWUFORyBtb2R1bGVzIGlzIHRoZSBvYmplY3RpdmUgb2YNCjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXlhbmct bW9kZWwtY2xhc3NpZmljYXRpb24vIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtbmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24vPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gY2xhc3M9Im1oIj48c3BhbiBsYW5nPSJFTi1HQiI+ QWJzdHJhY3Q8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IFRoZSBZQU5HIFtS RkM2MDIwXSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIGlzIGN1cnJlbnRseSBiZWluZzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IGNv bnNpZGVyZWQgZm9yIGEgd2lkZSB2YXJpZXR5IG9mIGFwcGxpY2F0aW9ucyB0aHJvdWdob3V0IHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7 Jm5ic3A7IG5ldHdvcmtpbmcgaW5kdXN0cnkgYXQgbGFyZ2UuJm5ic3A7IE1hbnkgc3RhbmRhcmRz LWRlZmluaW5nIG9yZ2FuaXphdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyAoU0RPcyksIG9wZW4gc291cmNlIHNvZnR3YXJl IHByb2plY3RzLCB2ZW5kb3JzIGFuZCB1c2VycyBhcmUgdXNpbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBZQU5HIHRvIGRldmVs b3AgYW5kIHB1Ymxpc2ggWUFORyBtb2R1bGVzIG9mIGNvbmZpZ3VyYXRpb24sIHN0YXRlIGRhdGE8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZu YnNwOyBhbmQgb3BlcmF0aW9ucyBmb3IgYSB3aWRlIHZhcmlldHkgb2YgYXBwbGljYXRpb25zLiZu YnNwOyBBdCB0aGUgc2FtZSB0aW1lLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IHRoZXJlIGlzIGN1cnJlbnRseSBubyB3ZWxsLWtu b3duIHRlcm1pbm9sb2d5IHRvIGNhdGVnb3JpemUgdmFyaW91czxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IHR5cGVzIG9mIFlBTkcg bW9kdWxlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+ Jm5ic3A7ICZuYnNwO0EgY29uc2lzdGVudCB0ZXJtaW5vbG9neSB3b3VsZCBoZWxwIHdpdGggdGhl IGNhdGVnb3JpemF0aW9uIG9mIFlBTkc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBtb2R1bGVzLCBhc3Npc3QgaW4gdGhlIGFuYWx5 c2lzIHRoZSBZQU5HIGRhdGEgbW9kZWxpbmcgZWZmb3J0cyBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBJRVRGIGFuZCBv dGhlciBvcmdhbml6YXRpb25zLCBhbmQgYnJpbmcgY2xhcml0eSB0byB0aGUgWUFORy1yZWxhdGVk PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsm bmJzcDsgZGlzY3Vzc2lvbnMgYmV0d2VlbiB0aGUgZGlmZmVyZW50IGdyb3Vwcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2V0IG9mIGNvbmNlcHRzIGFuZCBhc3NvY2lhdGVkIHRlcm1z IHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJz cDsmbmJzcDsgc3VwcG9ydCBjb25zaXN0ZW50IGNsYXNzaWZpY2F0aW9uIG9mIFlBTkcgbW9kdWxl cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj5SZWdhcmRzLCBCZW5vaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+SGksPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj5XZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBJLUQgdGhhdCBk aXNjdXNzZXMgdGhlIHNjb3BlIGFuZCBwdXJwb3NlIG9mIHNlcnZpY2UgbW9kZWxzIHdpdGhpbjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+dGhlIElFVEYg YW5kIGRlc2NyaWJlcyBob3cgYSBzZXJ2aWNlIG1vZGVsIGNhbiBiZSB1c2VkIGJ5IGEgbmV0d29y azxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+b3BlcmF0 b3IuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1vcHNhd2ctc2Vy dmljZS1tb2RlbC1leHBsYWluZWQvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQvPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj5JbiBhZGRpdGlvbiwgdGhpcyBkcmFm dCBjbGFyaWZpZXMgdGhlIHJvbGUgYW5kIHBvc2l0aW9uIG9mIHNlcnZpY2UgbW9kZWwgaW4gdGhl IFNETiBhcmNoaXRlY3R1cmUgYW5kPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLUdCIj5DbGVhciBzZXZlcmFsIG1pc2NvbmNlcHRpb24gb24gdGhlIHNlcnZpY2Ug bW9kZWwuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPllv dXIgcXVlc3Rpb25zIGFuZCBjb21tZW50cyBhcmUgd2VsY29tZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+UmVnYXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPi1RaW48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPi0tLS0tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpNaW5nTGlVIj7pgq7ku7bljp/ku7Y8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPi0t LS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpNaW5nTGlVIj7lj5Hku7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjogPGEgaHJlZj0i bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PC9hPiBbPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWluZ0xpVSI+5Y+R6YCB5pe26Ze0PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj46IDIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O01TIEdvdGhpYyZxdW90OyI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj43PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+NTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPiAxOTo1NTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7Ij7mlLbku7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjog TGl1c2h1Y2hlbmcgKFdpbGwpOyBBZHJpYW4gRmFycmVsOyBMaXVzaHVjaGVuZyAoV2lsbCk7IFFp biBXdTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7kuLs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5Ok1pbmdMaVUiPumimDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0w MC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj5BIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVk LTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+ aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBRaW4gV3UgYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLUdCIj5OYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBkcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPlJldmlzaW9uOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1HQiI+VGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlcnZpY2UgTW9kZWxzIEV4cGxhaW5lZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+RG9jdW1lbnQgZGF0ZTogMjAx Ni0wNy0wNTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+ R3JvdXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElu ZGl2aWR1YWwgU3VibWlzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1HQiI+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDEyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LUdCIj5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQtMDAudHh0Ij5o dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3Utb3BzYXdnLXNlcnZp Y2UtbW9kZWwtZXhwbGFpbmVkLTAwLnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tR0IiPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLyI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhw bGFpbmVkLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t R0IiPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9k ZWwtZXhwbGFpbmVkLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3Utb3Bz YXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IFRoZSBJRVRGIGhhcyBwcm9k dWNlZCBhIGNvbnNpZGVyYWJsZSBudW1iZXIgb2YgZGF0YSBtb2RlbHMgaW4gdGhlPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgWUFO RyBtb2RlbGxpbmcgbGFuZ3VhZ2UuJm5ic3A7IFRoZSBtYWpvcml0eSBvZiB0aGVzZSBhcmUgdXNl ZCB0byBtb2RlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1H QiI+Jm5ic3A7Jm5ic3A7IGRldmljZXMgYW5kIHRoZXkgYWxsb3cgYWNjZXNzIGZvciBjb25maWd1 cmF0aW9uIGFuZCB0byByZWFkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgb3BlcmF0aW9uYWwgc3RhdHVzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgQSBzbWFsbCBu dW1iZXIgb2YgWUFORyBtb2RlbHMgYXJlIHVzZWQgdG8gbW9kZWwgc2VydmljZXMgKGZvcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7 IGV4YW1wbGUsIHRoZSBMYXllciBUaHJlZSBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayBTZXJ2aWNl IE1vZGVsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj4g Jm5ic3A7Jm5ic3A7cHJvZHVjZWQgYnkgdGhlIEwzU00gd29ya2luZyBncm91cCkuPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBUaGlz IGRvY3VtZW50IGJyaWVmbHkgc2V0cyBvdXQgdGhlIHNjb3BlIG9mIGFuZCBwdXJwb3NlIG9mIGFu IElFVEY8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPiZu YnNwOyZuYnNwOyBzZXJ2aWNlIG1vZGVsLCBhbmQgaXQgc2hvd3Mgd2hlcmUgYSBzZXJ2aWNlIG1v ZGVsIG1pZ2h0IGZpdCBpbnRvIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBTb2Z0d2FyZSBEZWZpbmVkIE5ldHdvcmtpbmcgYXJj aGl0ZWN0dXJlIG9yIGRlcGxveW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj5QbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t R0IiPlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tR0IiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj5P UFNBV0cgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLUdCIj48YSBocmVmPSJtYWlsdG86T1BTQVdHQGlldGYub3JnIj5PUFNBV0dAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c8L2E+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA853A855Dnkgeml513mbxchi_-- From nobody Tue Jul 19 13:56:43 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C679112D89E for ; Tue, 19 Jul 2016 13:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 zkYHUBa-nIab for ; Tue, 19 Jul 2016 13:56:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EEA12D7B1 for ; Tue, 19 Jul 2016 13:56:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bPc4D-0003rk-0f; Tue, 19 Jul 2016 20:56:37 +0000 Date: Tue, 19 Jul 2016 22:56:36 +0200 Message-ID: From: Randy Bush To: Bert Wijnen In-Reply-To: <4ecf49c5-f987-7184-8cf6-b706eb914bcd@bwijnen.net> References: <4ecf49c5-f987-7184-8cf6-b706eb914bcd@bwijnen.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: opsawg Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 20:56:40 -0000 > Hi Randy, today, at IETF96 in Berlin, we discussed this document in > the OPSAWG meeting. > We would be interested to hear your opinion (from an operator point of > view) on this document. It is a short document. Hearing if you think > this makes sense or not would be great. > You can send you comments to me directly or (preferably) to the opsawg > mailing list at OPSAWG@ietf.org at this level of abstraction, anything can be made to look as if it would work and be wonderful. it essentially says that a multi-as vpn is composed by linking multiple single-as vpn systems. this is not a deep insight, and it provides no clues on how to do it. of the 392 devils to be found in the details, inter-provider authentication and identification of end-points, billing, ... the list goes on and one. then there are issues such as describing and provisioning the contracted (with the end customer) privacy constraints across multiple provider technologies. fwiw, our customers do use multi-provider vpns; they use ipsec. we provide ipsec capable cpe and various management/orchestration systems. randy From nobody Tue Jul 19 19:31:00 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE3812D0E6; Tue, 19 Jul 2016 19:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 gCNIn-t--5wr; Tue, 19 Jul 2016 19:30:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C8212D9DA; Tue, 19 Jul 2016 19:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=77724; q=dns/txt; s=iport; t=1468981850; x=1470191450; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=T8lFm523JTHmsUcY3s9AStaTJ5UiZyyAaJcgBCFrPl8=; b=NkjbPuweiXLf9Fv0EQ8ZFQTgEawGo9DHDkkB909mD+9mJjCD0XicIq+j q/H3fnVseHgVZZGR+mMLq24njXu7Np7KEQEuPlAM66GS+m8LTW8Dk480m 5mWs/FNjXWupjOOs9vqC4PohBX+r5nDSF/C4GpPeAoZ5FbHSdoqPzKW5V 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAD4o5X/4kNJK1dgnFOVnwGuGiBe?= =?us-ascii?q?iKFeAKBNDgUAQEBAQEBAWUnhFwBAQUaTRIQAgEIEQQBASEBBgcyFAkIAgQBDQU?= =?us-ascii?q?bBIgRDr0mAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhHaFJQWIIotBhUEBh?= =?us-ascii?q?hKCe4JzgmGCAo01kB0BHjaCCxyBTG6GYysYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,392,1464652800"; d="scan'208,217";a="125625146" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 02:30:48 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6K2UmAf020859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 02:30:48 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 21:30:47 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Tue, 19 Jul 2016 21:30:47 -0500 From: "Sashank Dara (sadara)" To: Tal Mizrahi , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tD/+pFIAA== Date: Wed, 20 Jul 2016 02:30:47 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.66.187] Content-Type: multipart/alternative; boundary="_000_D3B4DE197903Asadaraciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 02:30:54 -0000 --_000_D3B4DE197903Asadaraciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. [SD] The attack is valid only if the attacker can get away bypassing a serv= ice function/node. For example, if the attacker bypasses a node and if POT determines it did n= ot bypass is a valid attack on the system. In the current state, there is no way an attacker can get away as we determ= ine the exact path the packet travelled (aim of the draft) . I reiterate that the verifier needs to handle what to do with the path reco= nstructed ! We could emphasize this in our next draft , but it would be beyond scope of= POT to determine what to do with the path constructed. IMO, It would be highly application specific. Regards, Sashank Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We=92ll provide more details on 2. Per my earlier p= oint =96 1. is an interesting discussion, given that we don=92t claim to pr= ovide integrity protection for the packet payload. Or in other terms =96 to= be exact: What POT provides is a proof that the POT-header/meta-data trans= ited all the required nodes. There is no association (and thus proof) provi= ded for the additional data carried along with the POT-header =96 neither h= eader nor payload. As a consequence, attacks which change the packet payloa= d won=92t be detected/mitigated. We=92ll explicitly state this in the secur= ity considerations in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar =96 but that way we=92d restrict the applicability to dep= loyments where the packet payload isn=92t changed across the path (which mi= ght not apply to certain deployment =96 e.g. WAN optimization / compression= schemes). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of =93proof-of-transit=94 is to prove the path packet has= taken exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with =93reconstructed=94 path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rou= ghly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of =93proof-of-transit=94 is to prove the path pac= ket has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with =93reconstructed=94 path. Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rough= ly 1 million packets per second. That would mean the verifier has to store = a million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a =91mix and match=92 attack, by taking the corr= ect POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn=92t it be poss= ible to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that=92s reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let=92s say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can =91launder=92 packet B by replacing the (incorrect) POT of= packet B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node=92s POT values (from older pack= et traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier=92s share of RND-3 is never on wire , so attacker cannot just obse= rve the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the =93Reply Attacks=94 , we recommend that the RND-2 (= generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND n= umber=94) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_D3B4DE197903Asadaraciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


The POT replacement attack (1.) is = not an attack on the integrity. It is an attack on the path verification.

This simple attack can cause the ve= rifier to accept a packet that did not go through the firewall SF (even tho= ugh it should). I believe this is exactly the problem you were aiming to address in this draft.

[SD] The attack is valid only if the attacker can get away bypassing a= service function/node. 
For example, if the attacker bypasses a node and if POT determines it = did not bypass is a valid attack on the system.

In the current state, there is no way an attacker can get away as we d= etermine the exact path the packet travelled (aim of the draft) . 
I reiterate that the verifier needs to handle what to do with the path= reconstructed !
We could emphasize this in our next draft , but it would be beyond sco= pe of POT to determine what to do with the path constructed. 
IMO, It would be highly application specific. 

 
Regards,
Sashank


 

Thanks,

Tal.

 

From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary. We=92ll pro= vide more details on 2. Per my earlier point =96 1. is an interesting discu= ssion, given that we don=92t claim to provide integrity protection for the packet payload. Or in other terms =96 to be e= xact: What POT provides is a proof that the POT-header/meta-data transited = all the required nodes. There is no association (and thus proof) provided f= or the additional data carried along with the POT-header =96 neither header nor payload. As a consequence, atta= cks which change the packet payload won=92t be detected/mitigated. We=92ll = explicitly state this in the security considerations in the next rev of the= document.

What we could consider is linking t= he RND number to CRC across the packet payload or similar =96 but that way = we=92d restrict the applicability to deployments where the packet payload isn=92t changed across the path (which might not = apply to certain deployment =96 e.g. WAN optimization / compression schemes= ).

Do you think it is worthwhile to pr= ovide a solution for a deployment which is expected to not alter the packet= payload?

 

Thanks,

Frank

 

From: Tal Mizrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,

 

To summarize my take on this thread= :

The proposed mechanism has two sign= ificant vulnerabilities that (in my understanding) are currently not addres= sed:

   =     A man-in-the-middle can replace the POT of packet A= with the POT of packet B.

   =     It is possible to replay POTs within a certain time= window, whose length is determined by the timestamp resolution.=

 

Sashank, thanks for agreeing to loo= k into it further. I am looking forward to your insights on this.

 

Regards,

Tal.

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (indicating t= he path through 1,3,5,6) to packet B, will the verifier accept packet B and= believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is programmed to just v= alidate the POT meta data against {1,3,5,6} then yes it accepts it. 

If the verifier is programmed to consult a p= olicy database to cross check if the reconstructed path {1,3,5,6} is as per= the policies then no , it drops it . 

 

But I see your point , that the parameters u= sed in POT data donot consider the path or node-ids etc . We shall discuss = this internally and get back.

 

Also, We shall get back with more concrete n= umbers of the timestamp resolution and cache sizes (or other better approac= hes). 

 

Thank you so much for all the inputs. <= o:p>

 

 

 

From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate the quick and d= etailed responses.

 

>>>Lets take correct path taken by Packet A  = ;to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g. the fire= wall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only constructs the pa= th the packet took accurately, it is upto

>the application to determine whether it = violates any policies (I.e missing any function) 

>The bottom line is , an attacker taking = a different path cannot get away with it !

>The whole intent of =93proof-of-transit= =94 is to prove the path packet has taken exactly. <= /p>

>POT does not define whether it good/bad = path. It is upto high level applications on what

>do with =93reconstructed=94 path. <= o:p>

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of= packet A (indicating the path through 1,3,5,6) to packet B, will the verif= ier accept packet B and believe that its path was indeed (1,3,5,6)?

 

 

>>Hmmm=85 Let=92s say we are talking about = traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Se= cond level precision is only an example, we could use as much precision as = we want to reduce the number of values to be cached !

 

My point is that assuming reasonabl= e resources are used, the mechanism is vulnerable to a replay attack.<= /o:p>

In order to prove me wrong, can you= present concrete numbers of the timestamp resolution and the cache size?

Otherwise, you may consider using a= sequence number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

 

>[SD] Ok. This is an interesting attack.  <= span style=3D"color:black">

> 

>Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values from Path1 and reattach them to Path2 ,

>the reconstruction for PacketB would result in (1= ,3,5,6) instead of (1,2,3,6). =

>This could be compared with topology/policy db informa= tion for any policy

>violations. POT does not enforce a particular path to = be taken.

 

So packet B skipped node 5 (e.g. the firewall SF)= , but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only constructs the path t= he packet took accurately, it is upto the application to determine whether = it violates any policies (I.e missing any function) 

The bottom line is , an attacker taking a di= fferent path cannot get away with it ! The whole intent of =93proof-of-tran= sit=94 is to prove the path packet has taken exactly. 

POT does not define whether it good/bad path= . It is upto high level applications on what do with =93reconstructed=94 pa= th. 

 

 

Hmmm=85 Let=92s say we are talking about traffic = at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of = RND-2.

Moreover, every time a packet arrives, the verifi= er would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second= level precision is only an example, we could use as much precision as we w= ant to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A and B:<= span style=3D"color:black">

- Packet A that went through the correct path and= has a correct POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 Now the attacker performs a =91mix and match=92 atta= ck, by taking the correct POT from packet A and attaching it to packet B.

The attacker also terminates packet A.

There is no replay here, because the verifier rec= eives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the verifier, even= though it did not go through the correct path.

 

Is there a way to mitigate this attack?

 

[SD] Ok. This is an interesting attack.  

 

Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/policy db information= for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular path taken by th= e packets. 

 

Do you mean that there is a one-second-vulnerabil= ity for replay attacks?

One second is practically forever.

 

[SD] Not really , the verifier could cache the RND-2 numbe= rs used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as = such, if the verifier caches those values. 

 

Effective replay prevention is typically performe= d using a sequence number, with a sliding window to allow out-of-order packets. Wouldn=92t it be possible to incorpo= rate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high level sequence numb= er (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that=92s reason we recommend using  ( Timestamp(/ seq= uence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. More inline with = [SD] .. 

 

 

Right, I am referring to the former. The integrity check i= s not the issue.

Let=92s say we have:

- Packet A that went through the correct path and has a co= rrect POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 

The attacker can =91launder=92 packet B by replacing the (= incorrect) POT of packet B with the correct POT of packet A (and drop packe= t A).

Thus, packet B is verified correctly, even though it did n= ot go through the correct path.

 

[SD] This is valid scenario and we have certain in-built m= itigation techniques and recommendations for the same. 

There are two scenarios here 

 

Partial Replay of POT data (Replaying intermediate CMLs= )

 

Attacker cannot reuse few intermediate node=92s POT values= (from older packet traces) as it would disrupt the POLY-3 construction. <= o:p>

On the other hand if the attacker tries to replay entire s= equence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and partic= ipates in the reconstruction of RND-3.

Verifier=92s share of RND-3 is never on wire , so attacker= cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying complete RND-2)

 

Another trick, attacker could do is by completely reusing = RND-2 (but not intermediate CML values)<= o:p>

In order to prevent the =93Reply Attacks=94 , we recommend= that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND number=94)

So in case a passive attacker tries to replay one of the c= orrect but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than current timestamp= we drop/raise a flag ! =

 

There is still a small window , where the attacker could r= eplay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is 32 bits , we cou= ld get one seconds level precision in the time window . So it is highly impossible for the attacker to replay wi= thin such a small time at such a high packet rates. 

 

Also , the verifier could cache, if needed, certain number= of previously used RND-2 to mitigate replay attacks. =

 

Hope this clarifies. 

 

 --_000_D3B4DE197903Asadaraciscocom_-- From nobody Tue Jul 19 21:31:19 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49112DA15; Tue, 19 Jul 2016 21:31:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 J-MSkuplxsCB; Tue, 19 Jul 2016 21:31:09 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08EA812DA0C; Tue, 19 Jul 2016 21:31:08 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6K4UvO1018857; Tue, 19 Jul 2016 21:31:06 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 2494s9877f-20 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Jul 2016 21:31:06 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jul 2016 07:30:28 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Wed, 20 Jul 2016 07:30:28 +0300 From: Tal Mizrahi To: "Sashank Dara (sadara)" , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tD/+pFIAIAAkjGA Date: Wed, 20 Jul 2016 04:30:28 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_c44cec107c6741c5a51872ecad5b1429ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_04:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200050 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 04:31:13 -0000 --_000_c44cec107c6741c5a51872ecad5b1429ILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sashank, >[SD] The attack is valid only if the attacker can get away bypassing a ser= vice function/node. >For example, if the attacker bypasses a node and if POT determines it did = not bypass is a valid attack on the system. I would phrase it this way: *Given* a packet that did not go through its de= sired path, the attacker can easily make you think that it *did* go through= the desired path. Sounds like a very significant vulnerability. If a packet did not go through the firewall (for one reason or another), th= e attacker will make you think that it did go through the firewall. Cheers, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Wednesday, July 20, 2016 4:31 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: Re: Question regarding Proof of Transit draft The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. [SD] The attack is valid only if the attacker can get away bypassing a serv= ice function/node. For example, if the attacker bypasses a node and if POT determines it did n= ot bypass is a valid attack on the system. In the current state, there is no way an attacker can get away as we determ= ine the exact path the packet travelled (aim of the draft) . I reiterate that the verifier needs to handle what to do with the path reco= nstructed ! We could emphasize this in our next draft , but it would be beyond scope of= POT to determine what to do with the path constructed. IMO, It would be highly application specific. Regards, Sashank Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_c44cec107c6741c5a51872ecad5b1429ILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sashank,

 <= /p>

>[SD] The attack is vali= d only if the attacker can get away bypassing a service function/node. = ;

>For example, if the att= acker bypasses a node and if POT determines it did not bypass is a valid at= tack on the system.

 <= /p>

I would phrase it this wa= y: *Given* a packet that did not go through its desired path, the at= tacker can easily make you think that it *did* go through the desired path.

Sounds like a very signif= icant vulnerability.

 <= /p>

If a packet did not go th= rough the firewall (for one reason or another), the attacker will make you = think that it did go through the firewall.

 <= /p>

Cheers,=

Tal.

 <= /p>

 <= /p>

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com]
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-o= f-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

The POT replacement attack (1.) is not = an attack on the integrity. It is an attack on the path verification.

This simple attack can cause the verifi= er to accept a packet that did not go through the firewall SF (even though it should). I believe this is exactly the problem you were= aiming to address in this draft.

 

[SD] The attack is valid on= ly if the attacker can get away bypassing a service function/node. 

For example, if the attacke= r bypasses a node and if POT determines it did not bypass is a valid attack= on the system.

 

In the current state, there= is no way an attacker can get away as we determine the exact path the pack= et travelled (aim of the draft) . 

I reiterate that the verifi= er needs to handle what to do with the path reconstructed !

We could emphasize this in = our next draft , but it would be beyond scope of POT to determine what to d= o with the path constructed. 

IMO, It would be highly app= lication specific. 

 

 

Regards,<= /p>

Sashank

 

 

 

Thanks,

Tal.=

 

From: Frank Brockners (fbrockne) [mailto:fbrockn= e@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary. We’ll pro= vide more details on 2. Per my earlier point – 1. is an interesting discussion, given that we don’t claim to provide integrity protectio= n for the packet payload. Or in other terms – to be exact: What POT p= rovides is a proof that the POT-header/meta-data transited all the required= nodes. There is no association (and thus proof) provided for the additional data carried along with the POT-header –= neither header nor payload. As a consequence, attacks which change the pac= ket payload won’t be detected/mitigated. We’ll explicitly state= this in the security considerations in the next rev of the document.

What we could consider is linking the R= ND number to CRC across the packet payload or similar – but that way we’d restrict the applicability to deployments where the pa= cket payload isn’t changed across the path (which might not apply to = certain deployment – e.g. WAN optimization / compression schemes).

Do you think it is worthwhile to provid= e a solution for a deployment which is expected to not alter the packet payload?

 

Thanks,

Frank

 

From: Tal Mizrahi [mailto:talmi@marvell.com= ]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,<= o:p>

 

To summarize my take on this thread:

The proposed mechanism has two signific= ant vulnerabilities that (in my understanding) are currently not addressed:

1.    &nbs= p;  A man-in-the-middle can replace the POT o= f packet A with the POT of packet B.

2.    &nbs= p;  It is possible to replay POTs within a ce= rtain time window, whose length is determined by the timestamp resolution.<= /span>

 

Sashank, thanks for agreeing to look in= to it further. I am looking forward to your insights on this.

 

Regards,

Tal.=

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01=

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 =

I want to ask a simple question:

If the attacker attaches the POT of packet A (in= dicating the path through 1,3,5,6) to packet B, will the verifier accept pa= cket B and believe that its path was indeed (1,3,5,6)?

 =

[SD] If the verifier is programmed to jus= t validate the POT meta data against {1,3,5,6} then yes it accepts it. 

If the verifier is programmed to consult = a policy database to cross check if the reconstructed path {1,3,5,6} is as per the policies then no , it drops it . 

 =

But I see your point , that the parameter= s used in POT data donot consider the path or node-ids etc . We shall discuss this internally and get back.

 =

Also, We shall get back with more concret= e numbers of the timestamp resolution and cache sizes (or other better approaches). 

 =

Thank you so much for all the inputs.&nbs= p;

 

 

 

From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate the quick and detai= led responses.

 

>>>Lets take correct path taken = by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g= . the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only constructs the= path the packet took accurately, it is upto

>the application to determine whether = it violates any policies (I.e missing any function) 

>The bottom line is , an attacker taki= ng a different path cannot get away with it !

>The whole intent of “proof-of-t= ransit” is to prove the path packet has taken exactly. 

>POT does not define whether it good/b= ad path. It is upto high level applications on what

>do with “reconstructed” p= ath. 

 

 

 

I want to ask a simple question:=

If the attacker attaches the POT of pac= ket A (indicating the path through 1,3,5,6) to packet B, will the verifier accept packet B and believe that its path was indeed (1,3,5,6= )?

 

 

>>Hmmm… Let’s say we = are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, w= e could use as much precision as we want to reduce the number of values to be cached !

 

My point is that assuming reasonable re= sources are used, the mechanism is vulnerable to a replay attack.

In order to prove me wrong, can you pre= sent concrete numbers of the timestamp resolution and the cache size?

Otherwise, you may consider using a seq= uence number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.=

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 

 

>[SD] Ok. This is an interesting attac= k.  

> 

>Lets take correct path taken by Packe= t A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Pack= et B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values fro= m Path1 and reattach them to Path2 ,

>the reconstruction for PacketB w= ould result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/= policy db information for any policy

>violations. POT does not enforce a pa= rticular path to be taken.

 

So packet B skipped node 5 (e.g. the fi= rewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only constructs the pat= h the packet took accurately, it is upto the application to determine whether it violates any policies (I.e missing any function) = ;

The bottom line is , an attacker taking a= different path cannot get away with it ! The whole intent of “proof-of-transit” is to prove the path packet has taken ex= actly. 

POT does not define whether it good/bad p= ath. It is upto high level applications on what do with “reconstructe= d” path. 

 =

 

Hmmm… Let’s say we are talk= ing about traffic at 10 Gbps, which is roughly 1 million packets per second= . That would mean the verifier has to store a million values of RND-2.

Moreover, every time a packet arrives, = the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we co= uld use as much precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 =

 

We have two consecutive packets, A and = B:

- Packet A that went through the correc= t path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also terminates packet A.<= /span>

There is no replay here, because the ve= rifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the veri= fier, even though it did not go through the correct path.

 

Is there a way to mitigate this attack?=

 =

[SD] Ok. This is an interesting attack. &= nbsp;

 =

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B= i.e. Path2 -  (1,2,3,6).

 =

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/poli= cy db information for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular= path taken by the packets. 

 =

Do you mean that there is a one-second-= vulnerability for replay attacks?

One second is practically forever.

 =

[SD] Not really , the verifier could cach= e the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such= , if the verifier caches those values. 

 =

Effective replay prevention is typicall= y performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to incorporat= e such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high le= vel sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that’s reason we recommend using &n= bsp;( Timestamp(/ sequence number) + RND )

 

 =

 =

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. = More inline with [SD] .. 

 =

 =

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 =

[SD] This is valid scenario and we have c= ertain in-built mitigation techniques and recommendations for the same. 

There are two scenarios here =

 =

Partial Replay of POT data (Replaying = intermediate CMLs)=

 =

Attacker cannot reuse few intermediate no= de’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker tries t= o replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and particip= ates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never = on wire , so attacker cannot just observe the packet traces to reuse and replay it. <= /p>

 =

Total Replay of POT data (Replaying co= mplete RND-2)

 =

Another trick, attacker could do is by co= mpletely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Atta= cks” , we recommend that the RND-2 (generated per packet) be a combin= ation (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to re= play one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 =

There is still a small window , where the= attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is= 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within= such a small time at such a high packet rates. 

 =

Also , the verifier could cache, if neede= d, certain number of previously used RND-2 to mitigate replay attacks. 

 =

Hope this clarifies. 

 =

--_000_c44cec107c6741c5a51872ecad5b1429ILEXCH02marvellcom_-- From nobody Tue Jul 19 23:24:31 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FB412DABC; Tue, 19 Jul 2016 23:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jQremSyCE_vd; Tue, 19 Jul 2016 23:24:02 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B8012D8A1; Tue, 19 Jul 2016 23:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=95519; q=dns/txt; s=iport; t=1468995842; x=1470205442; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nCg96E6wFRehS9ege5WK7q+iNWSeeWj5mPdS8+Yn5ds=; b=YW2EXyas52m2Md324nTa3E9A7dy4IK0LETKbYFKf7BDf5iOA8W+ySEpj Tu3n9FTNNclYbM5fmMa96DduXH1u3Ai2N3A/4hGglaUoVtvQqhAYDqA19 tbPQu+70VvyV5xzgsU0Q9jkg+FJsHXJUwBVFM22/EbeA8ZgYSmX5Js/i1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQBXGI9X/5JdJa1dgnFOVnwGuGiBe?= =?us-ascii?q?iKFeAKBMzgUAQEBAQEBAWUnhFwBAQUaTRIQAgEIEQQBASEBBgcyFAkIAgQBDQU?= =?us-ascii?q?bBIgRDr00AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhHaFJQWIIotChUIBh?= =?us-ascii?q?hKCe4JzgmGCAo02kB8BHjaCCxyBTG6GLisYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,392,1464652800"; d="scan'208,217";a="299795457" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 06:24:00 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6K6O0rr014259 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 06:24:00 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 01:23:59 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 01:23:59 -0500 From: "Sashank Dara (sadara)" To: Tal Mizrahi , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tD/+pFIAIAAkjGA//+u9wA= Date: Wed, 20 Jul 2016 06:23:59 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.66.187] Content-Type: multipart/alternative; boundary="_000_D3B50FF97908Bsadaraciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 06:24:06 -0000 --_000_D3B50FF97908Bsadaraciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >[SD] The attack is valid only if the attacker can get away bypassing a ser= vice function/node. >For example, if the attacker bypasses a node and if POT determines it did = not bypass is a valid attack on the system. I would phrase it this way: *Given* a packet that did not go through its de= sired path, the attacker can easily make you think that it *did* go through= the desired path. Sounds like a very significant vulnerability. If a packet did not go through the firewall (for one reason or another), th= e attacker will make you think that it did go through the firewall. [SD] At a high level , looks like it is , Because each node did not really= digitially sign the packet that it infact went through it . We shall investigate what light weight mitigation techniques could be incor= porated as we wanted to avoid heavy encryptions doing this inband at each n= ode. Thanks again for point this . Regards, Sashank Cheers, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Wednesday, July 20, 2016 4:31 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: Re: Question regarding Proof of Transit draft The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. [SD] The attack is valid only if the attacker can get away bypassing a serv= ice function/node. For example, if the attacker bypasses a node and if POT determines it did n= ot bypass is a valid attack on the system. In the current state, there is no way an attacker can get away as we determ= ine the exact path the packet travelled (aim of the draft) . I reiterate that the verifier needs to handle what to do with the path reco= nstructed ! We could emphasize this in our next draft , but it would be beyond scope of= POT to determine what to do with the path constructed. IMO, It would be highly application specific. Regards, Sashank Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We=92ll provide more details on 2. Per my earlier p= oint =96 1. is an interesting discussion, given that we don=92t claim to pr= ovide integrity protection for the packet payload. Or in other terms =96 to= be exact: What POT provides is a proof that the POT-header/meta-data trans= ited all the required nodes. There is no association (and thus proof) provi= ded for the additional data carried along with the POT-header =96 neither h= eader nor payload. As a consequence, attacks which change the packet payloa= d won=92t be detected/mitigated. We=92ll explicitly state this in the secur= ity considerations in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar =96 but that way we=92d restrict the applicability to dep= loyments where the packet payload isn=92t changed across the path (which mi= ght not apply to certain deployment =96 e.g. WAN optimization / compression= schemes). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of =93proof-of-transit=94 is to prove the path packet has= taken exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with =93reconstructed=94 path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rou= ghly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of =93proof-of-transit=94 is to prove the path pac= ket has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with =93reconstructed=94 path. Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rough= ly 1 million packets per second. That would mean the verifier has to store = a million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a =91mix and match=92 attack, by taking the corr= ect POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn=92t it be poss= ible to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that=92s reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let=92s say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can =91launder=92 packet B by replacing the (incorrect) POT of= packet B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node=92s POT values (from older pack= et traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier=92s share of RND-3 is never on wire , so attacker cannot just obse= rve the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the =93Reply Attacks=94 , we recommend that the RND-2 (= generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND n= umber=94) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_D3B50FF97908Bsadaraciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B4EB3843F0D0849A96165E45D444CE3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

 

>[SD] The attack is valid only if the att= acker can get away bypassing a service function/node. 

>For example, if the attacker bypasses a = node and if POT determines it did not bypass is a valid attack on the syste= m.

 

I would phrase it this way: *Giv= en* a packet that did not go through its desired path, the attacker can= easily make you think that it *did* go through the desired path.

Sounds like a very significant vuln= erability.

 

If a packet did not go through the = firewall (for one reason or another), the attacker will make you think that= it did go through the firewall.


[SD]  At a high level , looks like it is , Because each node did = not really digitially sign the packet that it infact went through it . = ;
We shall investigate what light weight mitigation techniques could be = incorporated as we wanted to avoid heavy encryptions doing this inband at e= ach node. 
 

Thanks again for point this .

Regards,
Sashank


 

Cheers,

Tal.

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com]
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

The POT replacement attack (1.) is not an attack = on the integrity. It is an attack on the path verification.

This simple attack can cause the verifier to acce= pt a packet that did not go through the firewall SF (even though it should). I believe this is exactly the problem= you were aiming to address in this draft.

 

[SD] The attack is valid only if the attacke= r can get away bypassing a service function/node. 

For example, if the attacker bypasses a node= and if POT determines it did not bypass is a valid attack on the system.

 

In the current state, there is no way an att= acker can get away as we determine the exact path the packet travelled (aim= of the draft) . 

I reiterate that the verifier needs to handl= e what to do with the path reconstructed !

We could emphasize this in our next draft , = but it would be beyond scope of POT to determine what to do with the path c= onstructed. 

IMO, It would be highly application specific= . 

 

 

Regards,

Sashank

 

 

 

Thanks,

Tal.

 

From: Frank Brockners (fbrockne) [mailto:fbrockn= e@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary. We=92ll provide more deta= ils on 2. Per my earlier point =96 1. is an interesting discussion, given that we don=92t claim to provide integrity p= rotection for the packet payload. Or in other terms =96 to be exact: What P= OT provides is a proof that the POT-header/meta-data transited all the requ= ired nodes. There is no association (and thus proof) provided for the additional data carried along with the P= OT-header =96 neither header nor payload. As a consequence, attacks which c= hange the packet payload won=92t be detected/mitigated. We=92ll explicitly = state this in the security considerations in the next rev of the document. <= /o:p>

What we could consider is linking the RND number = to CRC across the packet payload or similar =96 but that way we=92d restrict the applicability to deployments where th= e packet payload isn=92t changed across the path (which might not apply to = certain deployment =96 e.g. WAN optimization / compression schemes).

Do you think it is worthwhile to provide a soluti= on for a deployment which is expected to not alter the packet payload?

 

Thanks,

Frank

 

From: Tal Mizrahi [mailto:talmi@marvell.com= ]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,=

 

To summarize my take on this thread:

The proposed mechanism has two significant vulner= abilities that (in my understanding) are currently not addressed:

       A man-in-the-middle can replace the POT of packet A= with the POT of packet B.

       It is possible to replay POTs within a certain time= window, whose length is determined by the timestamp resolution.

 

Sashank, thanks for agreeing to look into it furt= her. I am looking forward to your insights on this.

 

Regards,<= /o:p>

Tal.

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01=

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (indicating t= he path through 1,3,5,6) to packet B, will the verifier accept packet B and= believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is programmed to just validate the PO= T meta data against {1,3,5,6} then yes it accepts it. <= /p>

If the verifier is programmed to consult a policy database= to cross check if the reconstructed path {1,3,5,6} is as per the policies then no , it drops it . 

 

But I see your point , that the parameters used in POT dat= a donot consider the path or node-ids etc . We shall discuss this internally and get back.

 

Also, We shall get back with more concrete numbers of the = timestamp resolution and cache sizes (or other better approaches). 

 

Thank you so much for all the inputs. 

 

 

 

From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,<= o:p>

 

I really appreciate the quick and detailed respon= ses.

 

>>>Lets take correct path taken by Packet A  = ;to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g. the fire= wall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only constructs the path the packet = took accurately, it is upto

>the application to determine whether it violates any p= olicies (I.e missing any function) =

>The bottom line is , an attacker taking a different pa= th cannot get away with it !

>The whole intent of =93proof-of-transit=94 is to prove= the path packet has taken exactly. 

>POT does not define whether it good/bad path. It is up= to high level applications on what

>do with =93reconstructed=94 path. 

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (ind= icating the path through 1,3,5,6) to packet B, will the verifier accept packet B and believe that its path was indeed = (1,3,5,6)?

 

 

>>Hmmm=85 Let=92s say we are talking about = traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

&g= t;[SD] Second level precision is only an example, we could use as much= precision as we want to reduce the number of values to be cached !=

 

My point is that assuming reasonable resources ar= e used, the mechanism is vulnerable to a replay attack.

In order to prove me wrong, can you present concr= ete numbers of the timestamp resolution and the cache size?

Otherwise, you may consider using a sequence numb= er + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

 

>[SD] Ok. This is an interesting attack.  <= span style=3D"color:black">

> 

>Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values from Path1 and reattach them to Path2 ,

>the reconstruction for PacketB would result in (1= ,3,5,6) instead of (1,2,3,6). =

>This could be compared with topology/policy db informa= tion for any policy

>violations. POT does not enforce a particular path to = be taken.

 

So packet B skipped node 5 (e.g. the firewall SF)= , but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only constructs the path the packet took= accurately, it is upto the application to determine whether it violates any policies (I.e missing any function)&n= bsp;

The bottom line is , an attacker taking a different path c= annot get away with it ! The whole intent of =93proof-of-transit=94 is to prove the path packet has taken exactly.&n= bsp;

POT does not define whether it good/bad path. It is upto h= igh level applications on what do with =93reconstructed=94 path. 

 

 

Hmmm=85 Let=92s say we are talking about traffic = at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of = RND-2.

Moreover, every time a packet arrives, the verifi= er would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[S= D] Second level precision is only an example, we could use as much pre= cision as we want to reduce the number of values to be cached !

 

&n= bsp;

Sashank <= /span>

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A and B:<= span style=3D"color:black">

- Packet A that went through the correct path and= has a correct POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 Now the attacker performs a =91mix and match=92 atta= ck, by taking the correct POT from packet A and attaching it to packet B.

The attacker also terminates packet A.

There is no replay here, because the verifier rec= eives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the verifier, even= though it did not go through the correct path.

 

Is there a way to mitigate this attack?

 

[SD] Ok. This is an interesting attack.  

 

Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/policy db information= for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular path taken by th= e packets. 

 

Do you mean that there is a one-second-vulnerabil= ity for replay attacks?

One second is practically forever.

 

[SD] Not really , the verifier could cache the RND-2 numbe= rs used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as = such, if the verifier caches those values. 

 

Effective replay prevention is typically performe= d using a sequence number, with a sliding window to allow out-of-order packets. Wouldn=92t it be possible to incorpo= rate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high level sequence numb= er (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that=92s reason we recommend using  ( Timestamp(/ seq= uence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. More inline with = [SD] .. 

 

 

Right, I am referring to the former. The integrity check i= s not the issue.

Let=92s say we have:

- Packet A that went through the correct path and has a co= rrect POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 

The attacker can =91launder=92 packet B by replacing the (= incorrect) POT of packet B with the correct POT of packet A (and drop packe= t A).

Thus, packet B is verified correctly, even though it did n= ot go through the correct path.

 

[SD] This is valid scenario and we have certain in-built m= itigation techniques and recommendations for the same. 

There are two scenarios here 

 

Partial Replay of POT data (Replaying intermediate CMLs= )

 

Attacker cannot reuse few intermediate node=92s POT values= (from older packet traces) as it would disrupt the POLY-3 construction. <= o:p>

On the other hand if the attacker tries to replay entire s= equence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and partic= ipates in the reconstruction of RND-3.

Verifier=92s share of RND-3 is never on wire , so attacker= cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying complete RND-2)

 

Another trick, attacker could do is by completely reusing = RND-2 (but not intermediate CML values)<= o:p>

In order to prevent the =93Reply Attacks=94 , we recommend= that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND number=94)

So in case a passive attacker tries to replay one of the c= orrect but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than current timestamp= we drop/raise a flag ! =

 

There is still a small window , where the attacker could r= eplay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is 32 bits , we cou= ld get one seconds level precision in the time window . So it is highly impossible for the attacker to replay wi= thin such a small time at such a high packet rates. 

 

Also , the verifier could cache, if needed, certain number= of previously used RND-2 to mitigate replay attacks. =

 

Hope this clarifies. 

 

 --_000_D3B50FF97908Bsadaraciscocom_-- From nobody Wed Jul 20 00:16:16 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF63412D9B9; Wed, 20 Jul 2016 00:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FdLAv6Eugj4a; Wed, 20 Jul 2016 00:16:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265A412D0DE; Wed, 20 Jul 2016 00:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=85553; q=dns/txt; s=iport; t=1468998966; x=1470208566; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+YJuwJKXDbOy3GWoBZ9TK/MAh9CcKdo/UQkt7pDJp4Y=; b=B4HxsCblmKnb6HN0VBQEyWHGEAHG3iH95iNZh8VB1oJLGp0LctGUaSod CemLPQrqI+TmisGum+3D0yW8TgDt5CAM15gnx4oCjJBPAkyHQM6DNaXxd pD5tLoFuhtSBIbhzxxgymRxPHcn5oprmvtu5n4ld21AlvVZWGqLyCpp6/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQDcI49X/51dJa1dgnFOVnwGuGiBe?= =?us-ascii?q?iKFeAKBMzgUAQEBAQEBAWUnhFwBAQUaEzoSEAIBCBEEAQEhAQYHMhQJCAIEAQ0?= =?us-ascii?q?FCBMEiBEOvTIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqhE2EdoUlBYgii0KFQ?= =?us-ascii?q?gGGEoJ7gnOCWoIJjTaQHwEeNoILHIFMboYuKxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208,217";a="127817655" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 07:16:03 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u6K7G3mW022109 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 07:16:03 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 02:16:02 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 02:16:02 -0500 From: "Frank Brockners (fbrockne)" To: Tal Mizrahi , "Sashank Dara (sadara)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tCABdCDgA== Date: Wed, 20 Jul 2016 07:16:02 +0000 Message-ID: <99c4c8222952442f9a8c99713cbbbffe@XCH-RCD-008.cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.244.97] Content-Type: multipart/alternative; boundary="_000_99c4c8222952442f9a8c99713cbbbffeXCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 07:16:11 -0000 --_000_99c4c8222952442f9a8c99713cbbbffeXCHRCD008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal, well... if you could protect the integrity of the data stream between sourc= e and destination, you would not be able to swap the content of a packet - = which is what your attack is all about. Rather than continue arguing the po= int, let's acknowledge that it is a valid attack and let's look for a solut= ion :-). We'll need to couple POT to integrity protection of the packet. Hence, I'd like to come back to my question asked below: Do you (and the entire SFC team here) think it is worthwhile to provide a s= olution for a deployment which is expected to *not* alter the packet payloa= d? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 18:15 To: Frank Brockners (fbrockne) ; Sashank Dara (sadara) = ; draft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Frank, The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_99c4c8222952442f9a8c99713cbbbffeXCHRCD008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal,

 = ;

well... if you could protect the integrity of the data stream between = source and destination, you would not be able to swap the content of a packet – which is what your attack is all abou= t. Rather than continue arguing the point, let’s acknowledge that it = is a valid attack and let’s look for a solution :-). We’ll need= to couple POT to integrity protection of the packet.

 

Hence, I’d like to come back to my question asked below:  <= o:p>

Do you (and the entire= SFC team here) think it is worthwhile to provide a solution for a deployme= nt which is expected to *not* alter the packet payload?

 

Thanks, Frank

 

From: = Tal Mizrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 18:15
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Sashank D= ara (sadara) <sadara@cisco.com>; draft-brockners-proof-of-transit@too= ls.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Frank,

 

The POT replacement at= tack (1.) is not an attack on the integrity. It is an attack on the path ve= rification.

This simple attack can= cause the verifier to accept a packet that did not go through the firewall= SF (even though it should). I believe this is exactly the problem you were aiming to address in this draft.

 

Thanks,

Tal.=

 

From: Fr= ank Brockners (fbrockne) [mailto:fbro= ckne@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary= . We’ll provide more details on 2. Per my earlier point – 1. is= an interesting discussion, given that we don’t claim to provide integrity protection for the packet payload. Or in other terms – to = be exact: What POT provides is a proof that the POT-header/meta-data transi= ted all the required nodes. There is no association (and thus proof) provid= ed for the additional data carried along with the POT-header – neither header nor payload. As a consequence, = attacks which change the packet payload won’t be detected/mitigated. = We’ll explicitly state this in the security considerations in the nex= t rev of the document.

What we could consider= is linking the RND number to CRC across the packet payload or similar R= 11; but that way we’d restrict the applicability to deployments where the packet payload isn’t changed across the path (which might = not apply to certain deployment – e.g. WAN optimization / compression= schemes).

Do you think it is wor= thwhile to provide a solution for a deployment which is expected to not alt= er the packet payload?

 

Thanks,

Frank

 

 

Hi,<= /p>

 

To summarize my take o= n this thread:

The proposed mechanism= has two significant vulnerabilities that (in my understanding) are current= ly not addressed:

1.       A man-in-the-middle can replace the PO= T of packet A with the POT of packet B.

2.       It is possible to replay POTs within a= certain time window, whose length is determined by the timestamp resolutio= n.

 

Sashank, thanks for ag= reeing to look into it further. I am looking forward to your insights on th= is.

 

Regards,

Tal.=

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 

 

 

From: Sa= shank Dara (sadara) [mailto:sadara@cisc= o.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 =

I want to ask a simple question:

If the attacker attaches the POT of packet A = (indicating the path through 1,3,5,6) to packet B, will the verifier accept= packet B and believe that its path was indeed (1,3,5,6)?

 =

[SD] If the verifier is = programmed to just validate the POT meta data against {1,3,5,6} then yes it= accepts it. 

If the verifier is progr= ammed to consult a policy database to cross check if the reconstructed path= {1,3,5,6} is as per the policies then no , it drops it . 

 =

But I see your point , t= hat the parameters used in POT data donot consider the path or node-ids etc= . We shall discuss this internally and get back.

 =

Also, We shall get back = with more concrete numbers of the timestamp resolution and cache sizes (or = other better approaches). 

 =

Thank you so much for al= l the inputs. 

 

 

 

From: Ta= l Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate th= e quick and detailed responses.

 

>>>Lets take correct path tak= en by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (= e.g. the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier on= ly constructs the path the packet took accurately, it is upto

>the application to d= etermine whether it violates any policies (I.e missing any function) <= o:p>

>The bottom line is ,= an attacker taking a different path cannot get away with it !

>The whole intent of = “proof-of-transit” is to prove the path packet has taken exactl= y. 

>POT does not define = whether it good/bad path. It is upto high level applications on what

>do with “recon= structed” path. 

 

 

 

I want to ask a simple= question:

If the attacker attach= es the POT of packet A (indicating the path through 1,3,5,6) to packet B, w= ill the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 

 

>>Hmmm… Let’s say = we are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could u= se as much precision as we want to reduce the number of values to be cached !

 

My point is that assum= ing reasonable resources are used, the mechanism is vulnerable to a replay = attack.

In order to prove me w= rong, can you present concrete numbers of the timestamp resolution and the = cache size?

Otherwise, you may con= sider using a sequence number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.=

 

 

 

From: Sa= shank Dara (sadara) [mailto:sadara@cisc= o.com]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 

 

>[SD] Ok. This is an interesting at= tack.  

> 

>Lets take correct path taken by Pa= cket A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be P= acket B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values = from Path1 and reattach them to Path2 ,

>the reconstruction for Packet= B would result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topolo= gy/policy db information for any policy

>violations. POT does not enforce a= particular path to be taken.

 

So packet B skipped node 5 (e.g. the= firewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only c= onstructs the path the packet took accurately, it is upto the application t= o determine whether it violates any policies (I.e missing any function) 

The bottom line is , an = attacker taking a different path cannot get away with it ! The whole intent= of “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whet= her it good/bad path. It is upto high level applications on what do with &#= 8220;reconstructed” path. 

 =

 

Hmmm… Let’s say we are t= alking about traffic at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of = RND-2.

Moreover, every time a packet arrive= s, the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.=

Am I missing something here?<= span lang=3D"EN-US" style=3D"font-size:10.5pt;color:black">

 

[SD] Second level precision is only an example, we could use a= s much precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A a= nd B:

- Packet A that went through the cor= rect path and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 Now the attacker performs a ‘mix = and match’ attack, by taking the correct POT from packet A and attach= ing it to packet B.<= /o:p>

The attacker also terminates packet = A.

There is no replay here, because the= verifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the v= erifier, even though it did not go through the correct path.<= /p>

 

Is there a way to mitigate this atta= ck?

 

[SD] Ok. This is an interesting attack= .  

 

Lets take correct path taken by Packet= A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packe= t B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/p= olicy db information for any policy violations. POT does not enforce a particular path to be taken.

 It just reconstructs the particu= lar path taken by the packets. 

 

Do you mean that there is a one-seco= nd-vulnerability for replay attacks?

One second is practically forever.

 

[SD] Not really , the verifier could c= ache the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerabil= ity as such, if the verifier caches those values. 

 

Effective replay prevention is typic= ally performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to inc= orporate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high= level sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential anal= ysis of CML values (across packets) becomes very easy  and predictable= .

that’s reason we recommend using=  ( Timestamp(/ sequence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our wor= k. More inline with [SD] .. 

 

 

Right, I am referring to the former. The inte= grity check is not the issue.

Let’s say we have:

- Packet A that went through the correct path= and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 

The attacker can ‘launder’ packet= B by replacing the (incorrect) POT of packet B with the correct POT of pac= ket A (and drop packet A).

Thus, packet B is verified correctly, even th= ough it did not go through the correct path.

 

[SD] This is valid scenario and we hav= e certain in-built mitigation techniques and recommendations for the same. =

There are two scenarios here 

 

Partial Replay of POT data (Replayi= ng intermediate CMLs)=

 

Attacker cannot reuse few intermediate= node’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker trie= s to replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and = participates in the reconstruction of RND-3.

Verifier’s share of RND-3 is nev= er on wire , so attacker cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying= complete RND-2)=

 

Another trick, attacker could do is by= completely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply A= ttacks” , we recommend that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D “Time Stamp + RND number”)=

So in case a passive attacker tries to= replay one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved fr= om RND-2.

If the retrieved timestamp is older th= an current timestamp we drop/raise a flag ! 

 

There is still a small window , where = the attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearl= y impossible for the attacker to replay.

For example , if the Time Stamp chosen= is 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay= within such a small time at such a high packet rates. 

 

Also , the verifier could cache, if ne= eded, certain number of previously used RND-2 to mitigate replay attacks. 

 

Hope this clarifies. 

 

--_000_99c4c8222952442f9a8c99713cbbbffeXCHRCD008ciscocom_-- From nobody Wed Jul 20 00:18:26 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340BE12DAD3; Wed, 20 Jul 2016 00:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 3wnizUK4qnAa; Wed, 20 Jul 2016 00:18:17 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F415112D5A3; Wed, 20 Jul 2016 00:18:15 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6K7I993010023; Wed, 20 Jul 2016 08:18:09 +0100 Received: from 950129200 (jplon-nat14.juniper.net [193.110.55.14]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6K7I6BQ009948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2016 08:18:06 +0100 From: "Adrian Farrel" To: "'Tal Mizrahi'" , "'Sashank Dara \(sadara\)'" , "'Frank Brockners \(fbrockne\)'" , References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Date: Wed, 20 Jul 2016 08:18:08 +0100 Message-ID: <023a01d1e256$df024db0$9d06e910$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0241_01D1E25F.40DDE730" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGnwjP8403RB3RZITNexDlhPioHQgHOVwxCAZGjq+QCnnHCCQL1sC20AqPwfdABqYRZ+QGZXaZXAkfPlN0CfN4jWgIBLcy+AVdrFS0Bh6eIiZ+xJuIg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22462.005 X-TM-AS-Result: No--32.241-10.0-31-10 X-imss-scan-details: No--32.241-10.0-31-10 X-TMASE-MatchedRID: jFqw+1pFnMyscfIVXlfrb1VN8laWo90MnuwCcgqnTfAgUEQTkIWiYgli aG5U71Ci+h4WVqRDM2Stwp9aPllPBuE5IDxKpHS7wVaayvK71l9B+8LAeeOOMH1ZAf3L+lJd753 F/IrerKEd5bUwpqpsr9Xz4rXOsFj9o28kkGKrXVqzwJcJKPFV6w48ME9K+hF0q8z7POX8FJN88o MWq8CcbopzPHGRYWxAqNKsX8Rc5Jct0WlW1s7EaVeollpgzyxA4+ZcrqvCDkEcXmBZ3mI5ST5Re TebdoC/XF6q4U3K29LA3E/7HJRrJ/nVY0DWsTq3ZWiHWRWeiRsnF9tfS9Su0JlLjDiSpE8+9tSE +/rqNhjFd3GuoNVLfW9ZGG7u+faGZ73RnaBbLFpIRA38P/dwbmKaLwu81+avuu0N7j6PSiNugYk 8OnNISUwhG6kZw/fc8GIW4FpPo/OKkK3fTpnxAylrosmS0SOAoddeo3DnwAuBTeBKqBRm8r1A/V 6RVDjDpRye3XXGd7IrSkqxa82HLHsQZsIG1c2H1yMJs9mBCcWl9VzHf0qr7peZYtcskV9PRE9xQ BYdJhOj5dd1UyGsE7k3b0GdOaeHfL+CSMa2ZdXarFB+yK/aw7tq3FNsoMQgasEfs27jsmEeoQAG Xdw2QiT0w1zt2plxNwPV2Kp9lA6+9Go4BgFPZo1nuRzhSr7jLi2dwKiMR9xo5YsPsbyLXQqQQQL Mh66ndYxO9VuCM39vjiZqcnX6cga9D+nuvxP8tNMyJ72jQd1lrsuS5tC+PxsizOQuDf4x+mDWSr 86jwHMZPgkP0CcqtkRIHRUA4VL/dCbyVkjT66eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDOG2o4D tJIL5vLE5hS3p8WRjjVhf+j/wpKdDgyPBo713kguuQorcgMOiCHLfKhbQuZKNobWmYHQ/bIfn3R K6FR7HHcBSm4mdV+3BndfXUhXQ== Archived-At: Cc: opsawg@ietf.org, nvo3@ietf.org, sfc@ietf.org Subject: Re: [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 07:18:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0241_01D1E25F.40DDE730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What is worrying me in this conversations is the discrepancy between the stated aim in draft-brockners-proof-of-transit and the function provided by the draft. I'm not (at the moment ;-) picking hols in what the S**3 scheme achieves, but I am questioning whether it provides enough to be useful in the context stated. So draft-brockners-proof-of-transit says... > This document defines mechanisms to > securely prove that traffic transited the defined path. and > In certain cases regulatory > obligations or a compliance policy require operators to prove that > all packets that are supposed to follow a specific path are indeed > being forwarded across and exact set of pre-determined nodes. Shamir as applied in this document does not meet those criteria. It only shows that all members of a defined set of nodes were traversed at some point along the path. It neither guarantees ordering, nor does it protect against the insertion of additional nodes on the path. Other parts of the document are more clear about exactly this point. it is not clear to me, therefore, whether the intention is misstated in the text I quoted, or whether the proposed solution (while good at what it does) is inadequate for the purpose. BTW, think it is not clear in the text that the order of the polynomial must count the verifying node. I.e., the verifying node must also insert a point on the curve. This is needed because otherwise the full set of points is included in a message on the wire and the polynomial becomes vulnerable. Thanks, Adrian From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tal Mizrahi Sent: 20 July 2016 05:30 To: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org Cc: opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org Subject: Re: [OPSAWG] Question regarding Proof of Transit draft Hi Sashank, >[SD] The attack is valid only if the attacker can get away bypassing a service function/node. >For example, if the attacker bypasses a node and if POT determines it did not bypass is a valid attack on the system. I would phrase it this way: *Given* a packet that did not go through its desired path, the attacker can easily make you think that it *did* go through the desired path. Sounds like a very significant vulnerability. If a packet did not go through the firewall (for one reason or another), the attacker will make you think that it did go through the firewall. Cheers, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Wednesday, July 20, 2016 4:31 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: Re: Question regarding Proof of Transit draft The POT replacement attack (1.) is not an attack on the integrity. It is an attack on the path verification. This simple attack can cause the verifier to accept a packet that did not go through the firewall SF (even though it should). I believe this is exactly the problem you were aiming to address in this draft. [SD] The attack is valid only if the attacker can get away bypassing a service function/node. For example, if the attacker bypasses a node and if POT determines it did not bypass is a valid attack on the system. In the current state, there is no way an attacker can get away as we determine the exact path the packet travelled (aim of the draft) . I reiterate that the verifier needs to handle what to do with the path reconstructed ! We could emphasize this in our next draft , but it would be beyond scope of POT to determine what to do with the path constructed. IMO, It would be highly application specific. Regards, Sashank Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier point - 1. is an interesting discussion, given that we don't claim to provide integrity protection for the packet payload. Or in other terms - to be exact: What POT provides is a proof that the POT-header/meta-data transited all the required nodes. There is no association (and thus proof) provided for the additional data carried along with the POT-header - neither header nor payload. As a consequence, attacks which change the packet payload won't be detected/mitigated. We'll explicitly state this in the security considerations in the next rev of the document. What we could consider is linking the RND number to CRC across the packet payload or similar - but that way we'd restrict the applicability to deployments where the packet payload isn't changed across the path (which might not apply to certain deployment - e.g. WAN optimization / compression schemes). Do you think it is worthwhile to provide a solution for a deployment which is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) ; Frank Brockners (fbrockne) ; draft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my understanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT of packet B. 2. It is possible to replay POTs within a certain time window, whose length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1,3,5,6) to packet B, will the verifier accept packet B and believe that its path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data against {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check if the reconstructed path {1,3,5,6} is as per the policies then no , it drops it . But I see your point , that the parameters used in POT data donot consider the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolution and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6). >>>This could be compared with topology/policy db information for any policy >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier believes it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it is upto >the application to determine whether it violates any policies (I.e missing any function) >The bottom line is , an attacker taking a different path cannot get away with it ! >The whole intent of "proof-of-transit" is to prove the path packet has taken exactly. >POT does not define whether it good/bad path. It is upto high level applications on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1,3,5,6) to packet B, will the verifier accept packet B and believe that its path was indeed (1,3,5,6)? >>Hmmm. Let's say we are talking about traffic at 10 Gbps, which is roughly >>1 million packets per second. That would mean the verifier has to store a million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare its >>RND-2 value with the 1 million stored values, in order to verify there is no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much precision as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is vulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timestamp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g., as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believes it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it is upto the application to determine whether it violates any policies (I.e missing any function) The bottom line is , an attacker taking a different path cannot get away with it ! The whole intent of "proof-of-transit" is to prove the path packet has taken exactly. POT does not define whether it good/bad path. It is upto high level applications on what do with "reconstructed" path. Hmmm. Let's say we are talking about traffic at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precision as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a correct POT. Now the attacker performs a 'mix and match' attack, by taking the correct POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L Thus, packet B appears okay to the verifier, even though it did not go through the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6). This could be compared with topology/policy db information for any policy violations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn't it be possible to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis of CML values (across packets) becomes very easy and predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a correct POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of packet B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the correct path. [SD] This is valid scenario and we have certain in-built mitigation techniques and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observe the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not intermediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (generated per packet) be a combination (I.e. RND2 = "Time Stamp + RND number") So in case a passive attacker tries to replay one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a flag ! There is still a small window , where the attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously used RND-2 to mitigate replay attacks. Hope this clarifies. ------=_NextPart_000_0241_01D1E25F.40DDE730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is worrying me in this = conversations is the discrepancy between the stated aim in = draft-brockners-proof-of-transit and the function provided by the draft. = I'm not (at the moment ;-) picking hols in what the S**3 scheme = achieves, but I am questioning whether it provides enough to be useful = in the context stated.

 

So = draft-brockners-proof-of-transit says...

 

> This document defines = mechanisms to

> securely prove that = traffic transited the defined path.

 

and

 

>  In certain cases = regulatory

>  obligations or a compliance = policy require operators to prove that

>  all packets that are supposed = to follow a specific path are indeed

>  being forwarded across and = exact set of pre-determined nodes.

 

Shamir as applied in this = document does not meet those criteria. It only shows that all members of = a defined set of nodes were traversed at some point along the path. It = neither guarantees ordering, nor does it protect against the insertion = of additional nodes on the path.

 

Other parts of the document = are more clear about exactly this point. it is not clear to me, = therefore, whether the intention is misstated in the text I quoted, or = whether the proposed solution (while good at what it does) is inadequate = for the purpose.

 

BTW,  think it is not clear in the = text that the order of the polynomial must count the verifying node. = I.e., the verifying node must also insert a point on the curve. This is = needed because otherwise the full set of points is included in a message = on the wire and the polynomial becomes = vulnerable.

 

Thanks,

Adrian

 

From: OPSAWG = [mailto:opsawg-bounces@ietf.org] On Behalf Of Tal = Mizrahi
Sent: 20 July 2016 05:30
To: Sashank Dara = (sadara); Frank Brockners (fbrockne); = draft-brockners-proof-of-transit@tools.ietf.org
Cc: = opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org
Subject: Re: = [OPSAWG] Question regarding Proof of Transit = draft

 

Hi Sashank,

 

>[SD] The attack is valid only if the = attacker can get away bypassing a service = function/node. 

>For example, if the attacker bypasses a = node and if POT determines it did not bypass is a valid attack on the = system.

 

I would phrase it this way: *Given* a = packet that did not go through its desired path, the attacker can easily = make you think that it *did* go through the desired = path.

Sounds like a very significant = vulnerability.

 

If a packet did not go through the firewall = (for one reason or another), the attacker will make you think that it = did go through the firewall.

 

Cheers,

Tal.

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com] =
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal = Mizrahi; Frank Brockners (fbrockne); = draft-brockners-proof-of-transit@tools.ietf.org
Cc: = sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: Re: = Question regarding Proof of Transit = draft

 

<= p class=3DMsoNormal> 

 

The POT replacement attack (1.) is not an = attack on the integrity. It is an attack on the path = verification.

This simple attack can cause the verifier to = accept a packet that did not go through the firewall SF (even though it = should). I believe this is exactly the problem you were aiming to = address in this draft.

 

[SD] The attack is valid only if the attacker = can get away bypassing a service = function/node. 

For example, if the attacker bypasses a node = and if POT determines it did not bypass is a valid attack on the = system.

 

In the current state, there is no way an = attacker can get away as we determine the exact path the packet = travelled (aim of the draft) . 

I reiterate that the verifier needs to handle = what to do with the path reconstructed = !

We could emphasize this in our next draft , but = it would be beyond scope of POT to determine what to do with the path = constructed. 

IMO, It would be highly application = specific. 

 

 

Regards,

Sashank

 

 

 

Thanks,

Tal.

 

From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] =
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal = Mizrahi; Sashank Dara (sadara); draft-bro= ckners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: = Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary. We’ll provide = more details on 2. Per my earlier point – 1. is an interesting = discussion, given that we don’t claim to provide integrity = protection for the packet payload. Or in other terms – to be = exact: What POT provides is a proof that the POT-header/meta-data = transited all the required nodes. There is no association (and thus = proof) provided for the additional data carried along with the = POT-header – neither header nor payload. As a consequence, attacks = which change the packet payload won’t be detected/mitigated. = We’ll explicitly state this in the security considerations in the = next rev of the document.

What we could consider is linking the RND = number to CRC across the packet payload or similar – but that way = we’d restrict the applicability to deployments where the packet = payload isn’t changed across the path (which might not apply to = certain deployment – e.g. WAN optimization / compression schemes). =

Do you think it is worthwhile to provide a = solution for a deployment which is expected to not alter the packet = payload?

 

Thanks,

Frank

 

=

From: Tal Mizrahi [mailto:talmi@marvell.com] =
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank = Dara (sadara) <sadara@cisco.com>; Frank = Brockners (fbrockne) <fbrockne@cisco.com>; draft-bro= ckners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: = Question regarding Proof of Transit draft

 

Hi,

 

To summarize my take on this = thread:

The proposed mechanism has two significant = vulnerabilities that (in my understanding) are currently not = addressed:

1.       = A man-in-the-middle can replace the POT of = packet A with the POT of packet B.

2.       = It is possible to replay POTs within a = certain time window, whose length is determined by the timestamp = resolution.

 

Sashank, thanks for agreeing to look into it = further. I am looking forward to your insights on this.

 

Regards,

Tal.

 

Link to the draft: = https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com] =
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal = Mizrahi; Frank Brockners (fbrockne); draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: = Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A = (indicating the path through 1,3,5,6) to packet B, will the verifier = accept packet B and believe that its path was indeed = (1,3,5,6)?

 

[SD] If the verifier is programmed to just = validate the POT meta data against {1,3,5,6} then yes it accepts = it. 

If the verifier is programmed to consult a = policy database to cross check if the reconstructed path {1,3,5,6} is as = per the policies then no , it drops it . 

 

But I see your point , that the parameters used = in POT data donot consider the path or node-ids etc . We shall discuss = this internally and get back.

 

Also, We shall get back with more concrete = numbers of the timestamp resolution and cache sizes (or other better = approaches). 

 

Thank you so much for all the = inputs. 

 

 

 

From: Tal Mizrahi
Sent: Tuesday, July 19, = 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners = (fbrockne); draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: = Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate the quick and detailed = responses.

 

>>>Lets take correct path taken by = Packet A  to be Path1 - ( 1,3,5,6) = nodes. 
>>>Lets assume incorrect path to be Packet B = i.e. Path2 - =  (1,2,3,6).
>>> 
>>>If the attacker = could take values from Path1 and reattach them to Path2 , =
>>>the reconstruction for PacketB would result in = (1,3,5,6) instead of (1,2,3,6). 
>>>This could be = compared with topology/policy db information for any policy =
>>>violations. POT does not enforce a particular path to be = taken.

>>So packet B skipped node 5 (e.g. the = firewall SF), but the verifier believes it went through the correct = path.
>>Would you agree?

>[SD] The verifier only constructs the path = the packet took accurately, it is upto

>the application to determine whether it = violates any policies (I.e missing any function) 

>The bottom line is , an attacker taking a = different path cannot get away with it !

>The whole intent of = “proof-of-transit” is to prove the path packet has taken = exactly. 

>POT does not define whether it good/bad = path. It is upto high level applications on what

>do with “reconstructed” = path. 

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A = (indicating the path through 1,3,5,6) to packet B, will the verifier = accept packet B and believe that its path was indeed (1,3,5,6)? =

 

 

>>Hmmm… Let’s say we are = talking about traffic at 10 Gbps, which is roughly
>>1 million = packets per second. That would mean the verifier has to store a million = values of RND-2.
>>Moreover, every time a packet arrives, the = verifier would have to compare its
>>RND-2 value with the 1 = million stored values, in order to verify there is no = replay.
>>That does not sound feasible.
>>Am I missing = something here?

>[SD] Second level precision is only an example, we = could use as much precision as we want to reduce the number of values to = be cached !

 

My point is that assuming reasonable = resources are used, the mechanism is vulnerable to a replay = attack.

In order to prove me wrong, can you present = concrete numbers of the timestamp resolution and the cache = size?

Otherwise, you may consider using a sequence = number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com] =
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal = Mizrahi; Frank Brockners (fbrockne); draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: = Question regarding Proof of Transit draft

 

 

 

 

>[SD] Ok. This is an interesting attack. =  

> 

>Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Packet B = i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values from = Path1 and reattach them to Path2 ,

>the reconstruction for PacketB would = result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/policy = db information for any policy

>violations. POT does not enforce a = particular path to be taken.

 

So packet B skipped node 5 (e.g. the firewall = SF), but the verifier believes it went through the correct = path.

Would you agree?

 

[SD] The verifier only constructs the path the = packet took accurately, it is upto the application to determine whether = it violates any policies (I.e missing any function) 

The bottom line is , an attacker taking a = different path cannot get away with it ! The whole intent of = “proof-of-transit” is to prove the path packet has taken = exactly. 

POT does not define whether it good/bad path. = It is upto high level applications on what do with = “reconstructed” path. 

 

 

Hmmm… Let’s say we are talking = about traffic at 10 Gbps, which is roughly 1 million packets per second. = That would mean the verifier has to store a million values of = RND-2.

Moreover, every time a packet arrives, the = verifier would have to compare its RND-2 value with the 1 million stored = values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we could = use as much precision as we want to reduce the number of values to be = cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com] =
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal = Mizrahi; Frank Brockners (fbrockne); draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: = Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A and = B:

- Packet A that went through the correct path = and has a correct POT.

- Packet B that did not go through the = correct path and does not have a correct POT.

 Now the attacker performs a ‘mix = and match’ attack, by taking the correct POT from packet A and = attaching it to packet B.

The attacker also terminates packet = A.

There is no replay here, because the verifier = receives the correct POT only once. The problem is that the correct POT = happens to arrive with packet B. L

Thus, packet B appears okay to the verifier, = even though it did not go through the correct path.

 

Is there a way to mitigate this = attack?

 

[SD] Ok. This is an interesting attack. =  

 

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B i.e. = Path2 -  (1,2,3,6).

 

If the attacker could take values from = Path1 and reattach them to Path2 , = the reconstruction for PacketB would result in (1,3,5,6) = instead of (1,2,3,6). 

This could be compared with topology/policy db = information for any policy violations. POT does not enforce a particular = path to be taken.

 It just reconstructs the particular path = taken by the packets. 

 

Do you mean that there is a = one-second-vulnerability for replay attacks?

One second is practically = forever.

 

[SD] Not really , the verifier could cache the = RND-2 numbers used in the time slice of one second and flush off after = every second. There is no one-second-vulnerability as such, if the = verifier caches those values. 

 

Effective replay prevention is typically = performed using a sequence number, with a sliding window to allow = out-of-order packets. Wouldn’t it be possible to incorporate such = a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high level = sequence number (at seconds level)! The challenge with using complete = RND-2 as sequence number is that the differential analysis of CML values = (across packets) becomes very easy  and predictable.

that’s reason we recommend using  ( = Timestamp(/ sequence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com] =
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal = Mizrahi; Frank Brockners (fbrockne); draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: = Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. More = inline with [SD] .. 

 

 

Right, I am referring to the former. The = integrity check is not the issue.

Let’s say we have:

- Packet A that went through the correct path = and has a correct POT.

- Packet B that did not go through the = correct path and does not have a correct POT.

 

The attacker can ‘launder’ packet = B by replacing the (incorrect) POT of packet B with the correct POT of = packet A (and drop packet A).

Thus, packet B is verified correctly, even = though it did not go through the correct path.

=

 

[SD] This is valid scenario and we have certain = in-built mitigation techniques and recommendations for the = same. 

There are two scenarios here 

 

Partial Replay of POT data (Replaying = intermediate CMLs)

 

Attacker cannot reuse few intermediate = node’s POT values (from older packet traces) as it would disrupt = the POLY-3 construction. 

On the other hand if the attacker tries to = replay entire sequence of CML values, he cannot still , because notice = that verifier also has a secret share of RND-1 and participates in the = reconstruction of RND-3.

Verifier’s share of RND-3 is never on = wire , so attacker cannot just observe the packet traces to reuse and = replay it. 

 

Total Replay of POT data (Replaying complete = RND-2)

 

Another trick, attacker could do is by = completely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply = Attacks” , we recommend that the RND-2 (generated per packet) be a = combination (I.e. RND2 =3D “Time Stamp + RND = number”)

So in case a passive attacker tries to replay = one of the correct but older RND-2, the verifier first could check the = current timestamp against the timestamp retrieved from = RND-2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 

There is still a small window , where the = attacker could replay it within the valid time slice itself but by = carefully choosing the time slice we can make it nearly impossible for = the attacker to replay.

For example , if the Time Stamp chosen is 32 = bits , we could get one seconds level precision in the time window . So = it is highly impossible for the attacker to replay within such a small = time at such a high packet rates. 

 

Also , the verifier could cache, if needed, = certain number of previously used RND-2 to mitigate replay = attacks. 

 

Hope this clarifies. 

 

=
------=_NextPart_000_0241_01D1E25F.40DDE730-- From nobody Wed Jul 20 00:57:30 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD09312B037; Wed, 20 Jul 2016 00:57:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AMHl-Kmmn75J; Wed, 20 Jul 2016 00:57:25 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC63712B004; Wed, 20 Jul 2016 00:57:25 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6K7sgaC027175; Wed, 20 Jul 2016 00:57:24 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 24a2c38mtk-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Jul 2016 00:57:23 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jul 2016 10:57:17 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Wed, 20 Jul 2016 10:57:17 +0300 From: Tal Mizrahi To: "Frank Brockners (fbrockne)" , "Sashank Dara (sadara)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tCABdCDgIALm9VQ Date: Wed, 20 Jul 2016 07:57:16 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <99c4c8222952442f9a8c99713cbbbffe@XCH-RCD-008.cisco.com> In-Reply-To: <99c4c8222952442f9a8c99713cbbbffe@XCH-RCD-008.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_a5651eb92ae74a7dae50a22eb8919b7cILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_06:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200093 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 07:57:29 -0000 --_000_a5651eb92ae74a7dae50a22eb8919b7cILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank, >Hence, I'd like to come back to my question asked below: >Do you (and the entire SFC team here) think it is worthwhile to provide >a solution for a deployment which is expected to *not* alter the packet pa= yload? In a nutshell, YES. I don't think integrity protection is a requirement here. Path validation is the requirement that you guys have raised, and I believe= it is an important requirement. Integrity protection is a way to satisfy the requirement. Cheers, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Wednesday, July 20, 2016 9:16 AM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, well... if you could protect the integrity of the data stream between sourc= e and destination, you would not be able to swap the content of a packet - = which is what your attack is all about. Rather than continue arguing the po= int, let's acknowledge that it is a valid attack and let's look for a solut= ion :-). We'll need to couple POT to integrity protection of the packet. Hence, I'd like to come back to my question asked below: Do you (and the entire SFC team here) think it is worthwhile to provide a s= olution for a deployment which is expected to *not* alter the packet payloa= d? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 18:15 To: Frank Brockners (fbrockne) >; Sashank Dara (sadara) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Frank, The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_a5651eb92ae74a7dae50a22eb8919b7cILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Frank,

 <= /p>

>Hence, I’d like= to come back to my question asked below:  

>Do you (and the entir= e SFC team here) think it is worthwhile to provide

>a solution for a depl= oyment which is expected to *not* alter the packet payload?

 <= /p>

In a nutshell, YES.<= /o:p>

I don’t think integ= rity protection is a requirement here.

Path validation is the re= quirement that you guys have raised, and I believe it is an important requi= rement.

Integrity protection is a= way to satisfy the requirement.

 <= /p>

Cheers,=

Tal.

 <= /p>

 <= /p>

From: Frank Br= ockners (fbrockne) [mailto:fbrockne@cisco.com]
Sent: Wednesday, July 20, 2016 9:16 AM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-tra= nsit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,<= /o:p>

 

well... if you could prot= ect the integrity of the data stream between source and destination, you wo= uld not be able to swap the content of a packet – which is what your attack is all about. Rather than continue arguing the point, = let’s acknowledge that it is a valid attack and let’s look for = a solution :-). We’ll need to couple POT to integrity protection of t= he packet.

 <= /p>

Hence, I’d like to = come back to my question asked below:  

Do you (and the entire SF= C team here) think it is worthwhile to provide a solution for a deployment = which is expected to *not* alter the packet payload?

 <= /p>

Thanks, Frank<= /span>

 <= /p>

From: Tal Mi= zrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 18:15
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Sashank Dara (sadara) <sadara@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Frank,

 <= /p>

The POT replacement attac= k (1.) is not an attack on the integrity. It is an attack on the path verif= ication.

This simple attack can ca= use the verifier to accept a packet that did not go through the firewall SF= (even though it should). I believe this is exactly the problem you were aiming to address in this draft.

 <= /p>

Thanks,=

Tal.

 <= /p>

From: Frank Br= ockners (fbrockne) [mailto:fbrockne@c= isco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,<= /o:p>

 

thanks for the summary. W= e’ll provide more details on 2. Per my earlier point – 1. is an= interesting discussion, given that we don’t claim to provide integri= ty protection for the packet payload. Or in other terms – to be exact: = What POT provides is a proof that the POT-header/meta-data transited all th= e required nodes. There is no association (and thus proof) provided for the= additional data carried along with the POT-header – neither header nor payload. As a consequence, attacks w= hich change the packet payload won’t be detected/mitigated. We’= ll explicitly state this in the security considerations in the next rev of = the document.

What we could consider is= linking the RND number to CRC across the packet payload or similar –= but that way we’d restrict the applicability to deployments where the packet payload isn’t changed across the path (which might not ap= ply to certain deployment – e.g. WAN optimization / compression schem= es).

Do you think it is worthw= hile to provide a solution for a deployment which is expected to not alter = the packet payload?

 <= /p>

Thanks,=

Frank

 <= /p>

From: Tal Mi= zrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,

 <= /p>

To summarize my take on t= his thread:

The proposed mechanism ha= s two significant vulnerabilities that (in my understanding) are currently = not addressed:

1. &n= bsp;     A man-in-the-middle can replace the POT o= f packet A with the POT of packet B.

2. &n= bsp;     It is possible to replay POTs within a ce= rtain time window, whose length is determined by the timestamp resolution.<= o:p>

 <= /p>

Sashank, thanks for agree= ing to look into it further. I am looking forward to your insights on this.=

 <= /p>

Regards,

Tal.

 <= /p>

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 <= /p>

 <= /p>

 

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com<= /a>]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (in= dicating the path through 1,3,5,6) to packet B, will the verifier accept pa= cket B and believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is pro= grammed to just validate the POT meta data against {1,3,5,6} then yes it ac= cepts it. 

If the verifier is programm= ed to consult a policy database to cross check if the reconstructed path {1= ,3,5,6} is as per the policies then no , it drops it . 

 

But I see your point , that= the parameters used in POT data donot consider the path or node-ids etc . = We shall discuss this internally and get back.

 

Also, We shall get back wit= h more concrete numbers of the timestamp resolution and cache sizes (or oth= er better approaches). 

 

Thank you so much for all t= he inputs. 

 

 

 

From: Tal Mizr= ahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,<= /span>

 <= /p>

I really appreciate the q= uick and detailed responses.

 <= /p>

>>>Lets take correct path taken = by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g= . the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only = constructs the path the packet took accurately, it is upto

>the application to dete= rmine whether it violates any policies (I.e missing any function) 

>The bottom line is , an= attacker taking a different path cannot get away with it !

>The whole intent of = 220;proof-of-transit” is to prove the path packet has taken exactly.&= nbsp;

>POT does not define whe= ther it good/bad path. It is upto high level applications on what

>do with “reconstr= ucted” path. 

 <= /p>

 <= /p>

 <= /p>

I want to ask a simple qu= estion:

If the attacker attaches = the POT of packet A (indicating the path through 1,3,5,6) to packet B, will= the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 <= /p>

 <= /p>

>>Hmmm… Let’s say we = are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could use = as much precision as we want to reduce the number of values to be cached !

 <= /p>

My point is that assuming= reasonable resources are used, the mechanism is vulnerable to a replay att= ack.

In order to prove me wron= g, can you present concrete numbers of the timestamp resolution and the cac= he size?

Otherwise, you may consid= er using a sequence number + sliding window (e.g., as in IPsec).

 <= /p>

 <= /p>

Thanks,=

Tal.

 <= /p>

 <= /p>

 <= /p>

 

 

 

 

>[SD] Ok. This is an interesting attac= k.  

> 

>Lets take correct path taken by Packe= t A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Pack= et B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values fro= m Path1 and reattach them to Path2 ,

>the reconstruction for PacketB w= ould result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/= policy db information for any policy

>violations. POT does not enforce a pa= rticular path to be taken.

 

So packet B skipped node 5 (e.g. the fi= rewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only cons= tructs the path the packet took accurately, it is upto the application to d= etermine whether it violates any policies (I.e missing any function) 

The bottom line is , an att= acker taking a different path cannot get away with it ! The whole intent of= “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whether= it good/bad path. It is upto high level applications on what do with ̶= 0;reconstructed” path. 

 

 

Hmmm… Let’s say we are talk= ing about traffic at 10 Gbps, which is roughly 1 million packets per second= . That would mean the verifier has to store a million values of RND-2.

Moreover, every time a packet arrives, = the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we could use as m= uch precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 =

 

We have two consecutive packets, A and = B:

- Packet A that went through the correc= t path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also terminates packet A.<= /span>

There is no replay here, because the ve= rifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the veri= fier, even though it did not go through the correct path.

 

Is there a way to mitigate this attack?=

 =

[SD] Ok. This is an interesting attack. &= nbsp;

 =

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B= i.e. Path2 -  (1,2,3,6).

 =

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/poli= cy db information for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular= path taken by the packets. 

 =

Do you mean that there is a one-second-= vulnerability for replay attacks?

One second is practically forever.

 =

[SD] Not really , the verifier could cach= e the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such= , if the verifier caches those values. 

 =

Effective replay prevention is typicall= y performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to incorporat= e such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high le= vel sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that’s reason we recommend using &n= bsp;( Timestamp(/ sequence number) + RND )

 

 =

 =

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. = More inline with [SD] .. 

 =

 =

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 =

[SD] This is valid scenario and we have c= ertain in-built mitigation techniques and recommendations for the same. 

There are two scenarios here =

 =

Partial Replay of POT data (Replaying = intermediate CMLs)=

 =

Attacker cannot reuse few intermediate no= de’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker tries t= o replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and particip= ates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never = on wire , so attacker cannot just observe the packet traces to reuse and replay it. <= /p>

 =

Total Replay of POT data (Replaying co= mplete RND-2)

 =

Another trick, attacker could do is by co= mpletely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Atta= cks” , we recommend that the RND-2 (generated per packet) be a combin= ation (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to re= play one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 =

There is still a small window , where the= attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is= 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within= such a small time at such a high packet rates. 

 =

Also , the verifier could cache, if neede= d, certain number of previously used RND-2 to mitigate replay attacks. 

 =

Hope this clarifies. 

 =

--_000_a5651eb92ae74a7dae50a22eb8919b7cILEXCH02marvellcom_-- From nobody Wed Jul 20 01:51:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F9912D0B3; Wed, 20 Jul 2016 01:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Z9kGBjnBqAga; Wed, 20 Jul 2016 01:51:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC7512B037; Wed, 20 Jul 2016 01:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=113484; q=dns/txt; s=iport; t=1469004684; x=1470214284; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l/y7QEksu2ihLw7Z24rMk1gD2sRIl0bRrHG+Giw0LrM=; b=ZDHRugNlgHtpuUOKzPACCHzEs/5EpfLGjwR0AXRdS0PbD3d0qzIjP/IB T7Lh8crTm6LEKwHU/BzP6Pbf6tDMUoTj76J2K755YI7Us7/B/jYs/fa1U fvcXRFJsJ+fZW7twTVqHkeC/NkFjyo07Fqexzbp5psvpwYMKrqr0tNUrN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQAZOo9X/4wNJK1dgnFOVnwGuGmBe?= =?us-ascii?q?iKFeAKBNTgUAQEBAQEBAWUnhFwBAQQBGgESOhIFCwIBCBEEAQEhAQYHMhQJCAI?= =?us-ascii?q?EAQ0FCBMEiAkIDr1DAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhHaFJQWII?= =?us-ascii?q?otChUIBhhKCe4JzglqCCY02kB8BHjaCCxyBTG6GLisYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208,217";a="126052198" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 08:51:21 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6K8pLxB023251 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 08:51:21 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 03:51:20 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 03:51:20 -0500 From: "Frank Brockners (fbrockne)" To: "adrian@olddog.co.uk" , "'Tal Mizrahi'" , "Sashank Dara (sadara)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: [OPSAWG] Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tD/+pFIAIAAkjGA//9h6wCAADtH4A== Date: Wed, 20 Jul 2016 08:51:20 +0000 Message-ID: <91f263bf66d642549f7cd807cfff0cdd@XCH-RCD-008.cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <023a01d1e256$df024db0$9d06e910$@olddog.co.uk> In-Reply-To: <023a01d1e256$df024db0$9d06e910$@olddog.co.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.244.97] Content-Type: multipart/alternative; boundary="_000_91f263bf66d642549f7cd807cfff0cddXCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 08:51:31 -0000 --_000_91f263bf66d642549f7cd807cfff0cddXCHRCD008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, Thanks - very helpful comments. Point well taken on the fact that POT using= SSS is to verify that a specific set of nodes has been traversed - not all= nodes, nor in a specific order. We'll definitively provide clearer and cle= aner language in the next revision. We'll also extend the draft with another approach (based on nested crypto) = which would be order preserving, at the expense to be computationally more= intense. Also per your note, we'll also expand on the role of the verifier in the ne= xt revision. Frank From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Mittwoch, 20. Juli 2016 09:18 To: 'Tal Mizrahi' ; Sashank Dara (sadara) ; Frank Brockners (fbrockne) ; draft-brockners-proo= f-of-transit@tools.ietf.org Cc: opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org Subject: RE: [OPSAWG] Question regarding Proof of Transit draft What is worrying me in this conversations is the discrepancy between the st= ated aim in draft-brockners-proof-of-transit and the function provided by t= he draft. I'm not (at the moment ;-) picking hols in what the S**3 scheme a= chieves, but I am questioning whether it provides enough to be useful in th= e context stated. So draft-brockners-proof-of-transit says... > This document defines mechanisms to > securely prove that traffic transited the defined path. and > In certain cases regulatory > obligations or a compliance policy require operators to prove that > all packets that are supposed to follow a specific path are indeed > being forwarded across and exact set of pre-determined nodes. Shamir as applied in this document does not meet those criteria. It only sh= ows that all members of a defined set of nodes were traversed at some point= along the path. It neither guarantees ordering, nor does it protect agains= t the insertion of additional nodes on the path. Other parts of the document are more clear about exactly this point. it is = not clear to me, therefore, whether the intention is misstated in the text = I quoted, or whether the proposed solution (while good at what it does) is = inadequate for the purpose. BTW, think it is not clear in the text that the order of the polynomial mu= st count the verifying node. I.e., the verifying node must also insert a po= int on the curve. This is needed because otherwise the full set of points i= s included in a message on the wire and the polynomial becomes vulnerable. Thanks, Adrian From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tal Mizrahi Sent: 20 July 2016 05:30 To: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proo= f-of-transit@tools.ietf.org Cc: opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org Subject: Re: [OPSAWG] Question regarding Proof of Transit draft Hi Sashank, >[SD] The attack is valid only if the attacker can get away bypassing a ser= vice function/node. >For example, if the attacker bypasses a node and if POT determines it did = not bypass is a valid attack on the system. I would phrase it this way: *Given* a packet that did not go through its de= sired path, the attacker can easily make you think that it *did* go through= the desired path. Sounds like a very significant vulnerability. If a packet did not go through the firewall (for one reason or another), th= e attacker will make you think that it did go through the firewall. Cheers, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Wednesday, July 20, 2016 4:31 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: Re: Question regarding Proof of Transit draft The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. [SD] The attack is valid only if the attacker can get away bypassing a serv= ice function/node. For example, if the attacker bypasses a node and if POT determines it did n= ot bypass is a valid attack on the system. In the current state, there is no way an attacker can get away as we determ= ine the exact path the packet travelled (aim of the draft) . I reiterate that the verifier needs to handle what to do with the path reco= nstructed ! We could emphasize this in our next draft , but it would be beyond scope of= POT to determine what to do with the path constructed. IMO, It would be highly application specific. Regards, Sashank Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_91f263bf66d642549f7cd807cfff0cddXCHRCD008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adrian,

 = ;

Thanks – very helpful comments. Point well taken on the fact tha= t POT using SSS is to verify that a specific set of nodes has been traversed – not all nodes, nor in a specific order. We̵= 7;ll definitively provide clearer and cleaner language in the next revision= .

We’ll also extend the draft with another approach (based on nest= ed crypto) which would be order preserving, at the expense to be  computationally more intense.

Also per your note, we’ll also expand on the role of the verifie= r in the next revision.

 

Frank

 

From: = Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Mittwoch, 20. Juli 2016 09:18
To: 'Tal Mizrahi' <talmi@marvell.com>; Sashank Dara (sadara) &= lt;sadara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com&= gt;; draft-brockners-proof-of-transit@tools.ietf.org
Cc: opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org
Subject: RE: [OPSAWG] Question regarding Proof of Transit draft=

 

What is worrying me in= this conversations is the discrepancy between the stated aim in draft-broc= kners-proof-of-transit and the function provided by the draft. I'm not (at the moment ;-) picking hols in what the S**3 sch= eme achieves, but I am questioning whether it provides enough to be useful = in the context stated.

 

So draft-brockners-pro= of-of-transit says...

 

> This document def= ines mechanisms to

> securely prove th= at traffic transited the defined path.

 

and

 

>  In certain = cases regulatory

>  obligations= or a compliance policy require operators to prove that

>  all packets= that are supposed to follow a specific path are indeed

>  being forwa= rded across and exact set of pre-determined nodes.

 

Shamir as applied in t= his document does not meet those criteria. It only shows that all members o= f a defined set of nodes were traversed at some point along the path. It neither guarantees ordering, nor does it protect = against the insertion of additional nodes on the path.

 

Other parts of the doc= ument are more clear about exactly this point. it is not clear to me, there= fore, whether the intention is misstated in the text I quoted, or whether the proposed solution (while good at what it doe= s) is inadequate for the purpose.

 

BTW,  think it is= not clear in the text that the order of the polynomial must count the veri= fying node. I.e., the verifying node must also insert a point on the curve. This is needed because otherwise the full set of poi= nts is included in a message on the wire and the polynomial becomes vulnera= ble.

 

Thanks,

Adrian

 

From: OP= SAWG [mailto:opsawg-bounces@ietf= .org] On Behalf Of Tal Mizrahi
Sent: 20 July 2016 05:30
To: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org
Cc: opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org
Subject: Re: [OPSAWG] Question regarding Proof of Transit draft=

 

Hi Sashank,=

 

>[SD] The attack is v= alid only if the attacker can get away bypassing a service function/node.&n= bsp;

>For example, if the = attacker bypasses a node and if POT determines it did not bypass is a valid= attack on the system.

 

I would phrase it this= way: *Given* a packet that did not go through its desired path, the= attacker can easily make you think that it *did* go through the desired path.

Sounds like a very sig= nificant vulnerability.

 

If a packet did not go= through the firewall (for one reason or another), the attacker will make y= ou think that it did go through the firewall.

 

Cheers,

Tal.=

 

 

From: Sa= shank Dara (sadara) [mailto:sadara@cisc= o.com]
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 =

The POT replacement attack (1.) is n= ot an attack on the integrity. It is an attack on the path verification.

This simple attack can cause the ver= ifier to accept a packet that did not go through the firewall SF (even though it should). I believe this is exactly the problem= you were aiming to address in this draft.

 =

[SD] The attack is valid= only if the attacker can get away bypassing a service function/node. =

For example, if the atta= cker bypasses a node and if POT determines it did not bypass is a valid att= ack on the system.

 =

In the current state, th= ere is no way an attacker can get away as we determine the exact path the p= acket travelled (aim of the draft) . 

I reiterate that the ver= ifier needs to handle what to do with the path reconstructed !

We could emphasize this = in our next draft , but it would be beyond scope of POT to determine what t= o do with the path constructed. 

IMO, It would be highly = application specific. 

 =

 =

Regards,

Sashank

 =

 =

 

Thanks,

Tal.

 

From: Frank Brockners (fbrockne) [mailto:f= brockne@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary. We’ll = provide more details on 2. Per my earlier point – 1. is an interesting discussion, given that we don’t claim to provide inte= grity protection for the packet payload. Or in other terms – to be ex= act: What POT provides is a proof that the POT-header/meta-data transited a= ll the required nodes. There is no association (and thus proof) provided for the additional data carried along with the P= OT-header – neither header nor payload. As a consequence, attacks whi= ch change the packet payload won’t be detected/mitigated. We’ll= explicitly state this in the security considerations in the next rev of the document.

What we could consider is linking th= e RND number to CRC across the packet payload or similar – but that way we’d restrict the applicability to deployments = where the packet payload isn’t changed across the path (which might n= ot apply to certain deployment – e.g. WAN optimization / compression = schemes).

Do you think it is worthwhile to pro= vide a solution for a deployment which is expected to not alter the packet payload?

 

Thanks,

Frank

 

From: Tal Mizrahi [mailto:talmi@marvell.com= ]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,

 

To summarize my take on this thread:=

The proposed mechanism has two signi= ficant vulnerabilities that (in my understanding) are currently not addressed:

1.   &nbs= p;   A man-in-the-middle can replace the PO= T of packet A with the POT of packet B.<= o:p>

2.   &nbs= p;   It is possible to replay POTs within a= certain time window, whose length is determined by the timestamp resolutio= n.

 

Sashank, thanks for agreeing to look= into it further. I am looking forward to your insights on this.

 

Regards,

Tal.

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01=

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A = (indicating the path through 1,3,5,6) to packet B, will the verifier accept= packet B and believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is programmed to = just validate the POT meta data against {1,3,5,6} then yes it accepts it. 

If the verifier is programmed to consu= lt a policy database to cross check if the reconstructed path {1,3,5,6} is as per the policies then no , it drops it . =

 

But I see your point , that the parame= ters used in POT data donot consider the path or node-ids etc . We shall discuss this internally and get back.

 

Also, We shall get back with more conc= rete numbers of the timestamp resolution and cache sizes (or other better approaches). 

 

Thank you so much for all the inputs.&= nbsp;

 

 

 

From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate the quick and de= tailed responses.

 

>>>Lets take correct path tak= en by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (= e.g. the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only constructs = the path the packet took accurately, it is upto

>the application to determine wheth= er it violates any policies (I.e missing any function) 

>The bottom line is , an attacker t= aking a different path cannot get away with it !

>The whole intent of “proof-o= f-transit” is to prove the path packet has taken exactly. 

>POT does not define whether it goo= d/bad path. It is upto high level applications on what

>do with “reconstructed”= ; path. <= /span>

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of = packet A (indicating the path through 1,3,5,6) to packet B, will the verifier accept packet B and believe that its path was = indeed (1,3,5,6)?

 

 

>>Hmmm… Let’s say = we are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example= , we could use as much precision as we want to reduce the number of values to be cached !

 

My point is that assuming reasonable= resources are used, the mechanism is vulnerable to a replay attack.

In order to prove me wrong, can you = present concrete numbers of the timestamp resolution and the cache size?=

Otherwise, you may consider using a = sequence number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

 

>[SD] Ok. This is an interesting at= tack.  

> 

>Lets take correct path taken by Pa= cket A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be P= acket B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values = from Path1 and reattach them to Path2 ,

>the reconstruction for Packet= B would result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topolo= gy/policy db information for any policy

>violations. POT does not enforce a= particular path to be taken.

 

So packet B skipped node 5 (e.g. the= firewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only constructs the = path the packet took accurately, it is upto the application to determine whether it violates any policies (I.e missing any function)&n= bsp;

The bottom line is , an attacker takin= g a different path cannot get away with it ! The whole intent of “proof-of-transit” is to prove the path packet has t= aken exactly. <= /o:p>

POT does not define whether it good/ba= d path. It is upto high level applications on what do with “reconstructed” path. 

 

 

Hmmm… Let’s say we are t= alking about traffic at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of = RND-2.<= /p>

Moreover, every time a packet arrive= s, the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.=

Am I missing something here?<= span lang=3D"EN-US" style=3D"color:black">

 

[SD] Second level precision is only an example, we= could use as much precision as we want to reduce the number of values to be cached !=

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A a= nd B:

- Packet A that went through the cor= rect path and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 Now the attacker performs a ‘mix = and match’ attack, by taking the correct POT from packet A and attach= ing it to packet B.<= /o:p>

The attacker also terminates packet = A.

There is no replay here, because the= verifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the v= erifier, even though it did not go through the correct path.<= /p>

 

Is there a way to mitigate this atta= ck?

 

[SD] Ok. This is an interesting attack= .  

 

Lets take correct path taken by Packet= A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packe= t B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/p= olicy db information for any policy violations. POT does not enforce a particular path to be taken.

 It just reconstructs the particu= lar path taken by the packets. 

 

Do you mean that there is a one-seco= nd-vulnerability for replay attacks?

One second is practically forever.

 

[SD] Not really , the verifier could c= ache the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerabil= ity as such, if the verifier caches those values. 

 

Effective replay prevention is typic= ally performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to inc= orporate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high= level sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential anal= ysis of CML values (across packets) becomes very easy  and predictable= .

that’s reason we recommend using=  ( Timestamp(/ sequence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our wor= k. More inline with [SD] .. 

 

 

Right, I am referring to the former. The inte= grity check is not the issue.

Let’s say we have:

- Packet A that went through the correct path= and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 

The attacker can ‘launder’ packet= B by replacing the (incorrect) POT of packet B with the correct POT of pac= ket A (and drop packet A).

Thus, packet B is verified correctly, even th= ough it did not go through the correct path.

 

[SD] This is valid scenario and we hav= e certain in-built mitigation techniques and recommendations for the same. =

There are two scenarios here 

 

Partial Replay of POT data (Replayi= ng intermediate CMLs)=

 

Attacker cannot reuse few intermediate= node’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker trie= s to replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and = participates in the reconstruction of RND-3.

Verifier’s share of RND-3 is nev= er on wire , so attacker cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying= complete RND-2)=

 

Another trick, attacker could do is by= completely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply A= ttacks” , we recommend that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D “Time Stamp + RND number”)=

So in case a passive attacker tries to= replay one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved fr= om RND-2.

If the retrieved timestamp is older th= an current timestamp we drop/raise a flag ! 

 

There is still a small window , where = the attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearl= y impossible for the attacker to replay.

For example , if the Time Stamp chosen= is 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay= within such a small time at such a high packet rates. 

 

Also , the verifier could cache, if ne= eded, certain number of previously used RND-2 to mitigate replay attacks. 

 

Hope this clarifies. 

 

--_000_91f263bf66d642549f7cd807cfff0cddXCHRCD008ciscocom_-- From nobody Wed Jul 20 02:34:01 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4DB12D158; Wed, 20 Jul 2016 02:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 V3S6pxFNVG8P; Wed, 20 Jul 2016 02:33:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561A0128E18; Wed, 20 Jul 2016 02:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10384; q=dns/txt; s=iport; t=1469007230; x=1470216830; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=74pm+5UAmFrpITJN0mgC/xESTibWDLfiEurYewAL6h4=; b=ilzRODtLoFfoKFik9jvwI7EA5fzs0edzc1iPKG4ZCge4iOcpoH1XUPl0 4PJ+k/MtAIDz39ZfoSOrMTiu1UEO7Od3x1T66tw+X6YvC2/dV9B3YZd3K XmYeHe+kAPW9ClbasJhW0R0cBrjpnOdM5ukok5F5U0XDp9g6e/mCtIUed 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgDhRI9X/4gNJK1dgz9WfAa4aoF6I?= =?us-ascii?q?oV4AhyBEjgUAQEBAQEBAWUnhFwBAQQBIxEzEgULAgEZBAEBAQICIwMCAgIwFAE?= =?us-ascii?q?ICAIEDgUbiA0IDq9YjXIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhSmBeIcsg?= =?us-ascii?q?morgi8FmSYBhhKIT485kB8BHjaCCxyBTG6GLisYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="300034161" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 09:33:49 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6K9Xmvs028246 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 09:33:49 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 05:33:47 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 05:33:46 -0400 From: "Carlos Pignataro (cpignata)" To: Tal Mizrahi Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnQWhCKL97OnUKNXabFF15a7g== Date: Wed, 20 Jul 2016 09:33:46 +0000 Message-ID: <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.88.191] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 09:33:53 -0000 VGFsLA0KDQo+IE9uIEp1bCAyMCwgMjAxNiwgYXQgNjozMCBBTSwgVGFsIE1penJhaGkgPHRhbG1p QG1hcnZlbGwuY29tPiB3cm90ZToNCj4gDQo+IEhpIFNhc2hhbmssDQo+IA0KPj4gW1NEXSBUaGUg YXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhlIGF0dGFja2VyIGNhbiBnZXQgYXdheSBieXBhc3Np bmcgYSBzZXJ2aWNlIGZ1bmN0aW9uL25vZGUuDQo+PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFj a2VyIGJ5cGFzc2VzIGEgbm9kZSBhbmQgaWYgUE9UIGRldGVybWluZXMgaXQgZGlkIG5vdCBieXBh c3MgaXMgYSB2YWxpZCBhdHRhY2sgb24gdGhlIHN5c3RlbS4NCj4gDQo+IEkgd291bGQgcGhyYXNl IGl0IHRoaXMgd2F5OiAqR2l2ZW4qIGEgcGFja2V0IHRoYXQgZGlkIG5vdCBnbyB0aHJvdWdoIGl0 cyBkZXNpcmVkIHBhdGgsIHRoZSBhdHRhY2tlciBjYW4gZWFzaWx5IG1ha2UgeW91IHRoaW5rIHRo YXQgaXQgKmRpZCogZ28gdGhyb3VnaCB0aGUgZGVzaXJlZCBwYXRoLg0KPiBTb3VuZHMgbGlrZSBh IHZlcnkgc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0eS4NCj4gDQo+IElmIGEgcGFja2V0IGRpZCBu b3QgZ28gdGhyb3VnaCB0aGUgZmlyZXdhbGwgKGZvciBvbmUgcmVhc29uIG9yIGFub3RoZXIpLCB0 aGUgYXR0YWNrZXIgd2lsbCBtYWtlIHlvdSB0aGluayB0aGF0IGl0IGRpZCBnbyB0aHJvdWdoIHRo ZSBmaXJld2FsbC4NCj4gDQoNCkxldOKAmXMgc3RlcCBiYWNrIGEgbGl0dGxlIOKAlCB0aGUg4oCc dnVsbmVyYWJpbGl0eeKAnSB5b3UgYXJlIGRlc2NyaWJpbmcgY29tZXMgd2l0aCB0aGUgYXNzdW1w dGlvbiB0aGF0IGEgTUlJVCBhdHRhY2tlciBjYW4gaW50ZXJjZXB0IGEgcGFja2V0LCBleHRyYWN0 IGEgVExWIGZyb20gdGhlIE1EIFR5cGUgMiwgZHJvcCB0aGUgcGFja2V0OyB0aGVuIGludGVyY2Vw dCBhbm90aGVyIHBhY2tldCAod2l0aCB0aGUga25vd2xlZGdlIHRoYXQgaXQgdG9vayBhIGRpZmZl cmVudCBwYXRoLCBzbyBtYXliZSB0aGUgYXR0YWNrZXIgaXMgdXNpbmcgaW5iYW5kIE9BTSBhcyB3 ZWxsIDotKSwgYW5kIGluc2VydCAob3IgbW9kaWZ5KSBhIFRMViB3aXRoaW4gdGhlIGNvbnRlbnQg b2YgdGhlIE1EIFR5cGUgMiB3aXRoaW4gdGhlIGNvbnRlbnQgb2YgTlNILCB3aXRoaW4gYSBzcGVj aWZpYyBwYWNrZXQuDQoNClRoaXMgc291bmRzIHF1aXRlIHNvcGhpc3RpY2F0ZWQuDQoNCkRvIHlv dSB0aGluayB0aGF0IGlmIGFuIE1JSVQgY2FuIGhhdmUgdGhhdCBzdXJmYWNlIG9mIGF0dGFjayBh bmQgc29waGlzdGljYXRpb24sIHRoZXkgY2FuIG1lc3MgdXAgd2l0aCBvdGhlciBldmVuIG1vcmUg Y3JpdGljYWwgdGhpbmdzPyBDaGFuZ2luZyBhIFRlbmFudCBJRCwgbWVzc2luZyB1cCB3aXRoIFBv bGljeSBHcm91cHMsIGV0Yz8gDQoNCk15IHBvaW50IGlzIHRoYXQgd2hhdCB5b3Ugc2VlbSB0byBi ZSBkZXNjcmliaW5nIGlzIGEgZ2VuZXJpYyB0aHJlYXQgdXNlIGNhc2UgYW5kIG5vdCBhIHNwZWNp ZmljIHZ1bG5lcmFiaWxpdHkuIEVuZ2luZWVyaW5nIGlzIGFib3V0IHRyYWRlLW9mZnMgKGkuZS4s IHNvbHV0aW9ucyB0aGF0IGhhdmUgcHJhY3RpY2FsIHBlcmZvcm1hbmNlKSBhbmQgYWJvdXQgcGxh Y2luZyB0aGUgc29sdXRpb24gaW4gdGhlIG1vc3QgZWZmZWN0aXZlIHBsYWNlLg0KDQpJ4oCZbSBu b3QgZGVmbGVjdGluZyBidXQgYXQgdGhlIHNhbWUgdGltZSwgbGV04oCZcyB1bmRlcnN0YW5kIHRo ZSBhc3N1bXB0aW9ucyB5b3UgYXJlIG1ha2luZyBmb3IgdGhpcyBwb3RlbnRpYWwgYXR0YWNrIHlv dSBkZXNjcmliZSwgYXMgcGFydCBvZiB0aGUgdGhyZWF0IGFuYWx5c2lzLg0KDQpUaGFua3MsDQoN CuKAlCBDYXJsb3MuDQoNCj4gQ2hlZXJzLA0KPiBUYWwuDQo+IA0KPiANCj4gRnJvbTogU2FzaGFu ayBEYXJhIChzYWRhcmEpIFttYWlsdG86c2FkYXJhQGNpc2NvLmNvbV0NCj4gU2VudDogV2VkbmVz ZGF5LCBKdWx5IDIwLCAyMDE2IDQ6MzEgQU0NCj4gVG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9j a25lcnMgKGZicm9ja25lKTsgZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMu aWV0Zi5vcmcNCj4gQ2M6IHNmY0BpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnOyBudm8zQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBk cmFmdA0KPiANCj4gDQo+IA0KPiBUaGUgUE9UIHJlcGxhY2VtZW50IGF0dGFjayAoMS4pIGlzIG5v dCBhbiBhdHRhY2sgb24gdGhlIGludGVncml0eS4gSXQgaXMgYW4gYXR0YWNrIG9uIHRoZSBwYXRo IHZlcmlmaWNhdGlvbi4NCj4gVGhpcyBzaW1wbGUgYXR0YWNrIGNhbiBjYXVzZSB0aGUgdmVyaWZp ZXIgdG8gYWNjZXB0IGEgcGFja2V0IHRoYXQgZGlkIG5vdCBnbyB0aHJvdWdoIHRoZSBmaXJld2Fs bCBTRiAoZXZlbiB0aG91Z2ggaXQgc2hvdWxkKS4gSSBiZWxpZXZlIHRoaXMgaXMgZXhhY3RseSB0 aGUgcHJvYmxlbSB5b3Ugd2VyZSBhaW1pbmcgdG8gYWRkcmVzcyBpbiB0aGlzIGRyYWZ0Lg0KPiAN Cj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhlIGF0dGFja2VyIGNhbiBnZXQg YXdheSBieXBhc3NpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uL25vZGUuDQo+IEZvciBleGFtcGxlLCBp ZiB0aGUgYXR0YWNrZXIgYnlwYXNzZXMgYSBub2RlIGFuZCBpZiBQT1QgZGV0ZXJtaW5lcyBpdCBk aWQgbm90IGJ5cGFzcyBpcyBhIHZhbGlkIGF0dGFjayBvbiB0aGUgc3lzdGVtLg0KPiANCj4gSW4g dGhlIGN1cnJlbnQgc3RhdGUsIHRoZXJlIGlzIG5vIHdheSBhbiBhdHRhY2tlciBjYW4gZ2V0IGF3 YXkgYXMgd2UgZGV0ZXJtaW5lIHRoZSBleGFjdCBwYXRoIHRoZSBwYWNrZXQgdHJhdmVsbGVkIChh aW0gb2YgdGhlIGRyYWZ0KSAuDQo+IEkgcmVpdGVyYXRlIHRoYXQgdGhlIHZlcmlmaWVyIG5lZWRz IHRvIGhhbmRsZSB3aGF0IHRvIGRvIHdpdGggdGhlIHBhdGggcmVjb25zdHJ1Y3RlZCAhDQo+IFdl IGNvdWxkIGVtcGhhc2l6ZSB0aGlzIGluIG91ciBuZXh0IGRyYWZ0ICwgYnV0IGl0IHdvdWxkIGJl IGJleW9uZCBzY29wZSBvZiBQT1QgdG8gZGV0ZXJtaW5lIHdoYXQgdG8gZG8gd2l0aCB0aGUgcGF0 aCBjb25zdHJ1Y3RlZC4NCj4gSU1PLCBJdCB3b3VsZCBiZSBoaWdobHkgYXBwbGljYXRpb24gc3Bl Y2lmaWMuDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gU2FzaGFuaw0KPiANCj4gDQo+IA0KPiBUaGFu a3MsDQo+IFRhbC4NCj4gDQo+IEZyb206IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIFttYWls dG86ZmJyb2NrbmVAY2lzY28uY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDY6 MDAgUE0NCj4gVG86IFRhbCBNaXpyYWhpOyBTYXNoYW5rIERhcmEgKHNhZGFyYSk7IGRyYWZ0LWJy b2NrbmVycy1wcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9j a25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZz4NCj4gQ2M6IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0 Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KPiBTdWJqZWN0OiBS RTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4gDQo+IEhpIFRh bCwNCj4gDQo+IHRoYW5rcyBmb3IgdGhlIHN1bW1hcnkuIFdlJ2xsIHByb3ZpZGUgbW9yZSBkZXRh aWxzIG9uIDIuIFBlciBteSBlYXJsaWVyIHBvaW50IC0gMS4gaXMgYW4gaW50ZXJlc3RpbmcgZGlz Y3Vzc2lvbiwgZ2l2ZW4gdGhhdCB3ZSBkb24ndCBjbGFpbSB0byBwcm92aWRlIGludGVncml0eSBw cm90ZWN0aW9uIGZvciB0aGUgcGFja2V0IHBheWxvYWQuIE9yIGluIG90aGVyIHRlcm1zIC0gdG8g YmUgZXhhY3Q6IFdoYXQgUE9UIHByb3ZpZGVzIGlzIGEgcHJvb2YgdGhhdCB0aGUgUE9ULWhlYWRl ci9tZXRhLWRhdGEgdHJhbnNpdGVkIGFsbCB0aGUgcmVxdWlyZWQgbm9kZXMuIFRoZXJlIGlzIG5v IGFzc29jaWF0aW9uIChhbmQgdGh1cyBwcm9vZikgcHJvdmlkZWQgZm9yIHRoZSBhZGRpdGlvbmFs IGRhdGEgY2FycmllZCBhbG9uZyB3aXRoIHRoZSBQT1QtaGVhZGVyIC0gbmVpdGhlciBoZWFkZXIg bm9yIHBheWxvYWQuIEFzIGEgY29uc2VxdWVuY2UsIGF0dGFja3Mgd2hpY2ggY2hhbmdlIHRoZSBw YWNrZXQgcGF5bG9hZCB3b24ndCBiZSBkZXRlY3RlZC9taXRpZ2F0ZWQuIFdlJ2xsIGV4cGxpY2l0 bHkgc3RhdGUgdGhpcyBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gdGhlIG5leHQg cmV2IG9mIHRoZSBkb2N1bWVudC4NCj4gV2hhdCB3ZSBjb3VsZCBjb25zaWRlciBpcyBsaW5raW5n IHRoZSBSTkQgbnVtYmVyIHRvIENSQyBhY3Jvc3MgdGhlIHBhY2tldCBwYXlsb2FkIG9yIHNpbWls YXIgLSBidXQgdGhhdCB3YXkgd2UnZCByZXN0cmljdCB0aGUgYXBwbGljYWJpbGl0eSB0byBkZXBs b3ltZW50cyB3aGVyZSB0aGUgcGFja2V0IHBheWxvYWQgaXNuJ3QgY2hhbmdlZCBhY3Jvc3MgdGhl IHBhdGggKHdoaWNoIG1pZ2h0IG5vdCBhcHBseSB0byBjZXJ0YWluIGRlcGxveW1lbnQgLSBlLmcu IFdBTiBvcHRpbWl6YXRpb24gLyBjb21wcmVzc2lvbiBzY2hlbWVzKS4NCj4gRG8geW91IHRoaW5r IGl0IGlzIHdvcnRod2hpbGUgdG8gcHJvdmlkZSBhIHNvbHV0aW9uIGZvciBhIGRlcGxveW1lbnQg d2hpY2ggaXMgZXhwZWN0ZWQgdG8gbm90IGFsdGVyIHRoZSBwYWNrZXQgcGF5bG9hZD8NCj4gDQo+ IFRoYW5rcywNCj4gRnJhbmsNCj4gDQo+IEZyb206IFRhbCBNaXpyYWhpIFttYWlsdG86dGFsbWlA bWFydmVsbC5jb21dDQo+IFNlbnQ6IERpZW5zdGFnLCAxOS4gSnVsaSAyMDE2IDE3OjQ0DQo+IFRv OiBTYXNoYW5rIERhcmEgKHNhZGFyYSkgPHNhZGFyYUBjaXNjby5jb208bWFpbHRvOnNhZGFyYUBj aXNjby5jb20+PjsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgPGZicm9ja25lQGNpc2NvLmNv bTxtYWlsdG86ZmJyb2NrbmVAY2lzY28uY29tPj47IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi10 cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJh bnNpdEB0b29scy5pZXRmLm9yZz4NCj4gQ2M6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBudm8zQGlldGYu b3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJk aW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4gDQo+IEhpLA0KPiANCj4gVG8gc3VtbWFyaXpl IG15IHRha2Ugb24gdGhpcyB0aHJlYWQ6DQo+IFRoZSBwcm9wb3NlZCBtZWNoYW5pc20gaGFzIHR3 byBzaWduaWZpY2FudCB2dWxuZXJhYmlsaXRpZXMgdGhhdCAoaW4gbXkgdW5kZXJzdGFuZGluZykg YXJlIGN1cnJlbnRseSBub3QgYWRkcmVzc2VkOg0KPiANCj4gMS4gICAgICAgQSBtYW4taW4tdGhl LW1pZGRsZSBjYW4gcmVwbGFjZSB0aGUgUE9UIG9mIHBhY2tldCBBIHdpdGggdGhlIFBPVCBvZiBw YWNrZXQgQi4NCj4gDQo+IDIuICAgICAgIEl0IGlzIHBvc3NpYmxlIHRvIHJlcGxheSBQT1RzIHdp dGhpbiBhIGNlcnRhaW4gdGltZSB3aW5kb3csIHdob3NlIGxlbmd0aCBpcyBkZXRlcm1pbmVkIGJ5 IHRoZSB0aW1lc3RhbXAgcmVzb2x1dGlvbi4NCj4gDQo+IFNhc2hhbmssIHRoYW5rcyBmb3IgYWdy ZWVpbmcgdG8gbG9vayBpbnRvIGl0IGZ1cnRoZXIuIEkgYW0gbG9va2luZyBmb3J3YXJkIHRvIHlv dXIgaW5zaWdodHMgb24gdGhpcy4NCj4gDQo+IFJlZ2FyZHMsDQo+IFRhbC4NCj4gDQo+IExpbmsg dG8gdGhlIGRyYWZ0OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJz LXByb29mLW9mLXRyYW5zaXQtMDENCj4gDQo+IA0KPiANCj4gRnJvbTogU2FzaGFuayBEYXJhIChz YWRhcmEpIFttYWlsdG86c2FkYXJhQGNpc2NvLmNvbV0NCj4gU2VudDogVHVlc2RheSwgSnVseSAx OSwgMjAxNiAxMjoyMCBQTQ0KPiBUbzogVGFsIE1penJhaGk7IEZyYW5rIEJyb2NrbmVycyAoZmJy b2NrbmUpOyBkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzxt YWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc+OyBz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFF1ZXN0aW9u IHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQo+IA0KPiANCj4gDQo+IEkgd2FudCB0 byBhc2sgYSBzaW1wbGUgcXVlc3Rpb246DQo+IElmIHRoZSBhdHRhY2tlciBhdHRhY2hlcyB0aGUg UE9UIG9mIHBhY2tldCBBIChpbmRpY2F0aW5nIHRoZSBwYXRoIHRocm91Z2ggMSwzLDUsNikgdG8g cGFja2V0IEIsIHdpbGwgdGhlIHZlcmlmaWVyIGFjY2VwdCBwYWNrZXQgQiBhbmQgYmVsaWV2ZSB0 aGF0IGl0cyBwYXRoIHdhcyBpbmRlZWQgKDEsMyw1LDYpPw0KPiANCj4gW1NEXSBJZiB0aGUgdmVy aWZpZXIgaXMgcHJvZ3JhbW1lZCB0byBqdXN0IHZhbGlkYXRlIHRoZSBQT1QgbWV0YSBkYXRhIGFn YWluc3QgezEsMyw1LDZ9IHRoZW4geWVzIGl0IGFjY2VwdHMgaXQuDQo+IElmIHRoZSB2ZXJpZmll ciBpcyBwcm9ncmFtbWVkIHRvIGNvbnN1bHQgYSBwb2xpY3kgZGF0YWJhc2UgdG8gY3Jvc3MgY2hl Y2sgaWYgdGhlIHJlY29uc3RydWN0ZWQgcGF0aCB7MSwzLDUsNn0gaXMgYXMgcGVyIHRoZSBwb2xp Y2llcyB0aGVuIG5vICwgaXQgZHJvcHMgaXQgLg0KPiANCj4gQnV0IEkgc2VlIHlvdXIgcG9pbnQg LCB0aGF0IHRoZSBwYXJhbWV0ZXJzIHVzZWQgaW4gUE9UIGRhdGEgZG9ub3QgY29uc2lkZXIgdGhl IHBhdGggb3Igbm9kZS1pZHMgZXRjIC4gV2Ugc2hhbGwgZGlzY3VzcyB0aGlzIGludGVybmFsbHkg YW5kIGdldCBiYWNrLg0KPiANCj4gQWxzbywgV2Ugc2hhbGwgZ2V0IGJhY2sgd2l0aCBtb3JlIGNv bmNyZXRlIG51bWJlcnMgb2YgdGhlIHRpbWVzdGFtcCByZXNvbHV0aW9uIGFuZCBjYWNoZSBzaXpl cyAob3Igb3RoZXIgYmV0dGVyIGFwcHJvYWNoZXMpLg0KPiANCj4gVGhhbmsgeW91IHNvIG11Y2gg Zm9yIGFsbCB0aGUgaW5wdXRzLg0KPiANCj4gDQo+IA0KPiBGcm9tOiBUYWwgTWl6cmFoaQ0KPiBT ZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDEwOjI4IEFNDQo+IFRvOiAnU2FzaGFuayBEYXJh IChzYWRhcmEpJzsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSk7IGRyYWZ0LWJyb2NrbmVycy1w cm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25lcnMtcHJv b2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KPiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5z aXQgZHJhZnQNCj4gDQo+IERlYXIgU2FzaGFuaywNCj4gDQo+IEkgcmVhbGx5IGFwcHJlY2lhdGUg dGhlIHF1aWNrIGFuZCBkZXRhaWxlZCByZXNwb25zZXMuDQo+IA0KPj4+PiBMZXRzIHRha2UgY29y cmVjdCBwYXRoIHRha2VuIGJ5IFBhY2tldCBBICB0byBiZSBQYXRoMSAtICggMSwzLDUsNikgbm9k ZXMNCg0K From nobody Wed Jul 20 02:43:03 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B957112D134; Wed, 20 Jul 2016 02:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yr0A7cTc3FWy; Wed, 20 Jul 2016 02:42:59 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0424F12D096; Wed, 20 Jul 2016 02:42:58 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6K9ddiU023071; Wed, 20 Jul 2016 02:42:57 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 24a2qw8yyp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Jul 2016 02:42:57 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jul 2016 12:42:54 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Wed, 20 Jul 2016 12:42:54 +0300 From: Tal Mizrahi To: "Carlos Pignataro (cpignata)" Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnUR6x6RUowp0WBJweV5BhC9aAhDzig Date: Wed, 20 Jul 2016 09:42:53 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> In-Reply-To: <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_06:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200112 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 09:43:01 -0000 SGkgQ2FybG9zLA0KDQoNCj5MZXTigJlzIHN0ZXAgYmFjayBhIGxpdHRsZSDigJQgdGhlIOKAnHZ1 bG5lcmFiaWxpdHnigJ0geW91IGFyZSBkZXNjcmliaW5nIGNvbWVzIHdpdGggdGhlDQo+YXNzdW1w dGlvbiB0aGF0IGEgTUlJVCBhdHRhY2tlciBjYW4gaW50ZXJjZXB0IGEgcGFja2V0LCBleHRyYWN0 IGEgVExWIGZyb20NCj50aGUgTUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNrZXQ7IHRoZW4gaW50ZXJj ZXB0IGFub3RoZXIgcGFja2V0ICh3aXRoIHRoZQ0KPmtub3dsZWRnZSB0aGF0IGl0IHRvb2sgYSBk aWZmZXJlbnQgcGF0aCwgc28gbWF5YmUgdGhlIGF0dGFja2VyIGlzIHVzaW5nIGluYmFuZA0KPk9B TSBhcyB3ZWxsIDotKSwgYW5kIGluc2VydCAob3IgbW9kaWZ5KSBhIFRMViB3aXRoaW4gdGhlIGNv bnRlbnQgb2YgdGhlIE1EDQo+VHlwZSAyIHdpdGhpbiB0aGUgY29udGVudCBvZiBOU0gsIHdpdGhp biBhIHNwZWNpZmljIHBhY2tldC4NCj4NCj5UaGlzIHNvdW5kcyBxdWl0ZSBzb3BoaXN0aWNhdGVk Lg0KDQpJIGFtIG5vdCBzdXJlIEkgYWdyZWUgdGhpcyBpcyBhICdzb3BoaXN0aWNhdGVkJyBhdHRh Y2suDQpUaGUgYXR0YWNrIGRvZXMgbm90IHJlcXVpcmUgYW55IGNyeXB0b2dyYXBoaWMgb3IgYWxn b3JpdGhtaWMgZnVuY3Rpb25hbGl0eSwgYW5kIHRvIHRoYXQgZW5kIGl0IGlzIHZlcnkgbGlnaHR3 ZWlnaHQgaW4gdGVybXMgb2YgcHJvY2Vzc2luZyByZXNvdXJjZXMuDQoNCklmIHRoaXMga2luZCBv ZiBhdHRhY2sgaXMgbm90IHdpdGhpbiB0aGUgc2NvcGUgaGVyZSwgdGhlbiBJIHdvdWxkIGFyZ3Vl IHRoYXQgeW91IGRvbid0IG5lZWQgYSBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBhdCBhbGwuIEFs bCB5b3UgbmVlZCBpcyBhIFRMViB0aGF0IHNwZWNpZmllcyB0aGUgbGlzdCBvZiBub2Rlcy4gSG93 ZXZlciwgSSBiZWxpZXZlIHRoYXQgeW91IGRpZCB3YW50IHRvIHRyeSB0byBtaXRpZ2F0ZSBNSVRN IGF0dGFja2Vycy4gQ29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLg0KDQpJIGZ1bGx5IGFncmVlIHRo YXQgdGhlIHRocmVhdCBtb2RlbCBuZWVkcyB0byBiZSB3ZWxsLWRlZmluZWQuIEkgaG9wZSB5b3Ug d2lsbCBlbGFib3JhdGUgbW9yZSBvbiB0aGUgdGhyZWF0IG1vZGVsIGluIHRoZSBuZXh0IHZlcnNp b24gb2YgdGhlIGRyYWZ0Lg0KDQpDaGVlcnMsDQpUYWwuDQoNCg0KPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+RnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3Bp Z25hdGFAY2lzY28uY29tXQ0KPlNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMCwgMjAxNiAxMTozNCBB TQ0KPlRvOiBUYWwgTWl6cmFoaQ0KPkNjOiBTYXNoYW5rIERhcmEgKHNhZGFyYSk7IEZyYW5rIEJy b2NrbmVycyAoZmJyb2NrbmUpOyBkcmFmdC1icm9ja25lcnMtcHJvb2YtDQo+b2YtdHJhbnNpdEB0 b29scy5pZXRmLm9yZzsgc2ZjQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc7IG52bzNAaWV0Zi5v cmcNCj5TdWJqZWN0OiBNRCBUeXBlIGF0dGFjayAoV2FzOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJv b2Ygb2YgVHJhbnNpdCBkcmFmdCkNCj4NCj5UYWwsDQo+DQo+PiBPbiBKdWwgMjAsIDIwMTYsIGF0 IDY6MzAgQU0sIFRhbCBNaXpyYWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+Pg0KPj4g SGkgU2FzaGFuaywNCj4+DQo+Pj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhl IGF0dGFja2VyIGNhbiBnZXQgYXdheSBieXBhc3NpbmcgYQ0KPnNlcnZpY2UgZnVuY3Rpb24vbm9k ZS4NCj4+PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFja2VyIGJ5cGFzc2VzIGEgbm9kZSBhbmQg aWYgUE9UIGRldGVybWluZXMgaXQgZGlkDQo+bm90IGJ5cGFzcyBpcyBhIHZhbGlkIGF0dGFjayBv biB0aGUgc3lzdGVtLg0KPj4NCj4+IEkgd291bGQgcGhyYXNlIGl0IHRoaXMgd2F5OiAqR2l2ZW4q IGEgcGFja2V0IHRoYXQgZGlkIG5vdCBnbyB0aHJvdWdoIGl0cw0KPmRlc2lyZWQgcGF0aCwgdGhl IGF0dGFja2VyIGNhbiBlYXNpbHkgbWFrZSB5b3UgdGhpbmsgdGhhdCBpdCAqZGlkKiBnbyB0aHJv dWdoDQo+dGhlIGRlc2lyZWQgcGF0aC4NCj4+IFNvdW5kcyBsaWtlIGEgdmVyeSBzaWduaWZpY2Fu dCB2dWxuZXJhYmlsaXR5Lg0KPj4NCj4+IElmIGEgcGFja2V0IGRpZCBub3QgZ28gdGhyb3VnaCB0 aGUgZmlyZXdhbGwgKGZvciBvbmUgcmVhc29uIG9yIGFub3RoZXIpLCB0aGUNCj5hdHRhY2tlciB3 aWxsIG1ha2UgeW91IHRoaW5rIHRoYXQgaXQgZGlkIGdvIHRocm91Z2ggdGhlIGZpcmV3YWxsLg0K Pj4NCj4NCj5MZXTigJlzIHN0ZXAgYmFjayBhIGxpdHRsZSDigJQgdGhlIOKAnHZ1bG5lcmFiaWxp dHnigJ0geW91IGFyZSBkZXNjcmliaW5nIGNvbWVzIHdpdGggdGhlDQo+YXNzdW1wdGlvbiB0aGF0 IGEgTUlJVCBhdHRhY2tlciBjYW4gaW50ZXJjZXB0IGEgcGFja2V0LCBleHRyYWN0IGEgVExWIGZy b20NCj50aGUgTUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNrZXQ7IHRoZW4gaW50ZXJjZXB0IGFub3Ro ZXIgcGFja2V0ICh3aXRoIHRoZQ0KPmtub3dsZWRnZSB0aGF0IGl0IHRvb2sgYSBkaWZmZXJlbnQg cGF0aCwgc28gbWF5YmUgdGhlIGF0dGFja2VyIGlzIHVzaW5nIGluYmFuZA0KPk9BTSBhcyB3ZWxs IDotKSwgYW5kIGluc2VydCAob3IgbW9kaWZ5KSBhIFRMViB3aXRoaW4gdGhlIGNvbnRlbnQgb2Yg dGhlIE1EDQo+VHlwZSAyIHdpdGhpbiB0aGUgY29udGVudCBvZiBOU0gsIHdpdGhpbiBhIHNwZWNp ZmljIHBhY2tldC4NCj4NCj5UaGlzIHNvdW5kcyBxdWl0ZSBzb3BoaXN0aWNhdGVkLg0KPg0KPkRv IHlvdSB0aGluayB0aGF0IGlmIGFuIE1JSVQgY2FuIGhhdmUgdGhhdCBzdXJmYWNlIG9mIGF0dGFj ayBhbmQNCj5zb3BoaXN0aWNhdGlvbiwgdGhleSBjYW4gbWVzcyB1cCB3aXRoIG90aGVyIGV2ZW4g bW9yZSBjcml0aWNhbCB0aGluZ3M/DQo+Q2hhbmdpbmcgYSBUZW5hbnQgSUQsIG1lc3NpbmcgdXAg d2l0aCBQb2xpY3kgR3JvdXBzLCBldGM/DQo+DQo+TXkgcG9pbnQgaXMgdGhhdCB3aGF0IHlvdSBz ZWVtIHRvIGJlIGRlc2NyaWJpbmcgaXMgYSBnZW5lcmljIHRocmVhdCB1c2UgY2FzZQ0KPmFuZCBu b3QgYSBzcGVjaWZpYyB2dWxuZXJhYmlsaXR5LiBFbmdpbmVlcmluZyBpcyBhYm91dCB0cmFkZS1v ZmZzIChpLmUuLCBzb2x1dGlvbnMNCj50aGF0IGhhdmUgcHJhY3RpY2FsIHBlcmZvcm1hbmNlKSBh bmQgYWJvdXQgcGxhY2luZyB0aGUgc29sdXRpb24gaW4gdGhlIG1vc3QNCj5lZmZlY3RpdmUgcGxh Y2UuDQo+DQo+SeKAmW0gbm90IGRlZmxlY3RpbmcgYnV0IGF0IHRoZSBzYW1lIHRpbWUsIGxldOKA mXMgdW5kZXJzdGFuZCB0aGUgYXNzdW1wdGlvbnMgeW91DQo+YXJlIG1ha2luZyBmb3IgdGhpcyBw b3RlbnRpYWwgYXR0YWNrIHlvdSBkZXNjcmliZSwgYXMgcGFydCBvZiB0aGUgdGhyZWF0DQo+YW5h bHlzaXMuDQo+DQo+VGhhbmtzLA0KPg0KPuKAlCBDYXJsb3MuDQo+DQo+PiBDaGVlcnMsDQo+PiBU YWwuDQo+Pg0KPj4NCj4+IEZyb206IFNhc2hhbmsgRGFyYSAoc2FkYXJhKSBbbWFpbHRvOnNhZGFy YUBjaXNjby5jb21dDQo+PiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjAsIDIwMTYgNDozMSBBTQ0K Pj4gVG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsgZHJhZnQtYnJv Y2tuZXJzLXByb29mLW9mLQ0KPnRyYW5zaXRAdG9vbHMuaWV0Zi5vcmcNCj4+IENjOiBzZmNAaWV0 Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFF1 ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQo+Pg0KPj4NCj4+DQo+PiBU aGUgUE9UIHJlcGxhY2VtZW50IGF0dGFjayAoMS4pIGlzIG5vdCBhbiBhdHRhY2sgb24gdGhlIGlu dGVncml0eS4gSXQgaXMgYW4NCj5hdHRhY2sgb24gdGhlIHBhdGggdmVyaWZpY2F0aW9uLg0KPj4g VGhpcyBzaW1wbGUgYXR0YWNrIGNhbiBjYXVzZSB0aGUgdmVyaWZpZXIgdG8gYWNjZXB0IGEgcGFj a2V0IHRoYXQgZGlkIG5vdCBnbw0KPnRocm91Z2ggdGhlIGZpcmV3YWxsIFNGIChldmVuIHRob3Vn aCBpdCBzaG91bGQpLiBJIGJlbGlldmUgdGhpcyBpcyBleGFjdGx5IHRoZQ0KPnByb2JsZW0geW91 IHdlcmUgYWltaW5nIHRvIGFkZHJlc3MgaW4gdGhpcyBkcmFmdC4NCj4+DQo+PiBbU0RdIFRoZSBh dHRhY2sgaXMgdmFsaWQgb25seSBpZiB0aGUgYXR0YWNrZXIgY2FuIGdldCBhd2F5IGJ5cGFzc2lu ZyBhIHNlcnZpY2UNCj5mdW5jdGlvbi9ub2RlLg0KPj4gRm9yIGV4YW1wbGUsIGlmIHRoZSBhdHRh Y2tlciBieXBhc3NlcyBhIG5vZGUgYW5kIGlmIFBPVCBkZXRlcm1pbmVzIGl0IGRpZA0KPm5vdCBi eXBhc3MgaXMgYSB2YWxpZCBhdHRhY2sgb24gdGhlIHN5c3RlbS4NCj4+DQo+PiBJbiB0aGUgY3Vy cmVudCBzdGF0ZSwgdGhlcmUgaXMgbm8gd2F5IGFuIGF0dGFja2VyIGNhbiBnZXQgYXdheSBhcyB3 ZQ0KPmRldGVybWluZSB0aGUgZXhhY3QgcGF0aCB0aGUgcGFja2V0IHRyYXZlbGxlZCAoYWltIG9m IHRoZSBkcmFmdCkgLg0KPj4gSSByZWl0ZXJhdGUgdGhhdCB0aGUgdmVyaWZpZXIgbmVlZHMgdG8g aGFuZGxlIHdoYXQgdG8gZG8gd2l0aCB0aGUgcGF0aA0KPnJlY29uc3RydWN0ZWQgIQ0KPj4gV2Ug Y291bGQgZW1waGFzaXplIHRoaXMgaW4gb3VyIG5leHQgZHJhZnQgLCBidXQgaXQgd291bGQgYmUg YmV5b25kIHNjb3BlIG9mDQo+UE9UIHRvIGRldGVybWluZSB3aGF0IHRvIGRvIHdpdGggdGhlIHBh dGggY29uc3RydWN0ZWQuDQo+PiBJTU8sIEl0IHdvdWxkIGJlIGhpZ2hseSBhcHBsaWNhdGlvbiBz cGVjaWZpYy4NCj4+DQo+Pg0KPj4gUmVnYXJkcywNCj4+IFNhc2hhbmsNCj4+DQo+Pg0KPj4NCj4+ IFRoYW5rcywNCj4+IFRhbC4NCj4+DQo+PiBGcm9tOiBGcmFuayBCcm9ja25lcnMgKGZicm9ja25l KSBbbWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbV0NCj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTks IDIwMTYgNjowMCBQTQ0KPj4gVG86IFRhbCBNaXpyYWhpOyBTYXNoYW5rIERhcmEgKHNhZGFyYSk7 IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi0NCj50cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtDQo+dHJhbnNpdEB0b29scy5pZXRmLm9yZz4NCj4+ IENjOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47DQo+b3BzYXdnQGlldGYub3Jn PG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+Ow0KPm52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0 Zi5vcmc+DQo+PiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5z aXQgZHJhZnQNCj4+DQo+PiBIaSBUYWwsDQo+Pg0KPj4gdGhhbmtzIGZvciB0aGUgc3VtbWFyeS4g V2UnbGwgcHJvdmlkZSBtb3JlIGRldGFpbHMgb24gMi4gUGVyIG15IGVhcmxpZXINCj5wb2ludCAt IDEuIGlzIGFuIGludGVyZXN0aW5nIGRpc2N1c3Npb24sIGdpdmVuIHRoYXQgd2UgZG9uJ3QgY2xh aW0gdG8gcHJvdmlkZQ0KPmludGVncml0eSBwcm90ZWN0aW9uIGZvciB0aGUgcGFja2V0IHBheWxv YWQuIE9yIGluIG90aGVyIHRlcm1zIC0gdG8gYmUgZXhhY3Q6DQo+V2hhdCBQT1QgcHJvdmlkZXMg aXMgYSBwcm9vZiB0aGF0IHRoZSBQT1QtaGVhZGVyL21ldGEtZGF0YSB0cmFuc2l0ZWQgYWxsIHRo ZQ0KPnJlcXVpcmVkIG5vZGVzLiBUaGVyZSBpcyBubyBhc3NvY2lhdGlvbiAoYW5kIHRodXMgcHJv b2YpIHByb3ZpZGVkIGZvciB0aGUNCj5hZGRpdGlvbmFsIGRhdGEgY2FycmllZCBhbG9uZyB3aXRo IHRoZSBQT1QtaGVhZGVyIC0gbmVpdGhlciBoZWFkZXIgbm9yDQo+cGF5bG9hZC4gQXMgYSBjb25z ZXF1ZW5jZSwgYXR0YWNrcyB3aGljaCBjaGFuZ2UgdGhlIHBhY2tldCBwYXlsb2FkIHdvbid0DQo+ YmUgZGV0ZWN0ZWQvbWl0aWdhdGVkLiBXZSdsbCBleHBsaWNpdGx5IHN0YXRlIHRoaXMgaW4gdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQo+aW4gdGhlIG5leHQgcmV2IG9mIHRoZSBkb2N1bWVu dC4NCj4+IFdoYXQgd2UgY291bGQgY29uc2lkZXIgaXMgbGlua2luZyB0aGUgUk5EIG51bWJlciB0 byBDUkMgYWNyb3NzIHRoZSBwYWNrZXQNCj5wYXlsb2FkIG9yIHNpbWlsYXIgLSBidXQgdGhhdCB3 YXkgd2UnZCByZXN0cmljdCB0aGUgYXBwbGljYWJpbGl0eSB0byBkZXBsb3ltZW50cw0KPndoZXJl IHRoZSBwYWNrZXQgcGF5bG9hZCBpc24ndCBjaGFuZ2VkIGFjcm9zcyB0aGUgcGF0aCAod2hpY2gg bWlnaHQgbm90DQo+YXBwbHkgdG8gY2VydGFpbiBkZXBsb3ltZW50IC0gZS5nLiBXQU4gb3B0aW1p emF0aW9uIC8gY29tcHJlc3Npb24gc2NoZW1lcykuDQo+PiBEbyB5b3UgdGhpbmsgaXQgaXMgd29y dGh3aGlsZSB0byBwcm92aWRlIGEgc29sdXRpb24gZm9yIGEgZGVwbG95bWVudCB3aGljaCBpcw0K PmV4cGVjdGVkIHRvIG5vdCBhbHRlciB0aGUgcGFja2V0IHBheWxvYWQ/DQo+Pg0KPj4gVGhhbmtz LA0KPj4gRnJhbmsNCj4+DQo+PiBGcm9tOiBUYWwgTWl6cmFoaSBbbWFpbHRvOnRhbG1pQG1hcnZl bGwuY29tXQ0KPj4gU2VudDogRGllbnN0YWcsIDE5LiBKdWxpIDIwMTYgMTc6NDQNCj4+IFRvOiBT YXNoYW5rIERhcmEgKHNhZGFyYSkNCj48c2FkYXJhQGNpc2NvLmNvbTxtYWlsdG86c2FkYXJhQGNp c2NvLmNvbT4+OyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKQ0KPjxmYnJvY2tuZUBjaXNjby5j b208bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+OyBkcmFmdC1icm9ja25lcnMtDQo+cHJvb2Yt b2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9m LQ0KPnRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc+DQo+PiBDYzogc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Ow0KPm9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsN Cj5udm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KPj4gU3ViamVjdDogUkU6IFF1 ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQo+Pg0KPj4gSGksDQo+Pg0K Pj4gVG8gc3VtbWFyaXplIG15IHRha2Ugb24gdGhpcyB0aHJlYWQ6DQo+PiBUaGUgcHJvcG9zZWQg bWVjaGFuaXNtIGhhcyB0d28gc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0aWVzIHRoYXQgKGluIG15 DQo+dW5kZXJzdGFuZGluZykgYXJlIGN1cnJlbnRseSBub3QgYWRkcmVzc2VkOg0KPj4NCj4+IDEu ICAgICAgIEEgbWFuLWluLXRoZS1taWRkbGUgY2FuIHJlcGxhY2UgdGhlIFBPVCBvZiBwYWNrZXQg QSB3aXRoIHRoZSBQT1Qgb2YNCj5wYWNrZXQgQi4NCj4+DQo+PiAyLiAgICAgICBJdCBpcyBwb3Nz aWJsZSB0byByZXBsYXkgUE9UcyB3aXRoaW4gYSBjZXJ0YWluIHRpbWUgd2luZG93LCB3aG9zZQ0K Pmxlbmd0aCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSB0aW1lc3RhbXAgcmVzb2x1dGlvbi4NCj4+DQo+ PiBTYXNoYW5rLCB0aGFua3MgZm9yIGFncmVlaW5nIHRvIGxvb2sgaW50byBpdCBmdXJ0aGVyLiBJ IGFtIGxvb2tpbmcgZm9yd2FyZCB0bw0KPnlvdXIgaW5zaWdodHMgb24gdGhpcy4NCj4+DQo+PiBS ZWdhcmRzLA0KPj4gVGFsLg0KPj4NCj4+IExpbmsgdG8gdGhlIGRyYWZ0OiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPnRyYW5zaXQtMDENCj4+ DQo+Pg0KPj4NCj4+IEZyb206IFNhc2hhbmsgRGFyYSAoc2FkYXJhKSBbbWFpbHRvOnNhZGFyYUBj aXNjby5jb21dDQo+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDEyOjIwIFBNDQo+PiBU bzogVGFsIE1penJhaGk7IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpOyBkcmFmdC1icm9ja25l cnMtcHJvb2Ytb2YtDQo+dHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJvY2tu ZXJzLXByb29mLW9mLQ0KPnRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc+OyBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJv b2Ygb2YgVHJhbnNpdCBkcmFmdA0KPj4NCj4+DQo+Pg0KPj4gSSB3YW50IHRvIGFzayBhIHNpbXBs ZSBxdWVzdGlvbjoNCj4+IElmIHRoZSBhdHRhY2tlciBhdHRhY2hlcyB0aGUgUE9UIG9mIHBhY2tl dCBBIChpbmRpY2F0aW5nIHRoZSBwYXRoIHRocm91Z2gNCj4xLDMsNSw2KSB0byBwYWNrZXQgQiwg d2lsbCB0aGUgdmVyaWZpZXIgYWNjZXB0IHBhY2tldCBCIGFuZCBiZWxpZXZlIHRoYXQgaXRzIHBh dGgNCj53YXMgaW5kZWVkICgxLDMsNSw2KT8NCj4+DQo+PiBbU0RdIElmIHRoZSB2ZXJpZmllciBp cyBwcm9ncmFtbWVkIHRvIGp1c3QgdmFsaWRhdGUgdGhlIFBPVCBtZXRhIGRhdGEgYWdhaW5zdA0K PnsxLDMsNSw2fSB0aGVuIHllcyBpdCBhY2NlcHRzIGl0Lg0KPj4gSWYgdGhlIHZlcmlmaWVyIGlz IHByb2dyYW1tZWQgdG8gY29uc3VsdCBhIHBvbGljeSBkYXRhYmFzZSB0byBjcm9zcyBjaGVjayBp Zg0KPnRoZSByZWNvbnN0cnVjdGVkIHBhdGggezEsMyw1LDZ9IGlzIGFzIHBlciB0aGUgcG9saWNp ZXMgdGhlbiBubyAsIGl0IGRyb3BzIGl0IC4NCj4+DQo+PiBCdXQgSSBzZWUgeW91ciBwb2ludCAs IHRoYXQgdGhlIHBhcmFtZXRlcnMgdXNlZCBpbiBQT1QgZGF0YSBkb25vdCBjb25zaWRlcg0KPnRo ZSBwYXRoIG9yIG5vZGUtaWRzIGV0YyAuIFdlIHNoYWxsIGRpc2N1c3MgdGhpcyBpbnRlcm5hbGx5 IGFuZCBnZXQgYmFjay4NCj4+DQo+PiBBbHNvLCBXZSBzaGFsbCBnZXQgYmFjayB3aXRoIG1vcmUg Y29uY3JldGUgbnVtYmVycyBvZiB0aGUgdGltZXN0YW1wDQo+cmVzb2x1dGlvbiBhbmQgY2FjaGUg c2l6ZXMgKG9yIG90aGVyIGJldHRlciBhcHByb2FjaGVzKS4NCj4+DQo+PiBUaGFuayB5b3Ugc28g bXVjaCBmb3IgYWxsIHRoZSBpbnB1dHMuDQo+Pg0KPj4NCj4+DQo+PiBGcm9tOiBUYWwgTWl6cmFo aQ0KPj4gU2VudDogVHVlc2RheSwgSnVseSAxOSwgMjAxNiAxMDoyOCBBTQ0KPj4gVG86ICdTYXNo YW5rIERhcmEgKHNhZGFyYSknOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsgZHJhZnQtYnJv Y2tuZXJzLQ0KPnByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWJy b2NrbmVycy1wcm9vZi1vZi0NCj50cmFuc2l0QHRvb2xzLmlldGYub3JnPjsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5n IFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4+DQo+PiBEZWFyIFNhc2hhbmssDQo+Pg0KPj4gSSBy ZWFsbHkgYXBwcmVjaWF0ZSB0aGUgcXVpY2sgYW5kIGRldGFpbGVkIHJlc3BvbnNlcy4NCj4+DQo+ Pj4+PiBMZXRzIHRha2UgY29ycmVjdCBwYXRoIHRha2VuIGJ5IFBhY2tldCBBICB0byBiZSBQYXRo MSAtICggMSwzLDUsNikgbm9kZXMNCg0K From nobody Wed Jul 20 02:51:15 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8826912DB0A; Wed, 20 Jul 2016 02:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 CQPp-a4ZnOyR; Wed, 20 Jul 2016 02:51:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB71412DA1E; Wed, 20 Jul 2016 02:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14188; q=dns/txt; s=iport; t=1469008269; x=1470217869; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xYJVKkwt7sFtJXeuOXLrgHxyCErHHGKdK3pG/4PU5CQ=; b=NEGfR7F3tC2x/M3CIGeUYqcKmo0sIt8nAujKIYfLHv7VE2mQ2KIPzM4s XG07Rc+zw0yuntpuE9Hlntpr8InjPXCJhGYt7vjLqKEh1LWFOKkLH5201 jbqQjGHtDhJcSEH6uqeeG1+zVf0Lm2nuqSdGpH6HZZFmUC14Yql4o5ybK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgBKSI9X/4MNJK1dgz9WfAa4a4F6I?= =?us-ascii?q?oV4AhyBEjgUAQEBAQEBAWUnhFwBAQQBIxEzEgUHBAIBCBEEAQEBAgIjAwICAjA?= =?us-ascii?q?UAQgIAgQOBRuIDQgOr1WNdAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQGFKYF4C?= =?us-ascii?q?IJNhFeCaiuCLwWZJgGGEohPjzmQHwEeNoILHIFMboYuKxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="126081728" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 09:51:08 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6K9p8AI013616 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 09:51:08 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 05:51:05 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 05:51:05 -0400 From: "Carlos Pignataro (cpignata)" To: Tal Mizrahi Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnQwDyp0062d0e9x6ZtxvV7RaAhVGaAgAACSQA= Date: Wed, 20 Jul 2016 09:51:05 +0000 Message-ID: <16454292-3ADD-402A-AED6-CB785C5C833B@cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.88.191] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 09:51:12 -0000 SGksIFRhbCwNCg0KPiBPbiBKdWwgMjAsIDIwMTYsIGF0IDExOjQyIEFNLCBUYWwgTWl6cmFoaSA8 dGFsbWlAbWFydmVsbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgQ2FybG9zLA0KPiANCj4gDQo+PiBM ZXTigJlzIHN0ZXAgYmFjayBhIGxpdHRsZSDigJQgdGhlIOKAnHZ1bG5lcmFiaWxpdHnigJ0geW91 IGFyZSBkZXNjcmliaW5nIGNvbWVzIHdpdGggdGhlDQo+PiBhc3N1bXB0aW9uIHRoYXQgYSBNSUlU IGF0dGFja2VyIGNhbiBpbnRlcmNlcHQgYSBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbQ0KPj4g dGhlIE1EIFR5cGUgMiwgZHJvcCB0aGUgcGFja2V0OyB0aGVuIGludGVyY2VwdCBhbm90aGVyIHBh Y2tldCAod2l0aCB0aGUNCj4+IGtub3dsZWRnZSB0aGF0IGl0IHRvb2sgYSBkaWZmZXJlbnQgcGF0 aCwgc28gbWF5YmUgdGhlIGF0dGFja2VyIGlzIHVzaW5nIGluYmFuZA0KPj4gT0FNIGFzIHdlbGwg Oi0pLCBhbmQgaW5zZXJ0IChvciBtb2RpZnkpIGEgVExWIHdpdGhpbiB0aGUgY29udGVudCBvZiB0 aGUgTUQNCj4+IFR5cGUgMiB3aXRoaW4gdGhlIGNvbnRlbnQgb2YgTlNILCB3aXRoaW4gYSBzcGVj aWZpYyBwYWNrZXQuDQo+PiANCj4+IFRoaXMgc291bmRzIHF1aXRlIHNvcGhpc3RpY2F0ZWQuDQo+ IA0KPiBJIGFtIG5vdCBzdXJlIEkgYWdyZWUgdGhpcyBpcyBhICdzb3BoaXN0aWNhdGVkJyBhdHRh Y2suDQo+IFRoZSBhdHRhY2sgZG9lcyBub3QgcmVxdWlyZSBhbnkgY3J5cHRvZ3JhcGhpYyBvciBh bGdvcml0aG1pYyBmdW5jdGlvbmFsaXR5LCBhbmQgdG8gdGhhdCBlbmQgaXQgaXMgdmVyeSBsaWdo dHdlaWdodCBpbiB0ZXJtcyBvZiBwcm9jZXNzaW5nIHJlc291cmNlcy4NCg0KU29ycnkgaWYgSSB3 YXMgbm90IGNsZWFyIOKAlCBJIGRvIG5vdCBtZWFuIHRlY2hub2xvZ2ljYWwgc29waGlzdGljYXRp b24gb3IgbWFzc2l2ZSBwcm9jZXNzaW5nIHJlc291cmNlcyByZXF1aXJlZC4gSSBtZWFuIGFjY2Vz cyBhbmQgb3BlcmF0aW9uYWwgb25lLg0KDQo+IA0KPiBJZiB0aGlzIGtpbmQgb2YgYXR0YWNrIGlz IG5vdCB3aXRoaW4gdGhlIHNjb3BlIGhlcmUsIHRoZW4gSSB3b3VsZCBhcmd1ZSB0aGF0IHlvdSBk b24ndCBuZWVkIGEgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gYXQgYWxsLiBBbGwgeW91IG5lZWQg aXMgYSBUTFYgdGhhdCBzcGVjaWZpZXMgdGhlIGxpc3Qgb2Ygbm9kZXMuIEhvd2V2ZXIsIEkgYmVs aWV2ZSB0aGF0IHlvdSBkaWQgd2FudCB0byB0cnkgdG8gbWl0aWdhdGUgTUlUTSBhdHRhY2tlcnMu IENvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy4NCj4gDQoNCllvdSBzZWVtIHRvIGhhdmUgbWlzc2Vk IHF1b3RpbmcgdGhlIGltcG9ydGFudCBwYXJ0IG9mIG15IHJlc3BvbnNlOiAiTXkgcG9pbnQgaXMg dGhhdCB3aGF0IHlvdSBzZWVtIHRvIGJlIGRlc2NyaWJpbmcgaXMgYSBnZW5lcmljIHRocmVhdCB1 c2UgY2FzZSBhbmQgbm90IGEgc3BlY2lmaWMgdnVsbmVyYWJpbGl0eS7igJ0NCg0KU2VsZWN0aXZl bHkgZHJvcHBpbmcgcGFydCBvZiB0aGUgcmVzcG9uc2UgcmVtb3ZlcyBpbXBvcnRhbnQgY29udGV4 dC4NCg0KPiBJIGZ1bGx5IGFncmVlIHRoYXQgdGhlIHRocmVhdCBtb2RlbCBuZWVkcyB0byBiZSB3 ZWxsLWRlZmluZWQuDQoNClRoZSB0aHJlYXQgbW9kZWwgZm9yIFNGQyBNRCwgeWVzLiBBY2Nlc3Mg dG8gdGhlIFBPVCBjb21lcyB3aXRoIGFzc3VtcHRpb25zLg0KDQpUaGFua3MsDQoNCuKAlCBDYXJs b3MuDQoNCj4gSSBob3BlIHlvdSB3aWxsIGVsYWJvcmF0ZSBtb3JlIG9uIHRoZSB0aHJlYXQgbW9k ZWwgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQo+IA0KPiBDaGVlcnMsDQo+IFRh bC4NCj4gDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCj4+IFNl bnQ6IFdlZG5lc2RheSwgSnVseSAyMCwgMjAxNiAxMTozNCBBTQ0KPj4gVG86IFRhbCBNaXpyYWhp DQo+PiBDYzogU2FzaGFuayBEYXJhIChzYWRhcmEpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25l KTsgZHJhZnQtYnJvY2tuZXJzLXByb29mLQ0KPj4gb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzsg c2ZjQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6 IE1EIFR5cGUgYXR0YWNrIChXYXM6IFF1ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0 IGRyYWZ0KQ0KPj4gDQo+PiBUYWwsDQo+PiANCj4+PiBPbiBKdWwgMjAsIDIwMTYsIGF0IDY6MzAg QU0sIFRhbCBNaXpyYWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkg U2FzaGFuaywNCj4+PiANCj4+Pj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhl IGF0dGFja2VyIGNhbiBnZXQgYXdheSBieXBhc3NpbmcgYQ0KPj4gc2VydmljZSBmdW5jdGlvbi9u b2RlLg0KPj4+PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFja2VyIGJ5cGFzc2VzIGEgbm9kZSBh bmQgaWYgUE9UIGRldGVybWluZXMgaXQgZGlkDQo+PiBub3QgYnlwYXNzIGlzIGEgdmFsaWQgYXR0 YWNrIG9uIHRoZSBzeXN0ZW0uDQo+Pj4gDQo+Pj4gSSB3b3VsZCBwaHJhc2UgaXQgdGhpcyB3YXk6 ICpHaXZlbiogYSBwYWNrZXQgdGhhdCBkaWQgbm90IGdvIHRocm91Z2ggaXRzDQo+PiBkZXNpcmVk IHBhdGgsIHRoZSBhdHRhY2tlciBjYW4gZWFzaWx5IG1ha2UgeW91IHRoaW5rIHRoYXQgaXQgKmRp ZCogZ28gdGhyb3VnaA0KPj4gdGhlIGRlc2lyZWQgcGF0aC4NCj4+PiBTb3VuZHMgbGlrZSBhIHZl cnkgc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0eS4NCj4+PiANCj4+PiBJZiBhIHBhY2tldCBkaWQg bm90IGdvIHRocm91Z2ggdGhlIGZpcmV3YWxsIChmb3Igb25lIHJlYXNvbiBvciBhbm90aGVyKSwg dGhlDQo+PiBhdHRhY2tlciB3aWxsIG1ha2UgeW91IHRoaW5rIHRoYXQgaXQgZGlkIGdvIHRocm91 Z2ggdGhlIGZpcmV3YWxsLg0KPj4+IA0KPj4gDQo+PiBMZXTigJlzIHN0ZXAgYmFjayBhIGxpdHRs ZSDigJQgdGhlIOKAnHZ1bG5lcmFiaWxpdHnigJ0geW91IGFyZSBkZXNjcmliaW5nIGNvbWVzIHdp dGggdGhlDQo+PiBhc3N1bXB0aW9uIHRoYXQgYSBNSUlUIGF0dGFja2VyIGNhbiBpbnRlcmNlcHQg YSBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbQ0KPj4gdGhlIE1EIFR5cGUgMiwgZHJvcCB0aGUg cGFja2V0OyB0aGVuIGludGVyY2VwdCBhbm90aGVyIHBhY2tldCAod2l0aCB0aGUNCj4+IGtub3ds ZWRnZSB0aGF0IGl0IHRvb2sgYSBkaWZmZXJlbnQgcGF0aCwgc28gbWF5YmUgdGhlIGF0dGFja2Vy IGlzIHVzaW5nIGluYmFuZA0KPj4gT0FNIGFzIHdlbGwgOi0pLCBhbmQgaW5zZXJ0IChvciBtb2Rp ZnkpIGEgVExWIHdpdGhpbiB0aGUgY29udGVudCBvZiB0aGUgTUQNCj4+IFR5cGUgMiB3aXRoaW4g dGhlIGNvbnRlbnQgb2YgTlNILCB3aXRoaW4gYSBzcGVjaWZpYyBwYWNrZXQuDQo+PiANCj4+IFRo aXMgc291bmRzIHF1aXRlIHNvcGhpc3RpY2F0ZWQuDQo+PiANCj4+IERvIHlvdSB0aGluayB0aGF0 IGlmIGFuIE1JSVQgY2FuIGhhdmUgdGhhdCBzdXJmYWNlIG9mIGF0dGFjayBhbmQNCj4+IHNvcGhp c3RpY2F0aW9uLCB0aGV5IGNhbiBtZXNzIHVwIHdpdGggb3RoZXIgZXZlbiBtb3JlIGNyaXRpY2Fs IHRoaW5ncz8NCj4+IENoYW5naW5nIGEgVGVuYW50IElELCBtZXNzaW5nIHVwIHdpdGggUG9saWN5 IEdyb3VwcywgZXRjPw0KPj4gDQo+PiBNeSBwb2ludCBpcyB0aGF0IHdoYXQgeW91IHNlZW0gdG8g YmUgZGVzY3JpYmluZyBpcyBhIGdlbmVyaWMgdGhyZWF0IHVzZSBjYXNlDQo+PiBhbmQgbm90IGEg c3BlY2lmaWMgdnVsbmVyYWJpbGl0eS4gRW5naW5lZXJpbmcgaXMgYWJvdXQgdHJhZGUtb2ZmcyAo aS5lLiwgc29sdXRpb25zDQo+PiB0aGF0IGhhdmUgcHJhY3RpY2FsIHBlcmZvcm1hbmNlKSBhbmQg YWJvdXQgcGxhY2luZyB0aGUgc29sdXRpb24gaW4gdGhlIG1vc3QNCj4+IGVmZmVjdGl2ZSBwbGFj ZS4NCj4+IA0KPj4gSeKAmW0gbm90IGRlZmxlY3RpbmcgYnV0IGF0IHRoZSBzYW1lIHRpbWUsIGxl dOKAmXMgdW5kZXJzdGFuZCB0aGUgYXNzdW1wdGlvbnMgeW91DQo+PiBhcmUgbWFraW5nIGZvciB0 aGlzIHBvdGVudGlhbCBhdHRhY2sgeW91IGRlc2NyaWJlLCBhcyBwYXJ0IG9mIHRoZSB0aHJlYXQN Cj4+IGFuYWx5c2lzLg0KPj4gDQo+PiBUaGFua3MsDQo+PiANCj4+IOKAlCBDYXJsb3MuDQo+PiAN Cj4+PiBDaGVlcnMsDQo+Pj4gVGFsLg0KPj4+IA0KPj4+IA0KPj4+IEZyb206IFNhc2hhbmsgRGFy YSAoc2FkYXJhKSBbbWFpbHRvOnNhZGFyYUBjaXNjby5jb21dDQo+Pj4gU2VudDogV2VkbmVzZGF5 LCBKdWx5IDIwLCAyMDE2IDQ6MzEgQU0NCj4+PiBUbzogVGFsIE1penJhaGk7IEZyYW5rIEJyb2Nr bmVycyAoZmJyb2NrbmUpOyBkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtDQo+PiB0cmFuc2l0QHRv b2xzLmlldGYub3JnDQo+Pj4gQ2M6IHNmY0BpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnOyBudm8z QGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFF1ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBU cmFuc2l0IGRyYWZ0DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gVGhlIFBPVCByZXBsYWNlbWVudCBh dHRhY2sgKDEuKSBpcyBub3QgYW4gYXR0YWNrIG9uIHRoZSBpbnRlZ3JpdHkuIEl0IGlzIGFuDQo+ PiBhdHRhY2sgb24gdGhlIHBhdGggdmVyaWZpY2F0aW9uLg0KPj4+IFRoaXMgc2ltcGxlIGF0dGFj ayBjYW4gY2F1c2UgdGhlIHZlcmlmaWVyIHRvIGFjY2VwdCBhIHBhY2tldCB0aGF0IGRpZCBub3Qg Z28NCj4+IHRocm91Z2ggdGhlIGZpcmV3YWxsIFNGIChldmVuIHRob3VnaCBpdCBzaG91bGQpLiBJ IGJlbGlldmUgdGhpcyBpcyBleGFjdGx5IHRoZQ0KPj4gcHJvYmxlbSB5b3Ugd2VyZSBhaW1pbmcg dG8gYWRkcmVzcyBpbiB0aGlzIGRyYWZ0Lg0KPj4+IA0KPj4+IFtTRF0gVGhlIGF0dGFjayBpcyB2 YWxpZCBvbmx5IGlmIHRoZSBhdHRhY2tlciBjYW4gZ2V0IGF3YXkgYnlwYXNzaW5nIGEgc2Vydmlj ZQ0KPj4gZnVuY3Rpb24vbm9kZS4NCj4+PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFja2VyIGJ5 cGFzc2VzIGEgbm9kZSBhbmQgaWYgUE9UIGRldGVybWluZXMgaXQgZGlkDQo+PiBub3QgYnlwYXNz IGlzIGEgdmFsaWQgYXR0YWNrIG9uIHRoZSBzeXN0ZW0uDQo+Pj4gDQo+Pj4gSW4gdGhlIGN1cnJl bnQgc3RhdGUsIHRoZXJlIGlzIG5vIHdheSBhbiBhdHRhY2tlciBjYW4gZ2V0IGF3YXkgYXMgd2UN Cj4+IGRldGVybWluZSB0aGUgZXhhY3QgcGF0aCB0aGUgcGFja2V0IHRyYXZlbGxlZCAoYWltIG9m IHRoZSBkcmFmdCkgLg0KPj4+IEkgcmVpdGVyYXRlIHRoYXQgdGhlIHZlcmlmaWVyIG5lZWRzIHRv IGhhbmRsZSB3aGF0IHRvIGRvIHdpdGggdGhlIHBhdGgNCj4+IHJlY29uc3RydWN0ZWQgIQ0KPj4+ IFdlIGNvdWxkIGVtcGhhc2l6ZSB0aGlzIGluIG91ciBuZXh0IGRyYWZ0ICwgYnV0IGl0IHdvdWxk IGJlIGJleW9uZCBzY29wZSBvZg0KPj4gUE9UIHRvIGRldGVybWluZSB3aGF0IHRvIGRvIHdpdGgg dGhlIHBhdGggY29uc3RydWN0ZWQuDQo+Pj4gSU1PLCBJdCB3b3VsZCBiZSBoaWdobHkgYXBwbGlj YXRpb24gc3BlY2lmaWMuDQo+Pj4gDQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiBTYXNoYW5rDQo+ Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gVGhhbmtzLA0KPj4+IFRhbC4NCj4+PiANCj4+PiBGcm9tOiBG cmFuayBCcm9ja25lcnMgKGZicm9ja25lKSBbbWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbV0NCj4+ PiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDY6MDAgUE0NCj4+PiBUbzogVGFsIE1penJh aGk7IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4g dHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0K Pj4gdHJhbnNpdEB0b29scy5pZXRmLm9yZz4NCj4+PiBDYzogc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Ow0KPj4gb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+ Ow0KPj4gbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBS RTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4+PiANCj4+PiBI aSBUYWwsDQo+Pj4gDQo+Pj4gdGhhbmtzIGZvciB0aGUgc3VtbWFyeS4gV2UnbGwgcHJvdmlkZSBt b3JlIGRldGFpbHMgb24gMi4gUGVyIG15IGVhcmxpZXINCj4+IHBvaW50IC0gMS4gaXMgYW4gaW50 ZXJlc3RpbmcgZGlzY3Vzc2lvbiwgZ2l2ZW4gdGhhdCB3ZSBkb24ndCBjbGFpbSB0byBwcm92aWRl DQo+PiBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmb3IgdGhlIHBhY2tldCBwYXlsb2FkLiBPciBpbiBv dGhlciB0ZXJtcyAtIHRvIGJlIGV4YWN0Og0KPj4gV2hhdCBQT1QgcHJvdmlkZXMgaXMgYSBwcm9v ZiB0aGF0IHRoZSBQT1QtaGVhZGVyL21ldGEtZGF0YSB0cmFuc2l0ZWQgYWxsIHRoZQ0KPj4gcmVx dWlyZWQgbm9kZXMuIFRoZXJlIGlzIG5vIGFzc29jaWF0aW9uIChhbmQgdGh1cyBwcm9vZikgcHJv dmlkZWQgZm9yIHRoZQ0KPj4gYWRkaXRpb25hbCBkYXRhIGNhcnJpZWQgYWxvbmcgd2l0aCB0aGUg UE9ULWhlYWRlciAtIG5laXRoZXIgaGVhZGVyIG5vcg0KPj4gcGF5bG9hZC4gQXMgYSBjb25zZXF1 ZW5jZSwgYXR0YWNrcyB3aGljaCBjaGFuZ2UgdGhlIHBhY2tldCBwYXlsb2FkIHdvbid0DQo+PiBi ZSBkZXRlY3RlZC9taXRpZ2F0ZWQuIFdlJ2xsIGV4cGxpY2l0bHkgc3RhdGUgdGhpcyBpbiB0aGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4+IGluIHRoZSBuZXh0IHJldiBvZiB0aGUgZG9jdW1l bnQuDQo+Pj4gV2hhdCB3ZSBjb3VsZCBjb25zaWRlciBpcyBsaW5raW5nIHRoZSBSTkQgbnVtYmVy IHRvIENSQyBhY3Jvc3MgdGhlIHBhY2tldA0KPj4gcGF5bG9hZCBvciBzaW1pbGFyIC0gYnV0IHRo YXQgd2F5IHdlJ2QgcmVzdHJpY3QgdGhlIGFwcGxpY2FiaWxpdHkgdG8gZGVwbG95bWVudHMNCj4+ IHdoZXJlIHRoZSBwYWNrZXQgcGF5bG9hZCBpc24ndCBjaGFuZ2VkIGFjcm9zcyB0aGUgcGF0aCAo d2hpY2ggbWlnaHQgbm90DQo+PiBhcHBseSB0byBjZXJ0YWluIGRlcGxveW1lbnQgLSBlLmcuIFdB TiBvcHRpbWl6YXRpb24gLyBjb21wcmVzc2lvbiBzY2hlbWVzKS4NCj4+PiBEbyB5b3UgdGhpbmsg aXQgaXMgd29ydGh3aGlsZSB0byBwcm92aWRlIGEgc29sdXRpb24gZm9yIGEgZGVwbG95bWVudCB3 aGljaCBpcw0KPj4gZXhwZWN0ZWQgdG8gbm90IGFsdGVyIHRoZSBwYWNrZXQgcGF5bG9hZD8NCj4+ PiANCj4+PiBUaGFua3MsDQo+Pj4gRnJhbmsNCj4+PiANCj4+PiBGcm9tOiBUYWwgTWl6cmFoaSBb bWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tXQ0KPj4+IFNlbnQ6IERpZW5zdGFnLCAxOS4gSnVsaSAy MDE2IDE3OjQ0DQo+Pj4gVG86IFNhc2hhbmsgRGFyYSAoc2FkYXJhKQ0KPj4gPHNhZGFyYUBjaXNj by5jb208bWFpbHRvOnNhZGFyYUBjaXNjby5jb20+PjsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tu ZSkNCj4+IDxmYnJvY2tuZUBjaXNjby5jb208bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+OyBk cmFmdC1icm9ja25lcnMtDQo+PiBwcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtDQo+PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnPg0K Pj4+IENjOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47DQo+PiBvcHNhd2dAaWV0 Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47DQo+PiBudm8zQGlldGYub3JnPG1haWx0bzpu dm8zQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJFOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Yg b2YgVHJhbnNpdCBkcmFmdA0KPj4+IA0KPj4+IEhpLA0KPj4+IA0KPj4+IFRvIHN1bW1hcml6ZSBt eSB0YWtlIG9uIHRoaXMgdGhyZWFkOg0KPj4+IFRoZSBwcm9wb3NlZCBtZWNoYW5pc20gaGFzIHR3 byBzaWduaWZpY2FudCB2dWxuZXJhYmlsaXRpZXMgdGhhdCAoaW4gbXkNCj4+IHVuZGVyc3RhbmRp bmcpIGFyZSBjdXJyZW50bHkgbm90IGFkZHJlc3NlZDoNCj4+PiANCj4+PiAxLiAgICAgICBBIG1h bi1pbi10aGUtbWlkZGxlIGNhbiByZXBsYWNlIHRoZSBQT1Qgb2YgcGFja2V0IEEgd2l0aCB0aGUg UE9UIG9mDQo+PiBwYWNrZXQgQi4NCj4+PiANCj4+PiAyLiAgICAgICBJdCBpcyBwb3NzaWJsZSB0 byByZXBsYXkgUE9UcyB3aXRoaW4gYSBjZXJ0YWluIHRpbWUgd2luZG93LCB3aG9zZQ0KPj4gbGVu Z3RoIGlzIGRldGVybWluZWQgYnkgdGhlIHRpbWVzdGFtcCByZXNvbHV0aW9uLg0KPj4+IA0KPj4+ IFNhc2hhbmssIHRoYW5rcyBmb3IgYWdyZWVpbmcgdG8gbG9vayBpbnRvIGl0IGZ1cnRoZXIuIEkg YW0gbG9va2luZyBmb3J3YXJkIHRvDQo+PiB5b3VyIGluc2lnaHRzIG9uIHRoaXMuDQo+Pj4gDQo+ Pj4gUmVnYXJkcywNCj4+PiBUYWwuDQo+Pj4gDQo+Pj4gTGluayB0byB0aGUgZHJhZnQ6IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtDQo+PiB0cmFu c2l0LTAxDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gRnJvbTogU2FzaGFuayBEYXJhIChzYWRhcmEp IFttYWlsdG86c2FkYXJhQGNpc2NvLmNvbV0NCj4+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAy MDE2IDEyOjIwIFBNDQo+Pj4gVG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9j a25lKTsgZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4gdHJhbnNpdEB0b29scy5pZXRmLm9y ZzxtYWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4gdHJhbnNpdEB0b29scy5pZXRm Lm9yZz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJl OiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFmdA0KPj4+IA0KPj4+IA0K Pj4+IA0KPj4+IEkgd2FudCB0byBhc2sgYSBzaW1wbGUgcXVlc3Rpb246DQo+Pj4gSWYgdGhlIGF0 dGFja2VyIGF0dGFjaGVzIHRoZSBQT1Qgb2YgcGFja2V0IEEgKGluZGljYXRpbmcgdGhlIHBhdGgg dGhyb3VnaA0KPj4gMSwzLDUsNikgdG8gcGFja2V0IEIsIHdpbGwgdGhlIHZlcmlmaWVyIGFjY2Vw dCBwYWNrZXQgQiBhbmQgYmVsaWV2ZSB0aGF0IGl0cyBwYXRoDQo+PiB3YXMgaW5kZWVkICgxLDMs NSw2KT8NCj4+PiANCj4+PiBbU0RdIElmIHRoZSB2ZXJpZmllciBpcyBwcm9ncmFtbWVkIHRvIGp1 c3QgdmFsaWRhdGUgdGhlIFBPVCBtZXRhIGRhdGEgYWdhaW5zdA0KPj4gezEsMyw1LDZ9IHRoZW4g eWVzIGl0IGFjY2VwdHMgaXQuDQo+Pj4gSWYgdGhlIHZlcmlmaWVyIGlzIHByb2dyYW1tZWQgdG8g Y29uc3VsdCBhIHBvbGljeSBkYXRhYmFzZSB0byBjcm9zcyBjaGVjayBpZg0KPj4gdGhlIHJlY29u c3RydWN0ZWQgcGF0aCB7MSwzLDUsNn0gaXMgYXMgcGVyIHRoZSBwb2xpY2llcyB0aGVuIG5vICwg aXQgZHJvcHMgaXQgLg0KPj4+IA0KPj4+IEJ1dCBJIHNlZSB5b3VyIHBvaW50ICwgdGhhdCB0aGUg cGFyYW1ldGVycyB1c2VkIGluIFBPVCBkYXRhIGRvbm90IGNvbnNpZGVyDQo+PiB0aGUgcGF0aCBv ciBub2RlLWlkcyBldGMgLiBXZSBzaGFsbCBkaXNjdXNzIHRoaXMgaW50ZXJuYWxseSBhbmQgZ2V0 IGJhY2suDQo+Pj4gDQo+Pj4gQWxzbywgV2Ugc2hhbGwgZ2V0IGJhY2sgd2l0aCBtb3JlIGNvbmNy ZXRlIG51bWJlcnMgb2YgdGhlIHRpbWVzdGFtcA0KPj4gcmVzb2x1dGlvbiBhbmQgY2FjaGUgc2l6 ZXMgKG9yIG90aGVyIGJldHRlciBhcHByb2FjaGVzKS4NCj4+PiANCj4+PiBUaGFuayB5b3Ugc28g bXVjaCBmb3IgYWxsIHRoZSBpbnB1dHMuDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gRnJvbTogVGFs IE1penJhaGkNCj4+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDEwOjI4IEFNDQo+Pj4g VG86ICdTYXNoYW5rIERhcmEgKHNhZGFyYSknOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsg ZHJhZnQtYnJvY2tuZXJzLQ0KPj4gcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4gdHJhbnNpdEB0b29scy5pZXRmLm9yZz47 IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJFOiBRdWVz dGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFmdA0KPj4+IA0KPj4+IERlYXIgU2Fz aGFuaywNCj4+PiANCj4+PiBJIHJlYWxseSBhcHByZWNpYXRlIHRoZSBxdWljayBhbmQgZGV0YWls ZWQgcmVzcG9uc2VzLg0KPj4+IA0KPj4+Pj4+IExldHMgdGFrZSBjb3JyZWN0IHBhdGggdGFrZW4g YnkgUGFja2V0IEEgIHRvIGJlIFBhdGgxIC0gKCAxLDMsNSw2KSBub2Rlcw0KPiANCg0K From nobody Wed Jul 20 03:10:04 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3298612DB18; Wed, 20 Jul 2016 03:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OObqAU8NdCy7; Wed, 20 Jul 2016 03:09:53 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E25712DACD; Wed, 20 Jul 2016 03:09:53 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6KA0JIj028380; Wed, 20 Jul 2016 03:09:52 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 24a2c397fv-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Jul 2016 03:09:52 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jul 2016 13:09:48 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Wed, 20 Jul 2016 13:09:48 +0300 From: Tal Mizrahi To: "Carlos Pignataro (cpignata)" Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnUR6x6RUowp0WBJweV5BhC9aAhDzig///SIICAADQk4A== Date: Wed, 20 Jul 2016 10:09:47 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> <16454292-3ADD-402A-AED6-CB785C5C833B@cisco.com> In-Reply-To: <16454292-3ADD-402A-AED6-CB785C5C833B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_06:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200117 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 10:09:56 -0000 SGkgQ2FybG9zLA0KDQpJdCBhbGwgZ29lcyBiYWNrIHRvIHRoZSB0aHJlYXQgbW9kZWw7IHdoaWNo IHRocmVhdHMgeW91IHdhbnQgdG8gYWRkcmVzcywgYW5kIHdoaWNoIG9uZXMgeW91IGRvbid0Lg0K DQpUaGUgd2F5IEkgc2VlIGl0LCByb3VnaGx5IHNwZWFraW5nIHRoZXJlIGFyZSAzIGNsYXNzZXMg b2YgdGhyZWF0cyAodGhlcmUgYWUgcHJvYmFibHkgb3RoZXIgdGhyZWF0cywgYnV0IHRoZXNlIGFy ZSB0aGUgYmFzaWMgb25lcyk6DQotIE1pc3JvdXRlIC8gbWlzY29uZmlndXJhdGlvbiAobm90IGEg c2VjdXJpdHkgYXR0YWNrKS4NCi0gQXR0YWNrZXIgd2l0aCBubyBvbi1wYXRoIGFjY2Vzcy4NCi0g TWFuLWluLXRoZS1taWRkbGUgKGF0dGFja2VyICp3aXRoKiBvbi1wYXRoIGFjY2VzcykuDQoNCkl0 IGxvb2tzIGxpa2UgdGhlIHRoaXJkIHRocmVhdCAobWFuLWluLXRoZS1taWRkbGUpIGlzIGN1cnJl bnRseSBub3QgYWRkcmVzc2VkIGJ5IFBPVC4NCkkgY2VydGFpbmx5IGFncmVlIHRoYXQgdGhpcyB0 aHJlYXQgaXMgdGhlIG1vcmUgZGlmZmljdWx0IHRvIGltcGxlbWVudCBvZiB0aGUgdGhyZWUuDQoN Ckl0IHdvdWxkIHNpZ25pZmljYW50bHkgY2xhcmlmeSB0aGUgcGljdHVyZSBpZiB5b3Ugc3BlY2lm aWVkIGluIHRoZSBkcmFmdCB3aGljaCBvZiB0aGUgdGhyZWUgY2xhc3NlcyB5b3UgaW50ZW5kIHRv IGFkZHJlc3MuDQoNClRoYW5rcywNClRhbC4NCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj5Gcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBj aXNjby5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBKdWx5IDIwLCAyMDE2IDExOjUxIEFNDQo+VG86 IFRhbCBNaXpyYWhpDQo+Q2M6IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgRnJhbmsgQnJvY2tuZXJz IChmYnJvY2tuZSk7IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi0NCj5vZi10cmFuc2l0QHRvb2xzLmll dGYub3JnOyBzZmNAaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZw0KPlN1 YmplY3Q6IFJlOiBNRCBUeXBlIGF0dGFjayAoV2FzOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Yg b2YgVHJhbnNpdCBkcmFmdCkNCj4NCj5IaSwgVGFsLA0KPg0KPj4gT24gSnVsIDIwLCAyMDE2LCBh dCAxMTo0MiBBTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZlbGwuY29tPiB3cm90ZToNCj4+DQo+ PiBIaSBDYXJsb3MsDQo+Pg0KPj4NCj4+PiBMZXTigJlzIHN0ZXAgYmFjayBhIGxpdHRsZSDigJQg dGhlIOKAnHZ1bG5lcmFiaWxpdHnigJ0geW91IGFyZSBkZXNjcmliaW5nDQo+Pj4gY29tZXMgd2l0 aCB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgTUlJVCBhdHRhY2tlciBjYW4gaW50ZXJjZXB0IGENCj4+ PiBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbSB0aGUgTUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNr ZXQ7IHRoZW4NCj4+PiBpbnRlcmNlcHQgYW5vdGhlciBwYWNrZXQgKHdpdGggdGhlIGtub3dsZWRn ZSB0aGF0IGl0IHRvb2sgYSBkaWZmZXJlbnQNCj4+PiBwYXRoLCBzbyBtYXliZSB0aGUgYXR0YWNr ZXIgaXMgdXNpbmcgaW5iYW5kIE9BTSBhcyB3ZWxsIDotKSwgYW5kDQo+Pj4gaW5zZXJ0IChvciBt b2RpZnkpIGEgVExWIHdpdGhpbiB0aGUgY29udGVudCBvZiB0aGUgTUQgVHlwZSAyIHdpdGhpbiB0 aGUNCj5jb250ZW50IG9mIE5TSCwgd2l0aGluIGEgc3BlY2lmaWMgcGFja2V0Lg0KPj4+DQo+Pj4g VGhpcyBzb3VuZHMgcXVpdGUgc29waGlzdGljYXRlZC4NCj4+DQo+PiBJIGFtIG5vdCBzdXJlIEkg YWdyZWUgdGhpcyBpcyBhICdzb3BoaXN0aWNhdGVkJyBhdHRhY2suDQo+PiBUaGUgYXR0YWNrIGRv ZXMgbm90IHJlcXVpcmUgYW55IGNyeXB0b2dyYXBoaWMgb3IgYWxnb3JpdGhtaWMgZnVuY3Rpb25h bGl0eSwNCj5hbmQgdG8gdGhhdCBlbmQgaXQgaXMgdmVyeSBsaWdodHdlaWdodCBpbiB0ZXJtcyBv ZiBwcm9jZXNzaW5nIHJlc291cmNlcy4NCj4NCj5Tb3JyeSBpZiBJIHdhcyBub3QgY2xlYXIg4oCU IEkgZG8gbm90IG1lYW4gdGVjaG5vbG9naWNhbCBzb3BoaXN0aWNhdGlvbiBvcg0KPm1hc3NpdmUg cHJvY2Vzc2luZyByZXNvdXJjZXMgcmVxdWlyZWQuIEkgbWVhbiBhY2Nlc3MgYW5kIG9wZXJhdGlv bmFsIG9uZS4NCj4NCj4+DQo+PiBJZiB0aGlzIGtpbmQgb2YgYXR0YWNrIGlzIG5vdCB3aXRoaW4g dGhlIHNjb3BlIGhlcmUsIHRoZW4gSSB3b3VsZCBhcmd1ZSB0aGF0DQo+eW91IGRvbid0IG5lZWQg YSBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBhdCBhbGwuIEFsbCB5b3UgbmVlZCBpcyBhIFRMViB0 aGF0DQo+c3BlY2lmaWVzIHRoZSBsaXN0IG9mIG5vZGVzLiBIb3dldmVyLCBJIGJlbGlldmUgdGhh dCB5b3UgZGlkIHdhbnQgdG8gdHJ5IHRvDQo+bWl0aWdhdGUgTUlUTSBhdHRhY2tlcnMuIENvcnJl Y3QgbWUgaWYgSSBhbSB3cm9uZy4NCj4+DQo+DQo+WW91IHNlZW0gdG8gaGF2ZSBtaXNzZWQgcXVv dGluZyB0aGUgaW1wb3J0YW50IHBhcnQgb2YgbXkgcmVzcG9uc2U6ICJNeQ0KPnBvaW50IGlzIHRo YXQgd2hhdCB5b3Ugc2VlbSB0byBiZSBkZXNjcmliaW5nIGlzIGEgZ2VuZXJpYyB0aHJlYXQgdXNl IGNhc2UgYW5kDQo+bm90IGEgc3BlY2lmaWMgdnVsbmVyYWJpbGl0eS7igJ0NCj4NCj5TZWxlY3Rp dmVseSBkcm9wcGluZyBwYXJ0IG9mIHRoZSByZXNwb25zZSByZW1vdmVzIGltcG9ydGFudCBjb250 ZXh0Lg0KPg0KPj4gSSBmdWxseSBhZ3JlZSB0aGF0IHRoZSB0aHJlYXQgbW9kZWwgbmVlZHMgdG8g YmUgd2VsbC1kZWZpbmVkLg0KPg0KPlRoZSB0aHJlYXQgbW9kZWwgZm9yIFNGQyBNRCwgeWVzLiBB Y2Nlc3MgdG8gdGhlIFBPVCBjb21lcyB3aXRoDQo+YXNzdW1wdGlvbnMuDQo+DQo+VGhhbmtzLA0K Pg0KPuKAlCBDYXJsb3MuDQo+DQo+PiBJIGhvcGUgeW91IHdpbGwgZWxhYm9yYXRlIG1vcmUgb24g dGhlIHRocmVhdCBtb2RlbCBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9mDQo+dGhlIGRyYWZ0Lg0KPj4N Cj4+IENoZWVycywNCj4+IFRhbC4NCj4+DQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4gRnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25h dGFAY2lzY28uY29tXQ0KPj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMCwgMjAxNiAxMTozNCBB TQ0KPj4+IFRvOiBUYWwgTWl6cmFoaQ0KPj4+IENjOiBTYXNoYW5rIERhcmEgKHNhZGFyYSk7IEZy YW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpOw0KPj4+IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi0gb2Yt dHJhbnNpdEB0b29scy5pZXRmLm9yZzsgc2ZjQGlldGYub3JnOw0KPj4+IG9wc2F3Z0BpZXRmLm9y ZzsgbnZvM0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IE1EIFR5cGUgYXR0YWNrIChXYXM6IFF1ZXN0 aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0DQo+Pj4gZHJhZnQpDQo+Pj4NCj4+PiBUYWws DQo+Pj4NCj4+Pj4gT24gSnVsIDIwLCAyMDE2LCBhdCA2OjMwIEFNLCBUYWwgTWl6cmFoaSA8dGFs bWlAbWFydmVsbC5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+PiBIaSBTYXNoYW5rLA0KPj4+Pg0KPj4+ Pj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhlIGF0dGFja2VyIGNhbiBnZXQg YXdheQ0KPj4+Pj4gYnlwYXNzaW5nIGENCj4+PiBzZXJ2aWNlIGZ1bmN0aW9uL25vZGUuDQo+Pj4+ PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFja2VyIGJ5cGFzc2VzIGEgbm9kZSBhbmQgaWYgUE9U IGRldGVybWluZXMNCj4+Pj4+IGl0IGRpZA0KPj4+IG5vdCBieXBhc3MgaXMgYSB2YWxpZCBhdHRh Y2sgb24gdGhlIHN5c3RlbS4NCj4+Pj4NCj4+Pj4gSSB3b3VsZCBwaHJhc2UgaXQgdGhpcyB3YXk6 ICpHaXZlbiogYSBwYWNrZXQgdGhhdCBkaWQgbm90IGdvIHRocm91Z2gNCj4+Pj4gaXRzDQo+Pj4g ZGVzaXJlZCBwYXRoLCB0aGUgYXR0YWNrZXIgY2FuIGVhc2lseSBtYWtlIHlvdSB0aGluayB0aGF0 IGl0ICpkaWQqIGdvDQo+Pj4gdGhyb3VnaCB0aGUgZGVzaXJlZCBwYXRoLg0KPj4+PiBTb3VuZHMg bGlrZSBhIHZlcnkgc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0eS4NCj4+Pj4NCj4+Pj4gSWYgYSBw YWNrZXQgZGlkIG5vdCBnbyB0aHJvdWdoIHRoZSBmaXJld2FsbCAoZm9yIG9uZSByZWFzb24gb3IN Cj4+Pj4gYW5vdGhlciksIHRoZQ0KPj4+IGF0dGFja2VyIHdpbGwgbWFrZSB5b3UgdGhpbmsgdGhh dCBpdCBkaWQgZ28gdGhyb3VnaCB0aGUgZmlyZXdhbGwuDQo+Pj4+DQo+Pj4NCj4+PiBMZXTigJlz IHN0ZXAgYmFjayBhIGxpdHRsZSDigJQgdGhlIOKAnHZ1bG5lcmFiaWxpdHnigJ0geW91IGFyZSBk ZXNjcmliaW5nDQo+Pj4gY29tZXMgd2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgTUlJVCBhdHRh Y2tlciBjYW4gaW50ZXJjZXB0IGENCj4+PiBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbSB0aGUg TUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNrZXQ7IHRoZW4NCj4+PiBpbnRlcmNlcHQgYW5vdGhlciBw YWNrZXQgKHdpdGggdGhlIGtub3dsZWRnZSB0aGF0IGl0IHRvb2sgYSBkaWZmZXJlbnQNCj4+PiBw YXRoLCBzbyBtYXliZSB0aGUgYXR0YWNrZXIgaXMgdXNpbmcgaW5iYW5kIE9BTSBhcyB3ZWxsIDot KSwgYW5kDQo+Pj4gaW5zZXJ0IChvciBtb2RpZnkpIGEgVExWIHdpdGhpbiB0aGUgY29udGVudCBv ZiB0aGUgTUQgVHlwZSAyIHdpdGhpbiB0aGUNCj5jb250ZW50IG9mIE5TSCwgd2l0aGluIGEgc3Bl Y2lmaWMgcGFja2V0Lg0KPj4+DQo+Pj4gVGhpcyBzb3VuZHMgcXVpdGUgc29waGlzdGljYXRlZC4N Cj4+Pg0KPj4+IERvIHlvdSB0aGluayB0aGF0IGlmIGFuIE1JSVQgY2FuIGhhdmUgdGhhdCBzdXJm YWNlIG9mIGF0dGFjayBhbmQNCj4+PiBzb3BoaXN0aWNhdGlvbiwgdGhleSBjYW4gbWVzcyB1cCB3 aXRoIG90aGVyIGV2ZW4gbW9yZSBjcml0aWNhbCB0aGluZ3M/DQo+Pj4gQ2hhbmdpbmcgYSBUZW5h bnQgSUQsIG1lc3NpbmcgdXAgd2l0aCBQb2xpY3kgR3JvdXBzLCBldGM/DQo+Pj4NCj4+PiBNeSBw b2ludCBpcyB0aGF0IHdoYXQgeW91IHNlZW0gdG8gYmUgZGVzY3JpYmluZyBpcyBhIGdlbmVyaWMg dGhyZWF0DQo+Pj4gdXNlIGNhc2UgYW5kIG5vdCBhIHNwZWNpZmljIHZ1bG5lcmFiaWxpdHkuIEVu Z2luZWVyaW5nIGlzIGFib3V0DQo+Pj4gdHJhZGUtb2ZmcyAoaS5lLiwgc29sdXRpb25zIHRoYXQg aGF2ZSBwcmFjdGljYWwgcGVyZm9ybWFuY2UpIGFuZA0KPj4+IGFib3V0IHBsYWNpbmcgdGhlIHNv bHV0aW9uIGluIHRoZSBtb3N0IGVmZmVjdGl2ZSBwbGFjZS4NCj4+Pg0KPj4+IEnigJltIG5vdCBk ZWZsZWN0aW5nIGJ1dCBhdCB0aGUgc2FtZSB0aW1lLCBsZXTigJlzIHVuZGVyc3RhbmQgdGhlDQo+ Pj4gYXNzdW1wdGlvbnMgeW91IGFyZSBtYWtpbmcgZm9yIHRoaXMgcG90ZW50aWFsIGF0dGFjayB5 b3UgZGVzY3JpYmUsIGFzDQo+Pj4gcGFydCBvZiB0aGUgdGhyZWF0IGFuYWx5c2lzLg0KPj4+DQo+ Pj4gVGhhbmtzLA0KPj4+DQo+Pj4g4oCUIENhcmxvcy4NCj4+Pg0KPj4+PiBDaGVlcnMsDQo+Pj4+ IFRhbC4NCj4+Pj4NCj4+Pj4NCj4+Pj4gRnJvbTogU2FzaGFuayBEYXJhIChzYWRhcmEpIFttYWls dG86c2FkYXJhQGNpc2NvLmNvbV0NCj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDIwLCAyMDE2 IDQ6MzEgQU0NCj4+Pj4gVG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25l KTsNCj4+Pj4gZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+IHRyYW5zaXRAdG9vbHMuaWV0 Zi5vcmcNCj4+Pj4gQ2M6IHNmY0BpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnOyBudm8zQGlldGYu b3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNp dCBkcmFmdA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGUgUE9UIHJlcGxhY2VtZW50IGF0dGFj ayAoMS4pIGlzIG5vdCBhbiBhdHRhY2sgb24gdGhlIGludGVncml0eS4NCj4+Pj4gSXQgaXMgYW4N Cj4+PiBhdHRhY2sgb24gdGhlIHBhdGggdmVyaWZpY2F0aW9uLg0KPj4+PiBUaGlzIHNpbXBsZSBh dHRhY2sgY2FuIGNhdXNlIHRoZSB2ZXJpZmllciB0byBhY2NlcHQgYSBwYWNrZXQgdGhhdA0KPj4+ PiBkaWQgbm90IGdvDQo+Pj4gdGhyb3VnaCB0aGUgZmlyZXdhbGwgU0YgKGV2ZW4gdGhvdWdoIGl0 IHNob3VsZCkuIEkgYmVsaWV2ZSB0aGlzIGlzDQo+Pj4gZXhhY3RseSB0aGUgcHJvYmxlbSB5b3Ug d2VyZSBhaW1pbmcgdG8gYWRkcmVzcyBpbiB0aGlzIGRyYWZ0Lg0KPj4+Pg0KPj4+PiBbU0RdIFRo ZSBhdHRhY2sgaXMgdmFsaWQgb25seSBpZiB0aGUgYXR0YWNrZXIgY2FuIGdldCBhd2F5IGJ5cGFz c2luZw0KPj4+PiBhIHNlcnZpY2UNCj4+PiBmdW5jdGlvbi9ub2RlLg0KPj4+PiBGb3IgZXhhbXBs ZSwgaWYgdGhlIGF0dGFja2VyIGJ5cGFzc2VzIGEgbm9kZSBhbmQgaWYgUE9UIGRldGVybWluZXMN Cj4+Pj4gaXQgZGlkDQo+Pj4gbm90IGJ5cGFzcyBpcyBhIHZhbGlkIGF0dGFjayBvbiB0aGUgc3lz dGVtLg0KPj4+Pg0KPj4+PiBJbiB0aGUgY3VycmVudCBzdGF0ZSwgdGhlcmUgaXMgbm8gd2F5IGFu IGF0dGFja2VyIGNhbiBnZXQgYXdheSBhcyB3ZQ0KPj4+IGRldGVybWluZSB0aGUgZXhhY3QgcGF0 aCB0aGUgcGFja2V0IHRyYXZlbGxlZCAoYWltIG9mIHRoZSBkcmFmdCkgLg0KPj4+PiBJIHJlaXRl cmF0ZSB0aGF0IHRoZSB2ZXJpZmllciBuZWVkcyB0byBoYW5kbGUgd2hhdCB0byBkbyB3aXRoIHRo ZQ0KPj4+PiBwYXRoDQo+Pj4gcmVjb25zdHJ1Y3RlZCAhDQo+Pj4+IFdlIGNvdWxkIGVtcGhhc2l6 ZSB0aGlzIGluIG91ciBuZXh0IGRyYWZ0ICwgYnV0IGl0IHdvdWxkIGJlIGJleW9uZA0KPj4+PiBz Y29wZSBvZg0KPj4+IFBPVCB0byBkZXRlcm1pbmUgd2hhdCB0byBkbyB3aXRoIHRoZSBwYXRoIGNv bnN0cnVjdGVkLg0KPj4+PiBJTU8sIEl0IHdvdWxkIGJlIGhpZ2hseSBhcHBsaWNhdGlvbiBzcGVj aWZpYy4NCj4+Pj4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4gU2FzaGFuaw0KPj4+Pg0KPj4+ Pg0KPj4+Pg0KPj4+PiBUaGFua3MsDQo+Pj4+IFRhbC4NCj4+Pj4NCj4+Pj4gRnJvbTogRnJhbmsg QnJvY2tuZXJzIChmYnJvY2tuZSkgW21haWx0bzpmYnJvY2tuZUBjaXNjby5jb21dDQo+Pj4+IFNl bnQ6IFR1ZXNkYXksIEp1bHkgMTksIDIwMTYgNjowMCBQTQ0KPj4+PiBUbzogVGFsIE1penJhaGk7 IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+IHRy YW5zaXRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi0NCj4+ PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnPg0KPj4+PiBDYzogc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Ow0KPj4+IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3Jn PjsNCj4+PiBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KPj4+PiBTdWJqZWN0 OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4+Pj4NCj4+ Pj4gSGkgVGFsLA0KPj4+Pg0KPj4+PiB0aGFua3MgZm9yIHRoZSBzdW1tYXJ5LiBXZSdsbCBwcm92 aWRlIG1vcmUgZGV0YWlscyBvbiAyLiBQZXIgbXkNCj4+Pj4gZWFybGllcg0KPj4+IHBvaW50IC0g MS4gaXMgYW4gaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiwgZ2l2ZW4gdGhhdCB3ZSBkb24ndCBjbGFp bSB0bw0KPj4+IHByb3ZpZGUgaW50ZWdyaXR5IHByb3RlY3Rpb24gZm9yIHRoZSBwYWNrZXQgcGF5 bG9hZC4gT3IgaW4gb3RoZXIgdGVybXMgLSB0bw0KPmJlIGV4YWN0Og0KPj4+IFdoYXQgUE9UIHBy b3ZpZGVzIGlzIGEgcHJvb2YgdGhhdCB0aGUgUE9ULWhlYWRlci9tZXRhLWRhdGEgdHJhbnNpdGVk DQo+Pj4gYWxsIHRoZSByZXF1aXJlZCBub2Rlcy4gVGhlcmUgaXMgbm8gYXNzb2NpYXRpb24gKGFu ZCB0aHVzIHByb29mKQ0KPj4+IHByb3ZpZGVkIGZvciB0aGUgYWRkaXRpb25hbCBkYXRhIGNhcnJp ZWQgYWxvbmcgd2l0aCB0aGUgUE9ULWhlYWRlciAtDQo+Pj4gbmVpdGhlciBoZWFkZXIgbm9yIHBh eWxvYWQuIEFzIGEgY29uc2VxdWVuY2UsIGF0dGFja3Mgd2hpY2ggY2hhbmdlDQo+Pj4gdGhlIHBh Y2tldCBwYXlsb2FkIHdvbid0IGJlIGRldGVjdGVkL21pdGlnYXRlZC4gV2UnbGwgZXhwbGljaXRs eQ0KPj4+IHN0YXRlIHRoaXMgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIHRoZSBu ZXh0IHJldiBvZiB0aGUgZG9jdW1lbnQuDQo+Pj4+IFdoYXQgd2UgY291bGQgY29uc2lkZXIgaXMg bGlua2luZyB0aGUgUk5EIG51bWJlciB0byBDUkMgYWNyb3NzIHRoZQ0KPj4+PiBwYWNrZXQNCj4+ PiBwYXlsb2FkIG9yIHNpbWlsYXIgLSBidXQgdGhhdCB3YXkgd2UnZCByZXN0cmljdCB0aGUgYXBw bGljYWJpbGl0eSB0bw0KPj4+IGRlcGxveW1lbnRzIHdoZXJlIHRoZSBwYWNrZXQgcGF5bG9hZCBp c24ndCBjaGFuZ2VkIGFjcm9zcyB0aGUgcGF0aA0KPj4+ICh3aGljaCBtaWdodCBub3QgYXBwbHkg dG8gY2VydGFpbiBkZXBsb3ltZW50IC0gZS5nLiBXQU4gb3B0aW1pemF0aW9uIC8NCj5jb21wcmVz c2lvbiBzY2hlbWVzKS4NCj4+Pj4gRG8geW91IHRoaW5rIGl0IGlzIHdvcnRod2hpbGUgdG8gcHJv dmlkZSBhIHNvbHV0aW9uIGZvciBhIGRlcGxveW1lbnQNCj4+Pj4gd2hpY2ggaXMNCj4+PiBleHBl Y3RlZCB0byBub3QgYWx0ZXIgdGhlIHBhY2tldCBwYXlsb2FkPw0KPj4+Pg0KPj4+PiBUaGFua3Ms DQo+Pj4+IEZyYW5rDQo+Pj4+DQo+Pj4+IEZyb206IFRhbCBNaXpyYWhpIFttYWlsdG86dGFsbWlA bWFydmVsbC5jb21dDQo+Pj4+IFNlbnQ6IERpZW5zdGFnLCAxOS4gSnVsaSAyMDE2IDE3OjQ0DQo+ Pj4+IFRvOiBTYXNoYW5rIERhcmEgKHNhZGFyYSkNCj4+PiA8c2FkYXJhQGNpc2NvLmNvbTxtYWls dG86c2FkYXJhQGNpc2NvLmNvbT4+OyBGcmFuayBCcm9ja25lcnMNCj4+PiAoZmJyb2NrbmUpIDxm YnJvY2tuZUBjaXNjby5jb208bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+Ow0KPj4+IGRyYWZ0 LWJyb2NrbmVycy0NCj4+PiBwcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtDQo+Pj4gdHJhbnNpdEB0b29scy5pZXRmLm9yZz4NCj4+ Pj4gQ2M6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjsNCj4+PiBvcHNhd2dAaWV0 Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47DQo+Pj4gbnZvM0BpZXRmLm9yZzxtYWlsdG86 bnZvM0BpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUkU6IFF1ZXN0aW9uIHJlZ2FyZGluZyBQcm9v ZiBvZiBUcmFuc2l0IGRyYWZ0DQo+Pj4+DQo+Pj4+IEhpLA0KPj4+Pg0KPj4+PiBUbyBzdW1tYXJp emUgbXkgdGFrZSBvbiB0aGlzIHRocmVhZDoNCj4+Pj4gVGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBo YXMgdHdvIHNpZ25pZmljYW50IHZ1bG5lcmFiaWxpdGllcyB0aGF0IChpbg0KPj4+PiBteQ0KPj4+ IHVuZGVyc3RhbmRpbmcpIGFyZSBjdXJyZW50bHkgbm90IGFkZHJlc3NlZDoNCj4+Pj4NCj4+Pj4g MS4gICAgICAgQSBtYW4taW4tdGhlLW1pZGRsZSBjYW4gcmVwbGFjZSB0aGUgUE9UIG9mIHBhY2tl dCBBIHdpdGggdGhlIFBPVA0KPm9mDQo+Pj4gcGFja2V0IEIuDQo+Pj4+DQo+Pj4+IDIuICAgICAg IEl0IGlzIHBvc3NpYmxlIHRvIHJlcGxheSBQT1RzIHdpdGhpbiBhIGNlcnRhaW4gdGltZSB3aW5k b3csIHdob3NlDQo+Pj4gbGVuZ3RoIGlzIGRldGVybWluZWQgYnkgdGhlIHRpbWVzdGFtcCByZXNv bHV0aW9uLg0KPj4+Pg0KPj4+PiBTYXNoYW5rLCB0aGFua3MgZm9yIGFncmVlaW5nIHRvIGxvb2sg aW50byBpdCBmdXJ0aGVyLiBJIGFtIGxvb2tpbmcNCj4+Pj4gZm9yd2FyZCB0bw0KPj4+IHlvdXIg aW5zaWdodHMgb24gdGhpcy4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4gVGFsLg0KPj4+Pg0K Pj4+PiBMaW5rIHRvIHRoZSBkcmFmdDoNCj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi0NCj4+PiB0cmFuc2l0LTAxDQo+Pj4+DQo+Pj4+DQo+ Pj4+DQo+Pj4+IEZyb206IFNhc2hhbmsgRGFyYSAoc2FkYXJhKSBbbWFpbHRvOnNhZGFyYUBjaXNj by5jb21dDQo+Pj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTksIDIwMTYgMTI6MjAgUE0NCj4+Pj4g VG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsNCj4+Pj4gZHJhZnQt YnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+IHRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWJyb2NrbmVycy1wcm9vZi1vZi0NCj4+PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnPjsgc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlv biByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFmdA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+ PiBJIHdhbnQgdG8gYXNrIGEgc2ltcGxlIHF1ZXN0aW9uOg0KPj4+PiBJZiB0aGUgYXR0YWNrZXIg YXR0YWNoZXMgdGhlIFBPVCBvZiBwYWNrZXQgQSAoaW5kaWNhdGluZyB0aGUgcGF0aA0KPj4+PiB0 aHJvdWdoDQo+Pj4gMSwzLDUsNikgdG8gcGFja2V0IEIsIHdpbGwgdGhlIHZlcmlmaWVyIGFjY2Vw dCBwYWNrZXQgQiBhbmQgYmVsaWV2ZQ0KPj4+IHRoYXQgaXRzIHBhdGggd2FzIGluZGVlZCAoMSwz LDUsNik/DQo+Pj4+DQo+Pj4+IFtTRF0gSWYgdGhlIHZlcmlmaWVyIGlzIHByb2dyYW1tZWQgdG8g anVzdCB2YWxpZGF0ZSB0aGUgUE9UIG1ldGENCj4+Pj4gZGF0YSBhZ2FpbnN0DQo+Pj4gezEsMyw1 LDZ9IHRoZW4geWVzIGl0IGFjY2VwdHMgaXQuDQo+Pj4+IElmIHRoZSB2ZXJpZmllciBpcyBwcm9n cmFtbWVkIHRvIGNvbnN1bHQgYSBwb2xpY3kgZGF0YWJhc2UgdG8gY3Jvc3MNCj4+Pj4gY2hlY2sg aWYNCj4+PiB0aGUgcmVjb25zdHJ1Y3RlZCBwYXRoIHsxLDMsNSw2fSBpcyBhcyBwZXIgdGhlIHBv bGljaWVzIHRoZW4gbm8gLCBpdCBkcm9wcyBpdCAuDQo+Pj4+DQo+Pj4+IEJ1dCBJIHNlZSB5b3Vy IHBvaW50ICwgdGhhdCB0aGUgcGFyYW1ldGVycyB1c2VkIGluIFBPVCBkYXRhIGRvbm90DQo+Pj4+ IGNvbnNpZGVyDQo+Pj4gdGhlIHBhdGggb3Igbm9kZS1pZHMgZXRjIC4gV2Ugc2hhbGwgZGlzY3Vz cyB0aGlzIGludGVybmFsbHkgYW5kIGdldCBiYWNrLg0KPj4+Pg0KPj4+PiBBbHNvLCBXZSBzaGFs bCBnZXQgYmFjayB3aXRoIG1vcmUgY29uY3JldGUgbnVtYmVycyBvZiB0aGUgdGltZXN0YW1wDQo+ Pj4gcmVzb2x1dGlvbiBhbmQgY2FjaGUgc2l6ZXMgKG9yIG90aGVyIGJldHRlciBhcHByb2FjaGVz KS4NCj4+Pj4NCj4+Pj4gVGhhbmsgeW91IHNvIG11Y2ggZm9yIGFsbCB0aGUgaW5wdXRzLg0KPj4+ Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBGcm9tOiBUYWwgTWl6cmFoaQ0KPj4+PiBTZW50OiBUdWVzZGF5 LCBKdWx5IDE5LCAyMDE2IDEwOjI4IEFNDQo+Pj4+IFRvOiAnU2FzaGFuayBEYXJhIChzYWRhcmEp JzsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSk7DQo+Pj4+IGRyYWZ0LWJyb2NrbmVycy0NCj4+ PiBwcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25lcnMt cHJvb2Ytb2YtDQo+Pj4gdHJhbnNpdEB0b29scy5pZXRmLm9yZz47IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KPj4+PiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFBy b29mIG9mIFRyYW5zaXQgZHJhZnQNCj4+Pj4NCj4+Pj4gRGVhciBTYXNoYW5rLA0KPj4+Pg0KPj4+ PiBJIHJlYWxseSBhcHByZWNpYXRlIHRoZSBxdWljayBhbmQgZGV0YWlsZWQgcmVzcG9uc2VzLg0K Pj4+Pg0KPj4+Pj4+PiBMZXRzIHRha2UgY29ycmVjdCBwYXRoIHRha2VuIGJ5IFBhY2tldCBBICB0 byBiZSBQYXRoMSAtICgNCj4+Pj4+Pj4gMSwzLDUsNikgbm9kZXMNCj4+DQoNCg== From nobody Wed Jul 20 03:21:52 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0208812DB02; Wed, 20 Jul 2016 03:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 QD9fRM5kfOOa; Wed, 20 Jul 2016 03:21:44 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B548012DAF0; Wed, 20 Jul 2016 03:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17070; q=dns/txt; s=iport; t=1469010103; x=1470219703; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=441RmilXsuPXSCFK2XQZ2W+iGTvJ8mtmCetovA0urc8=; b=BTgxaKcTyxXq4XKTwQ0lSBFVzYLiMMLPfpAtGM/WPOXmbGmjsAWyserh Yf4wO3tT/nLrSuF0A5I2Oc86kZRzuwiRzPG0B+/gGhqCi1COBFg8LjIEQ u62hgrZ7aolIakp3CLHHKpDjRIgYxDgOpUfV1Ib4GMOQj1gds6ALjSffc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgBvT49X/40NJK1dgz9WfAa4YIF6I?= =?us-ascii?q?oV4AhyBEzgUAQEBAQEBAWUnhFwBAQQBIxEzEgUHBAIBCBEEAQEBAgIjAwICAjA?= =?us-ascii?q?UAQgIAgQOBRuIDQgOr0mNcwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQGFKYF4C?= =?us-ascii?q?IJNhEAXgmorgi8Fk2SFQgGGEohPjzmQHwEeNoILHIFMboYuKxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="298163879" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 10:21:42 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6KALgnO030733 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 10:21:42 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 06:21:41 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 06:21:41 -0400 From: "Carlos Pignataro (cpignata)" To: Tal Mizrahi Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnQwDyp0062d0e9x6ZtxvV7RaAhVGaAgAACSQCAAAU7gIAAA1IA Date: Wed, 20 Jul 2016 10:21:41 +0000 Message-ID: <615BB1D0-7B58-4566-9DB9-9363C9C116DD@cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> <16454292-3ADD-402A-AED6-CB785C5C833B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.88.191] Content-Type: text/plain; charset="utf-8" Content-ID: <026CB4CFB290784AB5ED43EDAEB00E12@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 10:21:47 -0000 SGkgVGFsLA0KDQo+IE9uIEp1bCAyMCwgMjAxNiwgYXQgMTI6MDkgUE0sIFRhbCBNaXpyYWhpIDx0 YWxtaUBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBDYXJsb3MsDQo+IA0KPiBJdCBhbGwg Z29lcyBiYWNrIHRvIHRoZSB0aHJlYXQgbW9kZWw7IHdoaWNoIHRocmVhdHMgeW91IHdhbnQgdG8g YWRkcmVzcywgYW5kIHdoaWNoIG9uZXMgeW91IGRvbid0Lg0KPiANCj4gVGhlIHdheSBJIHNlZSBp dCwgcm91Z2hseSBzcGVha2luZyB0aGVyZSBhcmUgMyBjbGFzc2VzIG9mIHRocmVhdHMgKHRoZXJl IGFlIHByb2JhYmx5IG90aGVyIHRocmVhdHMsIGJ1dCB0aGVzZSBhcmUgdGhlIGJhc2ljIG9uZXMp Og0KPiAtIE1pc3JvdXRlIC8gbWlzY29uZmlndXJhdGlvbiAobm90IGEgc2VjdXJpdHkgYXR0YWNr KS4NCj4gLSBBdHRhY2tlciB3aXRoIG5vIG9uLXBhdGggYWNjZXNzLg0KPiAtIE1hbi1pbi10aGUt bWlkZGxlIChhdHRhY2tlciAqd2l0aCogb24tcGF0aCBhY2Nlc3MpLg0KPiANCj4gSXQgbG9va3Mg bGlrZSB0aGUgdGhpcmQgdGhyZWF0IChtYW4taW4tdGhlLW1pZGRsZSkgaXMgY3VycmVudGx5IG5v dCBhZGRyZXNzZWQgYnkgUE9ULg0KPiBJIGNlcnRhaW5seSBhZ3JlZSB0aGF0IHRoaXMgdGhyZWF0 IGlzIHRoZSBtb3JlIGRpZmZpY3VsdCB0byBpbXBsZW1lbnQgb2YgdGhlIHRocmVlLg0KPiANCj4g SXQgd291bGQgc2lnbmlmaWNhbnRseSBjbGFyaWZ5IHRoZSBwaWN0dXJlIGlmIHlvdSBzcGVjaWZp ZWQgaW4gdGhlIGRyYWZ0IHdoaWNoIG9mIHRoZSB0aHJlZSBjbGFzc2VzIHlvdSBpbnRlbmQgdG8g YWRkcmVzcy4NCj4gDQoNClRoYXTigJlzIGEgZ29vZCBwb2ludCwgaW5kZWVkLiBUaGUgTUlJTSBp cyBvbmUgd2Ugc2hvdWxkIGV4cGFuZCB1cG9uLg0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoN Cj4gVGhhbmtzLA0KPiBUYWwuDQo+IA0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiBGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBj aXNjby5jb21dDQo+PiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjAsIDIwMTYgMTE6NTEgQU0NCj4+ IFRvOiBUYWwgTWl6cmFoaQ0KPj4gQ2M6IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgRnJhbmsgQnJv Y2tuZXJzIChmYnJvY2tuZSk7IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi0NCj4+IG9mLXRyYW5zaXRA dG9vbHMuaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnOyBudm8zQGlldGYu b3JnDQo+PiBTdWJqZWN0OiBSZTogTUQgVHlwZSBhdHRhY2sgKFdhczogUXVlc3Rpb24gcmVnYXJk aW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQpDQo+PiANCj4+IEhpLCBUYWwsDQo+PiANCj4+PiBP biBKdWwgMjAsIDIwMTYsIGF0IDExOjQyIEFNLCBUYWwgTWl6cmFoaSA8dGFsbWlAbWFydmVsbC5j b20+IHdyb3RlOg0KPj4+IA0KPj4+IEhpIENhcmxvcywNCj4+PiANCj4+PiANCj4+Pj4gTGV04oCZ cyBzdGVwIGJhY2sgYSBsaXR0bGUg4oCUIHRoZSDigJx2dWxuZXJhYmlsaXR54oCdIHlvdSBhcmUg ZGVzY3JpYmluZw0KPj4+PiBjb21lcyB3aXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgYSBNSUlUIGF0 dGFja2VyIGNhbiBpbnRlcmNlcHQgYQ0KPj4+PiBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbSB0 aGUgTUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNrZXQ7IHRoZW4NCj4+Pj4gaW50ZXJjZXB0IGFub3Ro ZXIgcGFja2V0ICh3aXRoIHRoZSBrbm93bGVkZ2UgdGhhdCBpdCB0b29rIGEgZGlmZmVyZW50DQo+ Pj4+IHBhdGgsIHNvIG1heWJlIHRoZSBhdHRhY2tlciBpcyB1c2luZyBpbmJhbmQgT0FNIGFzIHdl bGwgOi0pLCBhbmQNCj4+Pj4gaW5zZXJ0IChvciBtb2RpZnkpIGEgVExWIHdpdGhpbiB0aGUgY29u dGVudCBvZiB0aGUgTUQgVHlwZSAyIHdpdGhpbiB0aGUNCj4+IGNvbnRlbnQgb2YgTlNILCB3aXRo aW4gYSBzcGVjaWZpYyBwYWNrZXQuDQo+Pj4+IA0KPj4+PiBUaGlzIHNvdW5kcyBxdWl0ZSBzb3Bo aXN0aWNhdGVkLg0KPj4+IA0KPj4+IEkgYW0gbm90IHN1cmUgSSBhZ3JlZSB0aGlzIGlzIGEgJ3Nv cGhpc3RpY2F0ZWQnIGF0dGFjay4NCj4+PiBUaGUgYXR0YWNrIGRvZXMgbm90IHJlcXVpcmUgYW55 IGNyeXB0b2dyYXBoaWMgb3IgYWxnb3JpdGhtaWMgZnVuY3Rpb25hbGl0eSwNCj4+IGFuZCB0byB0 aGF0IGVuZCBpdCBpcyB2ZXJ5IGxpZ2h0d2VpZ2h0IGluIHRlcm1zIG9mIHByb2Nlc3NpbmcgcmVz b3VyY2VzLg0KPj4gDQo+PiBTb3JyeSBpZiBJIHdhcyBub3QgY2xlYXIg4oCUIEkgZG8gbm90IG1l YW4gdGVjaG5vbG9naWNhbCBzb3BoaXN0aWNhdGlvbiBvcg0KPj4gbWFzc2l2ZSBwcm9jZXNzaW5n IHJlc291cmNlcyByZXF1aXJlZC4gSSBtZWFuIGFjY2VzcyBhbmQgb3BlcmF0aW9uYWwgb25lLg0K Pj4gDQo+Pj4gDQo+Pj4gSWYgdGhpcyBraW5kIG9mIGF0dGFjayBpcyBub3Qgd2l0aGluIHRoZSBz Y29wZSBoZXJlLCB0aGVuIEkgd291bGQgYXJndWUgdGhhdA0KPj4geW91IGRvbid0IG5lZWQgYSBj cnlwdG9ncmFwaGljIG1lY2hhbmlzbSBhdCBhbGwuIEFsbCB5b3UgbmVlZCBpcyBhIFRMViB0aGF0 DQo+PiBzcGVjaWZpZXMgdGhlIGxpc3Qgb2Ygbm9kZXMuIEhvd2V2ZXIsIEkgYmVsaWV2ZSB0aGF0 IHlvdSBkaWQgd2FudCB0byB0cnkgdG8NCj4+IG1pdGlnYXRlIE1JVE0gYXR0YWNrZXJzLiBDb3Jy ZWN0IG1lIGlmIEkgYW0gd3JvbmcuDQo+Pj4gDQo+PiANCj4+IFlvdSBzZWVtIHRvIGhhdmUgbWlz c2VkIHF1b3RpbmcgdGhlIGltcG9ydGFudCBwYXJ0IG9mIG15IHJlc3BvbnNlOiAiTXkNCj4+IHBv aW50IGlzIHRoYXQgd2hhdCB5b3Ugc2VlbSB0byBiZSBkZXNjcmliaW5nIGlzIGEgZ2VuZXJpYyB0 aHJlYXQgdXNlIGNhc2UgYW5kDQo+PiBub3QgYSBzcGVjaWZpYyB2dWxuZXJhYmlsaXR5LuKAnQ0K Pj4gDQo+PiBTZWxlY3RpdmVseSBkcm9wcGluZyBwYXJ0IG9mIHRoZSByZXNwb25zZSByZW1vdmVz IGltcG9ydGFudCBjb250ZXh0Lg0KPj4gDQo+Pj4gSSBmdWxseSBhZ3JlZSB0aGF0IHRoZSB0aHJl YXQgbW9kZWwgbmVlZHMgdG8gYmUgd2VsbC1kZWZpbmVkLg0KPj4gDQo+PiBUaGUgdGhyZWF0IG1v ZGVsIGZvciBTRkMgTUQsIHllcy4gQWNjZXNzIHRvIHRoZSBQT1QgY29tZXMgd2l0aA0KPj4gYXNz dW1wdGlvbnMuDQo+PiANCj4+IFRoYW5rcywNCj4+IA0KPj4g4oCUIENhcmxvcy4NCj4+IA0KPj4+ IEkgaG9wZSB5b3Ugd2lsbCBlbGFib3JhdGUgbW9yZSBvbiB0aGUgdGhyZWF0IG1vZGVsIGluIHRo ZSBuZXh0IHZlcnNpb24gb2YNCj4+IHRoZSBkcmFmdC4NCj4+PiANCj4+PiBDaGVlcnMsDQo+Pj4g VGFsLg0KPj4+IA0KPj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBG cm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBjaXNjby5j b21dDQo+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMCwgMjAxNiAxMTozNCBBTQ0KPj4+PiBU bzogVGFsIE1penJhaGkNCj4+Pj4gQ2M6IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgRnJhbmsgQnJv Y2tuZXJzIChmYnJvY2tuZSk7DQo+Pj4+IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi0gb2YtdHJhbnNp dEB0b29scy5pZXRmLm9yZzsgc2ZjQGlldGYub3JnOw0KPj4+PiBvcHNhd2dAaWV0Zi5vcmc7IG52 bzNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogTUQgVHlwZSBhdHRhY2sgKFdhczogUXVlc3Rpb24g cmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQNCj4+Pj4gZHJhZnQpDQo+Pj4+IA0KPj4+PiBUYWws DQo+Pj4+IA0KPj4+Pj4gT24gSnVsIDIwLCAyMDE2LCBhdCA2OjMwIEFNLCBUYWwgTWl6cmFoaSA8 dGFsbWlAbWFydmVsbC5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBIaSBTYXNoYW5rLA0KPj4+ Pj4gDQo+Pj4+Pj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhlIGF0dGFja2Vy IGNhbiBnZXQgYXdheQ0KPj4+Pj4+IGJ5cGFzc2luZyBhDQo+Pj4+IHNlcnZpY2UgZnVuY3Rpb24v bm9kZS4NCj4+Pj4+PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFja2VyIGJ5cGFzc2VzIGEgbm9k ZSBhbmQgaWYgUE9UIGRldGVybWluZXMNCj4+Pj4+PiBpdCBkaWQNCj4+Pj4gbm90IGJ5cGFzcyBp cyBhIHZhbGlkIGF0dGFjayBvbiB0aGUgc3lzdGVtLg0KPj4+Pj4gDQo+Pj4+PiBJIHdvdWxkIHBo cmFzZSBpdCB0aGlzIHdheTogKkdpdmVuKiBhIHBhY2tldCB0aGF0IGRpZCBub3QgZ28gdGhyb3Vn aA0KPj4+Pj4gaXRzDQo+Pj4+IGRlc2lyZWQgcGF0aCwgdGhlIGF0dGFja2VyIGNhbiBlYXNpbHkg bWFrZSB5b3UgdGhpbmsgdGhhdCBpdCAqZGlkKiBnbw0KPj4+PiB0aHJvdWdoIHRoZSBkZXNpcmVk IHBhdGguDQo+Pj4+PiBTb3VuZHMgbGlrZSBhIHZlcnkgc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0 eS4NCj4+Pj4+IA0KPj4+Pj4gSWYgYSBwYWNrZXQgZGlkIG5vdCBnbyB0aHJvdWdoIHRoZSBmaXJl d2FsbCAoZm9yIG9uZSByZWFzb24gb3INCj4+Pj4+IGFub3RoZXIpLCB0aGUNCj4+Pj4gYXR0YWNr ZXIgd2lsbCBtYWtlIHlvdSB0aGluayB0aGF0IGl0IGRpZCBnbyB0aHJvdWdoIHRoZSBmaXJld2Fs bC4NCj4+Pj4+IA0KPj4+PiANCj4+Pj4gTGV04oCZcyBzdGVwIGJhY2sgYSBsaXR0bGUg4oCUIHRo ZSDigJx2dWxuZXJhYmlsaXR54oCdIHlvdSBhcmUgZGVzY3JpYmluZw0KPj4+PiBjb21lcyB3aXRo IHRoZSBhc3N1bXB0aW9uIHRoYXQgYSBNSUlUIGF0dGFja2VyIGNhbiBpbnRlcmNlcHQgYQ0KPj4+ PiBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbSB0aGUgTUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNr ZXQ7IHRoZW4NCj4+Pj4gaW50ZXJjZXB0IGFub3RoZXIgcGFja2V0ICh3aXRoIHRoZSBrbm93bGVk Z2UgdGhhdCBpdCB0b29rIGEgZGlmZmVyZW50DQo+Pj4+IHBhdGgsIHNvIG1heWJlIHRoZSBhdHRh Y2tlciBpcyB1c2luZyBpbmJhbmQgT0FNIGFzIHdlbGwgOi0pLCBhbmQNCj4+Pj4gaW5zZXJ0IChv ciBtb2RpZnkpIGEgVExWIHdpdGhpbiB0aGUgY29udGVudCBvZiB0aGUgTUQgVHlwZSAyIHdpdGhp biB0aGUNCj4+IGNvbnRlbnQgb2YgTlNILCB3aXRoaW4gYSBzcGVjaWZpYyBwYWNrZXQuDQo+Pj4+ IA0KPj4+PiBUaGlzIHNvdW5kcyBxdWl0ZSBzb3BoaXN0aWNhdGVkLg0KPj4+PiANCj4+Pj4gRG8g eW91IHRoaW5rIHRoYXQgaWYgYW4gTUlJVCBjYW4gaGF2ZSB0aGF0IHN1cmZhY2Ugb2YgYXR0YWNr IGFuZA0KPj4+PiBzb3BoaXN0aWNhdGlvbiwgdGhleSBjYW4gbWVzcyB1cCB3aXRoIG90aGVyIGV2 ZW4gbW9yZSBjcml0aWNhbCB0aGluZ3M/DQo+Pj4+IENoYW5naW5nIGEgVGVuYW50IElELCBtZXNz aW5nIHVwIHdpdGggUG9saWN5IEdyb3VwcywgZXRjPw0KPj4+PiANCj4+Pj4gTXkgcG9pbnQgaXMg dGhhdCB3aGF0IHlvdSBzZWVtIHRvIGJlIGRlc2NyaWJpbmcgaXMgYSBnZW5lcmljIHRocmVhdA0K Pj4+PiB1c2UgY2FzZSBhbmQgbm90IGEgc3BlY2lmaWMgdnVsbmVyYWJpbGl0eS4gRW5naW5lZXJp bmcgaXMgYWJvdXQNCj4+Pj4gdHJhZGUtb2ZmcyAoaS5lLiwgc29sdXRpb25zIHRoYXQgaGF2ZSBw cmFjdGljYWwgcGVyZm9ybWFuY2UpIGFuZA0KPj4+PiBhYm91dCBwbGFjaW5nIHRoZSBzb2x1dGlv biBpbiB0aGUgbW9zdCBlZmZlY3RpdmUgcGxhY2UuDQo+Pj4+IA0KPj4+PiBJ4oCZbSBub3QgZGVm bGVjdGluZyBidXQgYXQgdGhlIHNhbWUgdGltZSwgbGV04oCZcyB1bmRlcnN0YW5kIHRoZQ0KPj4+ PiBhc3N1bXB0aW9ucyB5b3UgYXJlIG1ha2luZyBmb3IgdGhpcyBwb3RlbnRpYWwgYXR0YWNrIHlv dSBkZXNjcmliZSwgYXMNCj4+Pj4gcGFydCBvZiB0aGUgdGhyZWF0IGFuYWx5c2lzLg0KPj4+PiAN Cj4+Pj4gVGhhbmtzLA0KPj4+PiANCj4+Pj4g4oCUIENhcmxvcy4NCj4+Pj4gDQo+Pj4+PiBDaGVl cnMsDQo+Pj4+PiBUYWwuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gRnJvbTogU2FzaGFuayBEYXJh IChzYWRhcmEpIFttYWlsdG86c2FkYXJhQGNpc2NvLmNvbV0NCj4+Pj4+IFNlbnQ6IFdlZG5lc2Rh eSwgSnVseSAyMCwgMjAxNiA0OjMxIEFNDQo+Pj4+PiBUbzogVGFsIE1penJhaGk7IEZyYW5rIEJy b2NrbmVycyAoZmJyb2NrbmUpOw0KPj4+Pj4gZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+ PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnDQo+Pj4+PiBDYzogc2ZjQGlldGYub3JnOyBvcHNhd2dA aWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiByZWdh cmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFmdA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+ Pj4gVGhlIFBPVCByZXBsYWNlbWVudCBhdHRhY2sgKDEuKSBpcyBub3QgYW4gYXR0YWNrIG9uIHRo ZSBpbnRlZ3JpdHkuDQo+Pj4+PiBJdCBpcyBhbg0KPj4+PiBhdHRhY2sgb24gdGhlIHBhdGggdmVy aWZpY2F0aW9uLg0KPj4+Pj4gVGhpcyBzaW1wbGUgYXR0YWNrIGNhbiBjYXVzZSB0aGUgdmVyaWZp ZXIgdG8gYWNjZXB0IGEgcGFja2V0IHRoYXQNCj4+Pj4+IGRpZCBub3QgZ28NCj4+Pj4gdGhyb3Vn aCB0aGUgZmlyZXdhbGwgU0YgKGV2ZW4gdGhvdWdoIGl0IHNob3VsZCkuIEkgYmVsaWV2ZSB0aGlz IGlzDQo+Pj4+IGV4YWN0bHkgdGhlIHByb2JsZW0geW91IHdlcmUgYWltaW5nIHRvIGFkZHJlc3Mg aW4gdGhpcyBkcmFmdC4NCj4+Pj4+IA0KPj4+Pj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9u bHkgaWYgdGhlIGF0dGFja2VyIGNhbiBnZXQgYXdheSBieXBhc3NpbmcNCj4+Pj4+IGEgc2Vydmlj ZQ0KPj4+PiBmdW5jdGlvbi9ub2RlLg0KPj4+Pj4gRm9yIGV4YW1wbGUsIGlmIHRoZSBhdHRhY2tl ciBieXBhc3NlcyBhIG5vZGUgYW5kIGlmIFBPVCBkZXRlcm1pbmVzDQo+Pj4+PiBpdCBkaWQNCj4+ Pj4gbm90IGJ5cGFzcyBpcyBhIHZhbGlkIGF0dGFjayBvbiB0aGUgc3lzdGVtLg0KPj4+Pj4gDQo+ Pj4+PiBJbiB0aGUgY3VycmVudCBzdGF0ZSwgdGhlcmUgaXMgbm8gd2F5IGFuIGF0dGFja2VyIGNh biBnZXQgYXdheSBhcyB3ZQ0KPj4+PiBkZXRlcm1pbmUgdGhlIGV4YWN0IHBhdGggdGhlIHBhY2tl dCB0cmF2ZWxsZWQgKGFpbSBvZiB0aGUgZHJhZnQpIC4NCj4+Pj4+IEkgcmVpdGVyYXRlIHRoYXQg dGhlIHZlcmlmaWVyIG5lZWRzIHRvIGhhbmRsZSB3aGF0IHRvIGRvIHdpdGggdGhlDQo+Pj4+PiBw YXRoDQo+Pj4+IHJlY29uc3RydWN0ZWQgIQ0KPj4+Pj4gV2UgY291bGQgZW1waGFzaXplIHRoaXMg aW4gb3VyIG5leHQgZHJhZnQgLCBidXQgaXQgd291bGQgYmUgYmV5b25kDQo+Pj4+PiBzY29wZSBv Zg0KPj4+PiBQT1QgdG8gZGV0ZXJtaW5lIHdoYXQgdG8gZG8gd2l0aCB0aGUgcGF0aCBjb25zdHJ1 Y3RlZC4NCj4+Pj4+IElNTywgSXQgd291bGQgYmUgaGlnaGx5IGFwcGxpY2F0aW9uIHNwZWNpZmlj Lg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+PiBTYXNoYW5rDQo+Pj4+PiAN Cj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiBUYWwuDQo+Pj4+PiANCj4+Pj4+ IEZyb206IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIFttYWlsdG86ZmJyb2NrbmVAY2lzY28u Y29tXQ0KPj4+Pj4gU2VudDogVHVlc2RheSwgSnVseSAxOSwgMjAxNiA2OjAwIFBNDQo+Pj4+PiBU bzogVGFsIE1penJhaGk7IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgZHJhZnQtYnJvY2tuZXJzLXBy b29mLW9mLQ0KPj4+PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25l cnMtcHJvb2Ytb2YtDQo+Pj4+IHRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc+DQo+Pj4+PiBDYzogc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Ow0KPj4+PiBvcHNhd2dAaWV0Zi5vcmc8bWFp bHRvOm9wc2F3Z0BpZXRmLm9yZz47DQo+Pj4+IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0 Zi5vcmc+DQo+Pj4+PiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRy YW5zaXQgZHJhZnQNCj4+Pj4+IA0KPj4+Pj4gSGkgVGFsLA0KPj4+Pj4gDQo+Pj4+PiB0aGFua3Mg Zm9yIHRoZSBzdW1tYXJ5LiBXZSdsbCBwcm92aWRlIG1vcmUgZGV0YWlscyBvbiAyLiBQZXIgbXkN Cj4+Pj4+IGVhcmxpZXINCj4+Pj4gcG9pbnQgLSAxLiBpcyBhbiBpbnRlcmVzdGluZyBkaXNjdXNz aW9uLCBnaXZlbiB0aGF0IHdlIGRvbid0IGNsYWltIHRvDQo+Pj4+IHByb3ZpZGUgaW50ZWdyaXR5 IHByb3RlY3Rpb24gZm9yIHRoZSBwYWNrZXQgcGF5bG9hZC4gT3IgaW4gb3RoZXIgdGVybXMgLSB0 bw0KPj4gYmUgZXhhY3Q6DQo+Pj4+IFdoYXQgUE9UIHByb3ZpZGVzIGlzIGEgcHJvb2YgdGhhdCB0 aGUgUE9ULWhlYWRlci9tZXRhLWRhdGEgdHJhbnNpdGVkDQo+Pj4+IGFsbCB0aGUgcmVxdWlyZWQg bm9kZXMuIFRoZXJlIGlzIG5vIGFzc29jaWF0aW9uIChhbmQgdGh1cyBwcm9vZikNCj4+Pj4gcHJv dmlkZWQgZm9yIHRoZSBhZGRpdGlvbmFsIGRhdGEgY2FycmllZCBhbG9uZyB3aXRoIHRoZSBQT1Qt aGVhZGVyIC0NCj4+Pj4gbmVpdGhlciBoZWFkZXIgbm9yIHBheWxvYWQuIEFzIGEgY29uc2VxdWVu Y2UsIGF0dGFja3Mgd2hpY2ggY2hhbmdlDQo+Pj4+IHRoZSBwYWNrZXQgcGF5bG9hZCB3b24ndCBi ZSBkZXRlY3RlZC9taXRpZ2F0ZWQuIFdlJ2xsIGV4cGxpY2l0bHkNCj4+Pj4gc3RhdGUgdGhpcyBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gdGhlIG5leHQgcmV2IG9mIHRoZSBkb2N1 bWVudC4NCj4+Pj4+IFdoYXQgd2UgY291bGQgY29uc2lkZXIgaXMgbGlua2luZyB0aGUgUk5EIG51 bWJlciB0byBDUkMgYWNyb3NzIHRoZQ0KPj4+Pj4gcGFja2V0DQo+Pj4+IHBheWxvYWQgb3Igc2lt aWxhciAtIGJ1dCB0aGF0IHdheSB3ZSdkIHJlc3RyaWN0IHRoZSBhcHBsaWNhYmlsaXR5IHRvDQo+ Pj4+IGRlcGxveW1lbnRzIHdoZXJlIHRoZSBwYWNrZXQgcGF5bG9hZCBpc24ndCBjaGFuZ2VkIGFj cm9zcyB0aGUgcGF0aA0KPj4+PiAod2hpY2ggbWlnaHQgbm90IGFwcGx5IHRvIGNlcnRhaW4gZGVw bG95bWVudCAtIGUuZy4gV0FOIG9wdGltaXphdGlvbiAvDQo+PiBjb21wcmVzc2lvbiBzY2hlbWVz KS4NCj4+Pj4+IERvIHlvdSB0aGluayBpdCBpcyB3b3J0aHdoaWxlIHRvIHByb3ZpZGUgYSBzb2x1 dGlvbiBmb3IgYSBkZXBsb3ltZW50DQo+Pj4+PiB3aGljaCBpcw0KPj4+PiBleHBlY3RlZCB0byBu b3QgYWx0ZXIgdGhlIHBhY2tldCBwYXlsb2FkPw0KPj4+Pj4gDQo+Pj4+PiBUaGFua3MsDQo+Pj4+ PiBGcmFuaw0KPj4+Pj4gDQo+Pj4+PiBGcm9tOiBUYWwgTWl6cmFoaSBbbWFpbHRvOnRhbG1pQG1h cnZlbGwuY29tXQ0KPj4+Pj4gU2VudDogRGllbnN0YWcsIDE5LiBKdWxpIDIwMTYgMTc6NDQNCj4+ Pj4+IFRvOiBTYXNoYW5rIERhcmEgKHNhZGFyYSkNCj4+Pj4gPHNhZGFyYUBjaXNjby5jb208bWFp bHRvOnNhZGFyYUBjaXNjby5jb20+PjsgRnJhbmsgQnJvY2tuZXJzDQo+Pj4+IChmYnJvY2tuZSkg PGZicm9ja25lQGNpc2NvLmNvbTxtYWlsdG86ZmJyb2NrbmVAY2lzY28uY29tPj47DQo+Pj4+IGRy YWZ0LWJyb2NrbmVycy0NCj4+Pj4gcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+PiB0cmFuc2l0QHRvb2xzLmlldGYub3Jn Pg0KPj4+Pj4gQ2M6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjsNCj4+Pj4gb3Bz YXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+Ow0KPj4+PiBudm8zQGlldGYub3Jn PG1haWx0bzpudm8zQGlldGYub3JnPg0KPj4+Pj4gU3ViamVjdDogUkU6IFF1ZXN0aW9uIHJlZ2Fy ZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQo+Pj4+PiANCj4+Pj4+IEhpLA0KPj4+Pj4gDQo+ Pj4+PiBUbyBzdW1tYXJpemUgbXkgdGFrZSBvbiB0aGlzIHRocmVhZDoNCj4+Pj4+IFRoZSBwcm9w b3NlZCBtZWNoYW5pc20gaGFzIHR3byBzaWduaWZpY2FudCB2dWxuZXJhYmlsaXRpZXMgdGhhdCAo aW4NCj4+Pj4+IG15DQo+Pj4+IHVuZGVyc3RhbmRpbmcpIGFyZSBjdXJyZW50bHkgbm90IGFkZHJl c3NlZDoNCj4+Pj4+IA0KPj4+Pj4gMS4gICAgICAgQSBtYW4taW4tdGhlLW1pZGRsZSBjYW4gcmVw bGFjZSB0aGUgUE9UIG9mIHBhY2tldCBBIHdpdGggdGhlIFBPVA0KPj4gb2YNCj4+Pj4gcGFja2V0 IEIuDQo+Pj4+PiANCj4+Pj4+IDIuICAgICAgIEl0IGlzIHBvc3NpYmxlIHRvIHJlcGxheSBQT1Rz IHdpdGhpbiBhIGNlcnRhaW4gdGltZSB3aW5kb3csIHdob3NlDQo+Pj4+IGxlbmd0aCBpcyBkZXRl cm1pbmVkIGJ5IHRoZSB0aW1lc3RhbXAgcmVzb2x1dGlvbi4NCj4+Pj4+IA0KPj4+Pj4gU2FzaGFu aywgdGhhbmtzIGZvciBhZ3JlZWluZyB0byBsb29rIGludG8gaXQgZnVydGhlci4gSSBhbSBsb29r aW5nDQo+Pj4+PiBmb3J3YXJkIHRvDQo+Pj4+IHlvdXIgaW5zaWdodHMgb24gdGhpcy4NCj4+Pj4+ IA0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+IFRhbC4NCj4+Pj4+IA0KPj4+Pj4gTGluayB0byB0aGUg ZHJhZnQ6DQo+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJz LXByb29mLW9mLQ0KPj4+PiB0cmFuc2l0LTAxDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+ PiBGcm9tOiBTYXNoYW5rIERhcmEgKHNhZGFyYSkgW21haWx0bzpzYWRhcmFAY2lzY28uY29tXQ0K Pj4+Pj4gU2VudDogVHVlc2RheSwgSnVseSAxOSwgMjAxNiAxMjoyMCBQTQ0KPj4+Pj4gVG86IFRh bCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsNCj4+Pj4+IGRyYWZ0LWJyb2Nr bmVycy1wcm9vZi1vZi0NCj4+Pj4gdHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQt YnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnPjsgc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+PiBTdWJqZWN0OiBSZTogUXVlc3Rpb24g cmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAN Cj4+Pj4+IEkgd2FudCB0byBhc2sgYSBzaW1wbGUgcXVlc3Rpb246DQo+Pj4+PiBJZiB0aGUgYXR0 YWNrZXIgYXR0YWNoZXMgdGhlIFBPVCBvZiBwYWNrZXQgQSAoaW5kaWNhdGluZyB0aGUgcGF0aA0K Pj4+Pj4gdGhyb3VnaA0KPj4+PiAxLDMsNSw2KSB0byBwYWNrZXQgQiwgd2lsbCB0aGUgdmVyaWZp ZXIgYWNjZXB0IHBhY2tldCBCIGFuZCBiZWxpZXZlDQo+Pj4+IHRoYXQgaXRzIHBhdGggd2FzIGlu ZGVlZCAoMSwzLDUsNik/DQo+Pj4+PiANCj4+Pj4+IFtTRF0gSWYgdGhlIHZlcmlmaWVyIGlzIHBy b2dyYW1tZWQgdG8ganVzdCB2YWxpZGF0ZSB0aGUgUE9UIG1ldGENCj4+Pj4+IGRhdGEgYWdhaW5z dA0KPj4+PiB7MSwzLDUsNn0gdGhlbiB5ZXMgaXQgYWNjZXB0cyBpdC4NCj4+Pj4+IElmIHRoZSB2 ZXJpZmllciBpcyBwcm9ncmFtbWVkIHRvIGNvbnN1bHQgYSBwb2xpY3kgZGF0YWJhc2UgdG8gY3Jv c3MNCj4+Pj4+IGNoZWNrIGlmDQo+Pj4+IHRoZSByZWNvbnN0cnVjdGVkIHBhdGggezEsMyw1LDZ9 IGlzIGFzIHBlciB0aGUgcG9saWNpZXMgdGhlbiBubyAsIGl0IGRyb3BzIGl0IC4NCj4+Pj4+IA0K Pj4+Pj4gQnV0IEkgc2VlIHlvdXIgcG9pbnQgLCB0aGF0IHRoZSBwYXJhbWV0ZXJzIHVzZWQgaW4g UE9UIGRhdGEgZG9ub3QNCj4+Pj4+IGNvbnNpZGVyDQo+Pj4+IHRoZSBwYXRoIG9yIG5vZGUtaWRz IGV0YyAuIFdlIHNoYWxsIGRpc2N1c3MgdGhpcyBpbnRlcm5hbGx5IGFuZCBnZXQgYmFjay4NCj4+ Pj4+IA0KPj4+Pj4gQWxzbywgV2Ugc2hhbGwgZ2V0IGJhY2sgd2l0aCBtb3JlIGNvbmNyZXRlIG51 bWJlcnMgb2YgdGhlIHRpbWVzdGFtcA0KPj4+PiByZXNvbHV0aW9uIGFuZCBjYWNoZSBzaXplcyAo b3Igb3RoZXIgYmV0dGVyIGFwcHJvYWNoZXMpLg0KPj4+Pj4gDQo+Pj4+PiBUaGFuayB5b3Ugc28g bXVjaCBmb3IgYWxsIHRoZSBpbnB1dHMuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBG cm9tOiBUYWwgTWl6cmFoaQ0KPj4+Pj4gU2VudDogVHVlc2RheSwgSnVseSAxOSwgMjAxNiAxMDoy OCBBTQ0KPj4+Pj4gVG86ICdTYXNoYW5rIERhcmEgKHNhZGFyYSknOyBGcmFuayBCcm9ja25lcnMg KGZicm9ja25lKTsNCj4+Pj4+IGRyYWZ0LWJyb2NrbmVycy0NCj4+Pj4gcHJvb2Ytb2YtdHJhbnNp dEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+PiB0 cmFuc2l0QHRvb2xzLmlldGYub3JnPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+Pj4+PiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQg ZHJhZnQNCj4+Pj4+IA0KPj4+Pj4gRGVhciBTYXNoYW5rLA0KPj4+Pj4gDQo+Pj4+PiBJIHJlYWxs eSBhcHByZWNpYXRlIHRoZSBxdWljayBhbmQgZGV0YWlsZWQgcmVzcG9uc2VzLg0KPj4+Pj4gDQo+ Pj4+Pj4+PiBMZXRzIHRha2UgY29ycmVjdCBwYXRoIHRha2VuIGJ5IFBhY2tldCBBICB0byBiZSBQ YXRoMSAtICgNCj4+Pj4+Pj4+IDEsMyw1LDYpIG5vZGVzDQo+Pj4gDQo+IA0KDQo= From nobody Wed Jul 20 04:06:51 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFD912D537; Wed, 20 Jul 2016 04:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 4LAWZA0pNVD6; Wed, 20 Jul 2016 04:06:43 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E3212DB7C; Wed, 20 Jul 2016 04:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12647; q=dns/txt; s=iport; t=1469012769; x=1470222369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FiKND2rxt+SLcN8J83DAM+qsRLyNgeaNXIuwQlaMsko=; b=DWa5pzC7ejkHsWsYzOuPxhqLD5aGO0+0IJmPsZPAOpzy10B8uO80x9Rr spt3eEBVwDQ0wuIRKmw2YsDkGvYjcgvvKeckOiY8hvhqmIiaBiSCH/+a7 jg9q9zWlvCeTYatRfFNZuBG2jIBtfjkMecUXtOqOwZD92XarSCvSwfW2B I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgBDWo9X/40NJK1dgz9WfAa4UYF6I?= =?us-ascii?q?oV4AoEvOBQBAQEBAQEBZSeEXAEBBWcSDAQCAQgRBAEBAScHMhQJCAIEAQ0FG4g?= =?us-ascii?q?VDr1DAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhECFWwEEmSYBhhKIT485k?= =?us-ascii?q?B8BHjaCCxyBTG6GLisYAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="300091954" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 11:06:08 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6KB68Sb031600 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 11:06:08 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 06:06:07 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 06:06:07 -0500 From: "Sashank Dara (sadara)" To: Tal Mizrahi , "Carlos Pignataro (cpignata)" Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnR49sgJZJZWUWTXAMFLb5ExaAhZSqAgAACSoCAAAU6gIAAa+mA Date: Wed, 20 Jul 2016 11:06:07 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> <16454292-3ADD-402A-AED6-CB785C5C833B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [72.163.210.134] Content-Type: text/plain; charset="Windows-1252" Content-ID: <371D2F1F0FD9B14C82534A1F21DAD3F1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "draft-brockners-proof-of-transit@tools.ietf.org" , "Frank Brockners \(fbrockne\)" Subject: Re: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:06:46 -0000 On 20/07/16, 3:39 PM, "Tal Mizrahi" wrote: >Hi Carlos, > >It all goes back to the threat model; which threats you want to address, >and which ones you don't. > >The way I see it, roughly speaking there are 3 classes of threats (there >ae probably other threats, but these are the basic ones): >- Misroute / misconfiguration (not a security attack). >- Attacker with no on-path access. >- Man-in-the-middle (attacker *with* on-path access). > >It looks like the third threat (man-in-the-middle) is currently not >addressed by POT. >I certainly agree that this threat is the more difficult to implement of >the three. Thanks for such classification, we shall work on better threat modelling and clarity in our next version. Now , Can we put some concrete high level protocol names here that could use POT and prone to MITM ? Helps us understand the validity of the =B3mix-and-match=B2 attack you described in a more concrete context. > >It would significantly clarify the picture if you specified in the draft >which of the three classes you intend to address. > >Thanks, >Tal. > > >>-----Original Message----- >>From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>Sent: Wednesday, July 20, 2016 11:51 AM >>To: Tal Mizrahi >>Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); >>draft-brockners-proof- >>of-transit@tools.ietf.org; sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org >>Subject: Re: MD Type attack (Was: Question regarding Proof of Transit >>draft) >> >>Hi, Tal, >> >>> On Jul 20, 2016, at 11:42 AM, Tal Mizrahi wrote: >>> >>> Hi Carlos, >>> >>> >>>> Let=B9s step back a little =8B the =B3vulnerability=B2 you are describ= ing >>>> comes with the assumption that a MIIT attacker can intercept a >>>> packet, extract a TLV from the MD Type 2, drop the packet; then >>>> intercept another packet (with the knowledge that it took a different >>>> path, so maybe the attacker is using inband OAM as well :-), and >>>> insert (or modify) a TLV within the content of the MD Type 2 within >>>>the >>content of NSH, within a specific packet. >>>> >>>> This sounds quite sophisticated. >>> >>> I am not sure I agree this is a 'sophisticated' attack. >>> The attack does not require any cryptographic or algorithmic >>>functionality, >>and to that end it is very lightweight in terms of processing resources. >> >>Sorry if I was not clear =8B I do not mean technological sophistication o= r >>massive processing resources required. I mean access and operational one. >> >>> >>> If this kind of attack is not within the scope here, then I would >>>argue that >>you don't need a cryptographic mechanism at all. All you need is a TLV >>that >>specifies the list of nodes. However, I believe that you did want to try >>to >>mitigate MITM attackers. Correct me if I am wrong. >>> >> >>You seem to have missed quoting the important part of my response: "My >>point is that what you seem to be describing is a generic threat use >>case and >>not a specific vulnerability.=B2 >> >>Selectively dropping part of the response removes important context. >> >>> I fully agree that the threat model needs to be well-defined. >> >>The threat model for SFC MD, yes. Access to the POT comes with >>assumptions. >> >>Thanks, >> >>=8B Carlos. >> >>> I hope you will elaborate more on the threat model in the next version >>>of >>the draft. >>> >>> Cheers, >>> Tal. >>> >>> >>>> -----Original Message----- >>>> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>>> Sent: Wednesday, July 20, 2016 11:34 AM >>>> To: Tal Mizrahi >>>> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); >>>> draft-brockners-proof- of-transit@tools.ietf.org; sfc@ietf.org; >>>> opsawg@ietf.org; nvo3@ietf.org >>>> Subject: MD Type attack (Was: Question regarding Proof of Transit >>>> draft) >>>> >>>> Tal, >>>> >>>>> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi wrote: >>>>> >>>>> Hi Sashank, >>>>> >>>>>> [SD] The attack is valid only if the attacker can get away >>>>>> bypassing a >>>> service function/node. >>>>>> For example, if the attacker bypasses a node and if POT determines >>>>>> it did >>>> not bypass is a valid attack on the system. >>>>> >>>>> I would phrase it this way: *Given* a packet that did not go through >>>>> its >>>> desired path, the attacker can easily make you think that it *did* go >>>> through the desired path. >>>>> Sounds like a very significant vulnerability. >>>>> >>>>> If a packet did not go through the firewall (for one reason or >>>>> another), the >>>> attacker will make you think that it did go through the firewall. >>>>> >>>> >>>> Let=B9s step back a little =8B the =B3vulnerability=B2 you are describ= ing >>>> comes with the assumption that a MIIT attacker can intercept a >>>> packet, extract a TLV from the MD Type 2, drop the packet; then >>>> intercept another packet (with the knowledge that it took a different >>>> path, so maybe the attacker is using inband OAM as well :-), and >>>> insert (or modify) a TLV within the content of the MD Type 2 within >>>>the >>content of NSH, within a specific packet. >>>> >>>> This sounds quite sophisticated. >>>> >>>> Do you think that if an MIIT can have that surface of attack and >>>> sophistication, they can mess up with other even more critical things? >>>> Changing a Tenant ID, messing up with Policy Groups, etc? >>>> >>>> My point is that what you seem to be describing is a generic threat >>>> use case and not a specific vulnerability. Engineering is about >>>> trade-offs (i.e., solutions that have practical performance) and >>>> about placing the solution in the most effective place. >>>> >>>> I=B9m not deflecting but at the same time, let=B9s understand the >>>> assumptions you are making for this potential attack you describe, as >>>> part of the threat analysis. >>>> >>>> Thanks, >>>> >>>> =8B Carlos. >>>> >>>>> Cheers, >>>>> Tal. >>>>> >>>>> >>>>> From: Sashank Dara (sadara) [mailto:sadara@cisco.com] >>>>> Sent: Wednesday, July 20, 2016 4:31 AM >>>>> To: Tal Mizrahi; Frank Brockners (fbrockne); >>>>> draft-brockners-proof-of- >>>> transit@tools.ietf.org >>>>> Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org >>>>> Subject: Re: Question regarding Proof of Transit draft >>>>> >>>>> >>>>> >>>>> The POT replacement attack (1.) is not an attack on the integrity. >>>>> It is an >>>> attack on the path verification. >>>>> This simple attack can cause the verifier to accept a packet that >>>>> did not go >>>> through the firewall SF (even though it should). I believe this is >>>> exactly the problem you were aiming to address in this draft. >>>>> >>>>> [SD] The attack is valid only if the attacker can get away bypassing >>>>> a service >>>> function/node. >>>>> For example, if the attacker bypasses a node and if POT determines >>>>> it did >>>> not bypass is a valid attack on the system. >>>>> >>>>> In the current state, there is no way an attacker can get away as we >>>> determine the exact path the packet travelled (aim of the draft) . >>>>> I reiterate that the verifier needs to handle what to do with the >>>>> path >>>> reconstructed ! >>>>> We could emphasize this in our next draft , but it would be beyond >>>>> scope of >>>> POT to determine what to do with the path constructed. >>>>> IMO, It would be highly application specific. >>>>> >>>>> >>>>> Regards, >>>>> Sashank >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Tal. >>>>> >>>>> From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] >>>>> Sent: Tuesday, July 19, 2016 6:00 PM >>>>> To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of- >>>> transit@tools.ietf.org>>> transit@tools.ietf.org> >>>>> Cc: sfc@ietf.org; >>>> opsawg@ietf.org; >>>> nvo3@ietf.org >>>>> Subject: RE: Question regarding Proof of Transit draft >>>>> >>>>> Hi Tal, >>>>> >>>>> thanks for the summary. We'll provide more details on 2. Per my >>>>> earlier >>>> point - 1. is an interesting discussion, given that we don't claim to >>>> provide integrity protection for the packet payload. Or in other >>>>terms - to >>be exact: >>>> What POT provides is a proof that the POT-header/meta-data transited >>>> all the required nodes. There is no association (and thus proof) >>>> provided for the additional data carried along with the POT-header - >>>> neither header nor payload. As a consequence, attacks which change >>>> the packet payload won't be detected/mitigated. We'll explicitly >>>> state this in the security considerations in the next rev of the >>>>document. >>>>> What we could consider is linking the RND number to CRC across the >>>>> packet >>>> payload or similar - but that way we'd restrict the applicability to >>>> deployments where the packet payload isn't changed across the path >>>> (which might not apply to certain deployment - e.g. WAN optimization / >>compression schemes). >>>>> Do you think it is worthwhile to provide a solution for a deployment >>>>> which is >>>> expected to not alter the packet payload? >>>>> >>>>> Thanks, >>>>> Frank >>>>> >>>>> From: Tal Mizrahi [mailto:talmi@marvell.com] >>>>> Sent: Dienstag, 19. Juli 2016 17:44 >>>>> To: Sashank Dara (sadara) >>>> >; Frank Brockners >>>> (fbrockne) >; >>>> draft-brockners- >>>> proof-of-transit@tools.ietf.org>>> transit@tools.ietf.org> >>>>> Cc: sfc@ietf.org; >>>> opsawg@ietf.org; >>>> nvo3@ietf.org >>>>> Subject: RE: Question regarding Proof of Transit draft >>>>> >>>>> Hi, >>>>> >>>>> To summarize my take on this thread: >>>>> The proposed mechanism has two significant vulnerabilities that (in >>>>> my >>>> understanding) are currently not addressed: >>>>> >>>>> 1. A man-in-the-middle can replace the POT of packet A with >>>>>the POT >>of >>>> packet B. >>>>> >>>>> 2. It is possible to replay POTs within a certain time window, >>>>>whose >>>> length is determined by the timestamp resolution. >>>>> >>>>> Sashank, thanks for agreeing to look into it further. I am looking >>>>> forward to >>>> your insights on this. >>>>> >>>>> Regards, >>>>> Tal. >>>>> >>>>> Link to the draft: >>>>> https://tools.ietf.org/html/draft-brockners-proof-of- >>>> transit-01 >>>>> >>>>> >>>>> >>>>> From: Sashank Dara (sadara) [mailto:sadara@cisco.com] >>>>> Sent: Tuesday, July 19, 2016 12:20 PM >>>>> To: Tal Mizrahi; Frank Brockners (fbrockne); >>>>> draft-brockners-proof-of- >>>> transit@tools.ietf.org>>> transit@tools.ietf.org>; sfc@ietf.org >>>>> Subject: Re: Question regarding Proof of Transit draft >>>>> >>>>> >>>>> >>>>> I want to ask a simple question: >>>>> If the attacker attaches the POT of packet A (indicating the path >>>>> through >>>> 1,3,5,6) to packet B, will the verifier accept packet B and believe >>>> that its path was indeed (1,3,5,6)? >>>>> >>>>> [SD] If the verifier is programmed to just validate the POT meta >>>>> data against >>>> {1,3,5,6} then yes it accepts it. >>>>> If the verifier is programmed to consult a policy database to cross >>>>> check if >>>> the reconstructed path {1,3,5,6} is as per the policies then no , it >>>>drops it . >>>>> >>>>> But I see your point , that the parameters used in POT data donot >>>>> consider >>>> the path or node-ids etc . We shall discuss this internally and get >>>>back. >>>>> >>>>> Also, We shall get back with more concrete numbers of the timestamp >>>> resolution and cache sizes (or other better approaches). >>>>> >>>>> Thank you so much for all the inputs. >>>>> >>>>> >>>>> >>>>> From: Tal Mizrahi >>>>> Sent: Tuesday, July 19, 2016 10:28 AM >>>>> To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); >>>>> draft-brockners- >>>> proof-of-transit@tools.ietf.org>>> transit@tools.ietf.org>; sfc@ietf.org >>>>> Subject: RE: Question regarding Proof of Transit draft >>>>> >>>>> Dear Sashank, >>>>> >>>>> I really appreciate the quick and detailed responses. >>>>> >>>>>>>> Lets take correct path taken by Packet A to be Path1 - ( >>>>>>>> 1,3,5,6) nodes >>> > From nobody Wed Jul 20 04:44:40 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA14412B05A for ; Wed, 20 Jul 2016 04:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 gs4eYd2oo-to for ; Wed, 20 Jul 2016 04:44:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1241E12D0B9 for ; Wed, 20 Jul 2016 04:44:37 -0700 (PDT) Received: from dhcp-b257.meeting.ietf.org ([IPv6:2001:67c:370:176:e436:a9e:be3c:4380]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u6KBiTQ5029017 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 20 Jul 2016 11:44:31 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2001:67c:370:176:e436:a9e:be3c:4380] claimed to be dhcp-b257.meeting.ietf.org To: "Bert Wijnen (IETF)" , "opsawg@ietf.org" References: <6553a6f9-4ef5-96be-d835-963d051e57a1@bwijnen.net> From: joel jaeggli Message-ID: <029b48c2-1fdf-26e9-4767-546495e550aa@bogus.com> Date: Wed, 20 Jul 2016 13:44:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 In-Reply-To: <6553a6f9-4ef5-96be-d835-963d051e57a1@bwijnen.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8MmUAVh70PpoIJMxGdVTXXoPb9T1gURXf" Archived-At: Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:44:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8MmUAVh70PpoIJMxGdVTXXoPb9T1gURXf Content-Type: multipart/mixed; boundary="I4FlgavcwCe217MPQbJNO1WaTjVR2HIR8" From: joel jaeggli To: "Bert Wijnen (IETF)" , "opsawg@ietf.org" Message-ID: <029b48c2-1fdf-26e9-4767-546495e550aa@bogus.com> Subject: Re: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt References: <6553a6f9-4ef5-96be-d835-963d051e57a1@bwijnen.net> In-Reply-To: <6553a6f9-4ef5-96be-d835-963d051e57a1@bwijnen.net> --I4FlgavcwCe217MPQbJNO1WaTjVR2HIR8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/19/16 8:29 PM, Bert Wijnen (IETF) wrote: >=20 > It is a short document. Hearing if you think this makes sense or not > would be great. >=20 > > Pages: 7 > > URL: > https://www.ietf.org/internet-drafts/draft-deng-opsawg-composed-vpn-sm-= requirements-01.txt yeah, so I'm not a huge consumer of L3 vpn at this point even if I have been in the past. that said, while i see some ultility in the customer modeling the interaction of single or multiple-provider-vpns for the purpose of describing the typology or expressing the configuration of pre-existing assets for reuse by VNFs, the configuration of provider vpns is typically opaque to customers, as they are to coordinating ISPs in a multi-provider setup. So from my vantage point the devil is in the question of how it get's used. joel >=20 > You can send you comments to me directly or (preferably) to the opsawg > mailing list at > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 > Thanks, > Bert Wijnen >=20 --I4FlgavcwCe217MPQbJNO1WaTjVR2HIR8-- --8MmUAVh70PpoIJMxGdVTXXoPb9T1gURXf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlePZB0ACgkQ8AA1q7Z/VrLEYgCdECNG96/Ozj+/VHu8GAUIPDgJ f2kAnjKwNPoQM0V2/3JvEh3oF+XebWH7 =/UW4 -----END PGP SIGNATURE----- --8MmUAVh70PpoIJMxGdVTXXoPb9T1gURXf-- From nobody Wed Jul 20 09:58:53 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277A912B046 for ; Wed, 20 Jul 2016 09:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 d-_495_r8BUA for ; Wed, 20 Jul 2016 09:58:42 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6B512D599 for ; Wed, 20 Jul 2016 09:58:42 -0700 (PDT) Received: from dhcp-b0ea.meeting.ietf.org ([31.133.176.234]) by smtp-cloud2.xs4all.net with ESMTP id M4yc1t00553osVK014yfkt; Wed, 20 Jul 2016 18:58:40 +0200 To: Randy Bush References: <4ecf49c5-f987-7184-8cf6-b706eb914bcd@bwijnen.net> From: "Bert Wijnen (IETF)" Message-ID: <82a37f28-49ee-f121-6b5f-64725f4bd7b5@bwijnen.net> Date: Wed, 20 Jul 2016 18:58:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: opsawg Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:58:45 -0000 for you input Randy. inline Thanks On 19/07/16 22:56, Randy Bush wrote: >> Hi Randy, today, at IETF96 in Berlin, we discussed this document in >> the OPSAWG meeting. >> We would be interested to hear your opinion (from an operator point of >> view) on this document. It is a short document. Hearing if you think >> this makes sense or not would be great. >> You can send you comments to me directly or (preferably) to the opsawg >> mailing list at OPSAWG@ietf.org > at this level of abstraction, anything can be made to look as if it > would work and be wonderful. it essentially says that a multi-as vpn is > composed by linking multiple single-as vpn systems. this is not a deep > insight, and it provides no clues on how to do it. Pls, the idea is to define REQUIREMENTS first. I will agree that the document is not very good at that yet either. So my real question is, does it make sense that we (as IETF and operators in IETF) try to define/specify a set of requirements fo composed VPN, and then, once we have that to try and develop protocols and interfaces that would allow interoperability. So mainly, I'd like to understand if operators feel that some IETF work in this space makes sense. And would operators be willing to help specify the requirements. > of the 392 devils to be found in the details, inter-provider > authentication and identification of end-points, billing, ... the list > goes on and one. And so, that list can possibly be converted into a set of requirements, I would think. > then there are issues such as describing and provisioning the contracted > (with the end customer) privacy constraints across multiple provider > technologies. yep, that will indeed be a big problem. But possibly we can find solutions once we know all the requirements. > fwiw, our customers do use multi-provider vpns; they use ipsec. we > provide ipsec capable cpe and various management/orchestration systems. So is that enough ? is there no improvements and interoperability improvements we can try to work on in this space, together with operators. > randy Thanks, Bert > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Wed Jul 20 10:28:21 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D483212D863 for ; Wed, 20 Jul 2016 10:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 hhAOqJaXxsWV for ; Wed, 20 Jul 2016 10:28:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8269F12D8E6 for ; Wed, 20 Jul 2016 10:28:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bPvI5-0000Dx-Jw; Wed, 20 Jul 2016 17:28:13 +0000 Date: Wed, 20 Jul 2016 19:28:12 +0200 Message-ID: From: Randy Bush To: "Bert Wijnen (IETF)" In-Reply-To: <82a37f28-49ee-f121-6b5f-64725f4bd7b5@bwijnen.net> References: <4ecf49c5-f987-7184-8cf6-b706eb914bcd@bwijnen.net> <82a37f28-49ee-f121-6b5f-64725f4bd7b5@bwijnen.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: opsawg Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 17:28:19 -0000 >> fwiw, our customers do use multi-provider vpns; they use ipsec. we >> provide ipsec capable cpe and various management/orchestration >> systems. > So is that enough ? no. it does not justify 312 internet-drafts, 92 rfcs, and sellimg me a lot of complex boxes. end of net predicted. news at eleven. randy From nobody Wed Jul 20 11:21:13 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1101A12D9E4; Wed, 20 Jul 2016 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.485 X-Spam-Level: X-Spam-Status: No, score=-5.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 ZBvLKGxRoHyh; Wed, 20 Jul 2016 11:21:00 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5442112B05C; Wed, 20 Jul 2016 11:20:59 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u6KII1KA018304; Wed, 20 Jul 2016 14:18:01 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Sashank Dara (sadara)" , Tal Mizrahi , "Carlos Pignataro (cpignata)" Thread-Topic: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4rN0FItGrjjQCU+KuYNgvl1r4g== Date: Wed, 20 Jul 2016 18:20:55 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> <16454292-3ADD-402A-AED6-CB785C5C833B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [172.25.177.156] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3551869245_103035243" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200203 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "opsawg@ietf.org" , "nvo3@ietf.org" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Subject: Re: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 18:21:03 -0000 --B_3551869245_103035243 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I suggest that while MITM is not the most common threat (there are more attackers that are without on-path access) - it is still common and dangerous *enough* to justify mitigating it, if at all possible. At the very worst, clearly specify why you do not address this threat (but again, I=E2=80=99d rather that you addressed it), and its potential consequences. --=20 Regards, Uri Blumenthal On 7/20/16, 7:06 , "OPSAWG on behalf of Sashank Dara (sadara)" wrote: > >On 20/07/16, 3:39 PM, "Tal Mizrahi" wrote: > >>Hi Carlos, >> >>It all goes back to the threat model; which threats you want to address, >>and which ones you don't. >> >>The way I see it, roughly speaking there are 3 classes of threats (there >>ae probably other threats, but these are the basic ones): >>- Misroute / misconfiguration (not a security attack). >>- Attacker with no on-path access. >>- Man-in-the-middle (attacker *with* on-path access). >> >>It looks like the third threat (man-in-the-middle) is currently not >>addressed by POT. >>I certainly agree that this threat is the more difficult to implement of >>the three. > >Thanks for such classification, we shall work on better threat modelling >and clarity in our next version. > >Now , Can we put some concrete high level protocol names here that could >use POT and prone to MITM ? >Helps us understand the validity of the =C2=B3mix-and-match=C2=B2 attack you >described in a more concrete context. > > > >> >>It would significantly clarify the picture if you specified in the draft >>which of the three classes you intend to address. >> >>Thanks, >>Tal. >> >> >>>-----Original Message----- >>>From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>>Sent: Wednesday, July 20, 2016 11:51 AM >>>To: Tal Mizrahi >>>Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); >>>draft-brockners-proof- >>>of-transit@tools.ietf.org; sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org >>>Subject: Re: MD Type attack (Was: Question regarding Proof of Transit >>>draft) >>> >>>Hi, Tal, >>> >>>> On Jul 20, 2016, at 11:42 AM, Tal Mizrahi wrote: >>>> >>>> Hi Carlos, >>>> >>>> >>>>> Let=C2=B9s step back a little =E2=80=B9 the =C2=B3vulnerability=C2=B2 you are describin= g >>>>> comes with the assumption that a MIIT attacker can intercept a >>>>> packet, extract a TLV from the MD Type 2, drop the packet; then >>>>> intercept another packet (with the knowledge that it took a different >>>>> path, so maybe the attacker is using inband OAM as well :-), and >>>>> insert (or modify) a TLV within the content of the MD Type 2 within >>>>>the >>>content of NSH, within a specific packet. >>>>> >>>>> This sounds quite sophisticated. >>>> >>>> I am not sure I agree this is a 'sophisticated' attack. >>>> The attack does not require any cryptographic or algorithmic >>>>functionality, >>>and to that end it is very lightweight in terms of processing resources. >>> >>>Sorry if I was not clear =E2=80=B9 I do not mean technological sophistication = or >>>massive processing resources required. I mean access and operational >>>one. >>> >>>> >>>> If this kind of attack is not within the scope here, then I would >>>>argue that >>>you don't need a cryptographic mechanism at all. All you need is a TLV >>>that >>>specifies the list of nodes. However, I believe that you did want to try >>>to >>>mitigate MITM attackers. Correct me if I am wrong. >>>> >>> >>>You seem to have missed quoting the important part of my response: "My >>>point is that what you seem to be describing is a generic threat use >>>case and >>>not a specific vulnerability.=C2=B2 >>> >>>Selectively dropping part of the response removes important context. >>> >>>> I fully agree that the threat model needs to be well-defined. >>> >>>The threat model for SFC MD, yes. Access to the POT comes with >>>assumptions. >>> >>>Thanks, >>> >>>=E2=80=B9 Carlos. >>> >>>> I hope you will elaborate more on the threat model in the next version >>>>of >>>the draft. >>>> >>>> Cheers, >>>> Tal. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>>>> Sent: Wednesday, July 20, 2016 11:34 AM >>>>> To: Tal Mizrahi >>>>> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); >>>>> draft-brockners-proof- of-transit@tools.ietf.org; sfc@ietf.org; >>>>> opsawg@ietf.org; nvo3@ietf.org >>>>> Subject: MD Type attack (Was: Question regarding Proof of Transit >>>>> draft) >>>>> >>>>> Tal, >>>>> >>>>>> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi wrote: >>>>>> >>>>>> Hi Sashank, >>>>>> >>>>>>> [SD] The attack is valid only if the attacker can get away >>>>>>> bypassing a >>>>> service function/node. >>>>>>> For example, if the attacker bypasses a node and if POT determines >>>>>>> it did >>>>> not bypass is a valid attack on the system. >>>>>> >>>>>> I would phrase it this way: *Given* a packet that did not go through >>>>>> its >>>>> desired path, the attacker can easily make you think that it *did* go >>>>> through the desired path. >>>>>> Sounds like a very significant vulnerability. >>>>>> >>>>>> If a packet did not go through the firewall (for one reason or >>>>>> another), the >>>>> attacker will make you think that it did go through the firewall. >>>>>> >>>>> >>>>> Let=C2=B9s step back a little =E2=80=B9 the =C2=B3vulnerability=C2=B2 you are describin= g >>>>> comes with the assumption that a MIIT attacker can intercept a >>>>> packet, extract a TLV from the MD Type 2, drop the packet; then >>>>> intercept another packet (with the knowledge that it took a different >>>>> path, so maybe the attacker is using inband OAM as well :-), and >>>>> insert (or modify) a TLV within the content of the MD Type 2 within >>>>>the >>>content of NSH, within a specific packet. >>>>> >>>>> This sounds quite sophisticated. >>>>> >>>>> Do you think that if an MIIT can have that surface of attack and >>>>> sophistication, they can mess up with other even more critical >>>>>things? >>>>> Changing a Tenant ID, messing up with Policy Groups, etc? >>>>> >>>>> My point is that what you seem to be describing is a generic threat >>>>> use case and not a specific vulnerability. Engineering is about >>>>> trade-offs (i.e., solutions that have practical performance) and >>>>> about placing the solution in the most effective place. >>>>> >>>>> I=C2=B9m not deflecting but at the same time, let=C2=B9s understand the >>>>> assumptions you are making for this potential attack you describe, as >>>>> part of the threat analysis. >>>>> >>>>> Thanks, >>>>> >>>>> =E2=80=B9 Carlos. >>>>> >>>>>> Cheers, >>>>>> Tal. >>>>>> >>>>>> >>>>>> From: Sashank Dara (sadara) [mailto:sadara@cisco.com] >>>>>> Sent: Wednesday, July 20, 2016 4:31 AM >>>>>> To: Tal Mizrahi; Frank Brockners (fbrockne); >>>>>> draft-brockners-proof-of- >>>>> transit@tools.ietf.org >>>>>> Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org >>>>>> Subject: Re: Question regarding Proof of Transit draft >>>>>> >>>>>> >>>>>> >>>>>> The POT replacement attack (1.) is not an attack on the integrity. >>>>>> It is an >>>>> attack on the path verification. >>>>>> This simple attack can cause the verifier to accept a packet that >>>>>> did not go >>>>> through the firewall SF (even though it should). I believe this is >>>>> exactly the problem you were aiming to address in this draft. >>>>>> >>>>>> [SD] The attack is valid only if the attacker can get away bypassing >>>>>> a service >>>>> function/node. >>>>>> For example, if the attacker bypasses a node and if POT determines >>>>>> it did >>>>> not bypass is a valid attack on the system. >>>>>> >>>>>> In the current state, there is no way an attacker can get away as we >>>>> determine the exact path the packet travelled (aim of the draft) . >>>>>> I reiterate that the verifier needs to handle what to do with the >>>>>> path >>>>> reconstructed ! >>>>>> We could emphasize this in our next draft , but it would be beyond >>>>>> scope of >>>>> POT to determine what to do with the path constructed. >>>>>> IMO, It would be highly application specific. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Sashank >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Tal. >>>>>> >>>>>> From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] >>>>>> Sent: Tuesday, July 19, 2016 6:00 PM >>>>>> To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of- >>>>> transit@tools.ietf.org>>>> transit@tools.ietf.org> >>>>>> Cc: sfc@ietf.org; >>>>> opsawg@ietf.org; >>>>> nvo3@ietf.org >>>>>> Subject: RE: Question regarding Proof of Transit draft >>>>>> >>>>>> Hi Tal, >>>>>> >>>>>> thanks for the summary. We'll provide more details on 2. Per my >>>>>> earlier >>>>> point - 1. is an interesting discussion, given that we don't claim to >>>>> provide integrity protection for the packet payload. Or in other >>>>>terms - to >>>be exact: >>>>> What POT provides is a proof that the POT-header/meta-data transited >>>>> all the required nodes. There is no association (and thus proof) >>>>> provided for the additional data carried along with the POT-header - >>>>> neither header nor payload. As a consequence, attacks which change >>>>> the packet payload won't be detected/mitigated. We'll explicitly >>>>> state this in the security considerations in the next rev of the >>>>>document. >>>>>> What we could consider is linking the RND number to CRC across the >>>>>> packet >>>>> payload or similar - but that way we'd restrict the applicability to >>>>> deployments where the packet payload isn't changed across the path >>>>> (which might not apply to certain deployment - e.g. WAN optimization >>>>>/ >>>compression schemes). >>>>>> Do you think it is worthwhile to provide a solution for a deployment >>>>>> which is >>>>> expected to not alter the packet payload? >>>>>> >>>>>> Thanks, >>>>>> Frank >>>>>> >>>>>> From: Tal Mizrahi [mailto:talmi@marvell.com] >>>>>> Sent: Dienstag, 19. Juli 2016 17:44 >>>>>> To: Sashank Dara (sadara) >>>>> >; Frank Brockners >>>>> (fbrockne) >; >>>>> draft-brockners- >>>>> proof-of-transit@tools.ietf.org>>>> transit@tools.ietf.org> >>>>>> Cc: sfc@ietf.org; >>>>> opsawg@ietf.org; >>>>> nvo3@ietf.org >>>>>> Subject: RE: Question regarding Proof of Transit draft >>>>>> >>>>>> Hi, >>>>>> >>>>>> To summarize my take on this thread: >>>>>> The proposed mechanism has two significant vulnerabilities that (in >>>>>> my >>>>> understanding) are currently not addressed: >>>>>> >>>>>> 1. A man-in-the-middle can replace the POT of packet A with >>>>>>the POT >>>of >>>>> packet B. >>>>>> >>>>>> 2. It is possible to replay POTs within a certain time window, >>>>>>whose >>>>> length is determined by the timestamp resolution. >>>>>> >>>>>> Sashank, thanks for agreeing to look into it further. I am looking >>>>>> forward to >>>>> your insights on this. >>>>>> >>>>>> Regards, >>>>>> Tal. >>>>>> >>>>>> Link to the draft: >>>>>> https://tools.ietf.org/html/draft-brockners-proof-of- >>>>> transit-01 >>>>>> >>>>>> >>>>>> >>>>>> From: Sashank Dara (sadara) [mailto:sadara@cisco.com] >>>>>> Sent: Tuesday, July 19, 2016 12:20 PM >>>>>> To: Tal Mizrahi; Frank Brockners (fbrockne); >>>>>> draft-brockners-proof-of- >>>>> transit@tools.ietf.org>>>> transit@tools.ietf.org>; sfc@ietf.org >>>>>> Subject: Re: Question regarding Proof of Transit draft >>>>>> >>>>>> >>>>>> >>>>>> I want to ask a simple question: >>>>>> If the attacker attaches the POT of packet A (indicating the path >>>>>> through >>>>> 1,3,5,6) to packet B, will the verifier accept packet B and believe >>>>> that its path was indeed (1,3,5,6)? >>>>>> >>>>>> [SD] If the verifier is programmed to just validate the POT meta >>>>>> data against >>>>> {1,3,5,6} then yes it accepts it. >>>>>> If the verifier is programmed to consult a policy database to cross >>>>>> check if >>>>> the reconstructed path {1,3,5,6} is as per the policies then no , it >>>>>drops it . >>>>>> >>>>>> But I see your point , that the parameters used in POT data donot >>>>>> consider >>>>> the path or node-ids etc . We shall discuss this internally and get >>>>>back. >>>>>> >>>>>> Also, We shall get back with more concrete numbers of the timestamp >>>>> resolution and cache sizes (or other better approaches). >>>>>> >>>>>> Thank you so much for all the inputs. >>>>>> >>>>>> >>>>>> >>>>>> From: Tal Mizrahi >>>>>> Sent: Tuesday, July 19, 2016 10:28 AM >>>>>> To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); >>>>>> draft-brockners- >>>>> proof-of-transit@tools.ietf.org>>>> transit@tools.ietf.org>; sfc@ietf.org >>>>>> Subject: RE: Question regarding Proof of Transit draft >>>>>> >>>>>> Dear Sashank, >>>>>> >>>>>> I really appreciate the quick and detailed responses. >>>>>> >>>>>>>>> Lets take correct path taken by Packet A to be Path1 - ( >>>>>>>>> 1,3,5,6) nodes >>>> >> > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg > --B_3551869245_103035243 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUZwYJKoZIhvcNAQcCoIIUWDCCFFQCAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCjM7 SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQxMgQw0OpuSmBy+rEjTOg0 XyEhxzRyfnRb7PxT5IjprhB9pl2EW8R7cjrenZBjo5dYzhHMMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDcyMDE4MjA0NVowDQYJKoZIhvcNAQEBBQAE ggEAEcv12OH2/nVhA6/aELEJfnQ5SpUNCaFOJk3eaB1qvuxElJu3ttRcY0gfw1toHBfX1nQn jmH/vkZH6aTFnvFYmm/A58FSOjBizB3GAP5VHs0+a42f76PPurymZsWn7m0bBWlQ00VhlWKG n2ywjlAXmUFzqalQGtNnKhdvCq7PF57xAlkkx5bmRAHc7jqxkaDp3IpvpgRpBwPpbfPuDvKM e3iwVq/1NogDNxkZs8YykJBHNPEQerBiQgv7KKtGZqSOb9Lzl2SE22SOTblrLNUXSyi6f1gg 1SFoQywLqx36bicZWwP+bkfU2jus1YR+HpE/NoT+z2LJGK6f9f4yMQNsXQ== --B_3551869245_103035243-- From nobody Sun Jul 24 14:37:28 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DB812D578 for ; Sun, 24 Jul 2016 14:37:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 KYaeSFw_FBPG for ; Sun, 24 Jul 2016 14:37:26 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 A5B3112B007 for ; Sun, 24 Jul 2016 14:37:26 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id g62so116691227lfe.3 for ; Sun, 24 Jul 2016 14:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=I39EfESDKaWgEFLrRrlFF8Imr0jQrMaYGg1Mx78ABJg=; b=K1Zh8uMNRqhGCN8vRswGEOzSHaXwswB3OVH5VrYH8lOZ9gJuRALNuZ5X7Czyjuf6sf MNOIc43UE47fCjg4o2QgbOUxZqssPEERJ1V7LtMdEspDP/Krp0O6DdKcQBYB+DFjFMnt Tlkl4VBq3z+15uVs/WRLra/WJsYqHcaSfCKpCY+N5tP6q6WtVWNg3cBkhElEZClbwShc gayDFQTydpXHah2HWpVCkao/og0MXEPkVYyX0LDOWH3KgDarbFVpECmyx9pcntO9abME OrC0AkvqBT4yxge34eIR8sC6bMPN5MkglP/NLBNTi4Rw42flKJ9BnXBXE63Ve7YNiiR+ FMaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=I39EfESDKaWgEFLrRrlFF8Imr0jQrMaYGg1Mx78ABJg=; b=D9+3psmq7sofZ7OIqzBDRmfuKKPU5mQqtTKsJKEZiWV1opy5oCl0uc0ZGUTAnuOb8a Xz4D6P0cZyim5pfQfsWdzanD7PvwlXqy8iAYw9ckVT+MlvAwOc/ONoHOA+LM8eB8Cb7W ioe4qLw7h7XZ/0xbxRs1AXq2Lk11xc1N2o1O1DtvCcoHbCy/OnOh/KSlRjisiL/EkQun Pn2EZy8VOFK3KmXzF6Kzs598oJSd7AjGfCN19eQV3L6NykmxTPkZWOxJjShpZ2oAxmID Dp3SL/cbeciscL1nIln8zKMqP7ZFRAf6vUre5obgatXG/x8h3JJW8bZXTqlVzcu9dmHT JM/Q== X-Gm-Message-State: AEkoouuhVKeOqzH5EZ9NZ/dE7aLMjBpH8Bcbl6XDNncAwjz0ZN+6jZSzN+q8djwZGJ9/puE4bR1LKuik+zcRPmWc X-Received: by 10.25.91.149 with SMTP id p143mr5725450lfb.39.1469396244381; Sun, 24 Jul 2016 14:37:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.160.42 with HTTP; Sun, 24 Jul 2016 14:36:54 -0700 (PDT) From: Warren Kumari Date: Sun, 24 Jul 2016 17:36:54 -0400 Message-ID: To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] Draft minutes from Berlin X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 21:37:28 -0000 Hi, Draft minutes from Berlin has been posted - please let us know if you have any corrections. https://www.ietf.org/proceedings/96/minutes/minutes-96-opsawg W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Jul 29 01:04:17 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F6712D62E for ; Fri, 29 Jul 2016 01:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 cC48ZRZX_Vtn for ; Fri, 29 Jul 2016 01:04:14 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4445912D61B for ; Fri, 29 Jul 2016 01:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10259; q=dns/txt; s=iport; t=1469779454; x=1470989054; h=references:subject:to:from:message-id:date:mime-version: in-reply-to; bh=gNvML9cm3CXOI6wUFMc0L9YBNmsKtproCVt3Z9/jd/M=; b=gTOQyC6Cy540ybw+f5LfgTWapoyjZNyeA7gFvR40dYHMJXWie+ZMZoPM ZRjPeJoFjQekyTy58FmqhdPOvrFmtiryavqOMPnbxaiPFVFGHyw0Z8hOk NerGu9CikuFw4HvPKyTmhmuRv9sXAhh2G1+RT9g+3xp5o7wcL9w5R15PL Y=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGBwDdDJtX/xbLJq1dhBsqUrQAhwIkh?= =?us-ascii?q?XkCgXwBAQEBAQFeHAuEXQYjVBIPAT0CAk0KBg0IAQGILQ6uNY1vAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEPDogiCIJNh0GCWgEEiCqFbIscgzqBcG6IZoFrToQNgw6Fb?= =?us-ascii?q?IZkhU2DeFSDfDoyAYgYAQEB?= X-IronPort-AV: E=Sophos;i="5.28,438,1464652800"; d="asc'?eml'208?scan'208,208,217";a="638111301" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jul 2016 08:04:12 +0000 Received: from [10.61.218.103] ([10.61.218.103]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6T84BK3022211 for ; Fri, 29 Jul 2016 08:04:11 GMT References: <20160729074718.27061.49768.idtracker@ietfa.amsl.com> To: "opsawg@ietf.org" From: Eliot Lear X-Forwarded-Message-Id: <20160729074718.27061.49768.idtracker@ietfa.amsl.com> Message-ID: <850da6c5-86cb-daec-5259-19222914ecfc@cisco.com> Date: Fri, 29 Jul 2016 10:04:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160729074718.27061.49768.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="apaxb8N7VMqsLoppdCmEFRwvMKkciT7j6" Archived-At: Subject: [OPSAWG] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 08:04:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --apaxb8N7VMqsLoppdCmEFRwvMKkciT7j6 Content-Type: multipart/mixed; boundary="r4eIKt8A55tfSBmn45K3VX9KBCfD2sURe" From: Eliot Lear To: "opsawg@ietf.org" Message-ID: <850da6c5-86cb-daec-5259-19222914ecfc@cisco.com> Subject: Fwd: New Version Notification for draft-lear-ietf-netmod-mud-03.txt References: <20160729074718.27061.49768.idtracker@ietfa.amsl.com> In-Reply-To: <20160729074718.27061.49768.idtracker@ietfa.amsl.com> --r4eIKt8A55tfSBmn45K3VX9KBCfD2sURe Content-Type: multipart/mixed; boundary="------------C0E05B272DE908587288D01A" This is a multi-part message in MIME format. --------------C0E05B272DE908587288D01A Content-Type: multipart/alternative; boundary="------------431BD2CD522027C2D9D3017E" --------------431BD2CD522027C2D9D3017E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear OPSAWG friends, Please see the attached submission of the next version of Manufacturer Usage Descriptions (MUDs). This update includes the following: * Completed the grand consolidation of functionality by incorporating the DNSNAME extension; * In anticipation that this document will be come a WG document, as discussed in Berlin, the model contact information now reflects the W= G; * A preliminary discussion of extensibility is now included, as discussed in Berlin. * A Placeholder has been added for LLDP. My hope is that we can curjole Dan Romascanu to write out that part, in which case I would want to list him as a co-author. With this, I hope the chairs won't mind taking this draft forward to the next step. Any and all comments, edits etc, are invited. I'll make the next version available in GITHUB for pull requests if people like. Eliot --------------431BD2CD522027C2D9D3017E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Dear OPSAWG friends,

Please see the attached submission of the next version of Manufacturer Usage Descriptions (MUDs).=C2=A0 This update includes = the following:

  • Completed the grand consolidation of functionality by incorporating the DNSNAME extension;
  • In anticipation that this document will be come a WG document, as discussed in Berlin, the model contact information now reflects the WG;
  • A preliminary discussion of extensibility is now included, as discussed in Berlin.
  • A Placeholder has been added for LLDP.=C2=A0 My hope is that we= can curjole Dan Romascanu to write out that part, in which case I would want to list him as a co-author.

With this, I hope the chairs won't mind taking this draft forward to the next step.

Any and all comments, edits etc, are invited.=C2=A0 I'll make the = next version available in GITHUB for pull requests if people like.

Eliot


--------------431BD2CD522027C2D9D3017E-- --------------C0E05B272DE908587288D01A Content-Type: message/rfc822; name="New Version Notification for draft-lear-ietf-netmod-mud-03_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-lear-ietf-netmod-mud-03_t"; filename*1="xt.eml" X-Mozilla-Keys: Received: from xch-aln-003.cisco.com (173.36.7.13) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Mailbox Transport; Fri, 29 Jul 2016 02:47:21 -0500 Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 29 Jul 2016 02:47:21 -0500 Received: from alln-iport-2.cisco.com (173.37.142.89) by mail.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Fri, 29 Jul 2016 02:47:21 -0500 Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jul 2016 07:47:20 +0000 Received: from alln-inbound-k.cisco.com (alln-inbound-k.cisco.com [173.37.147.241]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6T7lCiP025806 (version=TLSv1/SSLv3 cipher=DHE-RSA-SEED-SHA bits=128 verify=OK); Fri, 29 Jul 2016 07:47:20 GMT Authentication-Results: alln-inbound-k.cisco.com; dkim=none (message not signed) header.i=none; spf=Pass smtp.mailfrom=internet-drafts@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org Received-SPF: Pass (alln-inbound-k.cisco.com: domain of internet-drafts@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=alln-inbound-k.cisco.com; envelope-from="internet-drafts@ietf.org"; x-sender="internet-drafts@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (alln-inbound-k.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=4.31.198.44; receiver=alln-inbound-k.cisco.com; envelope-from="internet-drafts@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only X-from-outside-Cisco: 4.31.198.44 IronPort-PHdr: =?us-ascii?q?9a23=3AO4E9yRL/UYX4DZrGzdmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgUIvXxwZ3uMQTl6Ol3ixeRBMOAuqoC1bqd6vq/EUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkIt?= =?us-ascii?q?f6KuS9aU0ZT8jrrts7ToICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJce?= =?us-ascii?q?kFjUlhJFaUggqurpzopM0r221qtvkg789NV7nhN+R9FOQATWduD2dgruDvtB7f?= =?us-ascii?q?BS+C72FWGjESnxNSKwPE9xr9GJz2t32+/qBH0S2CPYXaV7cxQn7qu71nUhjtkw?= =?us-ascii?q?8MNiUy9yfcjckm34xBpxf0phpjzpTSbZ3QOOB3cL/GVdIXWWQHWdxeBH8JOZ+1?= =?us-ascii?q?c4ZaV7lJBu1ftYSo4gJW9RY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0EjAQBXCZtXhyzGHwRdGwEBAYJ6gQN8j?= =?us-ascii?q?SuYPJMegXMKGQuFeYEyOBQBAQEBAQEBAQIPAQEBCgsJCRkvgjIEARIBByIXEAE?= =?us-ascii?q?BAQEBASYBAQEBAQEjAj41AiBUESYCJgICA0QWAReILQICCa40hiyHRAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARyBAYl2hF2CZIJaBYgqhWx1iieGGIhcCoFrToQNiHq?= =?us-ascii?q?MMYN4HoJZgXdOAYgYAQEB?= X-IPAS-Result: =?us-ascii?q?A0EjAQBXCZtXhyzGHwRdGwEBAYJ6gQN8jSuYPJMegXMKGQu?= =?us-ascii?q?FeYEyOBQBAQEBAQEBAQIPAQEBCgsJCRkvgjIEARIBByIXEAEBAQEBASYBAQEBA?= =?us-ascii?q?QEjAj41AiBUESYCJgICA0QWAReILQICCa40hiyHRAEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBARyBAYl2hF2CZIJaBYgqhWx1iieGGIhcCoFrToQNiHqMMYN4HoJZgXdOA?= =?us-ascii?q?YgYAQEB?= X-IronPort-AV: E=Sophos;i="5.28,438,1464652800"; d="scan'208";a="226902270" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([4.31.198.44]) by alln-inbound-k.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jul 2016 07:47:19 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C825F12D51A; Fri, 29 Jul 2016 00:47:18 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: To: Eliot Lear , Ralph Droms Subject: New Version Notification for draft-lear-ietf-netmod-mud-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160729074718.27061.49768.idtracker@ietfa.amsl.com> Date: Fri, 29 Jul 2016 00:47:18 -0700 Return-Path: internet-drafts@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-RCD-020.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: b470f850-3808-4b5e-f83c-08d3b784927e X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 MIME-Version: 1.0 A new version of I-D, draft-lear-ietf-netmod-mud-03.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Name: draft-lear-ietf-netmod-mud Revision: 03 Title: Manufacturer Usage Description Specification Document date: 2016-07-29 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-lear-ietf-netmod-mud-03.txt Status: https://datatracker.ietf.org/doc/draft-lear-ietf-netmod-mud/ Htmlized: https://tools.ietf.org/html/draft-lear-ietf-netmod-mud-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-lear-ietf-netmod-mud-03 Abstract: This memo specifies the necessary components to implement manufacturer usage descriptions (MUD). This includes two YANG modules, IPv4 and IPv6 DHCP options, a URL suffix specification, an X.509 certificate extension and a means to sign and verify the descriptions. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------C0E05B272DE908587288D01A-- --r4eIKt8A55tfSBmn45K3VX9KBCfD2sURe-- --apaxb8N7VMqsLoppdCmEFRwvMKkciT7j6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXmw37AAoJEIe2a0bZ0nozsr0H/AuR96WcIHUO4yHaw4lPjDsR tI97It1cHp5wIT4aGdjHiRMRugYhPJd6dhaeCtevcDVyBof6iSBWGe9TrA6TXBQK tDk6EAC/1b2kko0bVmUzvu50MRRl/T0Gxc55k6M45xFrRchvFTHAsHtkEIFzBTJn SN0eZU2ut3HlW0XKHdEU4e8qEAF0TzYy/5DGDzaoqQmkjScFLlEdQpGzpoGYc77Z wO6+JpiYgKZGsGmrvvwIpaYdC7jsQiOmw1Y2gmZc38N4ONivx6Lz2FEBt+8a6BIb zZuTrQlAsZ0YgsQ8k0PES5cmBsODZp4mGHF33lbSo3suRnDzJeuopCE+9lTM7Uo= =Ymk3 -----END PGP SIGNATURE----- --apaxb8N7VMqsLoppdCmEFRwvMKkciT7j6--