From nobody Wed Feb 3 19:28:32 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414463A0AAF for ; Wed, 3 Feb 2021 19:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 DRt6DR5TyXXi for ; Wed, 3 Feb 2021 19:28:28 -0800 (PST) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 B1A543A0AA7 for ; Wed, 3 Feb 2021 19:28:28 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id a1so1094457qvd.13 for ; Wed, 03 Feb 2021 19:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RjSr0duO2qQaSt5PJSWkWceEeoorxq3ggRAB6MrMpMA=; b=FhA+j6z+WzoCGYjXpOa5IkHUDXjgsSSfARyWrO+VZpdyiASFSJRJmmZV+M2FKPQ9RT vvfQathDljpW//It1a1rX8nrkqcGDlM06YnVpCJiMJqp9EbO+DlzKUAbQqpr/rNwgyKI LRdiTx+cSoI8soc1nlLo85rHplWIqQDKiNSwk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RjSr0duO2qQaSt5PJSWkWceEeoorxq3ggRAB6MrMpMA=; b=YkXW4HmoYm7ZHufpES3getiiOoFYCDtoo7lEWtQY1fxtzri4QreLMqJecMDyzKoBhM Q2fbN48bOG1QZF0TEd+MLnQplRsOCQWvpeNr6gyZh3untJOe2KNTj7n/OfV4T0M6+73F ekB6Or/V3mqkaRqFkXNG7xWnPsZ3qzRkVNQx3w4dqvfHnPpCBkJY0tfKh/lIfONavU9t SdsAXuBCpB6Nin+2wj5goTgbrF6KKk5owA99jhznU9Tb/pxHoMi6coIoWIKhDxYDry0U 6Hs88bvyMTwj4y6YCE8Ewb40OYiNE2wgEhS2vBS0HogCWxLmHwQUABwWeUfCK4VFyLa8 zOZg== X-Gm-Message-State: AOAM533NVTn5wvliOUiLuZR+XZYYViOkLEoK6TRYY4z8j36JPNEAauLl FwummkokiKSUyH3zs/mKts3MXA== X-Google-Smtp-Source: ABdhPJzXl2RhjuRZ8m+wSBQk2jYguYN73SA/DkCs+oCrGVhByqOrVqmFaVcDCeRVQcv1THUUxj5ElQ== X-Received: by 2002:ad4:48c8:: with SMTP id v8mr5980610qvx.38.1612409307643; Wed, 03 Feb 2021 19:28:27 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id i17sm3528288qtg.77.2021.02.03.19.28.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2021 19:28:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Sean Turner In-Reply-To: <24590.9731.586561.210161@fireball.acr.fi> Date: Wed, 3 Feb 2021 22:28:25 -0500 Cc: ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5C517516-A210-45CC-AFA8-9DC6BE31F262@sn3rd.com> References: <24590.9731.586561.210161@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 03:28:30 -0000 Since we=E2=80=99re yang-ing all the things - sure let=E2=80=99s adopt = it. spt > On Jan 24, 2021, at 20:59, Tero Kivinen wrote: >=20 > This is the start of 3 week WG adoption call for this document, ending > 2021-02-15. Please send your reply about whether you support adopting > this document as WG document or not. >=20 > This document is not explictly mentioned in our charter, but as this > is part of the traffic flow confidentiality work that is part of our > charter, I think this is something we can and should work on. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Feb 3 19:38:13 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0895C3A0B13 for ; Wed, 3 Feb 2021 19:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 U3Y6hBTfM2CN for ; Wed, 3 Feb 2021 19:38:09 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 AF8963A0B02 for ; Wed, 3 Feb 2021 19:38:09 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id 2so1151585qvd.0 for ; Wed, 03 Feb 2021 19:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=mHZe/VCS84XwPPo6z3vhlPZRof60wq1vMK+58KB2x+s=; b=nM9NMnK0QWdoQ5i9sC/Kr3wCsIaqIJL9h5xsdlazVxGkZxDjDkakvdZ0iMQ+lU7GfX J6cfBtWyurNpL7lw+ewfcEXdMVa/4bWsbpmtMTI7vKVjJ2SD1sJyEUw7JE6R2/zOg4kY Pxf88d2uEu6khej9//lhsmv7vJfQLeka73v9A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=mHZe/VCS84XwPPo6z3vhlPZRof60wq1vMK+58KB2x+s=; b=f+JOIckCiTFHPvfCbcPWrO3qbpL8W88lO8b+ZVW0kvrsUz5DGWiXvro67jxtTNXrvW aQoiG/FGrQahminF96pPZ2tvxUrQTelUapdji9ndEWG1VJZ7Nzwl18gjYv518926+rqB v325rGu9+o+3H8q+nXvsyTfBWkedHH5t58CGDAluq/fBuvlrd25kIa0+AMTgd9gMvqNG jICpj9trt5LAhpHeuzFx3GcHqLwaiRVakgxZq2ejUfBOgTDlhqms2EP/GTAZcudHUwzN RIZZgKphTABNYDlr43xjLnmyzPsxTa8tc6b1rGqLjVq07LkEjjap1sgK8N8hEMBgMm2O Dzhw== X-Gm-Message-State: AOAM530MGpNgzCW99/IqXAF5eMo/ko/Tkj04Q17/Zw1KO9XCHvEApuIa GQNY5suJT2kuVOZbdENxSLbLNLJruuVspLZS X-Google-Smtp-Source: ABdhPJzmUEiUu4UcafQkrSUgglKI+XnHbFDIn4llwodqh5g1PlDsU8dpf10x+GmmsJAqhDNmbUXe7w== X-Received: by 2002:a05:6214:2a9:: with SMTP id m9mr868725qvv.20.1612409888274; Wed, 03 Feb 2021 19:38:08 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id z16sm3622800qtb.73.2021.02.03.19.38.07 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2021 19:38:07 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 3 Feb 2021 22:38:06 -0500 References: <24590.9470.995873.674029@fireball.acr.fi> To: ipsec@ietf.org In-Reply-To: <24590.9470.995873.674029@fireball.acr.fi> Message-Id: <569B8D50-F0B3-4EA1-8A1D-EFB9BD674578@sn3rd.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 03:38:12 -0000 Hi! I mostly just have nits, but there are a couple of questions = interspersed below. s1, para 1: s/While one may directly obscure the data through the use = of/While directly obscuring the data with s1, para 1: s/it=E2=80=99s/its s1, para 3: s/IP-TFS/IP-TFS (IP Traffic Flow Security) s1, last para: s/IP-TFS provides for dealing with network = congestion/IP-TFS addresses network congestion s1: You mention full TFC. Is it partial TFC if you use a non-constant = send-rate? if so that might be good to qualify in the 3rd paragraph with = something like: OLD: A non- constant send-rate is allowed, but the confidentiality properties of its use are outside the scope of this document. NEW: A non- constant send-rate is allowed to support partial TFC, but the confidentiality properties of its use are outside the scope of this document. s1.1, para 1: Use updated terminology para from 8174 ("BCP 14=E2=80=9D = is missing): The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. s2, para 1:=20 is the "(SA)" needed? ... tunnel (SA) ... s/it=E2=80=99s/its s2, 2nd para: I tripped over this para a couple of times. Does this get = the same point across? OLD: The primary input to the tunnel algorithm is the requested bandwidth used by the tunnel. Two values are then required to provide for this bandwidth, the fixed size of the encapsulating packets, and rate at which to send them. NEW: The primary input to the tunnel algorithm is the requested bandwidth for the tunnel. Two values needed to determine the bandwidth are the fixed size of the encapsulating packets and the rate at which to send them. s2, 3rd para: s/or could be/or be s2, 4th para: s/requested tunnel used bandwidth/ requested tunnel bandwidth s1, last para to make it match the rest of the sentence: s/The egress of = the IP-TFS/The egress (receiving) side of the IP-TFS=20 s2.1, 1st para: s/In order to maximize bandwidth IP-TFS/ In order to maximize bandwidth, IP-TFS s2.1, 3rd para: Does this say the same thing: OLD: This is accomplished using a new Encapsulating Security Payload (ESP, [RFC4303]) type which is identified by the number AGGFRAG_PAYLOAD (Section 6.1). NEW: IP-TFS uses a new Encapsulating Security Payload (ESP, [RFC4303]) type identified by the number assigned to AGGFRAG_PAYLOAD (Section 6.1). s2.2: I had a really hard time parsing this sentence: The AGGFRAG_PAYLOAD payload content defined in this document is comprised of a 4 or 24 octet header followed by either a partial, a full or multiple partial or full data blocks. There are three options: partial, full or multiple partial, or full = data? Maybe it=E2=80=99s just missing a comma: s/multiple partial = or/multiple partial or, s2.2.1: Should we be specific about the IPv4 and IPv6 length=E2=80=99s = field name: OLD: Likewise, the length of the data block is extracted from the encapsulated IPv4 or IPv6 packet's length field. NEW: Likewise, the length of the data block is extracted from the encapsulated IPv4=E2=80=99s Total Length or IPv6=E2=80=99s Payload = Length fields. s2.2: s/It=E2=80=99s/It is s2.2.3: s/to be able to reassemble/to reassemble=20 s2.2.3: s/This possible interleaving/This interleaving s2.2.3: s/sender to always be able to send a/sender to always send a=20 s2.2.3, 4th para: s/Finally, we note/Finally, note s2.2.3, 5th para: s/As the amount of reordering that may be present is = hard to predict the window/As the amount of reordering that may be = present is hard to predict, the window 2.2.3, 5th para: I am all about not littering I-Ds with 2119-language, = but here it looks like you are burying the MUST in the parenthetical. = BTW - I think the sentence stands on its own without the "i.e.=E2=80=9D = and it could safely be deleted. Would this rewording work: Gaps in the sequence numbers will not work for this document, therefore ESP sequence number stream MUST increase monotonically by 1 for each subsequent packet. s2.2.3, penultimate para: s/b/c/because s2.2.3, last para: Should the I-D state what happens if the = implementation does send initial fragments of an inner packet using one = SA and subsequent fragments in a different SA. I.e., motivate the SHOULD = NOT. s2.2.3, last para: implementation here refers to sender right so maybe: = senders SHOULD NOT s2.2.3.1: Implementations here refers to senders so maybe: s/An implementation/Senders s/Implementation implementing/Senders implementing ;) s2.2.4: s/In order to support/To support s2.2.5, 1st para: s/(by design!)/(by design) ;) s/although an implementation/although a sender s/An implementation SHOULD/A sender SHOULD s2.2.5, 2nd para: s/an implementation/a sender s/([RFC3168])/[RFC3168] s2.2.6, 1st para: s/([RFC0791])/[RFC0791] s2.2.6, 2nd para: 2119 the should?: s/should be/SHOULD be. Is there a = reason you would want to handle the errors differently? If not then = would the following also be true (i.e., replace "should be" with "are":=20= Any errors (e.g., ICMP errors arriving back at the tunnel ingress due to tunnel traffic) are handled the same as with non IP-TFS IPsec tunnels. s2.2.7, 1st para: s/am implementation/a sender s2.2.7, 2nd para: s/([RFC4301])/[RFC4301] s2.3: Does this work? OLD: It is not the intention of this specification to allow for mixed use of an AGGFRAG_PAYLOAD enabled SA. NEW: This document does not specify mixed use of an AGGFRAG_PAYLOAD enabled SA. s2.4.1, 1st para: s/In the non-congestion controlled mode IP_TFS /In the = non-congestion controlled mode, IP-TFS s2.4.1, 2nd para: Should the should be SHOULD? s/In this case packet/In this case, packet There is a reference to a user. Is it really a user? s2.4.2, 2nd para: s/the ingress sends/the ingress side sends Maybe just swap this around? OLD: An example of an implementation of the [RFC5348] algorithm which matches the requirements of IP-TFS (i.e., designed for fixed-size packet and send rate varied based on congestion) is documented in [RFC4342]. NEW: [RFC4342] provides an example of the [RFC5348] algorithm which matches the requirements of IP-TFS (i.e., designed for fixed-size packet and send rate varied based on congestion. s2.4.2, 3rd para: s/In particular these/In particular, these s2.4.2, 4th para: Should the must be MUST? s/The lack of receiving this information/Not receiving this information s2.4.2, 4th and 5th paras: s/it=E2=80=99s/its s2.4.2, 6th para: Does this work? OLD: When an implementation is choosing a congestion control algorithm (or a selection of algorithms) one should remember that IP-TFS is not providing for reliable delivery of IP traffic, and so per packet ACKs are not required and are not provided. NEW: When choosing a congestion control algorithm (or a selection of algorithms) note that IP-TFS is not providing for reliable delivery of IP traffic, and so per packet ACKs are not required and are not provided. s2.4.2, last para: s/It=E2=80=99s/It is s3, 1st para: s/and also be able to approximate/and also to approximate=20 s/([RFC5348])/[RFC5348] s/In order to obtain these values the/ In order to obtain these values, the=20 s/Thus in order, to support/Thus, to s/is used to convey/conveys s3, 1st and 3rd para: s/it=E2=80=99s/its s3, 3rd para: Nits complained about this so I am assuming it=E2=80=99s = MUST NOT here - s/MUST not/MUST NOT s3.1, 1st para: s/egress endpoint/egress (receiving) side s3.1, last para: s/For this reason ECN/For this reason, ECN/ s4: s/should be able to be specified/should be specified s4.1: s/For non-congestion controlled mode the/For non-congestion = controlled mode, the s4.1: Does this work: OLD: For congestion controlled mode one can configure the bandwidth or have no configuration and let congestion control discover the maximum bandwidth available. NEW: For congestion controlled mode, the bandwidth can be configured or the congestion controller discovers the maximum bandwidth available. s5.1, 2nd para: s/is used to enable use of/enables the s5.1, 3rd para: s/To request using the/To request use of the s/then response/then the response s5.1, penultimate para: Should the should not be SHOULD NOT? s6.1: s/8 bit/8-bit s6.1: s/specification/document s6.1.1: s/"DataBlocks=E2=80=9D data/=E2=80=9CDataBlocks" ? s6.1.1: s/16 bit/16-bit s6.1.2: s/7 bit/7-bit s6.1.2: s/1 bit/1-bit s6.1.2 x3: s/32 bit/32-bit s6.1.2: s/22 bit/22-bit s6.1.2 x2: s/21 bit/21-bit s6.1.3: s/4 bit/4-bit s6.1.3.1/s6.1.3.2/s6.1.3.3: s/4 bit/4-bit s6.1.3.1/s6.1.3.2: s/16 bit/16-bit s6.1.3.3: s/extends/Extends s6.1.4: s/As discussed in Section 5.1 a/As discussed in Section 5.1, a s6.1.4, D bullet (make it match C): s/Don't Fragment bit, if/Don't = Fragment bit. If s7: I may have missed this in earlier discussions but why is the = registration policy Standards Action? I thought that most of the = registries were trending more towards Expert Review. s8, 1st para: s/Traffic Flow Confidentiality/TFC s8: You warned in s1 about using a non-constant send-rate, but shouldn=E2=80=99= t that be echoed here? Likewise maybe repeat the ECN covert channel statement. s9.2: r/[draft-iab-wire-image]/[RFC8546] Appendix B: YMMV here but since this is an Appendix and you=E2=80=99re = repeating the current practice s/SHOULD/should Cheers, spt > On Jan 24, 2021, at 20:55, Tero Kivinen wrote: >=20 > This is the start of 3 week WGLC on the document, ending 2021-02-15. > Please submit your comments to the list, also send a note if you have > reviewed the document, so we can see how many people are interested in > getting this out. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Feb 4 07:14:31 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE2F3A1592 for ; Thu, 4 Feb 2021 07:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Pl5WT-MmToge for ; Thu, 4 Feb 2021 07:14:28 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 B83383A1598 for ; Thu, 4 Feb 2021 07:14:28 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DWhst0ht1z735; Thu, 4 Feb 2021 16:14:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1612451666; bh=IfJnjfUgv36atKAZV3y506ceAlp4oXxmEyqHN775McY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CmxMzW9ARXi/TH8zPWBAA3Cu8ZIBTJmIsDJ/6yS69tfLRhQaGUutSvkXQs6pKFE7k RnYN/dprLTv3KM+IHSxfURuubhJLf3qpaGR5VngnlGJzn+Jg9rec8OWHTHjuLtJ4vp hEd3Xyfm5li3ZvDlSly9STy0cVxDQqJARkFZ+TeU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id VuHxlvdndMeR; Thu, 4 Feb 2021 16:14:25 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 4 Feb 2021 16:14:25 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E806E6029B62; Thu, 4 Feb 2021 10:14:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DF66F66B1E; Thu, 4 Feb 2021 10:14:23 -0500 (EST) Date: Thu, 4 Feb 2021 10:14:23 -0500 (EST) From: Paul Wouters To: Sean Turner cc: ipsec@ietf.org In-Reply-To: <569B8D50-F0B3-4EA1-8A1D-EFB9BD674578@sn3rd.com> Message-ID: <508e4943-a43c-fcf8-8b69-12ecc9d323f5@nohats.ca> References: <24590.9470.995873.674029@fireball.acr.fi> <569B8D50-F0B3-4EA1-8A1D-EFB9BD674578@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 15:14:31 -0000 On Wed, 3 Feb 2021, Sean Turner wrote: > s1, last para: s/IP-TFS provides for dealing with network congestion/IP-TFS addresses network congestion I dont think it "addresses" network congestion. It maybe improves dealing with network congestion ? > It is not the intention of this specification to allow > for mixed use of an AGGFRAG_PAYLOAD enabled SA. > > NEW: > > This document does not specify mixed use of an > AGGFRAG_PAYLOAD enabled SA. Maybe add "purposefully" ? Otherwise agree with Sean's comments. Paul From nobody Mon Feb 8 03:44:17 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE25E3A165E for ; Mon, 8 Feb 2021 03:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oqoSEvh-mLoW for ; Mon, 8 Feb 2021 03:44:14 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B154E3A1658 for ; Mon, 8 Feb 2021 03:44:13 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id a22so813758ljp.10 for ; Mon, 08 Feb 2021 03:44:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=nOFZubutIpwKuKn/LeKiKgOJxMXAT/IV8deWIiSYCnQ=; b=e9CeUv7GkK0I+Iyef2uYz/PJq9Bmo8dGdhoG/pX/f1FeXVqZ2hYQyKeLwWTPWv+gF1 HGLyYtvJ+PYY8lAzSeNEVFrHy7hDDBCz8MijJffL1MxWnOjbv1orapamzbKjXMli3ox4 fXnezHz4ilPFf2N5kHyq5w0FCt18b4UaLQ+Lf/37x1Oh2Zhgn0xfatIk/91Ai0tEHUQ9 nLVY73BGdk7gnL9qTbvJUcXBJBa942RMbZWLjdyA1n+3+TzRmtmpVf0vzMxF8PyjIICW /5bLA+0oAtmQxYjHnMoN/rY/s5OvVS1VscUkP4ncqXW4J4JxKFConM/oT35Oj8f5QK6O Z50g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=nOFZubutIpwKuKn/LeKiKgOJxMXAT/IV8deWIiSYCnQ=; b=tYyw0EiAZknRu4mZEG2X9kqAkKXIRFg5L3hKmPShSar30rictbF2b5n1m+34S63JKm kRJ1JnYwGpivw/HWv2gIq/Vbb2Nfp/cgJwnGeyUOIhs9wDWnnGu3rAnntfRviojM0Avv oIo0SvmdzTtvd/7uomE1p0xx9rUuWArdu2+ezeZfW3PEKRE7UCeSkbQ1whADtk8iMotP qaGBfZJ61sr5wzUnItjgpPbqvFWv4PqFGv7agPeKUeyVNP1J4xHjCWbMBdhKqUJQ26zA 74wFT7BHXQBxIlj2wkgEnjDEy4IEaXGfK6sEib70ATVmprURWOIUjwbDm1ciWk99huh1 o5bQ== X-Gm-Message-State: AOAM531I7f2Q/X+P2Qw9hrh2jRk8mY14PaVOEXdnArcIQ8VT3YedkbHs ardFVy57K9/3npNanI7C37Y= X-Google-Smtp-Source: ABdhPJwD6dY3pjKQKFJKH0OrsIYQokIuXTLXb7eV99DfQ1ue1kBIYKiwbkA3EHytEOhU3TA90EKUcg== X-Received: by 2002:a2e:8e79:: with SMTP id t25mr3802191ljk.498.1612784651900; Mon, 08 Feb 2021 03:44:11 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id 8sm2064010lfz.113.2021.02.08.03.44.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2021 03:44:11 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , Cc: References: <24590.9470.995873.674029@fireball.acr.fi> In-Reply-To: <24590.9470.995873.674029@fireball.acr.fi> Date: Mon, 8 Feb 2021 14:44:12 +0300 Message-ID: <018901d6fe0f$b875a2d0$2960e870$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEwzZDjYo4hMYjGJNs7372CsQemJquPqmQA Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 11:44:16 -0000 Hi, I think that in its current form the draft is too focused on a single application for the Aggregation and Fragmentation mode - IP-TFS. From architectural point of view I'd like to see the draft first defining the mechanism itself and then describing possible applications for it, focusing on IP-TFS as the primary application. We discussed this with Christian off the list in length and came to a good compromise regarding naming of new entities defined in the draft. After re-reading the draft I still think that its structure of the document should be changed to better decouple mechanism from its applications. Below are some comments and ad hoc text proposals. 0. General note: The text constantly mixes up the mechanism (Aggregation and Fragmentation Mode) with one of its application (IP-TFS). IP-TFS is not the only possible application for this mechanism and when the mechanism itself is being described IP-TFS must not be mentioned unless the feature being described is important for this application (like congestion control). E.g., the payload must be named AGGFRAG (or something like that) payload and not IP-TFS payload. And so on. 1. I propose to rename the document: "Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security (IP-TFS)" (with short form "AGGFRAG ESP Mode and its use for IP-TFS"). 2. Abstract: I propose to change it as follows: This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payload. This mechanism can be used for various purposes, such as: improving performance when IP traffic flow confidentiality is in use, decreasing encapsulation overhead for small IP packets and so on. The document also describes the use of this mechanism for IP traffic flow confidentiality in detail. 3. Introduction: I propose to leave the first two paras as is and to rewrite the rest of the section: Modify text to clearly separate mechanism from its applications (e.g. s/The IP-TFS solution provides/The Aggregation and Fragmentation mode provides). Introduce IP-TFS acronym as one possible application for the mechanism and the one that is the draft is focused on. Move last para of Section 2.1 to Introduction to mention others possible applications. 4. Section 2: I believe the structure of this section is incorrect. It should first describe the Aggregation and Fragmentation mode (sections 2.2-2.4 and some text from 2.1) and only then describe the use of AGGFRAG for IP-TFS (section 2 up to 2.1). The name of the section should be "The Aggregation and Fragmentation Mode of Operation". 5. Section 2.1: This is accomplished using a new Encapsulating Security Payload (ESP, [RFC4303]) type which is identified by the number AGGFRAG_PAYLOAD (Section 6.1). RFC 4303 doesn't define what is "Encapsulating Security Payload type ". You should clarify this in more detail and also mention that the AGGFRAG_PAYLOAD number must be in the ESP "Next Header" field. 6. Section 2.2: s/Figure 1: Layout of an IP-TFS IPsec Packet/Figure 1: Layout of ESP Packet in Aggregation and Fragmentation Mode 7. Section 2.2.1: s/ Figure 2: Layout of IP-TFS data block/ Figure 2: Layout of Data Block 8. Section 2.2.2: Only when there is no data to encapsulated is end padding required, and then an explicit "Pad Data Block" would be used to identify the padding. Nit: isn't better: s/no data to encapsulated/no data to encapsulate 9. Section 2.2.3: When using the AGGFRAG_PAYLOAD in conjunction with replay detection, the window size for both MAY be reduced to share the smaller of the two window sizes. This is b/c packets outside of the smaller window but inside the larger would still be dropped by the mechanism with the smaller window size. I wonder why MAY is used here. It should be MUST instead. As you explained there is no point for the sizes to be different. And please s/b\/c/because 10. Section 2.2.3: Finally, as sequence numbers are reset when switching SAs (e.g., when re-keying a child SA), an implementation SHOULD NOT send initial fragments of an inner packet using one SA and subsequent fragments in a different SA. Two issues here - first why SHOULD NOT and not MUST NOT? In general you cannot reliably reassemble packet if it is fragmented over several SAs, so it will be dropped. Why do you allow this? Then, IPsec architecture allows several parallel ESP SAs to co-exist with the intention that kernel may use any of these SAs to send packets (e.g. for improving performance, see draft-pwouters-multi-sa-performance). I think you should mention that in this case a care must be taken not to fragment outgoing packets over several parallel SAs. I.e. if a packet get fragmented, all its fragments must be sent over single ESP SA. 11. Section 2.2.4: IKEv2 always creates ESP SAs in pairs, so you don't need to send empty AGGFRAG_PAYLOAD payloads over non-AGGFRAG enabled SAs. I understand your intention to use this mode in non-IKEv2 environments, but I think that in case of IPsec you don't need to send AGGFRAG_PAYLOAD payload over non- AGGFRAG enabled SAs. I think some text should be added that this section is only applicable for non-IKEv2 use case. 12. Section 2.3: Empty AGGFRAG_PAYLOAD payloads (Section 2.2.4) are used to transmit congestion control information on non-IP-TFS enabled SAs, so intermixing is allowed in this specific case. As I said before it is not needed in case of IKEv2, so I'd rather to stress that this is only allowed if AGGFREAG SAs are not being created in pairs (non-IKEv2 use case). 13. Section 2.3: While it's possible to envision making the algorithm work in the presence of sequence number skips in the AGGFRAG_PAYLOAD payload stream, the added complexity is not deemed worthwhile. I have trouble understanding applicability of this text to the section describing Exclusive SA Use. Shouldn't it be in 2..2.3? 14. Section 2.4.2: This section is concerned with IP-TFS use of AGGFREG mode. First, I think it must be mentioned in the text. Then, the text lacks discussion on how to deal with congestion when ESP over TCP is used (RFC 8229). >From my understanding it is TCP that will take care of congestion in this case. If both mechanisms are in use then I suspect that it may affect performance (like TCP in TCP), because in this case congestion information (RTT etc.) will be highly inaccurate. More general note - using ESP over TCP may also add some other implications on using AGGFRAG (e.g. header values mapping, ECN, fixed packet size etc.), I think it's worth to add some text. Is IP-TFS use of AGGFRAG ever make sense when ESP is sent over TCP? 15. Section 3: In order to obtain these values the receiver sends congestion control information on it's SA back to the sender. s/it's/its 16. Section 5.1: The USE_AGGFRAG notification MUST NOT be sent, and MUST be ignored, during a CREATE_CHILD_SA rekeying exchange as it is not allowed to change use of the AGGFRAG_PAYLOAD payload type during rekeying. A new child SA due to re-keying inherits the use of AGGFRAG_PAYLOAD from the re-keyed child SA. In IKEv2 re-keying of Child SA is semantically almost equal to creating a new Child SA with the only exception that the SA which is being rekeyed is indicated. However, all the properties of newly created substitute SA are negotiated as if it is not a rekey (transforms, mode of operation). I don't see any reason why to break this with AGGFRAG. I prefer to re-negotiate AGGFRAG in this case just to follow current IKEv2 practice. This will simplify implementations. And I see no problem if after AGGFRAG SA is replaced with normal one and visa versa. Am I missing something? 17. Section 5.1: The USE_AGGFRAG notification contains a 1 octet payload of flags that specify any requirements from the sender of the message. If any requirement flags are not understood or cannot be supported by the receiver then the receiver should not enable use of AGGFRAG_PAYLOAD payload type (either by not responding with the USE_AGGFRAG notification, or in the case of the initiator, by deleting the child SA if the now established non-AGGFRAG_PAYLOAD using SA is unacceptable). It is not clear for me from this text whether these flags are negotiated or independently announced by peers. In other words - are they independent in both direction or they must be the same? 18. Section 5.1: Add some text that USE_AGGFRAG cannot be combined with USE_TRANSPORT_MODE. General note: I think some words should be added somewhere (Section 2?) that AGGFRAG implies encapsulation whole IP packets, so it cannot be used for Transport mode ESP SA. 19. Section 6.1: An IP-TFS payload is identified by the ESP payload type AGGFRAG_PAYLOAD which has the value 0x5. Where this value has come from? Isn't it registered with IANA? We had a long discussion about this in the WG, current text looks like the value was squatted... Another issue: what is "ESP payload type"? RFC 4303 doesn't have this term. You should first introduce it. 20. Section 6.1.4: 0: 6 bits - reserved, MUST be zero on send, unless defined by later specifications. Add a sentence that these bits MUST be ignored on receipt. 21. IANA Considerations. I wonder why newly defined registry "AGGFRAG_PAYLOAD Sub-Type Registry " has an allocation policy "Standards Action". From my understanding this is too restrictive. Why "RFC Required" or "Expert Review" is insufficient? Out of 256 possible values only 2 are defined and I don't expect a lot of allocation requests for this registry, so why do you need such a restrictive policy? Another issue - I would have mark value 0 as "Reserved" (just in case a special value is needed in future), but it's a matter of taste. 22. Security Considerations. Add a text that correct functionality of the AGGFRAG mode requires restoring packets order on the receiver. Since this is done by utilizing ESP Sequence Number field, the ESP header must be authenticated, and thus the ESP SA MUST be created with authentication other than NONE or with AEAD cipher. Probably it's worth to mention this somewhere in Section 2.2.3... 23. Appendix C.1.1: The overhead of IP-TFS is 40 bytes per outer packet. I failed to understand where 40 bytes came from. From my understanding the overhead of AGGFRAG is either 4 bytes or 24 bytes depending on mode used (comparing with usual ESP). Am I missing something? s/bytes/octets 24. Appendix C.1.2: The overhead per inner packet for constant-send-rate padded ESP (i.e., traditional IPsec TFC) is 36 octets plus any padding, unless fragmentation is required. Again, I failed to understand where 36 octets came from. In general ESP overhead depends on transforms in use (which influence IV and ICV sizes), so you should mention under which condition this overhead was computed. Regards, Valery. From nobody Mon Feb 8 06:52:27 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B812E3A17F9 for ; Mon, 8 Feb 2021 06:52:25 -0800 (PST) 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.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 CiOspzmVrpDE for ; Mon, 8 Feb 2021 06:52:23 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2121.outbound.protection.outlook.com [40.107.243.121]) (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 34B523A177B for ; Mon, 8 Feb 2021 06:52:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HFWr9B8RjTKbrt+IdzTn4My29AX2hjv3rapJISg4csC3UrYWg28pxMFwS2DLc4MjSnAB50OXbYCFSl0C/Eob2jxTlkMelaCnAnkMA7mjWvmLZoyu8EXueH+dp5mEqTGq5ypGwfybbgxlmgMyx8+USdQZtlwLIw55x2QAPw4U2eip7SSzOmdFmVGuSfM5MdjxKkIEhR+Pz5jwebCz/MZj1VCs4MT0g8W9XJP8Lev3Nsf9Dp0na7RCpDrI11fiXyUfUV/Qsm/pWiwKR5pQO5AGnWHiBkWYQVDb9svikdNabH9H/t1upnLcNLgcsIVmGz9cP41KodlpfRWNlnx7Bs2JSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fe0JfdVBjTKevRgy8MgJUFy9FqOM3kFTUT9T0+eyMHE=; b=QDqMibzCuxg1mBqGHGAUdGYjv99CAvm8ZSsd3j0le7RZBvc6IcHXyNHRTJAUUSCHzE9J0CC+QihCxeG3McTQvnw3q20zkPhoMe7knS4jjLnLxbH4BFwMbSd0fHWzrr3pEq9zAzUxjv4egrkeyCGnw4qpOuBs0e4Syz5LlRCjmgMLbf9B415R59F80NrSLxgWdncuyVrF3EC3Q868rY1CvFCrl0D9DVgLgUY0TwVeCiwTHTzcIePdk1JealdzkOGWRpyKmGVkXD8fxsucEC6JcB0px5zZn2iRWjapabkTIdZC1Jsyw+ShiNeLosMNRpnQ844IrVJLSf4aYxm/C8rAWw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fe0JfdVBjTKevRgy8MgJUFy9FqOM3kFTUT9T0+eyMHE=; b=VF8zl7igo/8rf22Sc4qqOHr/XjVpumNAkd3/NDlDgj0zhG9V6eH9zo5zK4EURQlXFP1IpWBiAwoAMUcOZRiKTF0A0/QhpAwqXMMJWX7m+5b30mOCW93YCWoUe997dqfN/HynfG/scdIQQzDBMzEYa2PjZCzgX4ENwaaARZPg2aA= Authentication-Results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=labn.net; Received: from BL0PR14MB3779.namprd14.prod.outlook.com (2603:10b6:208:1c7::24) by MN2PR14MB3502.namprd14.prod.outlook.com (2603:10b6:208:1a9::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.23; Mon, 8 Feb 2021 14:52:21 +0000 Received: from BL0PR14MB3779.namprd14.prod.outlook.com ([fe80::9965:8049:fd3c:6f07]) by BL0PR14MB3779.namprd14.prod.outlook.com ([fe80::9965:8049:fd3c:6f07%3]) with mapi id 15.20.3825.030; Mon, 8 Feb 2021 14:52:21 +0000 From: Lou Berger To: Valery Smyslov , 'Tero Kivinen' , ipsec@ietf.org Cc: chopps@chopps.org References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> Message-ID: <7d22dad4-4b23-82a1-0c3b-eb66b3013aa5@labn.net> Date: Mon, 8 Feb 2021 09:52:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <018901d6fe0f$b875a2d0$2960e870$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [100.15.108.238] X-ClientProxiedBy: MN2PR12CA0032.namprd12.prod.outlook.com (2603:10b6:208:a8::45) To BL0PR14MB3779.namprd14.prod.outlook.com (2603:10b6:208:1c7::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:::1] (100.15.108.238) by MN2PR12CA0032.namprd12.prod.outlook.com (2603:10b6:208:a8::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.17 via Frontend Transport; Mon, 8 Feb 2021 14:52:21 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b00ccd96-ee86-4335-70f8-08d8cc412387 X-MS-TrafficTypeDiagnostic: MN2PR14MB3502: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6FONxHVI3Y3fETtN3LvyC1ha2SjIN2zwZ+Sj4pHxapFcpgRZuAxYnwggRBluJsn5nvPTEn/ZZNnuaonhyoQbOxTEpTBrdsr0v+D9D2Q7JTrbr08WmYzKezaNamiMm58X0ANhq22ACwkUWz9apJr6J0AWUQW00H3vZFb/57/ar2wubAfsR9WgUGhJCRsX+ftT1Ba7H46hM8ZUzvFJC+wPPFziVR7H9iiamfnpYspkxa21cjgT3G7K1PyvEwBIwkr94gv6Yg7aZi/n74HKRwM/3WxxPXyDV8T6gJ6AA1yX9h13gtkAuUGL4LA7XNIp9ZIBJ48pd+V0lWZNDvKYi2NgWhi9diHyhIRZNym+CZdAWl+lF8BqwZThQceeRYLZIAwP4ASGZ7m4GuDb8xvVgCP5IsAZzlJsl569Jzu7TL/pbxI1iHo66H0dRSLDmvcaZFaHsGlYpHnfX0b1gh7y23BvszG2Uw5YgltMUmZsvQC7jX74EpAaQUcAyFjPsgtLfFkl3bJWGcHDW0202SxgIcIv+rDJ5FrlYs/zznw+LsOc4b6Fn4tDOu2Yeh9ysVggIYb1f2kUK+1ij9OWdapo7/mu2s5vEj/Pp1Tb4fhNpPjsRH8+jn520H/VYK+igpEqHJLDmx4sHqVOa73c+YipKdFV7+cyBJXlNS84R0On6Zcwai1CFF/+Q9ppIvv1Xi92S1bD X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR14MB3779.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(39830400003)(346002)(376002)(136003)(956004)(86362001)(478600001)(316002)(110136005)(5660300002)(66476007)(2616005)(6666004)(66556008)(66946007)(31696002)(31686004)(6486002)(83380400001)(4326008)(8936002)(8676002)(26005)(52116002)(2906002)(53546011)(186003)(30864003)(36756003)(966005)(16526019)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Z1crdXVJeGtPQTYzYlYvN2xGV29BYXRRNC9MVkNzeDB5YThjTmVrNjFnQSsw?= =?utf-8?B?Q0YyK0hDOW5YRGg0cDhURkJndC96ZVlyRjdIbm9OWTRzd2hpSEVqZkx0RnMy?= =?utf-8?B?SnhXWGJMWmFsbjZ2VkdUZlpqU000SDB0bVdoUzQwMjJBTWNYbmQ0cUowR1pj?= =?utf-8?B?N1RYNjNGSEFwcjVuU2xRaFdqeTJ0MWlZUjROd2RWUGxKbnhTMW9xcTlSa2xH?= =?utf-8?B?VEZHZ1ZmQnBDazBOQy9NT1htSzNINWFWemZEc01Kb3NTVWxLRFBOMjdjZkd3?= =?utf-8?B?QysyK1lGSzZEdTJwVHY3R2RsVWZ6Q3lYMS9VQXpWM1I1LzJwUGt1c1gwdkhP?= =?utf-8?B?UFBxMG5PcGEyWDhFUnoyb3QzbzBqV2ZmZGVYZi92bHlSTlZKNGhyUmNCSFgw?= =?utf-8?B?QzdGNHh2elhkT09GWTRhaUFEZHN6OHdQNXhDVXcxSGFVeE80dFUvMGNaOUdV?= =?utf-8?B?eURROFRzQmpPMXVnNm1zMWJZeTZZRFRhRzRkWFVCQUVnMWFXSEQvNUlEdjRF?= =?utf-8?B?aWFrcmtwMVZxSTRGY2NKeTJWQUxaZE5kMHVRb0wxT05OK0VrNmo5d2xlRGFi?= =?utf-8?B?SjAyckpiVkFmaXJtZE8yaENJcWt0TUxrU1hWOUw3VW1qZ1RlTUYxcEpPU2My?= =?utf-8?B?T1laUEVjZmtSdHZmY1dXMklRbHFLSWRqSERNQ25xanFJb2E4MjFSUHcxaDVX?= =?utf-8?B?VzhYVitvamlLcnViSUpyTE5IZElNVkNxdFlCUGRmRGUzeDZuWWlJZlJBWjVy?= =?utf-8?B?YWk0VGpzQVEwK2kzM3ZUQysrOUJtMXE0cERTakpRUHN0MmtMVmdyQm5hTDlI?= =?utf-8?B?T3I5TlBCOSt0ZSsvSENZWCtpVlFBWk5UM0pHRStjRVBMeVlLZWFvZmtMaGNu?= =?utf-8?B?TkpNZVVuaVhoaHB2RjZCUUhIYUU1RVM0NnlaV01ETy9waTdIME9TNWNNSFMr?= =?utf-8?B?clgxT1dNVXlLUTRqblV1YzFocGFHdG5kZHZxUHU0QkdsYTh5ODFDdEZlamQ4?= =?utf-8?B?VHJrZ2tZWFl3d2hkUWJPd1d3d2p5RFp3QzhtUnRYTzQ3NGxtN0NMaFlXMDQw?= =?utf-8?B?SHVaQUFJb3pCZ0dkRGRwTkY1SUZ5SWMxbWFaOFV4SHpCbkE3NWIyQ3A0b0dq?= =?utf-8?B?UnRYWVJPOUdmc3FhcXlvdThTTDlPdWM2T3B0eVFHMEoxNjZiVWVTZGwyZ29I?= =?utf-8?B?UVpPNVErQThEZkxqa3E5U0lYdEpBK2pjbDlJTHZKTzlYeExoR3BzVEVlUFNI?= =?utf-8?B?d3liTmdZYnczOUJWQXZhT3psdzJDaXppYXlYaFJ1SEpZUEc4bnZPYjlBbXlV?= =?utf-8?B?VWpjdElwVm1tSGdvZmYxU2F6UW9QaDZqVmhWbndOa282YUQwakJtc3ZXOEdn?= =?utf-8?B?TlhhOHNzNnRrQVFGSWNvVnlWMXN5QjZOUjFKMTVsVG1yelVBa3lIeThxRlFJ?= =?utf-8?B?bVk0cC9MTmp2a3VVVFI4MjRSS0pYN1QxcnlocjIvMStwenZVYXNZSlQzRzcx?= =?utf-8?B?akZWRjcyeG52QUs2VERSUldkVmxyWCszK3ZNOGcvWFU1bDdIMzQzSWtCbk1K?= =?utf-8?B?QkR6ZURKZnFHK0gvQjFScTlOcGZYVGt6a3k5VlVhUGU4MEp6YUIvaEZITVpz?= =?utf-8?B?STNVVnFzYUdmWEIyNk5yRzFJQ0NYUGRkeG1ybGpjOWxaUlJETUZ3Ry9FTDB2?= =?utf-8?B?NDFnZU5iQ2pra3JRWEJBaUFpZ2ZVQmJRdnZhTUVjRlNKU0RJd3N0T1JnRXZj?= =?utf-8?Q?py6mT0TxxyoecZ/aSe07UaS9NrdLlEml/9eikNH?= X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-Network-Message-Id: b00ccd96-ee86-4335-70f8-08d8cc412387 X-MS-Exchange-CrossTenant-AuthSource: BL0PR14MB3779.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2021 14:52:21.6344 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: sW3JFuIs0Z5k7QqtjWfs/avKBtRYp4xlIpPMyow0RwEK4jsWwRW3H9y1tddfEPlw4070mVkKKwtLYGYrfsWU+A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3502 Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 14:52:26 -0000 Hi Valery, I think you make a number of good mechanism specific technical points that are worth addressing in the document, but I think that recasting/redirecting this work goes too far.  This work has always been focused on a specific application (TFS) and it's utility beyond that application is certainly a bonus -- the very recent name changes (made at your request) to accommodate such wider usage certainly provides a solid foundation for non-TFS usage.  This all said, I think the usage of the mechanisms defined in this document beyond TFS should be covered in its own document and not shoehorned in to this document. I support publishing this document, largely as is and without a major focus change, once clarifications and nits are addressed. Lou On 2/8/2021 6:44 AM, Valery Smyslov wrote: > Hi, > > I think that in its current form the draft is too focused on a single application for > the Aggregation and Fragmentation mode - IP-TFS. From architectural > point of view I'd like to see the draft first defining the mechanism itself > and then describing possible applications for it, focusing on IP-TFS > as the primary application. > > We discussed this with Christian off the list in length and came to > a good compromise regarding naming of new entities defined in the draft. > After re-reading the draft I still think that its structure of the document should be > changed to better decouple mechanism from its applications. > > Below are some comments and ad hoc text proposals. > > 0. General note: > The text constantly mixes up the mechanism (Aggregation and Fragmentation Mode) > with one of its application (IP-TFS). IP-TFS is not the only possible application for this mechanism and > when the mechanism itself is being described IP-TFS must not be mentioned unless the feature being described > is important for this application (like congestion control). E.g., the payload must be > named AGGFRAG (or something like that) payload and not IP-TFS payload. And so on. > > 1. I propose to rename the document: > > "Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security (IP-TFS)" > (with short form "AGGFRAG ESP Mode and its use for IP-TFS"). > > 2. Abstract: > > I propose to change it as follows: > > This document describes a mechanism for aggregation and fragmentation of IP packets > when they are being encapsulated in ESP payload. This mechanism can be used > for various purposes, such as: improving performance when IP traffic flow confidentiality is in use, > decreasing encapsulation overhead for small IP packets and so on. The document > also describes the use of this mechanism for IP traffic flow confidentiality > in detail. > > 3. Introduction: > > I propose to leave the first two paras as is and to rewrite the rest of the section: > Modify text to clearly separate mechanism from its applications > (e.g. s/The IP-TFS solution provides/The Aggregation and Fragmentation mode provides). > Introduce IP-TFS acronym as one possible application for the mechanism > and the one that is the draft is focused on. Move last para of Section 2.1 to Introduction > to mention others possible applications. > > 4. Section 2: > > I believe the structure of this section is incorrect. It should first describe the > Aggregation and Fragmentation mode (sections 2.2-2.4 and some text from 2.1) > and only then describe the use of AGGFRAG for IP-TFS (section 2 up to 2.1). > The name of the section should be "The Aggregation and Fragmentation Mode of Operation". > > 5. Section 2.1: > > This is accomplished using a new Encapsulating Security Payload (ESP, > [RFC4303]) type which is identified by the number AGGFRAG_PAYLOAD > (Section 6.1). > > RFC 4303 doesn't define what is "Encapsulating Security Payload type ". > You should clarify this in more detail and also mention that > the AGGFRAG_PAYLOAD number must be in the ESP "Next Header" field. > > 6. Section 2.2: > > s/Figure 1: Layout of an IP-TFS IPsec Packet/Figure 1: Layout of ESP Packet in Aggregation and Fragmentation Mode > > 7. Section 2.2.1: > > s/ Figure 2: Layout of IP-TFS data block/ Figure 2: Layout of Data Block > > 8. Section 2.2.2: > > Only > when there is no data to encapsulated is end padding required, and > then an explicit "Pad Data Block" would be used to identify the > padding. > > Nit: isn't better: > > s/no data to encapsulated/no data to encapsulate > > 9. Section 2.2.3: > > When using the AGGFRAG_PAYLOAD in conjunction with replay detection, > the window size for both MAY be reduced to share the smaller of the > two window sizes. This is b/c packets outside of the smaller window > but inside the larger would still be dropped by the mechanism with > the smaller window size. > > I wonder why MAY is used here. It should be MUST instead. > As you explained there is no point for the sizes to be different. > > And please s/b\/c/because > > 10. Section 2.2.3: > > Finally, as sequence numbers are reset when switching SAs (e.g., when > re-keying a child SA), an implementation SHOULD NOT send initial > fragments of an inner packet using one SA and subsequent fragments in > a different SA. > > Two issues here - first why SHOULD NOT and not MUST NOT? > In general you cannot reliably reassemble packet if it is fragmented over > several SAs, so it will be dropped. Why do you allow this? > > Then, IPsec architecture allows several parallel ESP SAs > to co-exist with the intention that kernel may use any of these SAs to send packets > (e.g. for improving performance, see draft-pwouters-multi-sa-performance). > I think you should mention that in this case a care must be taken not to > fragment outgoing packets over several parallel SAs. I.e. if a packet get fragmented, > all its fragments must be sent over single ESP SA. > > 11. Section 2.2.4: > > IKEv2 always creates ESP SAs in pairs, so you don't need to send empty AGGFRAG_PAYLOAD payloads > over non-AGGFRAG enabled SAs. I understand your intention to use this mode in non-IKEv2 > environments, but I think that in case of IPsec you don't need to send > AGGFRAG_PAYLOAD payload over non- AGGFRAG enabled SAs. > I think some text should be added that this section is only applicable > for non-IKEv2 use case. > > 12. Section 2.3: > > Empty AGGFRAG_PAYLOAD payloads (Section 2.2.4) are used to > transmit congestion control information on non-IP-TFS enabled SAs, so > intermixing is allowed in this specific case. > > As I said before it is not needed in case of IKEv2, so I'd rather to > stress that this is only allowed if AGGFREAG SAs are not being created in pairs > (non-IKEv2 use case). > > 13. Section 2.3: > > While it's possible to > envision making the algorithm work in the presence of sequence number > skips in the AGGFRAG_PAYLOAD payload stream, the added complexity is > not deemed worthwhile. > > I have trouble understanding applicability of this text to the section > describing Exclusive SA Use. Shouldn't it be in 2..2.3? > > 14. Section 2.4.2: > > This section is concerned with IP-TFS use of AGGFREG mode. > First, I think it must be mentioned in the text. > Then, the text lacks discussion on how to deal with congestion when ESP over TCP is used (RFC 8229). > >From my understanding it is TCP that will take care of congestion in this case. > If both mechanisms are in use then I suspect that it may affect performance > (like TCP in TCP), because in this case congestion information (RTT etc.) > will be highly inaccurate. > > More general note - using ESP over TCP may also add some other implications > on using AGGFRAG (e.g. header values mapping, ECN, fixed packet size etc.), > I think it's worth to add some text. Is IP-TFS use of AGGFRAG ever make sense > when ESP is sent over TCP? > > 15. Section 3: > > In order to obtain these values the receiver sends > congestion control information on it's SA back to the sender. > > s/it's/its > > 16. Section 5.1: > > The USE_AGGFRAG notification MUST NOT be sent, and MUST be ignored, > during a CREATE_CHILD_SA rekeying exchange as it is not allowed to > change use of the AGGFRAG_PAYLOAD payload type during rekeying. A > new child SA due to re-keying inherits the use of AGGFRAG_PAYLOAD > from the re-keyed child SA. > > In IKEv2 re-keying of Child SA is semantically almost equal to creating a new Child SA > with the only exception that the SA which is being rekeyed is indicated. > However, all the properties of newly created substitute SA are negotiated as if it is not a rekey > (transforms, mode of operation). I don't see any reason why to break this with AGGFRAG. > I prefer to re-negotiate AGGFRAG in this case just to follow > current IKEv2 practice. This will simplify implementations. > And I see no problem if after AGGFRAG SA is replaced with normal one > and visa versa. Am I missing something? > > 17. Section 5.1: > > The USE_AGGFRAG notification contains a 1 octet payload of flags that > specify any requirements from the sender of the message. If any > requirement flags are not understood or cannot be supported by the > receiver then the receiver should not enable use of AGGFRAG_PAYLOAD > payload type (either by not responding with the USE_AGGFRAG > notification, or in the case of the initiator, by deleting the child > SA if the now established non-AGGFRAG_PAYLOAD using SA is > unacceptable). > > It is not clear for me from this text whether these flags are negotiated > or independently announced by peers. In other words - are they > independent in both direction or they must be the same? > > 18. Section 5.1: > > Add some text that USE_AGGFRAG cannot be combined with USE_TRANSPORT_MODE. > > General note: I think some words should be added somewhere (Section 2?) > that AGGFRAG implies encapsulation whole IP packets, so it cannot be > used for Transport mode ESP SA. > > 19. Section 6.1: > > An IP-TFS payload is identified by the ESP payload type > AGGFRAG_PAYLOAD which has the value 0x5. > > Where this value has come from? Isn't it registered with IANA? > We had a long discussion about this in the WG, current > text looks like the value was squatted... > > Another issue: what is "ESP payload type"? > RFC 4303 doesn't have this term. You should first > introduce it. > > 20. Section 6.1.4: > > 0: > 6 bits - reserved, MUST be zero on send, unless defined by later > specifications. > > Add a sentence that these bits MUST be ignored on receipt. > > 21. IANA Considerations. > > I wonder why newly defined registry "AGGFRAG_PAYLOAD Sub-Type Registry " > has an allocation policy "Standards Action". From my understanding > this is too restrictive. Why "RFC Required" or "Expert Review" is insufficient? > Out of 256 possible values only 2 are defined and I don't expect > a lot of allocation requests for this registry, so why do you need such > a restrictive policy? > > Another issue - I would have mark value 0 as "Reserved" (just in case > a special value is needed in future), but it's a matter of taste. > > 22. Security Considerations. > > Add a text that correct functionality of the AGGFRAG mode > requires restoring packets order on the receiver. Since this > is done by utilizing ESP Sequence Number field, the ESP > header must be authenticated, and thus the ESP SA MUST > be created with authentication other than NONE > or with AEAD cipher. > > Probably it's worth to mention this somewhere in Section 2.2.3... > > 23. Appendix C.1.1: > > The overhead of IP-TFS is 40 bytes per outer packet. > > I failed to understand where 40 bytes came from. From my understanding the overhead > of AGGFRAG is either 4 bytes or 24 bytes depending on mode used (comparing with usual ESP). > Am I missing something? > > s/bytes/octets > > 24. Appendix C.1.2: > > The overhead per inner packet for constant-send-rate padded ESP > (i.e., traditional IPsec TFC) is 36 octets plus any padding, unless > fragmentation is required. > > Again, I failed to understand where 36 octets came from. > In general ESP overhead depends on transforms in use (which > influence IV and ICV sizes), so you should mention under > which condition this overhead was computed. > > Regards, > Valery. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Feb 8 15:19:41 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7413A16D8 for ; Mon, 8 Feb 2021 15:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 8GwhbJ90fIWW for ; Mon, 8 Feb 2021 15:19:34 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 503183A16D5 for ; Mon, 8 Feb 2021 15:19:34 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 938266092B; Mon, 8 Feb 2021 23:19:33 +0000 (UTC) From: Christian Hopps Message-Id: <2B7B497D-8759-4E48-85A3-190DC213A5C6@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_9C170F65-9058-4779-A085-5AC4F48B9092"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 8 Feb 2021 18:19:32 -0500 In-Reply-To: <569B8D50-F0B3-4EA1-8A1D-EFB9BD674578@sn3rd.com> Cc: Christian Hopps , ipsec@ietf.org To: Sean Turner References: <24590.9470.995873.674029@fireball.acr.fi> <569B8D50-F0B3-4EA1-8A1D-EFB9BD674578@sn3rd.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 23:19:38 -0000 --Apple-Mail=_9C170F65-9058-4779-A085-5AC4F48B9092 Content-Type: multipart/alternative; boundary="Apple-Mail=_D248BA1D-0CE5-4B04-B339-4240B64C04A6" --Apple-Mail=_D248BA1D-0CE5-4B04-B339-4240B64C04A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 3, 2021, at 10:38 PM, Sean Turner wrote: >=20 > Hi! I mostly just have nits, but there are a couple of questions = interspersed below. Hi Sean, Thanks so much for this very thorough review! I have made the vast majority of the suggested changes with only a few = style exceptions (and incorporated Paul's input in his follow-on email). I will post a new version soon with these changes (noted below) as well = as addressing some from Valery as well. > s1, para 1: s/While one may directly obscure the data through the use = of/While directly obscuring the data with Fixed > s1, para 1: s/it=E2=80=99s/its >=20 Fixed > s1, para 3: s/IP-TFS/IP-TFS (IP Traffic Flow Security) Fixed >=20 > s1, last para: s/IP-TFS provides for dealing with network = congestion/IP-TFS addresses network congestion "Additionally, IP-TFS provides for operating fairly within congested = networks" > s1: You mention full TFC. Is it partial TFC if you use a non-constant = send-rate? if so that might be good to qualify in the 3rd paragraph with = something like: > OLD: >=20 > A non- > constant send-rate is allowed, but the confidentiality properties of > its use are outside the scope of this document. >=20 > NEW: >=20 > A non- > constant send-rate is allowed to support partial TFC, but the > confidentiality properties of its use are outside the scope of > this document. There are other ideas being studied to achieve full TFC w/o use of = constant send-rate (e.g., using some sort of randomizing), I'm fairly = sure that this just reduces to a lower logical fixed send rate that = utilizes burstiness. In any case since I am aware of there being = research being done in this area I think leaving the text as is makes = sense (i.e., I don't want to claim anything not fixed-rate must be = partial TFC). >=20 > s1.1, para 1: Use updated terminology para from 8174 ("BCP 14=E2=80=9D = is missing): >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > "MAY", and "OPTIONAL" in this document are to be interpreted as > described in BCP 14 [RFC2119] [RFC8174] when, and only when, they > appear in all capitals, as shown here. Fixed. >=20 > s2, para 1: >=20 > is the "(SA)" needed? ... tunnel (SA) ... > s/it=E2=80=99s/its Fixed. > s2, 2nd para: I tripped over this para a couple of times. Does this = get the same point across? >=20 > OLD: >=20 > The primary input to the tunnel algorithm is the requested bandwidth > used by the tunnel. Two values are then required to provide for this > bandwidth, the fixed size of the encapsulating packets, and rate at > which to send them. >=20 > NEW: >=20 > The primary input to the tunnel algorithm is the requested > bandwidth for the tunnel. Two values needed to determine > the bandwidth are the fixed size of the encapsulating > packets and the rate at which to send them. Changed to: The primary input to the tunnel algorithm is the requested bandwidth to be used by the tunnel. Two values are then required to provide for this bandwidth use, the fixed size of the encapsulating packets, and rate at which to send them. > s2, 3rd para: s/or could be/or be Fixed > s2, 4th para: s/requested tunnel used bandwidth/ > requested tunnel bandwidth Changed to: "requested bandwidth to be used" and "The packet send rate is the requested bandwidth to be used divided = by the size of the encapsulating packet." > s1, last para to make it match the rest of the sentence: s/The egress = of the IP-TFS/The egress (receiving) side of the IP-TFS Fixed. >=20 > s2.1, 1st para: s/In order to maximize bandwidth IP-TFS/ > In order to maximize bandwidth, IP-TFS Fixed >=20 > s2.1, 3rd para: Does this say the same thing: >=20 > OLD: >=20 > This is accomplished using a new Encapsulating Security Payload (ESP, > [RFC4303]) type which is identified by the number AGGFRAG_PAYLOAD > (Section 6.1). >=20 > NEW: >=20 > IP-TFS uses a new Encapsulating Security Payload (ESP, [RFC4303]) > type identified by the number assigned to AGGFRAG_PAYLOAD > (Section 6.1). I think I prefer the original text, if that's OK, as it is saying how it = does the paragraph above vs. just making another statement (i.e., I = think it ties the text together better). > s2.2: I had a really hard time parsing this sentence: >=20 > The AGGFRAG_PAYLOAD payload content defined in this document is > comprised of a 4 or 24 octet header followed by either a partial, a > full or multiple partial or full data blocks. >=20 > There are three options: partial, full or multiple partial, or full = data? Maybe it=E2=80=99s just missing a comma: s/multiple partial = or/multiple partial or, Changed to: The AGGFRAG_PAYLOAD payload content defined in this document is comprised of a 4 or 24 octet header followed by either a partial datablock, a full datablock, or multiple partial or full datablocks. >=20 > s2.2.1: Should we be specific about the IPv4 and IPv6 length=E2=80=99s = field name: >=20 > OLD: >=20 > Likewise, the length of the data block is extracted from the > encapsulated IPv4 or IPv6 packet's length field. >=20 > NEW: >=20 > Likewise, the length of the data block is extracted from the > encapsulated IPv4=E2=80=99s Total Length or IPv6=E2=80=99s Payload = Length fields. Fixed >=20 > s2.2: s/It=E2=80=99s/It is > s2.2.3: s/to be able to reassemble/to reassemble > s2.2.3: s/This possible interleaving/This interleaving > s2.2.3: s/sender to always be able to send a/sender to always send a > s2.2.3, 4th para: s/Finally, we note/Finally, note > s2.2.3, 5th para: s/As the amount of reordering that may be present is = hard to predict the window/As the amount of reordering that may be = present is hard to predict, the window Fixed. >=20 > 2.2.3, 5th para: I am all about not littering I-Ds with 2119-language, = but here it looks like you are burying the MUST in the parenthetical. = BTW - I think the sentence stands on its own without the "i.e.=E2=80=9D = and it could safely be deleted. Would this rewording work: >=20 > Gaps in the sequence numbers will not work for this document, > therefore ESP sequence number stream MUST increase monotonically > by 1 for each subsequent packet. Fixed >=20 > s2.2.3, penultimate para: s/b/c/because Fixed > s2.2.3, last para: Should the I-D state what happens if the = implementation does send initial fragments of an inner packet using one = SA and subsequent fragments in a different SA. I.e., motivate the SHOULD = NOT. >=20 > s2.2.3, last para: implementation here refers to sender right so = maybe: senders SHOULD NOT Simplified to "senders MUST NOT"... :) > s2.2.3.1: Implementations here refers to senders so maybe: > s/An implementation/Senders > s/Implementation implementing/Senders implementing ;) Fixed > s2.2.4: s/In order to support/To support Fixed > s2.2.5, 1st para: > s/(by design!)/(by design) ;) > s/although an implementation/although a sender > s/An implementation SHOULD/A sender SHOULD Fixed > s2.2.5, 2nd para: > s/an implementation/a sender > s/([RFC3168])/[RFC3168] Fixed > s2.2.6, 1st para: s/([RFC0791])/[RFC0791] Fixed, and update other single refs to not use parens. > s2.2.6, 2nd para: 2119 the should?: s/should be/SHOULD be. Is there a = reason you would want to handle the errors differently? If not then = would the following also be true (i.e., replace "should be" with "are": >=20 > Any errors (e.g., ICMP errors arriving back at the tunnel ingress due > to tunnel traffic) are handled the same as with non IP-TFS > IPsec tunnels. Fixed > s2.2.7, 1st para: s/am implementation/a sender Fixed >=20 > s2.2.7, 2nd para: s/([RFC4301])/[RFC4301] Fixed > s2.3: Does this work? >=20 > OLD: >=20 > It is not the intention of this specification to allow > for mixed use of an AGGFRAG_PAYLOAD enabled SA. >=20 > NEW: >=20 > This document does not specify mixed use of an > AGGFRAG_PAYLOAD enabled SA. Fixed > s2.4.1, 1st para: s/In the non-congestion controlled mode IP_TFS /In = the non-congestion controlled mode, IP-TFS Fixed > s2.4.1, 2nd para: > Should the should be SHOULD? > s/In this case packet/In this case, packet > There is a reference to a user. Is it really a user? I think it's a should (non-normative), as this is guidance on the right = way to deploy IPTFS, but not how to implement it. > s2.4.2, 2nd para: > s/the ingress sends/the ingress side sends > Maybe just swap this around? >=20 > OLD: >=20 > An example of an implementation of the [RFC5348] algorithm which > matches the requirements of IP-TFS (i.e., designed for fixed-size > packet and send rate varied based on congestion) is documented in > [RFC4342]. >=20 > NEW: >=20 > [RFC4342] provides an example of the [RFC5348] algorithm which > matches the requirements of IP-TFS (i.e., designed for fixed-size > packet and send rate varied based on congestion. Fixed. > s2.4.2, 3rd para: s/In particular these/In particular, these Fixed > s2.4.2, 4th para: > Should the must be MUST? > s/The lack of receiving this information/Not receiving this = information Yes, and fixed. > s2.4.2, 4th and 5th paras: s/it=E2=80=99s/its Fixed > s2.4.2, 6th para: Does this work? >=20 > OLD: >=20 > When an implementation is choosing a congestion control algorithm (or > a selection of algorithms) one should remember that IP-TFS is not > providing for reliable delivery of IP traffic, and so per packet ACKs > are not required and are not provided. >=20 > NEW: >=20 > When choosing a congestion control algorithm (or > a selection of algorithms) note that IP-TFS is not > providing for reliable delivery of IP traffic, and so per packet ACKs > are not required and are not provided. Fixed > s2.4.2, last para: s/It=E2=80=99s/It is Fixed > s3, 1st para: > s/and also be able to approximate/and also to approximate > s/([RFC5348])/[RFC5348] > s/In order to obtain these values the/ > In order to obtain these values, the > s/Thus in order, to support/Thus, to Fixed > s/is used to convey/conveys This is a style one I think that I'd like to leave be, I think it better = highlights that one needs to send these empty payloads in this case. > s3, 1st and 3rd para: s/it=E2=80=99s/its Fixed. >=20 > s3, 3rd para: Nits complained about this so I am assuming it=E2=80=99s = MUST NOT here - s/MUST not/MUST NOT Fixed >=20 > s3.1, 1st para: s/egress endpoint/egress (receiving) side Fixed > s3.1, last para: s/For this reason ECN/For this reason, ECN/ Fixed > s4: s/should be able to be specified/should be specified Fixed > s4.1: s/For non-congestion controlled mode the/For non-congestion = controlled mode, the Fixed > s4.1: Does this work: >=20 > OLD: >=20 > For congestion controlled mode one can configure the > bandwidth or have no configuration and let congestion > control discover the maximum bandwidth available. >=20 > NEW: >=20 > For congestion controlled mode, the bandwidth can be > configured or the congestion controller discovers > the maximum bandwidth available. Changed to: "For congestion controlled mode, the bandwidth can be configured or the = congestion control algorithm discovers and uses the maximum bandwidth = available." >=20 > s5.1, 2nd para: s/is used to enable use of/enables the Fixed > s5.1, 3rd para: > s/To request using the/To request use of the > s/then response/then the response Fixed > s5.1, penultimate para: Should the should not be SHOULD NOT? Fixed > s6.1: s/8 bit/8-bit > s6.1: s/specification/document Fixed > s6.1.1: s/"DataBlocks=E2=80=9D data/=E2=80=9CDataBlocks" ? I'm going to leave this as the ``"DataBlocks" data'' as it is referring = to that area of the packet data. DataBlocks may be spread across = multiple packets or there may be multiple DataBlocks in a single packet. > s6.1.1: s/16 bit/16-bit > s6.1.2: s/7 bit/7-bit > s6.1.2: s/1 bit/1-bit > s6.1.2 x3: s/32 bit/32-bit > s6.1.2: s/22 bit/22-bit > s6.1.2 x2: s/21 bit/21-bit > s6.1.3: s/4 bit/4-bit > s6.1.3.1/s6.1.3.2/s6.1.3.3: s/4 bit/4-bit > s6.1.3.1/s6.1.3.2: s/16 bit/16-bit > s6.1.3.3: s/extends/Extends Fixed > s6.1.4: s/As discussed in Section 5.1 a/As discussed in Section 5.1, a Fixed > s6.1.4, D bullet (make it match C): s/Don't Fragment bit, if/Don't = Fragment bit. If Fixed > s7: I may have missed this in earlier discussions but why is the = registration policy Standards Action? I thought that most of the = registries were trending more towards Expert Review. No particular reason other than it was the conservative choice. :) > s8, 1st para: s/Traffic Flow Confidentiality/TFC Fixed > s8: >=20 > You warned in s1 about using a non-constant send-rate, but shouldn=E2=80= =99t that be echoed here? As mentioned previously it's not necessarily less secure to use a = non-constant send rate (research being done by others here), we are only = claiming use of constant send rate is more secure. > Likewise maybe repeat the ECN covert channel statement. Repeated. >=20 > s9.2: r/[draft-iab-wire-image]/[RFC8546] Fixed. > Appendix B: YMMV here but since this is an Appendix and you=E2=80=99re = repeating the current practice s/SHOULD/should Fixed. Thanks again for the very thorough review! Thanks, Chris. >=20 > Cheers, > spt >=20 >> On Jan 24, 2021, at 20:55, Tero Kivinen wrote: >>=20 >> This is the start of 3 week WGLC on the document, ending 2021-02-15. >> Please submit your comments to the list, also send a note if you have >> reviewed the document, so we can see how many people are interested = in >> getting this out. >> -- >> kivinen@iki.fi >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_D248BA1D-0CE5-4B04-B339-4240B64C04A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 3, 2021, at 10:38 PM, Sean Turner <sean@sn3rd.com> = wrote:

Hi! I mostly just have nits, but there are a couple of = questions interspersed below.

Hi = Sean,

Thanks so much for this very = thorough review!

I have made the = vast majority of the suggested changes with only a few style exceptions = (and incorporated Paul's input in his follow-on email).

I will post a new version soon with these changes = (noted below) as well as addressing some from Valery as well.

s1, para 1: s/While one may directly obscure the data through = the use of/While directly obscuring the data with

Fixed

s1, para 1: = s/it=E2=80=99s/its


Fixed

s1, para 3: s/IP-TFS/IP-TFS (IP Traffic Flow = Security)

Fixed


s1, last para: = s/IP-TFS provides for dealing with network congestion/IP-TFS addresses = network congestion

"Additionally, IP-TFS provides for operating = fairly within congested networks"

s1: You mention = full TFC. Is it partial TFC if you use a non-constant send-rate? if so = that might be good to qualify in the 3rd paragraph with something = like:

OLD:

A non-
= constant send-rate is allowed, but the confidentiality properties of
its use are outside the scope of this document.

NEW:

A non-
constant send-rate is allowed to support partial TFC, but = the
confidentiality properties of its use are outside the = scope of
this document.

There = are other ideas being studied to achieve full TFC w/o use of constant = send-rate (e.g., using some sort of randomizing), I'm fairly sure that = this just reduces to a lower logical fixed send rate that utilizes = burstiness. In any case since I am aware of there being research being = done in this area I think leaving the text as is makes sense (i.e., I = don't want to claim anything not fixed-rate must be partial = TFC).


s1.1, para 1: Use updated = terminology para from 8174 ("BCP 14=E2=80=9D is missing):

The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", = "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" = in this document are to be interpreted as
described in = BCP 14 [RFC2119] [RFC8174] when, and only when, they
= appear in all capitals, as shown here.

Fixed.


s2, para 1: =

is the "(SA)" needed?  ... tunnel = (SA) ...
s/it=E2=80=99s/its

Fixed.

s2, 2nd para: I = tripped over this para a couple of times. Does this get the same point = across?

OLD:

= The primary input to the tunnel algorithm is the requested bandwidth
used by the tunnel.  Two values are then required to = provide for this
bandwidth, the fixed size of the = encapsulating packets, and rate at
which to send them.

NEW:

The primary = input to the tunnel algorithm is the requested
bandwidth = for the tunnel.  Two values needed to determine
the = bandwidth are the fixed size of the encapsulating
packets = and the rate at which to send them.

Changed = to:

The primary input to the = tunnel algorithm is the requested bandwidth
to be used by the = tunnel. Two values are then required to provide for
this = bandwidth use, the fixed size of the encapsulating packets, = and
rate at which to send them.

s2, 3rd para: s/or could be/or be

Fixed

s2, 4th para: s/requested = tunnel used bandwidth/
requested tunnel bandwidth

Changed = to:

"requested bandwidth to be = used"

and "The packet send rate is = the requested bandwidth to be used divided by the size of the = encapsulating packet."


s1, last para to make it match the rest of the sentence: = s/The egress of the IP-TFS/The egress (receiving) side of the IP-TFS

Fixed.


s2.1, 1st = para: s/In order to maximize bandwidth IP-TFS/
In order to = maximize bandwidth, IP-TFS
Fixed


s2.1, 3rd = para: Does this say the same thing:

OLD:

This is accomplished using a new = Encapsulating Security Payload (ESP,
[RFC4303]) type = which is identified by the number AGGFRAG_PAYLOAD
= (Section 6.1).

NEW:

IP-TFS uses a new Encapsulating Security Payload (ESP, = [RFC4303])
type identified by the number assigned to = AGGFRAG_PAYLOAD
(Section 6.1).

I = think I prefer the original text, if that's OK, as it is saying how it = does the paragraph above vs. just making another statement (i.e., I = think it ties the text together better).

s2.2: I had a = really hard time parsing this sentence:

= The AGGFRAG_PAYLOAD payload content defined in this document is
comprised of a 4 or 24 octet header followed by either a = partial, a
full or multiple partial or full data = blocks.

There are three options: partial, = full or multiple partial, or full data? Maybe it=E2=80=99s just missing = a comma: s/multiple partial or/multiple partial or,

Changed= to:

The AGGFRAG_PAYLOAD = payload content defined in this document is
comprised of a 4 = or 24 octet header followed by either a partial
datablock, a = full datablock, or multiple partial or full datablocks.


s2.2.1: Should we be specific about the IPv4 = and IPv6 length=E2=80=99s field name:

OLD:
Likewise, the length of the data block is = extracted from the
encapsulated IPv4 or IPv6 packet's = length field.

NEW:

Likewise, the length of the data block is extracted from = the
encapsulated IPv4=E2=80=99s Total Length or IPv6=E2=80=99= s Payload Length fields.

Fixed


s2.2: = s/It=E2=80=99s/It is
s2.2.3: s/to be able to reassemble/to = reassemble
s2.2.3: s/This possible interleaving/This = interleaving
s2.2.3: s/sender to always be able to send = a/sender to always send a
s2.2.3, 4th para: s/Finally, we = note/Finally, note
s2.2.3, 5th para: s/As the amount of = reordering that may be present is hard to predict the window/As the = amount of reordering that may be present is hard to predict, the = window

Fixed.


2.2.3, 5th = para: I am all about not littering I-Ds with 2119-language, but here it = looks like you are burying the MUST in the parenthetical. BTW - I think = the sentence stands on its own without the "i.e.=E2=80=9D and it could = safely be deleted. Would this rewording work:

Gaps in the sequence numbers will not work for this = document,
therefore ESP sequence number stream MUST = increase monotonically
by 1 for each subsequent = packet.

Fixed


s2.2.3, = penultimate para: s/b/c/because

Fixed

s2.2.3, last para: Should the = I-D state what happens if the implementation does send initial fragments = of an inner packet using one SA and subsequent fragments in a different = SA. I.e., motivate the SHOULD NOT.

s2.2.3, last para: implementation here refers to sender right = so maybe: senders SHOULD NOT

Simplified to "senders MUST NOT"... :)

s2.2.3.1: Implementations here refers to senders so maybe:
s/An implementation/Senders
s/Implementation = implementing/Senders implementing ;)

Fixed

s2.2.4: s/In = order to support/To support

Fixed

s2.2.5, 1st para:
s/(by design!)/(by design)    ;)
= s/although an implementation/although a sender
s/An = implementation SHOULD/A sender SHOULD

Fixed

s2.2.5, 2nd para:
s/an implementation/a sender
= s/([RFC3168])/[RFC3168]

Fixed

s2.2.6, 1st para: = s/([RFC0791])/[RFC0791]

Fixed, and update other single refs to not use = parens.

s2.2.6, 2nd para: 2119 the should?: s/should = be/SHOULD be.  Is there a reason you would want to handle the = errors differently? If not then would the following also be true (i.e., = replace "should be" with "are":

Any errors (e.g., ICMP = errors arriving back at the tunnel ingress due
to tunnel = traffic) are handled the same as with non IP-TFS
IPsec = tunnels.

Fixed

s2.2.7, 1st para: s/am = implementation/a sender

Fixed


s2.2.7, 2nd = para: s/([RFC4301])/[RFC4301]

Fixed

s2.3: Does this work?

OLD:

It is not = the intention of this specification to allow
for mixed = use of an AGGFRAG_PAYLOAD enabled SA.

NEW:
This document does not specify mixed use of = an
AGGFRAG_PAYLOAD enabled SA.

Fixed

s2.4.1, 1st para: s/In the = non-congestion controlled mode IP_TFS /In the non-congestion controlled = mode, IP-TFS

Fixed

s2.4.1, 2nd para:
Should the should be SHOULD?
s/In this case = packet/In this case, packet
There is a reference to a = user. Is it really a user?
I think it's a should (non-normative), as this is = guidance on the right way to deploy IPTFS, but not how to implement = it.

s2.4.2, 2nd para:
s/the = ingress sends/the ingress side sends
Maybe just swap this = around?

OLD:

= An example of an implementation of the [RFC5348] algorithm which
matches the requirements of IP-TFS (i.e., designed for = fixed-size
packet and send rate varied based on = congestion) is documented in
[RFC4342].

NEW:

[RFC4342] provides an = example of the [RFC5348] algorithm which
matches the = requirements of IP-TFS (i.e., designed for fixed-size
= packet and send rate varied based on congestion.

Fixed.

s2.4.2, 3rd = para: s/In particular these/In particular, these

Fixed

s2.4.2, 4th para:
Should the must be MUST?
s/The lack of = receiving this information/Not receiving this information

Yes, = and fixed.

s2.4.2, 4th and 5th paras: s/it=E2=80=99s/its

Fixed

s2.4.2, 6th para: Does this = work?

OLD:

= When an implementation is choosing a congestion control algorithm (or
a selection of algorithms) one should remember that IP-TFS = is not
providing for reliable delivery of IP traffic, and = so per packet ACKs
are not required and are not = provided.

NEW:

= When choosing a congestion control algorithm (or
a = selection of algorithms) note that IP-TFS is not
= providing for reliable delivery of IP traffic, and so per packet ACKs
are not required and are not provided.

Fixed

s2.4.2, last para: = s/It=E2=80=99s/It is

Fixed

s3, 1st para:
= s/and also be able to approximate/and also to approximate
= s/([RFC5348])/[RFC5348]
s/In order to obtain these values = the/
  In order to obtain these values, the
s/Thus in order, to support/Thus, to

Fixed

s/is used to = convey/conveys

This is a style one I think that I'd like to leave = be, I think it better highlights that one needs to send these empty = payloads in this case.

s3, 1st and 3rd para: = s/it=E2=80=99s/its

Fixed.


s3, 3rd para: = Nits complained about this so I am assuming it=E2=80=99s MUST NOT here - = s/MUST not/MUST NOT

Fixed


s3.1, 1st = para: s/egress endpoint/egress (receiving) side

Fixed

s3.1, last para: s/For this = reason ECN/For this reason, ECN/
Fixed

s4: s/should be able to be specified/should be specified

Fixed

s4.1: s/For non-congestion = controlled mode the/For non-congestion controlled mode, the

Fixed

s4.1: Does this work:

OLD:

For = congestion controlled mode one can configure the
= bandwidth or have no configuration and let congestion
= control discover the maximum bandwidth available.

NEW:

For congestion controlled = mode, the bandwidth can be
configured or the congestion = controller discovers
the maximum bandwidth available.

Changed= to:

"For congestion controlled = mode, the bandwidth can be configured or the congestion control = algorithm discovers and uses the maximum bandwidth = available."


s5.1, 2nd = para: s/is used to enable use of/enables the

Fixed

s5.1, 3rd para:
s/To request = using the/To request use of the
s/then response/then the = response

Fixed

s5.1, penultimate para: = Should the should not be SHOULD NOT?

Fixed

s6.1: s/8 bit/8-bit
s6.1: s/specification/document

Fixed

s6.1.1: s/"DataBlocks=E2=80=9D = data/=E2=80=9CDataBlocks" ?

I'm = going to leave this as the ``"DataBlocks" data'' as it is referring to = that area of the packet data. DataBlocks may be spread across multiple = packets or there may be multiple DataBlocks in a single packet.

s6.1.1: s/16 bit/16-bit
s6.1.2: s/7 = bit/7-bit
s6.1.2: s/1 bit/1-bit
s6.1.2 x3: = s/32 bit/32-bit
s6.1.2: s/22 bit/22-bit
s6.1.2= x2: s/21 bit/21-bit
s6.1.3: s/4 bit/4-bit
s6.1.3.1/s6.1.3.2/s6.1.3.3: s/4 bit/4-bit
s6.1.3.1/s6.1.3.2: s/16 bit/16-bit
s6.1.3.3: = s/extends/Extends

Fixed

s6.1.4: s/As discussed in = Section 5.1 a/As discussed in Section 5.1, a

Fixed

s6.1.4, D bullet (make it = match C): s/Don't Fragment bit, if/Don't Fragment bit.  If

Fixed

s7: I may have missed this in = earlier discussions but why is the registration policy Standards Action? = I thought that most of the registries were trending more towards Expert = Review.

No particular reason other than it was the = conservative choice. :)

s8, 1st para: s/Traffic Flow = Confidentiality/TFC

Fixed

s8:

You warned in s1 about using a non-constant send-rate, but = shouldn=E2=80=99t that be echoed here?

As = mentioned previously it's not necessarily less secure to use a = non-constant send rate (research being done by others here), we are only = claiming use of constant send rate is more secure.

Likewise maybe repeat the ECN covert channel statement.

Repeated.


s9.2: r/[draft-iab-wire-image]/[RFC8546]

Fixed.

Appendix B: YMMV here but = since this is an Appendix and you=E2=80=99re repeating the current = practice s/SHOULD/should

Fixed.

Thanks again = for the very thorough review!

Thanks,
Chris.


Cheers,
spt

On Jan 24, 2021, at = 20:55, Tero Kivinen <kivinen@iki.fi> wrote:

This= is the start of 3 week WGLC on the document, ending 2021-02-15.
Please submit your comments to the list, also send a note if = you have
reviewed the document, so we can see how many = people are interested in
getting this out.
-- =
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_D248BA1D-0CE5-4B04-B339-4240B64C04A6-- --Apple-Mail=_9C170F65-9058-4779-A085-5AC4F48B9092 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAhxwQACgkQLh2DDte4 MCW4jQ/+LfSTkB1gRbCCcn5pnwDqi/k353bifMgCGLU0a69mjPU9sMfRgm8aA6Ek AjhfUPeWXr+oG9sdN2fqP4r8n/H2rgchOzFm5hR9f0vptuXHjVPJn3mO3+2soKsj dAcUEgJVeMh3UEg5NpU8XaIlHg8C4bERLL29NmXYXJDvomEXcBF8dY4OiYffl3aP 8eRw37DhqYjZtaUIwJUc/HZtTVX7I+33RpTeM3Hmz8saPcTLV6cdVLLecB8tNNit I6TLRMEbN/3AkXGxSeMKv8nBbzhEiUo4UhVA4h/vAv25qWzDVP69aSDjfVscZeCH 96N7zdYh//8E03IzWenu6kEl689OivqlE8TKyduHCdynx3ZFrVZBKDDU9oeYfx7W RG9ya2+ZnYxy1AGIP5WRSdsKXITM9m6QymHCRv7IJzO+MxjDXnwTQmzBrPbrvzxZ JawzXLDwGCnNvnC9yi0uA8LVhfHv2VK7pRG584cfHMk2uXvdGwP6sjQyAaGUUOfi z5U+rLfbLeBGa33hcEmeRqzVLNHJJBRYDojWmoBcYDP47bVo1JW+XC/g6aS8JgPt CwOH+lucBC3QNbuPv9qmObNTE4rK+tKl13GzaVe+ie2aR9Jw1NnLaOVr9+wFPjSs v+obqmirP3ok7Isuui4t2olrCgEDvWSeu7kqtV7V/EjcjxpC0sw= =cpSN -----END PGP SIGNATURE----- --Apple-Mail=_9C170F65-9058-4779-A085-5AC4F48B9092-- From nobody Mon Feb 8 23:57:16 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144843A121B for ; Mon, 8 Feb 2021 23:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 T60yJovEuv0c for ; Mon, 8 Feb 2021 23:57:12 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E08F03A121A for ; Mon, 8 Feb 2021 23:57:11 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 18E4A61669; Tue, 9 Feb 2021 07:57:11 +0000 (UTC) From: Christian Hopps Message-Id: <9E9A8E75-B269-4CFC-904B-272F3E1B59A4@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F6747C74-0A06-46F6-96C0-13C7ADA14617"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 9 Feb 2021 02:57:09 -0500 In-Reply-To: <018901d6fe0f$b875a2d0$2960e870$@gmail.com> Cc: Christian Hopps , Tero Kivinen , ipsec@ietf.org To: Valery Smyslov References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 07:57:14 -0000 --Apple-Mail=_F6747C74-0A06-46F6-96C0-13C7ADA14617 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 8, 2021, at 6:44 AM, Valery Smyslov = wrote: >=20 > Hi, >=20 > I think that in its current form the draft is too focused on a single = application for > the Aggregation and Fragmentation mode - IP-TFS. =46rom architectural > point of view I'd like to see the draft first defining the mechanism = itself > and then describing possible applications for it, focusing on IP-TFS > as the primary application. >=20 > We discussed this with Christian off the list in length and came to > a good compromise regarding naming of new entities defined in the = draft. > After re-reading the draft I still think that its structure of the = document should be > changed to better decouple mechanism from its applications. Hi Valery, Thanks for your continued reviews and suggestions. I agree with what Lou with regards to it going too far to = recast/redirect this work any further. I did do a round of changes based = on our agreement to help with future uses, and while it's nice that this = work could lead to these uses, those should be documented in another = document at this point. The focus of this work has and should continue = to be traffic flow security. I've incorporated your other suggestions from below. > 5. Section 2.1: >=20 > This is accomplished using a new Encapsulating Security Payload = (ESP, > [RFC4303]) type which is identified by the number AGGFRAG_PAYLOAD > (Section 6.1). >=20 > RFC 4303 doesn't define what is "Encapsulating Security Payload type = ". > You should clarify this in more detail and also mention that > the AGGFRAG_PAYLOAD number must be in the ESP "Next Header" field. s/type which is identified by the number/Next Header field value/ > 7. Section 2.2.1: >=20 > s/ Figure 2: Layout of IP-TFS data block/ Figure 2: Layout of Data = Block Updated. > 8. Section 2.2.2: >=20 > Only > when there is no data to encapsulated is end padding required, and > then an explicit "Pad Data Block" would be used to identify the > padding. >=20 > Nit: isn't better: >=20 > s/no data to encapsulated/no data to encapsulate Fixed > 9. Section 2.2.3: >=20 > When using the AGGFRAG_PAYLOAD in conjunction with replay detection, > the window size for both MAY be reduced to share the smaller of the > two window sizes. This is b/c packets outside of the smaller window > but inside the larger would still be dropped by the mechanism with > the smaller window size. >=20 > I wonder why MAY is used here. It should be MUST instead. > As you explained there is no point for the sizes to be different. They remain different mechanisms and the user may wish to have them = treated differently (e.g., logging replayed packets). > And please s/b\/c/because Fixed. > 10. Section 2.2.3: >=20 > Finally, as sequence numbers are reset when switching SAs (e.g., = when > re-keying a child SA), an implementation SHOULD NOT send initial > fragments of an inner packet using one SA and subsequent fragments = in > a different SA. >=20 > Two issues here - first why SHOULD NOT and not MUST NOT? > In general you cannot reliably reassemble packet if it is fragmented = over > several SAs, so it will be dropped. Why do you allow this? Changed to MUST NOT. > Then, IPsec architecture allows several parallel ESP SAs > to co-exist with the intention that kernel may use any of these SAs to = send packets > (e.g. for improving performance, see = draft-pwouters-multi-sa-performance). > I think you should mention that in this case a care must be taken not = to > fragment outgoing packets over several parallel SAs. I.e. if a packet = get fragmented, > all its fragments must be sent over single ESP SA. Covered by the switch to MUST NOT. > 11. Section 2.2.4: >=20 > IKEv2 always creates ESP SAs in pairs, so you don't need to send empty = AGGFRAG_PAYLOAD payloads > over non-AGGFRAG enabled SAs. I understand your intention to use this = mode in non-IKEv2 > environments, but I think that in case of IPsec you don't need to send > AGGFRAG_PAYLOAD payload over non- AGGFRAG enabled SAs. SAs are a concept that extend beyond IKEv2 so I think that the text is = OK here. > I think some text should be added that this section is only applicable > for non-IKEv2 use case. Add: "Currently this situation is only applicable in non-IKEv2 use = cases." > 12. Section 2.3: >=20 > Empty AGGFRAG_PAYLOAD payloads (Section 2.2.4) are used to > transmit congestion control information on non-IP-TFS enabled SAs, = so > intermixing is allowed in this specific case. >=20 > As I said before it is not needed in case of IKEv2, so I'd rather to > stress that this is only allowed if AGGFREAG SAs are not being created = in pairs > (non-IKEv2 use case). Covered with above change. > 13. Section 2.3: >=20 > While it's possible to > envision making the algorithm work in the presence of sequence = number > skips in the AGGFRAG_PAYLOAD payload stream, the added complexity is > not deemed worthwhile. >=20 > I have trouble understanding applicability of this text to the section > describing Exclusive SA Use. Shouldn't it be in 2..2.3? It's just referring to what happens (sequence number skips) if one = intermixes which we are disallowing. > 14. Section 2.4.2: >=20 > This section is concerned with IP-TFS use of AGGFREG mode. > First, I think it must be mentioned in the text. > Then, the text lacks discussion on how to deal with congestion when = ESP over TCP is used (RFC 8229). >> =46rom my understanding it is TCP that will take care of congestion = in this case. > If both mechanisms are in use then I suspect that it may affect = performance > (like TCP in TCP), because in this case congestion information (RTT = etc.) > will be highly inaccurate. >=20 > More general note - using ESP over TCP may also add some other = implications > on using AGGFRAG (e.g. header values mapping, ECN, fixed packet size = etc.), > I think it's worth to add some text. Is IP-TFS use of AGGFRAG ever = make sense > when ESP is sent over TCP? I'll add this to the previous (non-congestion control mode) section. "Non-congestion control mode is also appropriate if ESP over TCP is in use [RFC8229]." >=20 > 15. Section 3: >=20 > In order to obtain these values the receiver sends > congestion control information on it's SA back to the sender. >=20 > s/it's/its Fixed. >=20 > 16. Section 5.1: >=20 > The USE_AGGFRAG notification MUST NOT be sent, and MUST be ignored, > during a CREATE_CHILD_SA rekeying exchange as it is not allowed to > change use of the AGGFRAG_PAYLOAD payload type during rekeying. A > new child SA due to re-keying inherits the use of AGGFRAG_PAYLOAD > from the re-keyed child SA. >=20 > In IKEv2 re-keying of Child SA is semantically almost equal to = creating a new Child SA > with the only exception that the SA which is being rekeyed is = indicated. > However, all the properties of newly created substitute SA are = negotiated as if it is not a rekey > (transforms, mode of operation). I don't see any reason why to break = this with AGGFRAG. > I prefer to re-negotiate AGGFRAG in this case just to follow > current IKEv2 practice. This will simplify implementations. > And I see no problem if after AGGFRAG SA is replaced with normal one > and visa versa. Am I missing something? I think you have a good point on simplicity. I've removed that paragraph = and removed "non-rekeying" in the text in the previous paragraph. > 17. Section 5.1: >=20 > The USE_AGGFRAG notification contains a 1 octet payload of flags = that > specify any requirements from the sender of the message. If any > requirement flags are not understood or cannot be supported by the > receiver then the receiver should not enable use of AGGFRAG_PAYLOAD > payload type (either by not responding with the USE_AGGFRAG > notification, or in the case of the initiator, by deleting the child > SA if the now established non-AGGFRAG_PAYLOAD using SA is > unacceptable). >=20 > It is not clear for me from this text whether these flags are = negotiated > or independently announced by peers. In other words - are they > independent in both direction or they must be the same? They are not negotiated as they are "requirements from the sender of the = message" and the receiver either understands and accepts them or doesn't = use AGGFRAG_PAYLOADs. I've changed "that specify any requirements from the sender" to "that specify requirements from the sender" perhaps that makes it more clear? > 18. Section 5.1: >=20 > Add some text that USE_AGGFRAG cannot be combined with = USE_TRANSPORT_MODE. >=20 > General note: I think some words should be added somewhere (Section = 2?) > that AGGFRAG implies encapsulation whole IP packets, so it cannot be > used for Transport mode ESP SA. I'll add this to 5.1: "As the use of AGGFRAG_PAYLOAD payloads is currently only defined for non-transport mode tunnels, the USE_AGGFRAG notification MUST NOT be combined with USE_TRANSPORT notification." > 19. Section 6.1: >=20 > An IP-TFS payload is identified by the ESP payload type > AGGFRAG_PAYLOAD which has the value 0x5. >=20 > Where this value has come from? Isn't it registered with IANA? > We had a long discussion about this in the WG, current > text looks like the value was squatted... The discussion lead to the understanding that the ESP next-header field = is not actually required to be IP protocol number, and people don't = generically use it that way so we are free to choose whatever non-used = value we would like. We chose 0x5 simply b/c that *was* an IP protocol = number that is allocated but will not used; however, this wasn't = required -- it's just trying to be smart about picking a value. :) I don't think we need to go into this in the document though -- it's = enough that its a valid value to use. > Another issue: what is "ESP payload type"? > RFC 4303 doesn't have this term. You should first > introduce it. I've changed payload type to "ESP Next Header value" in the document. > 20. Section 6.1.4: >=20 > 0: > 6 bits - reserved, MUST be zero on send, unless defined by later > specifications. >=20 > Add a sentence that these bits MUST be ignored on receipt. They must not be ignored. If they are set and they and not understood = then AGGFRAG mode will not be enabled as indicated in section 5.1 > 21. IANA Considerations. >=20 > I wonder why newly defined registry "AGGFRAG_PAYLOAD Sub-Type Registry = " > has an allocation policy "Standards Action". =46rom my understanding > this is too restrictive. Why "RFC Required" or "Expert Review" is = insufficient? > Out of 256 possible values only 2 are defined and I don't expect > a lot of allocation requests for this registry, so why do you need = such > a restrictive policy? You're the second person to suggest this so I've changed it to "Expert = Review". :) >=20 > Another issue - I would have mark value 0 as "Reserved" (just in case > a special value is needed in future), but it's a matter of taste. 0 is a very useful value b/c a typical non-congestion control header can = simply be zero'd efficiently. I've definitely used this fact in our = implementation. >=20 > 22. Security Considerations. >=20 > Add a text that correct functionality of the AGGFRAG mode > requires restoring packets order on the receiver. Since this > is done by utilizing ESP Sequence Number field, the ESP > header must be authenticated, and thus the ESP SA MUST > be created with authentication other than NONE > or with AEAD cipher. I think this falls under the non-IPTFS use case. I'd like to leave it = out as it would be confusing. > Probably it's worth to mention this somewhere in Section 2.2.3... >=20 > 23. Appendix C.1.1: >=20 > The overhead of IP-TFS is 40 bytes per outer packet. >=20 > I failed to understand where 40 bytes came from. =46rom my = understanding the overhead > of AGGFRAG is either 4 bytes or 24 bytes depending on mode used = (comparing with usual ESP). > Am I missing something? See final comment below.. > s/bytes/octets Fixed. >=20 > 24. Appendix C.1.2: >=20 > The overhead per inner packet for constant-send-rate padded ESP > (i.e., traditional IPsec TFC) is 36 octets plus any padding, unless > fragmentation is required. >=20 > Again, I failed to understand where 36 octets came from. > In general ESP overhead depends on transforms in use (which > influence IV and ICV sizes), so you should mention under > which condition this overhead was computed. These were done a couple years ago when we first published this, and for = some reason I had the ESP overhead (shared by both IPTFS and regular = IPsec) plugged into the table formulas as 16. I'll rerun the tables using AES-GCM-256 values. New value IPsec/ESP = overhead would be 54 (20 (IP) + 8+2 (ESPH/F) + 8 (IV) + (16 ICV)) The results will still highlight the same things, but thanks for = catching this! :) Thanks, Chris. >=20 > Regards, > Valery. >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_F6747C74-0A06-46F6-96C0-13C7ADA14617 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAiQFUACgkQLh2DDte4 MCWYog//YYhwpv7j3IW+MHmV278u4wrt+oQCI7oaah21VLKn0UselsWf03egBWy1 RXzWs6dIrqqKs7unyCgeMRnRuyxekyAIZ9X0IzTVs5Jl/cXOsIAogKcQDGU9jUPA X34OUPpFurfc3aiAYRJjyz340io2ABjZy1DN4V4KD62HSuXtUag8XLNWWQB0hi5Q zxLgLZY2wyZecCPh2yH6qMQWlmOTLhSWRaX9s64tO07WKKD4bd1Rjn+IQP5JojAE EpHSkuvgPQcYTGCecPwuAcBwfdowWonBenFN7qfawlMuJE/vTr0CT0jwJyDXyNkd dbWMs3nDdLI/v72I39pJMfOvVjuoNSQ3MjDWeyZ/5IbVUMTnqLsKDuVaRDqu+wDL 2A3zG0IvRw/88DeT26PBwRGEqjZYHL504jaGzzM4mGbdR8gxvwig3NmHG736S8yb vuxPwP8A65na2O4WDKiWC5mj3ZSR1r5AI37qGYB9maXU/wN0Jhyor7vd+5IdJQHx tH8nW6heoVJybsDJf5ftQ9YmMVA+gmFZfcQSVRTO3M85ZdxYmdYguNFUYVBr5Tvn kSlgsl4KhQ+jeECOtHCyI0uPLeoSx+8m56+sjpBYTPXAn8zRuhajX/LP9UP9fzpz CsGEYJ0qJeRoK9cryxCHXGKSySV2or6WRplnhA0n5LvUhhfgm5Q= =kFu+ -----END PGP SIGNATURE----- --Apple-Mail=_F6747C74-0A06-46F6-96C0-13C7ADA14617-- From nobody Wed Feb 10 00:36:55 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E55E3A0F01 for ; Wed, 10 Feb 2021 00:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4_ks-wNwp2DR for ; Wed, 10 Feb 2021 00:36:43 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3D03A0E8D for ; Wed, 10 Feb 2021 00:36:41 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id f2so1697596ljp.11 for ; Wed, 10 Feb 2021 00:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=LbcE7sbAxB9qGR8IvTydNHLWmPS8vpxBFKep9IXNRDY=; b=uMBiP3QrxBK8yo8BERRuNW3241pCqI9zfwzI9/u4fYEeD8igaMWOhzV32OMsvjZjC4 TJBtVgy4fejczAeiIG4eZXV8WdZKwLRQuYS+xhHpoy7IswXGD1RVSudXAHQVv1UuwYaK /nvgouM7kl4W1SgkkTaLzVRGygNvyu3snXLiC8334e2TUsuVOUQHRnCH9iJmd1lw79j/ xr4kILLxY0iBlEa19ArO/m9eKWp4GbOrDKdRCjhvokG19IygSTOCiraSvues4bDvChQ9 xpNxDC3H5LJdzNAwwIrLPEc27IsMptxqrrRK/x67NDZBsWnhbSv26QUwvvBdOS+Uostq NJNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=LbcE7sbAxB9qGR8IvTydNHLWmPS8vpxBFKep9IXNRDY=; b=jALLHsjJO1f1fwdt5BkzX7oDRMTfi9cpRadA+ZS8LwpzvPeKKikRz0T3J/dUcg0pyx yqhkci1lZhXv/UbKTsbH6T2bDfjIk7IPLSKmy8ILKa8WcP2S5fU6wy5cnxwluE0K6A4t fojnFimqaUXR5nkOPeAoJquxvmgwegw6UbjtmD1ADBZs+Di5udsFcRS6nqZxaId+3ChF cdsmjq3hj3I5YTDleXSKKM1p5Xy+vlBrY2edpTalPq8b4AGKTnomI3UYwQtKinOEEDr8 Vh6NJS19mXZqdE4bjB5A1kYVb2+PYRezHmOehw4JisrJHOhEYdRDcfo8AK0VdNcTq8Qc UZCQ== X-Gm-Message-State: AOAM532FGXXhBVRSv2qg/xFiUwPWW9/O3WOIO1K1g40dOslIAp3awsej 6eK0mWTA71dzUbMgNVftwVg= X-Google-Smtp-Source: ABdhPJwHtgwdB1z5vesAsICk4LI7rNaV0Mj8veWzJUwi4TaYXa+Df/GmGCqr70N6QbbmOPi0uM2bdA== X-Received: by 2002:a05:651c:1045:: with SMTP id x5mr1260260ljm.328.1612946199266; Wed, 10 Feb 2021 00:36:39 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id v18sm323775ljj.55.2021.02.10.00.36.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Feb 2021 00:36:38 -0800 (PST) From: "Valery Smyslov" To: "'Christian Hopps'" Cc: "'Tero Kivinen'" , References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> <9E9A8E75-B269-4CFC-904B-272F3E1B59A4@chopps.org> In-Reply-To: <9E9A8E75-B269-4CFC-904B-272F3E1B59A4@chopps.org> Date: Wed, 10 Feb 2021 11:36:40 +0300 Message-ID: <034d01d6ff87$db060140$911203c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEwzZDjYo4hMYjGJNs7372CsQemJgHa0ryfAWDZU56rg4foMA== Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 08:36:53 -0000 Hi Christian, > > On Feb 8, 2021, at 6:44 AM, Valery Smyslov wrote: > > > > Hi, > > > > I think that in its current form the draft is too focused on a single application for > > the Aggregation and Fragmentation mode - IP-TFS. From architectural > > point of view I'd like to see the draft first defining the mechanism itself > > and then describing possible applications for it, focusing on IP-TFS > > as the primary application. > > > > We discussed this with Christian off the list in length and came to > > a good compromise regarding naming of new entities defined in the draft. > > After re-reading the draft I still think that its structure of the document should be > > changed to better decouple mechanism from its applications. > > Hi Valery, > > Thanks for your continued reviews and suggestions. No problem :-) > I agree with what Lou with regards to it going too far to recast/redirect this work any further. I did do a round > of changes based on our agreement to help with future uses, and while it's nice that this work could lead to > these uses, those should be documented in another document at this point. The focus of this work has and > should continue to be traffic flow security. Here we disagree. My point is that you define a very good mechanism that can be used not only for IP-TFS, but for other purposes too. I fully understand that IP-TFS was your primary focus and I agree the document to remain focused on it. However, if the document is kept in its current form any attempt to use it for other applications will look as an improper use of mechanism, because the way document is organized highly ties the mechanism and its application. E.g. if one wants to use it for reducing ESP overhead for small packets (with no intention to hide traffic flow), and references your document, then it'll look like he/she uses mechanism explicitly defined for IP-TFS for some other purpose it wasn't designed for. Note, that I don't suggest recast/redirect this work from IP-TFS, I only want to reorganize the document so that the mechanism itself is defined independently from its primary application (IP-TFS). In other words: - make name and abstract more neutral regarding IP-TFS (instead "we wanted IP-TFS and we defined a special mechanism for it" use "we defined a new mechanism and we described how it can be used for IP-TFS"). - mention at least two possible applications in Introduction (with focus on IP-TFS) - reorganize the document so that first the mechanism is defined with as a generic one and then it's use for IP-TFS is described in details Note, that all these are editorial changes, but they are essential, so that if future documents defining non-IP-TFS use case reference this document, it'll be clear that they reference the multi-purpose mechanism and not the mechanism that was explicitly designed for IP-TFS. > I've incorporated your other suggestions from below. Please see my comments (I removed parts where we are in concert). > > 9. Section 2.2.3: > > > > When using the AGGFRAG_PAYLOAD in conjunction with replay detection, > > the window size for both MAY be reduced to share the smaller of the > > two window sizes. This is b/c packets outside of the smaller window > > but inside the larger would still be dropped by the mechanism with > > the smaller window size. > > > > I wonder why MAY is used here. It should be MUST instead. > > As you explained there is no point for the sizes to be different. > > They remain different mechanisms and the user may wish to have them treated differently (e.g., logging > replayed packets). My question was regarding "MAY" vs "MUST". Even if these are different mechanisms, what is the reason for having different window sizes if both mechanisms are employed? I may yet understand that reassembly window may be shorter then replay window (you will just have a penalty of dropping too old packets even when replay protection allows them in), but what may be the reason for having reassembly window longer than replay window? If you have some gaps at the far left end of reassembly window waiting for missing packets, you'll never receive them if replay window is shorter - they will fall outside it. So, it's just a waste of resources. > > 10. Section 2.2.3: > > > > Finally, as sequence numbers are reset when switching SAs (e.g., when > > re-keying a child SA), an implementation SHOULD NOT send initial > > fragments of an inner packet using one SA and subsequent fragments in > > a different SA. > > > > Two issues here - first why SHOULD NOT and not MUST NOT? > > In general you cannot reliably reassemble packet if it is fragmented over > > several SAs, so it will be dropped. Why do you allow this? > > Changed to MUST NOT. > > > Then, IPsec architecture allows several parallel ESP SAs > > to co-exist with the intention that kernel may use any of these SAs to send packets > > (e.g. for improving performance, see draft-pwouters-multi-sa-performance). > > I think you should mention that in this case a care must be taken not to > > fragment outgoing packets over several parallel SAs. I.e. if a packet get fragmented, > > all its fragments must be sent over single ESP SA. > > Covered by the switch to MUST NOT. Well, this text is explicitly about "sequence numbers are reset when switching SAs". I think it's better to generalize it and say that "packet fragmentation MUST not take place over different SAs". This will cover both cases - rekeying and parallel SAs. > > 13. Section 2.3: > > > > While it's possible to > > envision making the algorithm work in the presence of sequence number > > skips in the AGGFRAG_PAYLOAD payload stream, the added complexity is > > not deemed worthwhile. > > > > I have trouble understanding applicability of this text to the section > > describing Exclusive SA Use. Shouldn't it be in 2..2.3? > > It's just referring to what happens (sequence number skips) if one intermixes which we are disallowing. Oh, I see. But I think that it's better to remove this sentence, as it only adds confusion and is not important for the mechanism itself. > > 17. Section 5.1: > > > > The USE_AGGFRAG notification contains a 1 octet payload of flags that > > specify any requirements from the sender of the message. If any > > requirement flags are not understood or cannot be supported by the > > receiver then the receiver should not enable use of AGGFRAG_PAYLOAD > > payload type (either by not responding with the USE_AGGFRAG > > notification, or in the case of the initiator, by deleting the child > > SA if the now established non-AGGFRAG_PAYLOAD using SA is > > unacceptable). > > > > It is not clear for me from this text whether these flags are negotiated > > or independently announced by peers. In other words - are they > > independent in both direction or they must be the same? > > They are not negotiated as they are "requirements from the sender of the message" and the receiver either > understands and accepts them or doesn't use AGGFRAG_PAYLOADs. > > I've changed > "that specify any requirements from the sender" > > to > > "that specify requirements from the sender" > > perhaps that makes it more clear? I think even better would be "that specify requirements from the sender of this notification". > > 19. Section 6.1: > > > > An IP-TFS payload is identified by the ESP payload type > > AGGFRAG_PAYLOAD which has the value 0x5. > > > > Where this value has come from? Isn't it registered with IANA? > > We had a long discussion about this in the WG, current > > text looks like the value was squatted... > > The discussion lead to the understanding that the ESP next-header field is not actually required to be IP > protocol number, and people don't generically use it that way so we are free to choose whatever non-used > value we would like. We chose 0x5 simply b/c that *was* an IP protocol number that is allocated but will not > used; however, this wasn't required -- it's just trying to be smart about picking a value. :) > > I don't think we need to go into this in the document though -- it's enough that its a valid value to use. I still think that some words about this must be added. Otherwise it looks like the value 5 has come to you as a miracle and you cannot explain why it is exactly 5 (and not any other value). > > 20. Section 6.1.4: > > > > 0: > > 6 bits - reserved, MUST be zero on send, unless defined by later > > specifications. > > > > Add a sentence that these bits MUST be ignored on receipt. > > They must not be ignored. If they are set and they and not understood then AGGFRAG mode will not be > enabled as indicated in section 5.1 Section 5.1 is about USE_AGGFRAG notification, here we talk about Reserved bits AGGFRAG_PAYLOAD. How they are related? As implementer I have a question - what should I do if these bits are non-zero on receipt? The draft is silent about this. > > 21. IANA Considerations. > > > > I wonder why newly defined registry "AGGFRAG_PAYLOAD Sub-Type Registry " > > has an allocation policy "Standards Action". From my understanding > > this is too restrictive. Why "RFC Required" or "Expert Review" is insufficient? > > Out of 256 possible values only 2 are defined and I don't expect > > a lot of allocation requests for this registry, so why do you need such > > a restrictive policy? > > You're the second person to suggest this so I've changed it to "Expert Review". :) Thanks :-) > > Another issue - I would have mark value 0 as "Reserved" (just in case > > a special value is needed in future), but it's a matter of taste. > > 0 is a very useful value b/c a typical non-congestion control header can simply be zero'd efficiently. I've > definitely used this fact in our implementation. As I said, it's a matter of taste - I prefer to have at least one value in registry that can never appear on the wire under current specification. This can help protocol extensibility (and it happened in IPsec a couple of times). But that's up to you. > > 22. Security Considerations. > > > > Add a text that correct functionality of the AGGFRAG mode > > requires restoring packets order on the receiver. Since this > > is done by utilizing ESP Sequence Number field, the ESP > > header must be authenticated, and thus the ESP SA MUST > > be created with authentication other than NONE > > or with AEAD cipher. > > I think this falls under the non-IPTFS use case. I'd like to leave it out as it would be confusing. No, it's about any use case of this mechanism. ESP can be used without authentication (although it's strictly discouraged) and in this if AGGFRAG is employed (regardless of IP-TFS), then an attacker can re-order packets on his/her will, by playing with SN field, so your reassembly mechanism won't work. Regards, Valery. From nobody Wed Feb 10 07:02:48 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9642D3A0D7A for ; Wed, 10 Feb 2021 07:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 EHevNyklBpGf for ; Wed, 10 Feb 2021 07:02:36 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 276AB3A0DAD for ; Wed, 10 Feb 2021 07:02:36 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1DA9761669; Wed, 10 Feb 2021 15:02:35 +0000 (UTC) From: Christian Hopps Message-Id: <252DEFA7-AE92-4974-9ECE-2B8BD742FED2@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_8D7F6226-97C5-4693-90DD-53068FCAC994"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 10 Feb 2021 10:02:33 -0500 In-Reply-To: <034d01d6ff87$db060140$911203c0$@gmail.com> Cc: Christian Hopps , Tero Kivinen , ipsec@ietf.org To: Valery Smyslov References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> <9E9A8E75-B269-4CFC-904B-272F3E1B59A4@chopps.org> <034d01d6ff87$db060140$911203c0$@gmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 15:02:46 -0000 --Apple-Mail=_8D7F6226-97C5-4693-90DD-53068FCAC994 Content-Type: multipart/alternative; boundary="Apple-Mail=_5024E057-6D4F-42F2-AAC2-17CCE9C76CE9" --Apple-Mail=_5024E057-6D4F-42F2-AAC2-17CCE9C76CE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 10, 2021, at 3:36 AM, Valery Smyslov = wrote: >=20 > Hi Christian, >=20 >>> On Feb 8, 2021, at 6:44 AM, Valery Smyslov = wrote: >>>=20 >>> Hi, >>>=20 >>> I think that in its current form the draft is too focused on a = single application for >>> the Aggregation and Fragmentation mode - IP-TFS. =46rom = architectural >>> point of view I'd like to see the draft first defining the mechanism = itself >>> and then describing possible applications for it, focusing on IP-TFS >>> as the primary application. >>>=20 >>> We discussed this with Christian off the list in length and came to >>> a good compromise regarding naming of new entities defined in the = draft. >>> After re-reading the draft I still think that its structure of the = document should be >>> changed to better decouple mechanism from its applications. >>=20 >> Hi Valery, >>=20 >> Thanks for your continued reviews and suggestions. >=20 > No problem :-) >=20 >> I agree with what Lou with regards to it going too far to = recast/redirect this work any further. I did do a round >> of changes based on our agreement to help with future uses, and while = it's nice that this work could lead to >> these uses, those should be documented in another document at this = point. The focus of this work has and >> should continue to be traffic flow security. >=20 > Here we disagree. My point is that you define a very good mechanism > that can be used not only for IP-TFS, but for other purposes too. > I fully understand that IP-TFS was your primary focus and I agree > the document to remain focused on it. However, if the document > is kept in its current form any attempt to use it for other = applications > will look as an improper use of mechanism, because the way document > is organized highly ties the mechanism and its application. A compromise and to address your concern that other uses might look = improper I've changed the abstract to include this final sentence: "The mechanisms defined in this document are generic with the intent of = allowing for non-TFS uses, but such uses are outside the scope of this = document." The introduction to include this final paragraph: "The mechanisms defined in this document are generic with the intent of = allowing for non-TFS uses, but such uses are outside the scope of this = document." And the "Packets and Data Formats" top level section to start: "The packet and data formats defined below are generic with the intent = of allowing for non-IP-TFS uses, but such uses are outside the scope of = this document." I believe this addresses your concern about other uses looking improper. >> I've incorporated your other suggestions from below. >=20 > Please see my comments (I removed parts where we are in concert). >=20 >>> 9. Section 2.2.3: >>>=20 >>> When using the AGGFRAG_PAYLOAD in conjunction with replay = detection, >>> the window size for both MAY be reduced to share the smaller of the >>> two window sizes. This is b/c packets outside of the smaller = window >>> but inside the larger would still be dropped by the mechanism with >>> the smaller window size. >>>=20 >>> I wonder why MAY is used here. It should be MUST instead. >>> As you explained there is no point for the sizes to be different. >>=20 >> They remain different mechanisms and the user may wish to have them = treated differently (e.g., logging >> replayed packets). >=20 > My question was regarding "MAY" vs "MUST". Even if these are different > mechanisms, what is the reason for having different window sizes if = both mechanisms > are employed? I may yet understand that reassembly window may be = shorter > then replay window (you will just have a penalty of dropping too old = packets > even when replay protection allows them in), but what may be the = reason > for having reassembly window longer than replay window? If you have = some gaps > at the far left end of reassembly window waiting for missing packets, > you'll never receive them if replay window is shorter - they will fall > outside it. So, it's just a waste of resources. The implementation may wish to allow the user to have replayed packets = logged (one can have a very large replay window w/o consuming many = resources). >>> 10. Section 2.2.3: >>>=20 >>> Finally, as sequence numbers are reset when switching SAs (e.g., = when >>> re-keying a child SA), an implementation SHOULD NOT send initial >>> fragments of an inner packet using one SA and subsequent fragments = in >>> a different SA. >>>=20 >>> Two issues here - first why SHOULD NOT and not MUST NOT? >>> In general you cannot reliably reassemble packet if it is fragmented = over >>> several SAs, so it will be dropped. Why do you allow this? >>=20 >> Changed to MUST NOT. >>=20 >>> Then, IPsec architecture allows several parallel ESP SAs >>> to co-exist with the intention that kernel may use any of these SAs = to send packets >>> (e.g. for improving performance, see = draft-pwouters-multi-sa-performance). >>> I think you should mention that in this case a care must be taken = not to >>> fragment outgoing packets over several parallel SAs. I.e. if a = packet get fragmented, >>> all its fragments must be sent over single ESP SA. >>=20 >> Covered by the switch to MUST NOT. >=20 > Well, this text is explicitly about "sequence numbers are reset when = switching SAs". > I think it's better to generalize it and say that "packet = fragmentation MUST not take > place over different SAs". This will cover both cases - rekeying and = parallel SAs. It's explaining the restriction. This adds information/justification w/o = changing the actual requirement. I think that's a good thing not bad. >>> 13. Section 2.3: >>>=20 >>> While it's possible to >>> envision making the algorithm work in the presence of sequence = number >>> skips in the AGGFRAG_PAYLOAD payload stream, the added complexity = is >>> not deemed worthwhile. >>>=20 >>> I have trouble understanding applicability of this text to the = section >>> describing Exclusive SA Use. Shouldn't it be in 2..2.3? >>=20 >> It's just referring to what happens (sequence number skips) if one = intermixes which we are disallowing. >=20 > Oh, I see. But I think that it's better to remove this sentence, as it = only > adds confusion and is not important for the mechanism itself. This also represents removing the justification for the decision, but I = agree the text is a little hard to comprehend, so I will remove the last = 2 sentences. >=20 >>> 17. Section 5.1: >>>=20 >>> The USE_AGGFRAG notification contains a 1 octet payload of flags = that >>> specify any requirements from the sender of the message. If any >>> requirement flags are not understood or cannot be supported by the >>> receiver then the receiver should not enable use of AGGFRAG_PAYLOAD >>> payload type (either by not responding with the USE_AGGFRAG >>> notification, or in the case of the initiator, by deleting the = child >>> SA if the now established non-AGGFRAG_PAYLOAD using SA is >>> unacceptable). >>>=20 >>> It is not clear for me from this text whether these flags are = negotiated >>> or independently announced by peers. In other words - are they >>> independent in both direction or they must be the same? >>=20 >> They are not negotiated as they are "requirements from the sender of = the message" and the receiver either >> understands and accepts them or doesn't use AGGFRAG_PAYLOADs. >>=20 >> I've changed >> "that specify any requirements from the sender" >>=20 >> to >>=20 >> "that specify requirements from the sender" >>=20 >> perhaps that makes it more clear? >=20 > I think even better would be "that specify requirements from the = sender of this notification". OK, changed "of the message" to "of the notification". >=20 >>> 19. Section 6.1: >>>=20 >>> An IP-TFS payload is identified by the ESP payload type >>> AGGFRAG_PAYLOAD which has the value 0x5. >>>=20 >>> Where this value has come from? Isn't it registered with IANA? >>> We had a long discussion about this in the WG, current >>> text looks like the value was squatted... >>=20 >> The discussion lead to the understanding that the ESP next-header = field is not actually required to be IP >> protocol number, and people don't generically use it that way so we = are free to choose whatever non-used >> value we would like. We chose 0x5 simply b/c that *was* an IP = protocol number that is allocated but will not >> used; however, this wasn't required -- it's just trying to be smart = about picking a value. :) >>=20 >> I don't think we need to go into this in the document though -- it's = enough that its a valid value to use. >=20 > I still think that some words about this must be added. Otherwise it = looks like > the value 5 has come to you as a miracle and you cannot explain why it = is exactly 5 > (and not any other value). Ok well then I've added "The value 5 was chosen to not conflict with = other used values". What I don't want to do here, in the packet and data = format definition section, is get into some distracting explanation = about why this value isn't conflicting -- this does not help people = trying to implement the specification. >>> 20. Section 6.1.4: >>>=20 >>> 0: >>> 6 bits - reserved, MUST be zero on send, unless defined by later >>> specifications. >>>=20 >>> Add a sentence that these bits MUST be ignored on receipt. >>=20 >> They must not be ignored. If they are set and they and not understood = then AGGFRAG mode will not be >> enabled as indicated in section 5.1 >=20 > Section 5.1 is about USE_AGGFRAG notification, here we talk about > Reserved bits AGGFRAG_PAYLOAD. How they are related? >=20 > As implementer I have a question - what should I do if these bits > are non-zero on receipt? The draft is silent about this. I think maybe you mixed something up in your reading? Section 6.1.4 is: "6.1.4 = . = IKEv2 USE_AGGFRAG Notification Message" It is not about the AGGFRAG_PAYLOAD. >>> 22. Security Considerations. >>>=20 >>> Add a text that correct functionality of the AGGFRAG mode >>> requires restoring packets order on the receiver. Since this >>> is done by utilizing ESP Sequence Number field, the ESP >>> header must be authenticated, and thus the ESP SA MUST >>> be created with authentication other than NONE >>> or with AEAD cipher. >>=20 >> I think this falls under the non-IPTFS use case. I'd like to leave it = out as it would be confusing. >=20 > No, it's about any use case of this mechanism. > ESP can be used without authentication > (although it's strictly discouraged) and in this > if AGGFRAG is employed (regardless of IP-TFS), > then an attacker can re-order packets on his/her will, > by playing with SN field, so your reassembly mechanism won't work. You think I need to state that things are not secure if the user turns = off authentication? I would think that's covered already by: " Other than the additional security afforded by using this mechanism, IP-TFS utilizes the security protocols [RFC4303 = ] and [RFC7296 = ] and so their security considerations apply to IP-TFS as well. " Thanks, Chris. >=20 > Regards, > Valery. --Apple-Mail=_5024E057-6D4F-42F2-AAC2-17CCE9C76CE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Feb 10, 2021, at 3:36 AM, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

Hi Christian,

On= Feb 8, 2021, at 6:44 AM, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

Hi,

I think that in its current = form the draft is too focused on a single application for
the Aggregation and Fragmentation mode - IP-TFS. =46rom = architectural
point of view I'd like to see the draft = first defining the mechanism itself
and then describing = possible applications for it, focusing on IP-TFS
as the = primary application.

We discussed this with = Christian off the list in length and came to
a good = compromise regarding naming of new entities defined in the draft.
After re-reading the draft I still think that its structure = of the document should be
changed to better decouple = mechanism from its applications.

Hi Valery,

Thanks for your = continued reviews and suggestions.

No problem = :-)

I = agree with what Lou with regards to it going too far to recast/redirect = this work any further. I did do a round
of changes based = on our agreement to help with future uses, and while it's nice that this = work could lead to
these uses, those should be documented = in another document at this point. The focus of this work has and
should continue to be traffic flow security.

Here we disagree. My point is that you define a very good = mechanism
that can be = used not only for IP-TFS, but for other purposes too.
I fully = understand that IP-TFS was your primary focus and I agree
the document = to remain focused on it. However, if the document 
is kept in = its current form any attempt to use it for other applications
will look as = an improper use of mechanism, because the way document
is organized = highly ties the mechanism and its application.

A = compromise and to address your concern that other uses might look = improper I've changed the abstract to include this final = sentence:

"The mechanisms defined in this = document are generic with the intent of allowing for non-TFS uses, but = such uses are outside the scope of this document."

The introduction to include this = final paragraph:

"The mechanisms defined in this document are generic with the = intent of allowing for non-TFS uses, but such uses are outside the scope = of this document."

And the "Packets and Data Formats" top level section to = start:

"The packet and data formats defined below are generic with = the intent of allowing for non-IP-TFS uses, but such uses are outside = the scope of this document."

I believe this addresses your = concern about other uses looking improper.

I've = incorporated your other suggestions from below.

Please see my comments (I removed parts where we are in = concert).

9. Section 2.2.3:

 When using the AGGFRAG_PAYLOAD in = conjunction with replay detection,
 the window size = for both MAY be reduced to share the smaller of the
 two window sizes.  This is b/c packets outside of = the smaller window
 but inside the larger would still = be dropped by the mechanism with
 the smaller window = size.

I wonder why MAY is used here. It = should be MUST instead.
As you explained there is no point = for the sizes to be different.

They remain different mechanisms and the user may wish to = have them treated differently (e.g., logging
replayed = packets).

My question was regarding "MAY" vs "MUST". Even if these are = different
mechanisms, = what is the reason for having different window sizes if both = mechanisms
are employed? = I may yet understand that reassembly window may be shorter
then replay = window (you will just have a penalty of dropping too old = packets
even when = replay protection allows them in), but what may be the reason
for having = reassembly window longer than replay window? If you have some = gaps
at the far = left end of reassembly window waiting for missing packets,
you'll never = receive them if replay window is shorter - they will fall
outside it. = So, it's just a waste of resources.

The implementation may wish to allow the user = to have replayed packets logged (one can have a very large replay window = w/o consuming many resources).

10. Section 2.2.3:

 Finally, as sequence numbers are reset = when switching SAs (e.g., when
 re-keying a child = SA), an implementation SHOULD NOT send initial
 fragments of an inner packet using one SA and = subsequent fragments in
 a different SA.

Two issues here - first why SHOULD NOT and not = MUST NOT?
In general you cannot reliably reassemble packet = if it is fragmented over
several SAs, so it will be = dropped. Why do you allow this?

Changed to MUST NOT.

Then, IPsec architecture allows several = parallel ESP SAs
to co-exist with the intention that = kernel may use any of these SAs to send packets
(e.g. for = improving performance, see draft-pwouters-multi-sa-performance).
I think you should mention that in this case a care must be = taken not to
fragment outgoing packets over several = parallel SAs. I.e. if a packet get fragmented,
all its = fragments must be sent over single ESP SA.

Covered by the switch to MUST NOT.

Well, this text is explicitly about "sequence numbers are = reset when switching SAs".
I think it's better to generalize it and say that "packet = fragmentation MUST not take
place over different SAs". This will cover both cases - = rekeying and parallel SAs.

It's explaining the restriction. This adds = information/justification w/o changing the actual requirement. I think = that's a good thing not bad. 

13. Section 2.3:

 While = it's possible to
 envision making the algorithm work = in the presence of sequence number
 skips in the = AGGFRAG_PAYLOAD payload stream, the added complexity is
 not deemed worthwhile.

I = have trouble understanding applicability of this text to the section
describing Exclusive SA Use. Shouldn't it be in 2..2.3?

It's just referring to what = happens (sequence number skips) if one intermixes which we are = disallowing.

Oh, I see. But I think that it's better to remove this = sentence, as it only
adds confusion and is not important for the mechanism = itself.

This = also represents removing the justification for the decision, but I agree = the text is a little hard to comprehend, so I will remove the last 2 = sentences.


17. Section 5.1:

 The USE_AGGFRAG notification contains a = 1 octet payload of flags that
 specify any = requirements from the sender of the message.  If any
 requirement flags are not understood or cannot be = supported by the
 receiver then the receiver should = not enable use of AGGFRAG_PAYLOAD
 payload type = (either by not responding with the USE_AGGFRAG
 notification, or in the case of the initiator, by = deleting the child
 SA if the now established = non-AGGFRAG_PAYLOAD using SA is
 unacceptable).

It is not clear for me from this text whether = these flags are negotiated
or independently announced by = peers. In other words - are they
independent in both = direction or they must be the same?

They are not negotiated as they are "requirements from the = sender of the message" and the receiver either
understands = and accepts them or doesn't use AGGFRAG_PAYLOADs.

I've changed
 "that specify any = requirements from the sender"

to

"that specify requirements from the sender"

perhaps that makes it more clear?

I think even better would be "that specify requirements from = the sender of this notification".

OK, changed "of the message" to "of the = notification".


19. Section 6.1:

 An IP-TFS = payload is identified by the ESP payload type
 AGGFRAG_PAYLOAD which has the value 0x5.

Where this value has come from? Isn't it = registered with IANA?
We had a long discussion about this = in the WG, current
text looks like the value was = squatted...

The discussion = lead to the understanding that the ESP next-header field is not actually = required to be IP
protocol number, and people don't = generically use it that way so we are free to choose whatever = non-used
value we would like. We chose 0x5 simply b/c that = *was* an IP protocol number that is allocated but will not
used; however, this wasn't required -- it's just trying to be = smart about picking a value. :)

I don't = think we need to go into this in the document though -- it's enough that = its a valid value to use.

I still think = that some words about this must be added. Otherwise it looks = like
the value 5 = has come to you as a miracle and you cannot explain why it is exactly = 5 
(and not any = other value).

Ok = well then I've added "The value 5 was chosen to not conflict with other = used values". What I don't want to do here, in the packet and data = format definition section, is get into some distracting explanation = about why this value isn't conflicting -- this does not help people = trying to implement the specification.

20. Section 6.1.4:

 0:
    6= bits - reserved, MUST be zero on send, unless defined by later
    specifications.

Add a sentence that these bits MUST be ignored on receipt.

They must not be ignored. If they = are set and they and not understood then AGGFRAG mode will not be
enabled as indicated in section 5.1

Section 5.1 is about USE_AGGFRAG notification, here we talk = about
Reserved bits = AGGFRAG_PAYLOAD. How they are related?

As implementer I have a question - what should I do if these = bits
are non-zero = on receipt? The draft is silent about this.

I = think maybe you mixed something up in your reading? Section 6.1.4 = is:

"6.1.4. =
 IKEv2 USE_AGGFRAG Notification Message"


It is = not about the AGGFRAG_PAYLOAD.

22. Security Considerations.

Add = a text that correct functionality of the AGGFRAG mode
requires restoring packets order on the receiver. Since = this
is done by utilizing ESP Sequence Number field, the = ESP
header must be authenticated, and thus the ESP SA = MUST
be created with authentication other than NONE
or with AEAD cipher.

I think this falls under the non-IPTFS use case. I'd like to = leave it out as it would be confusing.

No, it's = about any use case of this mechanism.
ESP can be used without authentication 
(although = it's strictly discouraged) and in this
if AGGFRAG is employed (regardless of IP-TFS),
then an = attacker can re-order packets on his/her will,
by playing = with SN field, so your reassembly mechanism won't work.

You = think I need to state that things are not secure if the user turns off = authentication?

I would think that's = covered already by:

"
   Other than
   the additional security afforded by using this mechanism, IP-TFS
   utilizes the security protocols [RFC4303] and [RFC7296] and so their
   security considerations apply to IP-TFS as well.
"

Thanks,
Chris.


Regards,
Valery.

= --Apple-Mail=_5024E057-6D4F-42F2-AAC2-17CCE9C76CE9-- --Apple-Mail=_8D7F6226-97C5-4693-90DD-53068FCAC994 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAj9YkACgkQLh2DDte4 MCXShg//dl/oqjTvhxItCpuIqeONadiZWpNBYHm2krh2cSv3QiJx5fNjQ50Z8ay5 GsITTbVOzNCoxO9PJDQx0QnWSpJuz/qeGFOyysuOpbtDSQ1mn51R5rK3H6wr1OpJ nTz7tY0dDIMQ9azOWiS99sMaUFsDTEav5vPx2ayx6RpB4sOzLvUcAfXNfjEe/oI1 9aHxlI009Cm6JBfJw4Gmuw/bAtukT2opoSAClkhuWGCZqsOd8GiS8X3e9Jxqngbc i7xtNX5VKnK/vaxnnGTikEBd+7kVbzcPx8mt0ZBFnl0zhdkWobrkAm/fI0ES6Y5e b6l3OHfuQi/vs5Vrz+0TA9IqMO6cgyhud0jkyIS/8p+Prbbh+OludszfH53gLVGS GOspIdi95oWbubvr1lA74XDyPgw/oxV9emyp+/1ukReeMxHk71s2V1IknUWwHTt5 h2G1ouhj+fcfFriRTwQa8YpHmAuzb8SMq8rifWVj8WKgsJpIzyT4QxdFeix0X5m9 0gvwukCGRBPhA635LZfmEnXIWwM1p1sx5LY88GkrL7+GflXjZnZkX2r+laqpGKyV hRuugShbqh5hD3g0Wyw90n/es5foCYexw6uNeVAVBs3uPW/zZFWmL8RCuhd5Jdd9 BpjDVIR+j+1i8Kd422/RTK+457MKRYrolHiNlUtsArLlNA0XYpo= =+ZX/ -----END PGP SIGNATURE----- --Apple-Mail=_8D7F6226-97C5-4693-90DD-53068FCAC994-- From nobody Wed Feb 10 07:15:16 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B033A0D55 for ; Wed, 10 Feb 2021 07:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 9Llxr8iQkTSc for ; Wed, 10 Feb 2021 07:15:13 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE583A0D52 for ; Wed, 10 Feb 2021 07:15:13 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id CEAFC61669; Wed, 10 Feb 2021 15:15:12 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EE63F66C-5447-4157-80CC-E195642CFBAB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 10 Feb 2021 10:15:11 -0500 In-Reply-To: <24590.9470.995873.674029@fireball.acr.fi> Cc: Christian Hopps , ipsec@ietf.org To: Tero Kivinen References: <24590.9470.995873.674029@fireball.acr.fi> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 15:15:15 -0000 --Apple-Mail=_EE63F66C-5447-4157-80CC-E195642CFBAB Content-Type: multipart/alternative; boundary="Apple-Mail=_F8DB9A8D-845C-4ED7-A072-87BA305E5E03" --Apple-Mail=_F8DB9A8D-845C-4ED7-A072-87BA305E5E03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As there have been a number of editorial changes (nits etc), to help any = remaining reviewers here's a pointer to the current text which includes = the changes made so far during the WGLC: = https://app.circleci.com/pipelines/github/LabNConsulting/iptfs/6/workflows= /6e885d99-8577-4899-82b7-6b4bd938d18e/jobs/6/artifacts = Thanks, Chris. > On Jan 24, 2021, at 8:55 PM, Tero Kivinen wrote: >=20 > This is the start of 3 week WGLC on the document, ending 2021-02-15. > Please submit your comments to the list, also send a note if you have > reviewed the document, so we can see how many people are interested in > getting this out. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_F8DB9A8D-845C-4ED7-A072-87BA305E5E03 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As = there have been a number of editorial changes (nits etc), to help any = remaining reviewers here's a pointer to the current text which includes = the changes made so far during the WGLC:

https://app.circleci.com/pipelines/github/LabNConsulting/iptfs/= 6/workflows/6e885d99-8577-4899-82b7-6b4bd938d18e/jobs/6/artifacts

Thanks,
Chris.

On Jan 24, 2021, at 8:55 PM, = Tero Kivinen <kivinen@iki.fi> wrote:

This = is the start of 3 week WGLC on the document, ending 2021-02-15.
Please submit your comments to the list, also send a note if = you have
reviewed the document, so we can see how many = people are interested in
getting this out.
-- =
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


= --Apple-Mail=_F8DB9A8D-845C-4ED7-A072-87BA305E5E03-- --Apple-Mail=_EE63F66C-5447-4157-80CC-E195642CFBAB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAj+H8ACgkQLh2DDte4 MCWyeBAAlVDlypADFqyy55JzCSKPrwvn8/w2GPinDrN0Y1iLAPqkHxThTMYxl93f gTTDT0x1QMUBZeYmEmQJjVfDldSs+NbO44aPhH5TkNDk0D399wBAVZL1zaEqh0hf sSvcTPxQlzznB4r0+SWXVezMjon/UvZlUb0f4QwAw4Q7MAG8Cy3ZX3QSEj87vsUg hLnyIce8q/bjnOmUl0QY4Ni98fRyynxglKbF38U1GSlrb8x+zuCTuY1RY6uSqhT1 pR0PAFeQdlwVfDsO5y3F9m/WEVjj8P+TED0pKpviWrnzqT26uljWGn3Mi/Dc91UM +PDeKv4vmBZjGGSdH9HHezDyqlyJEEUQaHt+f3Zvij+fF8bYLdtfI0UOQv6XGJDS BY5vefqLN0r+Gyg6GFB+oQ58SgqbxbBE3g7hUjhnY+muj4/DlNxJHvBNDx74wKZg wApeIsuz66Q3xeP+CQyC8UzRvw9MNFnXc091eQNIBoGE0p9Gtypb5X7zrjndtpbD UD9/rj1jFIIdl39VDJ6sviaos9ASP3I2GiHenWnhduWHLe7PdO8z8TtFjVmKtVNK v7HbmrDK2UNJ22k902juyBgJKmOLSGVY7JNF76dstcCMItpAeN+7KV+v6GFDP3no CTd+8HRJxYo50/0bcPOq4qswEBCibJZ65MLfrPu/xj+eAJOniOo= =rYoc -----END PGP SIGNATURE----- --Apple-Mail=_EE63F66C-5447-4157-80CC-E195642CFBAB-- From nobody Wed Feb 10 12:39:13 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570483A114C; Wed, 10 Feb 2021 12:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_RATIO_04=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 5uBuDVKevLel; Wed, 10 Feb 2021 12:39:06 -0800 (PST) Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam08on2108.outbound.protection.outlook.com [40.107.100.108]) (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 EFD413A1147; Wed, 10 Feb 2021 12:39:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BrdjhVg8Bk0+dNEKlMbB3Y3uEeAScOv1FUZ4tFm0F9ODNwgp1im/PGJVzpx79ctm11+PLXiRhmAEOe/w1voOe9Mf2j5/RFKRd6mBADDdZr6wIdiskUjQTHVu/l5QehEs3BQ9BeQSRW93/MQWo+CTGz6truBkGvZ1v3U05ppT7AfRcmkIUutjbY0/MF1Igv7zss1CXPUUnUmAJP6FKfgs6KWXX3wgx8Wq0KWn15vC5SNW1oWe9TgLpo5q8rs0YbKDuG68K+WM9A9vxXe/hJSe5Ggs/htNrqqVEsYI9+zT/vCZ/hwSnTlQUWuWqSg+2XNH6OF4sZcPUOMbOhJDLdOyiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bA0rWLWF35oxGQRekG2sDfhboLiXjzJFWyx56H4Mw1A=; b=lWciOqqdfCv2i6lukS95BanHA4siRVftQ7zIgTY7ak1fmOTmNjZOC6le9SDgbszPYe1zdRrd1Ti30HGUGiIVXBVpq0ijtpr0hzyRbFGjSsBJ4KadTA+KtrSyBkvBL0ezbifJ+BR1x+3acZF0sijArfo09jdCqxOEjB2MCUBIunQn8dq1UDGvIPE9ogqgXbTQPg7hfhUcqFTnWUHP+EJtnQTIgfePwVRahBiFQIYtN9xswoFA9JVhvkLE7e1t0OOWpU4nerlk5Fq/83XXn8xZbb2VMXlZxeGOwz/QDqbj+az1N1QF2YeJSNogUu+Gaz3DV5d4dEjQpRLwhtGELh5CRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bA0rWLWF35oxGQRekG2sDfhboLiXjzJFWyx56H4Mw1A=; b=HBhyK+5leHfFmeaTkuC4URVSTrRczLlRVAlF8dxdSAm5q4kveQUMtNL3ePmN49KR3CSroBfzdo6GzvU4HNq7U/gJ4bf2Q72QDRUUV8xgcbP9pH5JqF+/8u528LJ4jDKJO+p635njVmHTHr+3MnHEINkxsVHWXJ2heUIr0syyD/M= Received: from (2603:10b6:5:cc::16) by DM6PR13MB4431.namprd13.prod.outlook.com (2603:10b6:5:1bb::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.11; Wed, 10 Feb 2021 20:38:58 +0000 Received: from DM6PR13MB2330.namprd13.prod.outlook.com ([fe80::a0ee:878c:3c01:2045]) by DM6PR13MB2330.namprd13.prod.outlook.com ([fe80::a0ee:878c:3c01:2045%3]) with mapi id 15.20.3846.026; Wed, 10 Feb 2021 20:38:58 +0000 From: Linda Dunbar To: "ipsec@ietf.org WG" CC: "idr@ietf.org" , "draft-dunbar-idr-sdwan-edge-discovery@ietf.org" Thread-Topic: Soliciting feedback from IPsec experts on using BGP to announce clients routes that can be carried by IPsec SAs. Thread-Index: Adb/7Jo1GS2VXevBQJG9uBPj74etxA== Date: Wed, 10 Feb 2021 20:38:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2603:8081:1700:ab:fd1f:911e:7e98:af9a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 331116b6-f096-48ae-c58c-08d8ce03e447 x-ms-traffictypediagnostic: DM6PR13MB4431: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6rZ6hb6iFZK5Rl/7DfJLXvk7/tZRDCg/KTFs0V/IfmCPhuYSBD5mApz3KWyuD1eER7AwRqjMHFpWwzWYy+uRUBoR6sAnbgwFLYJ6qJyNvR3fd95NwhfLCt+fDB0Amebm+voXZ4U8aVz0pl0OnauTTnS/47iipedogFL0RIj2bry2CS/yntymhKFCMU1iMkqpuTJYfb6qJovl49wLi1RHRq+b2R1t9eJ3skutZLiin0qisyD9a4aTobufFOoi+0O8G+GBMz1fYtm5/aScSnlVPWTBqgQsQLLRuf3ds5z9zAEWb5Ah4PQUbUMcw3s4eQTjV/c7wEVOAZn+GxYZfBbL8su6YMD2z2z0BeZd03s2Au/Fg1puJJYOa9zFhMhnI1lXYCyGju3nbRnUwvLtdgobq40MxaUjgbK5aFom56Rg+uXTXSVFbQkFOtY9qR6JFXQbT0FbXL29tWk+/M+ZKLh3j68Zbyx8ZLel/XZKlYO8z72lXQ8/lq3sGK9GbQ2lNH2pKb87ssqat7lDmiT3yXNw2K3Oat0Rrl8TBZh4d8ePcusFdw95qu4CN+ZS7anXcOR/I9gKTobvpml5+6/DyET4k4LWoipvDhdDDYjVUrbyoDc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR13MB2330.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(39840400004)(376002)(366004)(346002)(66574015)(99936003)(2906002)(33656002)(86362001)(83380400001)(55016002)(6506007)(166002)(9686003)(4326008)(64756008)(66946007)(66576008)(66476007)(316002)(44832011)(76116006)(5660300002)(450100002)(71200400001)(478600001)(4743002)(186003)(6916009)(8676002)(8936002)(7696005)(54906003)(52536014)(66556008)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?zA4FgnjMQRV2xR10sRDFQvhm2iLEMpyarQep56UZ2CQhOHtE7oyyJiXqqchp?= =?us-ascii?Q?1a289mBAPuwe/IvQ8q9O8fqRgEh8RjRr17G8MLVlMDKwoXDInhz6iSBBTekV?= =?us-ascii?Q?6fWdAEmPcj0qo7gp9Rd1ShkwEA0RuUGqta7qI2KfUaJYEWf1QOlcdhYElzGa?= =?us-ascii?Q?iHWFuVoKLGjj4K6gsYDly8HiCuqY91FcOMG/PhSJFswpJETBE+Fmu5VGySt/?= =?us-ascii?Q?HauzmXR025i7MOVX4Yr9uaEUMMJiKRMUUIsFffkVGguJTVgS00OtLUf+UQG2?= =?us-ascii?Q?iDh0HM/iXcMd6LwEdMmgmsknrEozB3PVDs2wCiufzXkqXvpL1e+raWN81+5Z?= =?us-ascii?Q?dHMJV2bF7UGQhTYMo1TN9Fp42Jv83R83ziK5ahJrKNtFjkK6vBziFpXSxHyD?= =?us-ascii?Q?aPBkH/vGG4PbijVSSv2oMJJ6YElIugEuFaaMmSdBFntPIhPovX7qgtNKXnmq?= =?us-ascii?Q?Szy7zZ2opO7tEzeCQGqhB9gQMEDKuZMS+pnKu1LmqNNRl7Fd1o8rj+8SPfRZ?= =?us-ascii?Q?4J5lCVqfBgVypQIxVCBWf/DPEl1ZqcxdS5/wQ8s+080yyUgpRda4ak4jCIgy?= =?us-ascii?Q?zXG2iiM/IljmvzbYX0SpF0f6HosiKpsC2uizjGuPjdrsoFUT2KrXVQGTBe2b?= =?us-ascii?Q?ECZ0fxrdHdSdH4D1v6OosUwV4aoAB3EmmtgTw0NqVFOYFMUMWGThgqUyhz/8?= =?us-ascii?Q?c5BBO7nwnSKMeUDwSVhdvUbdqXhS2wiO/y+ZbseGWKC/FyiQmfqlU7hfHteG?= =?us-ascii?Q?6CecyG8NnHA7YRIEcKRwMikW728P2nBXEc3rPQB8q6usQfeBv5LV5adDXeIT?= =?us-ascii?Q?oYKEoMDATl+o6Gz8+MfLZ2X6PtevaFinaO0QxIlFlwww9E1BSDrg108Zsgaq?= =?us-ascii?Q?JqNbYEl05tPENXkL44Xxq1SuR2tH769/IVFdJiZB6gDCmxRNeqIX1Z6xsZ59?= =?us-ascii?Q?lyldKwld9MwaufLw99m9Ymp75dWnYPaqhJAYU2B9rr1oM3XuiSDi5mf2sZj/?= =?us-ascii?Q?aLAErrxE0YEBNFKB6lbPUZ5In7uTmu+z6zcjfdx+kwcGDiEfuxldWWgIkUgN?= =?us-ascii?Q?OMPlYj12D298GccVKGeOlVs1H8RFrglGQsqyC6yZeDYMJqhzsV02Sc1Op57q?= =?us-ascii?Q?ter1Ek0gItcHMfUd9GKxsI3TLcWEan9Jc9pDUACcyIyeyc9OIOc6ZGoDFib5?= =?us-ascii?Q?vPaTf1SbyF964dOqm/tlbHV9Hqmovl1UbznqxIknxJ9B1hWOLkEBW9U74rKE?= =?us-ascii?Q?Lexnf3W5fJ+mN7/yjBrFgJ0FvzC3R8uDHzv/gTP9fJrJw9zVU2GvpenJzEZR?= =?us-ascii?Q?pQPLR6pI63AwWPbOhAEE97RB//m1ikNX+IniwIJIyxvFShKIZamaTsPKJw3J?= =?us-ascii?Q?Q9KXbtlcLdVsZXZhmzAcYK9PKzmC?= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_005_DM6PR13MB233024BBB6C83FA92B77F995858D9DM6PR13MB2330namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR13MB2330.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 331116b6-f096-48ae-c58c-08d8ce03e447 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2021 20:38:58.1498 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pOUJ2yaMGzmt4r7+0apbubV3YhxCg9vCAmZF8oi4YqX3iJ9jRItsaMYpi7w2OgSzGSt+bCbVTOitmszEAs1DrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB4431 Archived-At: Subject: [IPsec] Soliciting feedback from IPsec experts on using BGP to announce clients routes that can be carried by IPsec SAs. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 20:39:09 -0000 --_005_DM6PR13MB233024BBB6C83FA92B77F995858D9DM6PR13MB2330namp_ Content-Type: multipart/alternative; boundary="_000_DM6PR13MB233024BBB6C83FA92B77F995858D9DM6PR13MB2330namp_" --_000_DM6PR13MB233024BBB6C83FA92B77F995858D9DM6PR13MB2330namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPsec Experts, We have a draft in IDR on using BGP to distribute routes attached to SDWAN = edge nodes (https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-edge-di= scovery/ ). Since SDWAN can have L3/L2 VPN paths and IPsec paths between edge nodes, we= think using the BGP UPDATE to announce all possible paths (including IPsec= SAs) for reaching the client routes is more efficient than declaring the c= lient routes as the IPsec SA Child. Do you see any issues? Here is control flow: In the figure below, C-PE2 has public internet facing WAN ports from ISP1 (= 192.0.0.1) and ISP2 (170.0.0.1). Suppose there are already IPsec SA establi= shed between the WAN ports * IPsec SA #1: between C-PE1 and CPE2 (170.0.0.1 <-> 160.0.0.1); * IPsec SA#2: between C-PE1 and CPE2 (192.0.0.1 <-> 192.10.0.10); * IPsec SA#3: between C-PE2(170.0.0.1)<-> C-PE3 (180.0.0.1). [cid:image001.png@01D6FFBA.7621E0E0] For C-PE2 to announce its attached routes being reachable by L3VPN path and= IPsec SAs, the BGP UPDATE can include the following in its Tunnel attribut= es. [cid:image005.png@01D6FFBA.7621E0E0] Your feedback is greatly appreciated. Linda Dunbar --_000_DM6PR13MB233024BBB6C83FA92B77F995858D9DM6PR13MB2330namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IPsec Experts,

 

We have a draft in IDR on using BGP to distribute ro= utes attached to SDWAN edge nodes (https://datatracker.ietf.org/do= c/draft-dunbar-idr-sdwan-edge-discovery/ ).

Since SDWAN can have L3/L2 VPN paths and IPsec paths= between edge nodes, we think using the BGP UPDATE to announce all possible= paths (including IPsec SAs) for reaching the client routes is more efficie= nt than declaring the client routes as  the  IPsec SA Child.

 

Do you see any issues?

 

Here is control flow:

In the figure below, C-PE2 has public internet facin= g WAN ports from ISP1 (192.0.0.1) and ISP2 (170.0.0.1). Suppose there are a= lready IPsec SA established between the WAN ports

  • IPsec SA #1: between C-PE1 and CPE2 (170.0.0.1 <-> 160.0.0.1);
  • IPsec SA#2: between C-PE1 and CPE2 (192.0.0.1 <-&g= t; 192.10.0.10);
  • IPsec SA#3: between C-PE2(170.0.0.1)&= lt;-> C-PE3 (180.0.0.1).

 

 

 

 

 

For C-PE2 to announce its attached routes being reac= hable by L3VPN path and IPsec SAs, the BGP UPDATE can include the following= in its Tunnel attributes.

 

 

Your feedback is greatly appreciated.

 

Linda Dunbar

--_000_DM6PR13MB233024BBB6C83FA92B77F995858D9DM6PR13MB2330namp_-- --_005_DM6PR13MB233024BBB6C83FA92B77F995858D9DM6PR13MB2330namp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=62277; creation-date="Wed, 10 Feb 2021 20:38:57 GMT"; modification-date="Wed, 10 Feb 2021 20:38:57 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA4MAAADZCAYAAACaauX2AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAPLFSURBVHhe 7F0HYBVV1j5TXksPSSAUaQISCIIorKBg77333v3XXXVddXeV50NXd9XVddW1rb2LvWEXRUFBsKFB em/p7dUp/3fmvRdeQoAQAiTkXL28KXdu+WYyc797mh4IBEiSICAICAKCgCAgCAgCgoAgIAgIAoJA 50JA71zDldEKAoKAICAICAKCgCAgCAgCgoAgIAgwAkIG5TkQBAQBQUAQEAQEAUFAEBAEBAFBoBMi IGSwE950GbIgIAgIAoKAICAICAKCgCAgCAgCQgblGRAEBAFBQBAQBAQBQUAQEAQEAUGgEyIgZLAT 3nQZsiAgCAgCgoAgIAgIAoKAICAICAJCBuUZEAQEAUGgCQL+0ad7qHaQGiiZGBJwBAFBQBAQBAQB QUAQ2FkREDK4s95ZGZcgIAhsFAH/hAlKYOJE29/v+lzKDfUg8hSicH8yIwNJ8xRTNOYlX+XZOCZk UJ4jQUAQEAQEAUFAENhpERAyuNPeWhmYICAIbBSBd8N9/cP/+Cj8Ke9KhppHbi2LXB4UTwMvxE9l zc2B2fevEgQFAUFAEBAEBAFBQBDYmREQMrgz310ZmyAgCDSPwNHepfRG9CUi60HypHkoGiYnp2cR ldfMpJj1L4FOEBAEBAFBQBAQBASBnR0BIYM7+x2W8QkCgsAGCEBF1PIPu2ImWbSG0tL6UCxCpGhE 4SCRat0WKLlf1EPluREEBAFBQBAQBASBnR4BIYM7/S2WAQoCgkAqAv7Cs3Ooe8EN5PJeR0bEpprq D8mmQygnW6WqqmcDP93/tiAmCAgCgoAgIAgIAoJAZ0BAyGBnuMsyRkFAEHAQ8A+7+lRy63dQblp/ qg59Q6HQjYGSh77w7/6HWykYPo9sPSBQCQI7OwL+0ye4Ai9NjO3s45TxCQKCgCAgCGweASGDm8dI SggCgkAHR8BfdMkQ8mUGKDPjZKoL1VNF3Z/pl98eDETei6uDxj6+heyDnw/8fP/CDj5U6b4gsHkE 5tWNgAOlO0h3WRSL2aQ4l1STbQfJ7VWgNh2hqOWHuvTqzVcmJQQBQUAQEAQ6MgJCBjvy3ZO+CwKC wCYRgEqol3p0vZp0z03kdaVTTd0LZIQCgZ8fmpd6YaCkxCQqmStwCgKdAgF91U9kFv5COWl/IJjL kmnDVhaMUMU2zwoqow8QfbK2U2AhgxQEBAFBoJMjIGSwkz8AMnxBYGdFwD/s/w4nl+8O6pI2girD v1B53V8Dv4g94M56v2VcLUcgMOOliL9owjVUVp1G6dkXU6iOyLbICa8Si4XgWOl9LJDggCRBQBAQ BASBnR0BIYM7+x2W8QkCnQwB/8BL+lJm1s2Uln4hBYMWSOBEWr3u3sCa56o6GRQyXEFgowgESuBR t+iqP5BSU0hpWUdTEITQ8aqruMjne9+/558+IdN8lNaUvYO/HcRdkSQICAKCgCCwMyIgZHBnvKsy JkGgEyLgLyrSyHfEZaR5bqEMVwFV175DsbAfKqHfd0I4ZMiCwGYR4BAqsKe9EN50J1Ne1p5UXv1P EMB3KBI8j1T1AsrNOphUbZ6/8Nr/UST2Isqv2GylUkAQEAQEAUGgQyEgZLBD3S7prCAgCDSHgH/Y VfuSy3075aWPo+roYqqsuTrww79fELQEAUFg0wgESh4r9RddcTHV1P8BTmP+AcJXhSu+xt/U7fg7 Ops0/WLqkn4nVdX7/cOvfpo86hOBGffMElwFAUFAEBAEdg4EhAzuHPdRRiEIdEoE/EVnF5I7/y/k y/gDWQZRae09FDH+iQntuk4JiAxaEGgFAgiv8gMuuzD1UnjWXYL92/xjr7qXKugE0tRLKDP9SooZ V/r3+vO7ZJmP0KJVHwaqXpIQFa3AXC4RBAQBQaC9ICBksL3cCemHICAIbBEC/hFXn026+++U4+1N FfVfUCz6N0xgv96iSqSwICAIbBKBwLT761HgOc6QFu5PmnYxVEdPp6yMo2nXXj/7o1c/Sob5KhZg 1giUgoAgIAgIAh0PASGDHe+eSY8FgU6NAFTaRpAvbSLlph9DNZF1iBl4OYUmPybeDzv1YyGD3w4I YLFlCpqZ4h92hZ8qzXNJhwppftb9VFl7m3/ENY+TajwTmH3/j9uhK9KEICAICAKCQBshIGSwjYCU agQBQWDbIgCV0Bzy5F8NG6YJ5E1TqDL4PwpV3wabp6XbtmWpXRAQBFIRgFOmhdj3+/td8m8ErD8B +XLKyLyWwuFr/Xv++VUyY49S5MNPZYFGnhtBQBAQBNo/AkIG2/89kh4KAp0eAf+Ia48lXb2DctOG UFnd91RV/pfALw9+2OmBEQAEgR2IQGDxY5W0mJ7wT5jwFL1dtx+CFV6JxZqTKDvrZKo9cpZ/xGGP UHX9GyhXtgO7KU0LAoKAICAIbAIBIYPyeAgCgkC7RQAqoQMgBfRTVvrZFIzW0pqaG6i07D8S96zd 3jLpWCdEIDBxIgeo/5wzYhcWkWWdh3iFF1CXrEfx+3f/Htc+Bunhs4HZ98zthPDIkAUBQUAQaNcI CBls17dHOicIdE4E/IVHpVHhbleQqkykjPQ0qq9/mawgxwz8rXMiIqMWBDoGAnAkU4Ke3ghSeA+R dTLZ1mWUlf1Xqg/d6B/5pxcpFPwfvJdO6RijkV4KAoKAILDzIyBkcOe/xzJCQaBDIeAf9n8Hksv7 D8QMHAUvofMR6+wvgZ///VqHGoR0VhDo5Agkwrv81z96wqNUU3MwJISXk8tzFuUXnAVnM99ApfQh iphvoVx1J4dKhi8ICAKCwA5FQMjgDoVfGhcEBIEkAv6R13cjxWLnMFdSJGLSuurbKVp+V6DkuSpB SRAQBDomAoEZExEAlD7g7B951e5kmucjZuGFlJ3+NFXUrvCPuO5RUq3noEK6uGOOUHotCAgCgkDH RkDIYMe+f9J7QaDDI+CfU6TR2YddQGTehgliN6oNv0+R2pugEvp9hx+cDEAQEAQaEEDYiZ+wcy1I 4b+oNHoKYhZeRjkIE1MX/itUSF8gij6OMtMEMkFAEBAEBIHth4CQwe2HtbQkCAgCTRBAvLLf0ci0 2xAz8GCohK6misoLAz/c/6QAJQgIAjsvAiB8KzG6f/tHn/4Q1ZiHk61fTt70C0lJv9C/xzVfkGE/ gkD270CFtG7nRUFGJggIAoJA+0BAyGD7uA/SC0GgUyHgH3tVNoU9NyBo9Y2k6gqV1zwI+6G/Y/K3 ulMBIYMVBDoxAoEZL0Uw/Lc4+4ddO4rc6vlE6gWUn74f1YTm+0dChTQUeRHvBSaPkgQBQUAQEAS2 AQJCBrcBqFKlICAIbBwB/4irT6Owfjt1SetPlaGpZET/Evjh318LZoKAINB5EQj8fM9MjH4mbIfv oMq6MxCK4hLKzrgLx/z+4X98HuEqHg/8fD+XkSQICAKCgCDQhggIGWxDMKUqQUAQ2AQJHHZVMblc EzHBO4FqglVUVvlHWlL6UKDqpZjgJggIAoIAIxCYfecK/NyF0BQPkF1+FKneKyg9+zKQwcuwkPQh JIeP0JpvJgfWTAsLYoKAICAICAJbj4CQwa3HUGoQBASBTSDgLzzbSz0Kr4aziAnk8/gQKuI5MlXE DLx/kQAnCAgCgkBzCEA1NITjr3L2D7tqX3K7zydSzqecjMNI33eOv8fej1Jl7OXA4vvXCYKCgCAg CAgCrUdAyGDrsZMrBQFBYDMI+EdcdSTp3r9Trm8EVUZ+QLyxG6ESitV9SYKAICAItAwBLBx9hZJf +Ude+3eqqjmLNNdF0DD4D1H9Lf7sa58lM/YkyvzYstqklCAgCAgCgkAqAkIG5XkQBASBNkfAX3RF P/J5/ZSeeR6FwhEqrbuJIrF/Y7W/vs0bkwoFAUGgUyCQiEV4G7QN7iMz/xjS9CspPf2PFI3+EV5I 3yHbeISe++SDQHGJ2SkAkUEKAoKAINAGCAgZbAMQpQpBQBCII5CIGXgZVu4DlO3LR1Dpt8kM/w0x A+cIRoKAICAItAUCgTXP1dIaQlxCegHaBwcQaZeSop5OWbnH0HlHz/KbRzxCafprgWl3VrRFe1KH ICAICAI7MwJCBnfmuytjEwS2IwKQBo6jvTJupRzfflQVXkilNf8X+Pnfr2zHLkhTgoAg0MkQQFzS zzHkz6FCOoGqqs4hl+ciys14lKrqb4MX0ifgeOYZqJCWdDJYZLiCgCAgCLQYASGDLYZKCgoCgkBz CPhHXtUNDmEC5MuAxz9oZ1XU30mhmn8GSh6TVXl5ZAQBQWC7IAAV0vloaAK8kP6LTPsk0pXLKSP7 Rqqvv9G/559eItN8mo7N+igwcaK1XTokjQgCgoAg0EEQEDLYQW6UdFMQaL8I+Ijs8GiKhqYTxa4J zL7/2/bbV+mZICAI7MwIwC65GuN7wl804Wkyyg8h230xZWSeTrVVxfRJ5VScE7vlnfkBkLEJAoLA FiMgZHCLIZMLBAFBIBUBxAVb6x87YV/6dV5MYgbKsyEICALtAYFAyUR2IvMBZ/+wa/cklzcGG0Ih gu3h5kgfBAFBoF0hIGSwXd0O6Ywg0DERCEybGOyYPZdeCwKCwM6OQODne2bt7GOU8QkCgoAg0FoE hAy2Fjm5ThAQBAQBQUAQEAQEAUFAEBAEBIEOjICQwQ5886TrgoAgIAgIAoKAICAICAKCgCAgCLQW ASGDrUVOrhMEBAFBQBAQBAQBQUAQEAQEAUGgAyMgZLAD3zzpuiAgCAgCgoAgIAgIAoKAICAICAKt RUDIYGuRk+sEAUFAEBAEBAFBQBAQBAQBQUAQ6MAICBnswDdPui4ICAKCgCAgCAgCgoAgIAgIAoJA axEQMtha5OQ6QUAQEAQEAUFAEBAEBAFBQBAQBDowAkIGO/DNk64LAoKAICAICAKCgCAgCAgCgoAg 0FoEhAy2Fjm5ThAQBAQBQUAQEAQEAUFAEBAEBIEOjICQwQ5886TrgoAgIAgIAoKAICAICAKCgCAg CLQWASGDrUVOrhMEBAFBQBAQBAQBQUAQEAQEAUGgAyMgZLAD3zzpuiAgCAgCgoAgIAgIAoKAICAI CAKtRUDIYGuRk+sEAUFAEBAEBAFBQBAQBAQBQUAQ6MAICBnswDdPui4ICAKCgCAgCAgCgoAgIAgI AoJAaxEQMtha5OQ6QUAQEAQEAUFAEBAEBAFBQBAQBDowAkIGO/DNk64LAoKAICAICAKCgCAgCAgC goAg0FoEhAy2Fjm5ThAQBAQBQUAQEAQEAUFAEBAEBIEOjICQwQ5886TrgoAg0PYI+MfO6ULhkEoh n+3Urhs5+NdHFIvvu8immMuNLT6uIcePc9JU3k4jspDJxH915IpVY7uWYqTgYoVcepgoVOXU7wsp +I0FSoq5jCRBQBAQBAQBQUAQEAS2KwJCBrcr3NKYICAItAUC/tHTPVSbCYJGGSBU6aS7MsiIpTvE zFJzQbqYrGlkWoX4lwmbhyy7Bym2RaRkYT8PvyButgKKVkiK4iabd1G2njLBABVyx5JdTcdxDyl6 nPSZKKjaOq5JY3rXOKF6XUXzeLVyfVHsGy5UZIVIVVAax4wYaKFe59RvOu0Y/hHf1zj1cBHLNrC1 liknftV4G8oqnIigu6gcZ1RlHX7rQTZV0kyU0MpRWW28Ly7kWC2ZWj2IKF/NJDSI2uJtUIw7GCZD r3LqYuLrDUcDJePqm45G9gUBQUAQEAQEAUFg50ZAyODOfX9ldIJAu0cgIYnLRkdBwpAtTw6ITz6I Tib4WjfQHR+IVQF4URp+80GE0iniTQeJ8oDKpIH0eEHQQMx03ocMD681JmSc1AQpU1NYW+o2k69U QscEDvytUbL42Hrhn1Oed/lYyuENruEDbvTDq7jQZ5YnJvqEClSli7PD7XEftJROcDk+nppS23eu Sy0D8ufsMwlE4qoivGHaDtl0qrYj+K0HntjDMbKjwI/Jo01u3s8w/MO/r8UeE00ctUycW42+xdAX EFKFUVmH7RB33jlmK2tAREFINQZbwXY5qVqCcOJILBYkl4vbULCtYjvokFTUAPIOCSlIcchXSbnc +0qVFlEssGYcpKaSBAFBQBAQBAQBQWB7ISBkcHshLe0IAp0QAX/RnDxI7vIx9K5kuUDozD5gPt1B JgpxrAeIXg4oSg7YARM/SPZA9HzgFhoL85CYmDiyrSa/SSLm/CYIXJJA8TED3CUKPmPaQVwL4mIz SWGKxLSJVTKjXDv26lA/yiTOMOEhhUlTnE2yJM62K9CPSlSWYJhgbqaJyjUmQ6gnhckxhdJMJrY6 SFIF5IyQ8pldsJ2H41Ab1WzSrSwQTkgmnQEyyfI5pHc9/+P3MjBx+mejb/yby3TL6SUfUSgb4wLB TAxaU30O8UzW4UgnU1ivongwBk9DAcZTVbo2PJI8/lSSzCdSCWiSfKZyVEeSmiCgDlZMvBM1JuuL 2ZBuMpkE4bRAJG0d0so4sCCqMRDSatwBvu0KdVUMf7fZ1RhXvBYbUlwFhNPGfeP74fRBWYtt1IP7 wuUUswxHWQrKElJ+cFhCup6QqhYIKLcA8umo6aIuRyIKaagPguUQjuZW8vNgUWWuQpm1ZmDGGH42 JAkCgoAgIAgIAp0CASGDneI2yyAFgW2LAKR76VQb2pU8rt6gP4MxkR+KyfpAh/SZOoiQkkNpeN2A vzjciYlHknwkJW+ppK6eNStZmqXUoA4mFJjgQ0qV/GWSQCBxNpViig9Zk1kKQgBJlEP41pLKtnux CPpTg/6oFEM9rlg0bgdYWUPDh0Rp0TwVE39HhtbeEtRgdajB2rAlZHpJ/rFTYYOYq1IlJGiU66VM Iw/jApgGxuMDpTG8pJteqKCmQU0W6rEEAq6xOmwQJAnSNq0HsAPhBMgWCKhqZeBcV5AqECqW+kGy SsRS2IRk1CHBXRpIcpyQZmGfqRyXZ3bOpJf3maCyFNRFbvBVh7TxPrZZKsr3NewMA0RfT2+473GS D9XdRPmNEdJUAtpUQtpIOssSUiaoiYUErpgXBAwL5A7H42q6EXIb1SClKplRqOgqUarLqHHUh91Q qY14TUhIq+IqxJxsVGBDZVfh5ySpsrsWCLBKLfaBg2qxyi4IJz/YIKQqFgFizoJDXF2YQng+XXUO GWW13ZiLCWlcpZdtRskXI722muYNsmnQPAX33Uze9/b2XEp/BAFBQBAQBHY+BIQM7nz3VEYkCGxT BPw55S7qv6gv1Dn7gxeMAmnbg0Igfqo2EJNfL3kSmog8N2a5V5LsQWuR6mBEp1AlcrUjbTNtnniv RCFIfNRSlC4DkcM21Ak1ZwINEmdEYdNWBcmNgUkyKxlufSrhKsZscT3+YT8MgvJqF6rU56MvkEI1 Tv4c2DL21weR7oMNo2FSKLYyUDIK4wOhK5qTQz6jCMdMWj3v+0DVWQ1Gic75HBDAXfQRUKckOvyD WfTB4W5/0Q8jWG5IYS+zGhag1gV+Lp6P4kxAnOTvNzOfevu60rramkDJmO9Se+QfOTOXMnzdQZnf 3lKCgf76IDXD3cqFXBIkNOzNdhznuHQL9FuJO9aJucnn4n3I3Gyo+LJIFuOzXFDfdaSfuchQ4bVv AHUqoJrIs7jPy0HamPrx8W5xMuiooUJyqUBinJDKOs55bBBaJqY466i7QiLKUtekDFJRMlCXFyeZ oMKyEyJlh5AmuByrDIPyrceEVXZhZ5qamkpEm+7zc5uaktLo5LFGhDShlpwUmDKnDDskNehQSRN/ FKodJneUFzdYjRdHoS4b8VZSn2WQgXrZhjRBSNm+NZEU/I00lpCW4u+HZaoJaXXjLrZ+D2SWF1V4 QYUxTvLqFlXoSM5ZSsvS2pYnx8QVknpXDH/vLjhV2sSlBtvA+tgBU/P2rSFWK+AFoVMS9rOpdU1S tvRvoOWDkJKCgCAgCHRcBIQMdtx7Jz0XBLYLApBSuSmkg+h5xpBl7ocp7SBMYnfDFDub3JjJuRLz UZ40g/9QXcyAxGc15pJM7pYgL8DEdzmkJkshtSnDVL4M9VU0R6a2y4Ba2Yg/53mQisGvkDttOOnB P6Gae1KrAlE8jrzpd2F6PpAy8Gpl6zddXekfMetRTP7/QYavAOT3C8rxusgz9FT6gSY16kpP90GU 5fmAamOLQASHUK37KMrSXnNUZL3gSQxzTZT8e/z4HQSCfw/8POJNR4IY9qAedX/KyyL/sNkTAz+P 9DfUG9WeAPbHkyd8HI69vSVDb4Z4N52AL21aH8hnIYhwemBG8cLkOX/RVDwn6dc649DNewOzR37f 0n44EmeHFFbG6WBtZheQUR2SUDvuHMcFsmgwfeDzFhz2ZIMz+yiW4FGamQVywvaZ8fPscMghoI4K Ku/DDhUSUsey0iGUbNvZPaGay1cx6lBhxlPrKOiywyEQUMgRcSwpA0WdLPJmqSRKe9BdzkkOmYkq 2NkQp/govMg5DRg0tVvlE80R0lQ70k3Zq7YU3GbLJaSryfrjBLyFCWNOLv608AqnmLMYgAtNSEtV DJKtWzeWbLaBhS0q6ZDmOng2LuvBMwGXSEQvVDVThQKpLztn4nOOqLohOW6ZHM0DJsFcJl6vjZuj sGYCayI4at7J9lhpO4Ja8J5LLlU4asoVCe/BiaqxUBL3JGw6JJcXUVwxXjqJL2qFfKivMiLOm7bk gZGygoAg0NYICBlsa0SlPkFgJ0AAk/p+pLr2AOk4mGLePTGF2YM8rAbIkhaW+GFWy7mW9fCUFZgP MeH7DhOk2ZAOLcf8fDHIBKty7kSpPxMBl2OPqGkp0qbkEGEbaCtzEYHiVloXZju3YyjTfTamigEK Rd8DeZuFyeiblO4+herrT8NVjcmgppzrkIia6CRWX/UPm5XpOMKpjZZSbeRmKGRWkamcSV28x1J1 9BmQzzGQIP5KbxyfRXG12nJoKl7jHzbztcDPo35yesW2gqxJalpN3eJsm/tiau+C6uzpHzhz78D8 Ud86jYShXupOSLD05MpBy5oPTCtuSkDX2wO2rIqtLgVCmgGpqItC4XgokJiLpZ1wVoRQI45bIBdL KzHVZzEgjkUtSEitdIdScFIx/pgjJY0TUs2Ed9qkvSYIKHuqJRBQlhzyXtwWtJD9xDYQyriKbmoY E5BkG31IqrNu9TDjFcQJrhvPEfdpyxJfybfXu0XixHgbHkeCyw6kNp8UJvQp9q7NXbEpEtsc+eY6 uP9mM38mznH+h6dLKRUzOW8kNU5IpC28GpKSbH5HmjaTXIOglewsMpjQeCALkkt0hBc0lIygf/fv YSuLhYa42nYFKuAFNSbJTDZZXR5PE+xlOViNhk6aBHtlPFUxqCenW1hcc0FpPFYPchknn7mVsIG9 tD5QUrJ9/u43f9ekhCAgCLRjBIQMtuObI10TBLYXArBJg81f5lDYPx1FujYGNk2jQUSyKQuvCJZS 8KQmAt5XEy3D9kJMaWaRocyGCudcTEBKQPwwgekUyXRUEKEI2XS0gZ/3fBLHODvJXzSrhsKxs0HG WAoRt01UrKeoPnoyVGH3YcIdmD1qsVN22MzBcLJyNFVEopCuPpOoIiFbsqupvPDpwJqeYaiETiEl vAfl+nahiuDowMTAL/7dZ1sUsZgN3k9p7lsoaP0N1zPZ5BTv70aSE6Ij4rkVdoS1mEw+jt8zIXn7 HQjvOgobL0DF9Wunf2yzWJu2DyazJ5Cus+MZlpLNo2DsfyizONH/AOIsDnDsA9Ndd/lH/riOYlE/ SFF8UcCRHBu7gsQeRF51L+CyBvkpkOTZ7fnJASFldczUVLm9++uo+4Z8cftMTr5QDv/bsN9WHWI1 TVfMC8LbJYWKtqx2FX8TIdiiGnCQ1EgBukWX+9AeHEyxKu0mymv8EGnZeAfBnrVZIszPO9vKsrS3 aU2O3BaZVZPjqseNE8+H4irEDU6M+M9c4eNMvlOYILeN4y6WCCcS18fvyrQUp0p8SlUyG/0NKo6t 7frEtcalnPFfJoHJxMNN2skyUXX6jO7wcf675mg3vNjDkm5Tr+QwNdgpo/pMk9wvVvlHwGZYxSKS 4TjSWoM7VAoyCRVz12pyW/j7g4TVW1kTmDauGbXaDfCRA4KAILCTIiBkcCe9sTIsQWBzCDiePtON UZgoHEbBjP1Js0dQOuZKvLqf9MhZG63DxGMhohFMwQRvGuqcEfh5jyWbq7uznoc07yzKcB9OIQPe O7V9MBEsh2rttYGfx8xxMEkLTqFa9Tsq8I2iUvN4HLk3jpV6KuX7smhd8FWQq18b44eJZ+9lFq3p yVPV3UDScxITxPUkRVM4puKbaHd3tH+Kf+ishwO/7Pn5Zu9DrQEVTu/FsPPMpZh+BSaj6VCx1Cjb kw5idwHGcx5I7iQQwWOhwvoiJJBVaDuMiagb7ZyMyeV5IHf7wc4RNoL2OFzPZIClYSMxKTUQY/Hf lBteQXXY5ucqpsBmEBPTKKRjuZC2VUfOApE8GJLM7zfb105cAIsGTQkoq2BLakMEnIURA86uGiVI 2tg5kyvWBQQ5haVBAgy9efwt5DUQXyaqtqZTTQiktpGHYcyzEO+UJb1x1WQdfzcc8zQuCVShquw4 c3KUXlk2DBtYJrOOEyeWPafhPYLjbBvrnIvb17JtbJJ8qk780XjfFZBd5zeVYSZII/9tmriOfyPM JmPlcKC0BhoLa9FlkEWb7beXof/zIB9eCpX1SryP5Flrw+dMqhIE2iMCQgbb412RPgkC2wgBSJZy KddzEMxfjsWkYV/46uhHWSkaj6xuWIfJgOaQv68wCfqGYr5fAz/FvVpK2hwCClRqlZNQSoPKpxsq g3D0oQ0C8e7C0lOswAdBsF4C4RqFcuf6J/j/TY8eDLW3jNMhZcNl6tONWuBJm0KFkN49AVUyDlZ/ PEhUJpUGP6RSz8eO0xn22AMflhQx6uDU5S9kpB+J+/c3v98/hV4/btMyGp8XTkyogrx6LkWjk6nG +Cuc9dRRhfUY5aedgf5fjr6/jsnjNExyj4Fkbx48gvJkNJNq7GehsjqUqkO/C8ze8wWoUxZB6vkp VIn3pLB1AhnaZ3TKJIsmHd0TXjvhGIVtyuxnKFx7A1RHMSG2PkIbw2FBug/qEzK4uUdLzm9TBBKe hVdtpJEl27TxJpXjby6pa8vSX7Z5tSANhsSTbWTxFxuLZWJhJcfxXhtFTNa4syUO1+N2vADbCNGj OM6X8vH+YCkqvAw7HoOZWHocVd4MkFsF5wmehxUqdsgjSx9Z8x9+vpAN/C2v9u/xw1yoq8IGGJoA uutnqlfn0vDuawMv5W25/Hd7gihtCQKCQIsREDLYYqikoCDQMRFwVEDDmeMxGTgeZOIQTBv6UWbC JIglgHXRGKSDv2GS8BFmA1Mo6pkK4lLVMUe7Y3sN5y3XQsLwFxAzL5lpx8EW6t+U7/0blQV51f4K p3d1wUmYfPmhKlpM7x5dRHkOIS+iqsgnZLonNxoB3x+F1czoDBA8lhzMgj3iC2S4oTZaXOVIM5Jh 2nU9nW0F/cUz76Js3830yrG434iZuPnERJK14P4bWDyKHWiQf8QPH0It+Axs9qXVP6qUO7yesqKj QBrvw7SUw8SH8BzlQBLJxTEp5VSJAPUZcfVZWEg5nhsnFkNddiYOQNoYZj8cxkNwluGoFMPZTQmk icMhORW7ps3fIynRiRBI8XrK0v+masotRgKLTQrN+4NOg+4z6NfLCmlRaXc4t8qlOqMn1ZmF0AbZ BX+UhQgLk4+/6d4gg3n4zcaCD2glDMRtnFcUZDrEMRNgx0zpVjUtWvGrf+TyX7BgOAcLQl/Sfr3n BSamteRd0+K+S0FBQBDYfggIGdx+WEtLgsB2Q8BZWc409oUt2XEUyjwcH/SiBgkgE4zqcJgUbTo+ 9h9BpjSFloUR6qB9xtzbbqBtUUPmBhMff+HUzMCacbUJCUME+69Qt4y/YXIF8qT0aaj+3E9W0OvH fwivoqdQeegPIFU9HLVPxXxiA9f3LE2LmEsg8TuEvL41dPCketgJbswIMK7GlhW+m+r1U2HPdCPq rXdsijaZ2AyLtcyiA/HPLKeobQ1NeIktoz/OM+j1IQ9Rt/RTaG39S7A5usUpY2jPQ9q3J2EtIZH0 uCocn0O4hGQKhyEVZKegTmI1t/XleUvVNtfBzfRfTgsCOw4BSOBZWlcbCMT/LrHPUr0B/FeEvATH oziWg22W3K3GfnXT3uJ8bxxjKeC8ZD3JMjjHf5z8txnGuQ08+CbaZOc7QZxvpMGReFfE/H5lL5yv wflm7XP9d906hHrnuujRw6tAGHencmsAdc2AZ157CCSMbAfM6uksXeT3UTb+xsdQjwx4l8b+6lqD Xvl1nn9P99eQJn5ML/74RaD4vHXo9+5oMwNtsnmBJEFAEGjHCAgZbMc3R7omCGwpArDf6ovp+NGY lJ+GVdt9YPvluLBznA3URjn8+rdQMnqPVPM9OvqtnzdBLLa06Z2/fMgAkF7dUadS1ZP9w2fDAyTm aSbADRkvkTftWv8uP3WnqAGPqoBDzRgP/AcBd2xbzyUB4sme35j1IiSyp2AF/jJyYe5YF5lLRvjD RiBaYGjsTZSjqId81YHZcGQyrXhDnNmuiMvFuH9EUEWt8Q/94e/QHmVHNCzy48ObcPGomA6BU5X/ +Ud8fwAmeBGMi+0HmRQ+7/RXmZUbd1qhFFBMPQHkcXeQzT3jznQcJomW9Aj2Y/CgigmjcbN/j59+ hHrp42R4q3Cd2+mj2SgunhYfX1vHytv5H0UZ4Y5HAGRnV/TiNmQmYschmzjGhO/3yFXI7Pn2VRyD sS9diTwPeQj278bf1G/JEWD/TGz/DpnjlurY/yfOO4tN2Oa6/4zMiyu9sP8pzr2Sci2vslyDfGoi z22KDK5hxzwXId+a6MtfsX0z6qlIEM3jsd+Tfi3dhfZ9lvv4GvLhXK9DZFc+nUGvrXqIjuz7Lc0u PRp/01EqTM+ngrQ96ZyhbnprgU4/lQ6hu8YPgTr4JVRlVvnpo9fomlFz6N6Zu6EeIYNNb4rsCwLt DAEhg+3shkh3BIEtRcCRAqZHDoakBmp99tHwZpfnTLKZAzARse0fMBl/Dy4H3kFgq1mBWWPiTu9n j9rSpjp3eZ/OxGolbGr6gBDuDxVQON0BY3KcMlhMAN/E+TtA7o5w7OOC8OxXF32bIrEnA7+MwrnU 5PkYErXPKF0f69joWDakgnH1yYbkMqOoFzHVFA4wvzFVSqiOqpXoAwcKX1/G0l+AJ899YBt0Plbr Wc2MJ5rNJ3ZhwSpgtv0qnpMj4SimF/q8HFLLB8g392GiPZkUXk2lofvwXMETqOsgqjd+Ajn8DGpj e0NS6EgBnXAYI2bdC6cwtyMQ/eGo8xAcfgUOZJZTffo6jAVeKlM8PCpQNXXGh4DjkgSBjocAVCyJ Sd1QZHYhylK5i5H5/foEky0eEgjXP/AzGftvYPv/sM3kz584xxoDpyBfgPNVOM82w3sjf5qA4xj8 5uHc/+FcX2zfjd+PsZ90KNQdx6qQ4fSFPZ42m0bjaAjXrMK1/bDNksykMxz+SjBZY2/HByGPRX4K meeG5yM/So8u2gO/1YEBZzzgfxbXZ3gfDJx59SLU9S5URL+llXW4zi6mSfPy6NTBHCYkB2TxIhrT wwTBrPGvfG0Z/WPv+wP392y1uutGxiWHBQFBoI0QEDLYRkBKNYLA9kYAUsBBmIifAHXPk2CSNYoy eT6ScAJQG12Dyf3bkPa8QmHXtGYCiG/v7nb49qBGa/i7zzmF9BCcMGA4rAmZVIbMDrNzmLC//PkP 6JDhsA/0wqVLyIQXSMcGr2nC/agDiT+OFG8WlWFe5/VtWC7ieYPSPFMoA947D5lUSYENpYIgYFHU cxL65KHli+D1b4zTVELd9HKEJJgImaBJ0XNxrqT5e8AB15nUxqyHyfBcQR5PLi2wg4E1I6ocIsj1 /TzqF0z+DqF3jsbkMxf0LbyWToVzmI/P6U56uEHtLfDDni9DPfYDGto9ndZWRmGDWMbXox/j8OMm n+HsO0k3f08x95/JKN9Aba7DPywygJ0eAZCrKfibgGMVugs5qepchG3+W74Q51i183lkdgADL51O YskdS8uSidVDWWqfjJ/J9a1XKY+XTS7ksFdPDgHB0keHDKIPiO9KD6AtVgPdmPSf1TV5QSmZkhEw +Xob1/KH42xkh9zimIFjj2H7Mvw+hd9jkT9JXJxHdeGLcJwXcGYFep50q/9R2CV2S3uEXpk3HgtA u2MBsivC0gyAVoRGvTJzoQ5/O/1Uc4p/ZPndgdm7v5DSD9kUBASBdoKAkMF2ciOkG4JASxCAwxB4 qHQfQqp+JqRJR1G6N7tBya4OzERVvoZ05yU463gDLsGTE5CWVC1lWoBAwrFO1caKBvLOitHsRFy9 zdTHhBBFNrpaniDwIaeaZohgsnqUS0wWN5T0gowmvCNuhAiG2J4vI8exJ40ZOYGfi0PgjPE2myTH lmk2rfe2yH2alrKfKA+7yWog0IjgoR/rSWCyXDxcAjKbV0kSBDokAkwCDfxtxOOIxiWE07DP6qEc 73M8MpM4VvfkxESvBudYMsfkjYkj18HLSyzZ74U8A+f5HB9niR9LHjmxRI+lf2U4z3M3C+0ktQEc PZBEuaY/7C462T9ul69Zv4ATCCzHPkscuQ+f4vc91PsdfjlW6VXITB4/TJznaxchz0KZHxIN5dLa II/jNnpx7kNOP4Z3/TftWbgHtCPOgvdjLxzU7IHwRM8j9ujpWEn6M94HDWqyG+mzHBYEBIHtiICQ we0ItjQlCLQWAUhWhpLlOomi3pOhqjeMTdfijjowBwgZHB/qPTKVF2n5nC8DVSAkkgSBliCQqVdT RLmfqqO7wNnQ4pZcImUEAUHAUf8cARyOQh6E7Uvw+ybyk8gnJWz92FaQyRF7Ej4Xx1gKOBz5AeQD kNlbL3sY/hr57zi/Br8rkKcg34zMBIvt90bj3OX4ZSL5MjIvILE66Z2Ja47ENvQz6QzsvwKSNqfJ /fkZ+2yTyIm/DSxZvAJluZ4ZyAcm6uTjnyMnF254+37kv6HOEMozqeTrf0whglwnE8RMHFuJMixB /Cv9Z9bFgbxjH/S/82o6XTa8L6SFo6F9oCJUxTEUsveETfM1gV9GNNg+Numv7AoCgsB2RkDI4HYG XJoTBLYEAf/IH/bH+vCl0KmDFFDPigcSRuJ4gDZ9g/XkF/F9fi3wQ1IKOGJLqpeynRyBhOdTx35J kiAgCGwRAiyR/wz5XWSW2LG3z8kgRKy6yYHf38d+PFRLnOjlI7Pt4BrsM+FaxiqZ+GVSx3aCLJmb iWPw/ul/AtsxbLNXzhuxPQT5a+z/nJAaBrDPEj2WRLKUjckieyNN2hKmDoQJ3+G4jh3JsGSfHc5w X/hjshqZCWd/5F9QP5dNJoQaosO4n4kDTAT5XdFUrfufOOZoE+D6/6Ad2KZTKX5Z5F9B78w8nw7s ewiZxj2wYR4Im+oepBov+vf9On3QW0c9V1AZ6gEQeuiqmonYo1W4Zu2hAyJLUwcg24KAILBtEWgg gxMmTNgfTd2JzKoIkgSBtkSAP3gfT5w4kT9CkjaDAGzAckiPnIiP5jkouj8cwsQ/2+zNMRJbi3VY SAHpBRq6y5cS+FceJ0FAEBAEtj8CID5Mxjg3Sjg+Hwc4NyQca+TlM+EApoG4Yf+bJuWTBIwJFpdj 6aGTsM+OatjrJycmYZv01onyK0DM3ka5/thmlVW+Nnl9str16t/r2+HvNhPbZLusisqktlFiwtqk 746GAdpkb6sfBc6CCu139C6+a99DleVJ8tmHuOs8atefej7SpTp8jW3q3RCPJlcxVZdtWxFbU6om L9DnK2Q9o4aDrx1arDR2rNW0A7IvCAgCW41AqmSQ1RaGIbPagyRBoC0RuACVnYcsZHATqEIVFCup rtNA9s4jr3tgwu0+u+nHGrH9I/y7QTVIhxSwOD5RYOUfSYKAICAICAKCwCYQAGFj6eV2TWizUagc 2Dav9E/49wl5D534ad+SAb9LW5fmUlzasHB6iCLeICLUmPAppXu8QV83T9TXzdLtfY007dKPFsQu gKSwqerrdh2LNCYI7OwIpJJBXm0qh/SG1R4kCQJthgCkziNRGbuZl9QMAvAKOgbKPheCCB4PW8B8 OIGJl6ozWBeUVXWeoLTaD+Ctkt3wSxIEBAFBQBAQBDocAvufeEuxmWb3gZMzCmcEadWglVTes4xi PkTRUS04x9bIE3RT/tKu1H1hD/KoGXtFLfOdjxakH3LogPoGKWWHG7h0WBBo5wikkkFWAUjGnmnn 3ZbudTAEPOhv0vV2B+v6tumuf+zUTAqmHYmwEOejhUOgChp3C24BpiBUQW3ldaiFPhX4eUSqDce2 6YzUKggIAoKAICAIbEMEioqK1A/mL7nB5UovrNMraf7ev1FtD2iAggCShaknPn2mZlDQG6VlBTVU l1dLA2YMIo8rs2/UqP89unb1NuyeVC0IdGoExIFMp779MvgdgQCcwgyk+ozXIAUcRi72GYAUg2A+ YsxFyIhnsfNi4PtR4tlxR9wcaVMQEAQEAUGgzREoKSmxyJU5GF6LqapXJdX2hP+dCOzhISVsSLxk bIEcmipV9F1Lwd96ka8qi3TNNSjho6bN+yUVCgKCAAyQBARBYDsgkIxttB2aav9NBGaPmO/fby7b AA5DoO9KxF/6lHqlPRl4qd/77b/30kNBQBAQBAQBQWDzCMCJzG4o5cRY1L0ZruHH/CmmpxVQRkUm eSozKJJTj7VPTENZMphMKhihy6C00izy1nvIwn6wcp3qf/KOvTbfYocrsRK2lezRVZIgsEMR2GZk cELOzALDGy6spcql9685tmaHjlIa39EIhCsrK7vgw/AMOuLd0Z1pB+1bcKRdQIf2I/p+bZR+rGF7 3RPgs5vjPT2Ej8PCdtBH6YIgIAgIAoKAINAqBPC9PwUXctxFDrtBRriOFn/2OO120MWUFcuk3b4e QsuGLaYaqIRaHjhJg80gSwQ1SAtzludT75/6ki/ko1DdUpr30UMc4oLzzpaWAKexQgh3ttva8caz 1WTw+pyp/XSvfh7Cn40yTItsy5oSqqX/BnXrXC+57nYZmfuhTKWe7vIbodjrd1aMe2FrYLo+f3pf nQxVL/hkycSSAAc7bZSuzf98ECKbXudzq7kx00ozTYq5dHprWaX14nORceGtaZuv3Vz7W1L/hKI5 Wt3q0t28XvfJulsfEA4bT925bh/Hgc8E6NcblY8OwrLYSXqavls0GH3+H+vGNfLOlWxrQs7zrrDe e6iqa6fomrJLNGI8cGfZuGZtza7yvO3zZWbuoWmeU2zbzo1GrX/cUzWukdvrhnoL386MWrm/U1T1 ZNO0bXi0vPXOqnEbuKBuwZijkUiESeA5atc+pLixieo2a0bYYivDRMFNlt9UGZzb2LWNjm+igQ1O babzIZx/FV7B7axulJ9/mhWsIDtYxVCyq/L7WoCpFBEEBAFBQBAQBNorAhwbMd2970nkHnMc2aE6 xMFQaDU+ed1XLaHsNS4aUlFEtV2CFM4Kk6WbpEU18tX4IDlMQyhCg6I5Llrday+yut8eZ5QNKfHN duYRyalE6nect5P7TX4brml6PFlRSj1OHSnfcmfa0mTu0nCscfdSOrbB/VEUjUKfPkRm5cq+OMnh 3EQ62F6f4k7Sr60ig9d2+eJkt8/9qGlYVZZFz0DQHzJJ3cfnsz5RVTXqYGgg1ChRNjTDRyCk6vSt xdWyzZcMVcm8vSQwtLm6dNKHerPcl8TqomjLelNR1KEgWk90z4wNp8jWGyAjDs7LaD8N7XMYjq1K 4dWVe2gu118URUmH/dhhatCYjQodMmiU/rc4pugTXJqSRm79CCtolOBws2SwTu+1r6bQHxSyc1Wf ez+KGeyBslky6EvPPdom9SyQ911cPtdIy4rARo2aJYPBaO5ZikqHIRjs7ppq94/o5oMo2xoyqNhg 5ZzSb3iR3ANGkh2BY8zUl2wSyaYv3iRLc97Hm3u5Y22goVzTj0HKfvIFn/xY2InrGh1PfADYoYvT dPL61D6knkvpX9O+Jk41MM7kt4V/FZuUtFwKvn83hT57pKHk5h4srCb2QZn9saL4NLZHYPsk5Frk 55HZ6+gfkflv0I3M93gl8snIvblV5Mc5+PGm2kG97AF2HPI/UbYe+12wfQkyO7vh5wChLogDGZ+O zB80ru8ZlI3/7SPhGjaKPA6ZJwZcj4FjrDbEQZI5YDIHZX46EXw5ec3wRF95/0Oc+yq1n7i+e+J6 DuDsxOfCMV41Hpuo8wkcF89zqaDJtiAgCAgC2xcB5zvgKhpL3hPOIZtD1eObVx2pp9jqJZS7+FdK L11J2aUqdVmVhukahAmaSiZ8qUXTvVTXtRdV9oWJYf4u8K+Gz1hy6Z+/18m5QHK+4HynN/bNT3yz uUzDd5yL83e/6bEm9STPO20n6mlEEJPHEp1r9O1PuaYJ7ormpvC3LxNVruQrNhBqbN/bJK0JAlth M3h9zsxC0vV/W6YdLquyDngsMm5pEtAJRX41XHrwwWZ8Zq57Y7TciBifGJb1PR+YkDPdbXitC1VF OcAwrHrLtp+AJOurCXP8Wnj/Q/8PfxshSMRqXC7lRFtVFhoh4wFv90/WBEsPu8Xr1gZHY5ZrQq/p rweDxlN3V4zjYKoNycJ6EkUgDjSMl++u2O++sSvfThu3R/6ZKLAvJowKJon2tTmfj3a53We5dLUw Zpjr7GjsmTurDpg5oXBqWthQ/4z269Gfu7nS6/On/pFUNZOi7kcsPXyl26UPNmKWNmGX6a8F66No f793gEWu6o1eAdI0PBajtbFY+OF7qg74NX7919fBPrpbuMb6+/2RcVWpffWS/hPF6LQaO3pSVkjj yWwkeV43vHP1QXR63SLjqIxg7Aj0qeFc0wc3w3BPo+4XfhEs/d9lrrCxn2oliHgzT7jXTe9MXLPP pD91+foOvHZHgqxzYNlmU6S+8un7I8c+/Of8r15QSOmJQnFGtzVJBTdI5jYng3GPZOs/Ck2IWwP5 a/oBSFzXHBlsIKNtQQZTPxhJEFGvCm4Fdp5ISaq4OZQLUeAwPNNv4jeA/DAyLyaw59YeyLsjM3Hb B/lW5GuR+Zl8HfnvyGch/wvX832txt9FXWqDOM7XXZWo6z/4hXEH3Y7MAY75b+4fyJWJOr/EL69s 3p/4fS+lrkOxfQWyj9tD5uftBmQmgUxSb0NmNfJJfA3a7Yaf65B54YHbxCH/MvTPia2YIKQ8Fv57 4XfONzg2Cr9nIzMOvEh0E45djmu2WhMgZRyyKQgIAoKAILCFCPDCr403vF0Lz6H4umHRmuq79aZg QU/y1FSSu7YSEkHIDJkMqtD78nopktmFomnZaAkzunA92VAxbdDeSUrmHN6W+Fy2hAw2R/xaSgZT SV6zZDDRjxaSQdKwDmpt/XRqC29Fo+I5YxfkUTjspUHd11W9lIcwVpI6MwKtlgxaanj3tHRPz1Bt 9LlUIshgsvomSFQCVz0SVql3Rob7MrsusvD0nOe/Cut93lBJKbZM8z+KqhVjKvzhdV2mXoLp4It0 gH2GN92zd6gu+iKkjEshOLnWdinjqfLgo0m1V+B9Ad06TCgVZaFlGVXN3Dw7Zlimy6VffH3XaXvq 3bCspNFvpmVPYCJ4Xf7Uy9wu7z2WYX1pGPZsTVEOtDN8F17n/uLkRZXq590znQlwKbJDBjFFPxdk tTei4jyJ3ZV4IQVt1dZh8LwI0s/Kq3Km9oZHyPdAlqKWZT2racrBUMH8AuM/DoRyGojgEahjgM9H 94LqNervxKoxzsrZdV2/3sCOzjkH2d71Xafy5H6TCWVRcwmI5+bt8SauiavKgo9ttl4QQcaaiQpL l+w2CQ6BG+i8BDm3ORncCPlrWDFssrK3oyWDDrjo08aw2PRtZ1LFZImlgF8gM7nLRX4RGZ7XsMxA xBK0/onneR1+YaToSORY42ZKQmp3J7bZlrOp1PkHHGMyeS9y8j3BnzommlwvSyGH4W/qLe4m6uI6 uU188RslfhHMQ2bSx+Uy8MNxJ//Ikknsf47tEcgOGUTaE9mVIvFbgX0mtg4ZRGLiOAGZx55k0Pth ewVLA1EfS0BPRO6L3KzEu3H3ZE8QEAQEgS1DAO+ZAbhiON45r2Gb32dYsCWWfbFmBms88LuT34f8 znw28a7LwfZFyF9if+bmWkS9B6MMayA9gPIx7OdhG/FoHc2MEn73JrQkWOODtS34ffcmjjdImhKL fefgOGtofItzn6a2i/Pjsc+Z63wK5xsW9blcYpys+cHaG2zC0CZJNTD1wQJoJKsLhXPyEw5FeVEW mjKYIyj4JqqsUyZCs63Gu3Dk3IG6l87UPNrAWNQKk2m+mV1tTa609btUr35EcFnl8B57lw53p2nH 14UjT5RNK57V2kaLYPpUmevNx9pvZM20nlXN1dNr7NzRiqacbll2tqIq8BBE5eFYbFLZjOJGGkCt 6UNL2t+Serm+0lwa5NXdJ9umnWNqsf+u+bK4wadD4eg5e6su7QK32+WzTOvTCw54njWjNljQzzm9 3OVdtnqoprpOgkTaZdqu/6yZNqBZLbvCsSu9ul67B1ZGTkCddeWVxn8iJcXNYllYNCdDL3D/Dn83 x0Iwt7ScSv8bmdY6c7hWk8EGQBU74Rt/IxDrBv7CdSMWjDEBqe5NvYd6PfqR0Zj5k2Wp+RaehLRs b1qsKsgvnBeBYjgcjC3yGdoFE8vGRP6U/3VvTVVOAHHrcnfZPo/+Ke+rC7GfMXH53pDgbTThNaNU KbYd1XV1/7BhvXD3unHvF82Zoyn7K9dDrbXcU7PghImR88Igcz19Ni1QLO3MXKqYQkoX+Du2Gya0 6E8lCGmON5RbPzFS/L/r8r6+BOrevokr4+1f13Xq5d50V3G4LjrFthVINWzDV5CWHyutOwGnp/ny PzpkEp2ilJQUt24ZyEp1s7Ulj7GU7QQIOH97ePncg482e227EZknJo8i87IqT1CYLP6VJwgow5JD /tgfjszS8tk4ziRyg4TjrBbKEwTOyWf3b9jmv9N9kVnt812+EOW4LT/ye7iukSp4oh5e9OC+Jn95 spIkck3fQU0l1TyxapjcoD4+z6qmqf3i/iXr41+uU1RvmruxckwQEATaAgFeWDsS7yE26+CFrjuQ WU2eF7t6Ie+B/Afko+OvSD+/O69HPhaZSePMxGIcL+DV4r3WoFqfeKeyiv5fkHmh+CGU5XfcP5HZ BIRV4/+OY5irOItyrK3Bmh28sMd94H1uFLqXdDPyJ8isFXILjpWhrR8T50fgl0nrXchFyBNw/kqc d7SQsN03cT1riTCJbDMyyPXHiR/W9Z2vSxPJmlNA0tYiUDj61ys96a5/mDF7Oea9H2i66jNs87LV uaHZaXYGq2lBITdsIKTVUAg3TnWTyve51WRwEcxS8qzYD5YSnUzUkxcuNkj4MB/eJT/tmsq1wY+g qTsH9358errnCvfYX89bNW0IL2a3Oi3KrfR0sfN/JDuGuUnPi1tdUeLCymz9BJdtXwiHtn08ma4h 9VUmxkUOGSzc+9dzoWEIDSb7cyNm8iL0E49+fPo+IWP6lVUzxjSax6QtW3u2bWunqKpSpGp6XzMS 5sXvZsmgSrW/x/060OWivbEs4snNpafwR13VdCxMMGmZ/jfbtIZpmnq4rdjLc216HGVbpRHVajKI xZv54bpYpapqB1zl+WiX+yOHNrwoJoyerofxVDRNjI7K5FDB/M6GhrgCTzC2vYgMYyJURufSKZgw 2opmW7ZBISiSx98RMNOzG0TYYHnpeIdsqt+KS1fUYMR49+6ycf+EJHBpWpZ34vX0xTt3Fu/30jH0 lYHXjotyITABatCSzHCpHlfEdJaheEap25baYKuMP5A0aCDYcGuFZSz0H+1j7OsJsAWKyyp+Npn4 N4Iz31FdZA4eckc0Om/1IO2UQbXKxE2oWEKiWMsN473YSFWPr7dUSEL4HKkN59jxDLxzpuf21sMT Z8Sli05Z/iDwVNhwpCdOgkquTl4jjcLLQhOrzmrAEc5j4lK/2HrpKjuiIW9vH+WC+DYmr/xxgMR1 A6nPhjdZjmwvBPhvgCcKhfho8+oxf+B5YsKTEF4l5o8+f+SdhDIsIeTMUjq+zuYVLBxnFc6vsP1z asdxnG0AmfDxxGY37PPzx8/BS8i9kfdCnozjxfi9D5k/IlOxn4NfnuDwpIdJKUugByfq4bK/If/A 51H2Tfz+DnkStvmX22MVUyauLO3j55Wv54nTefjlt8rXyLsg90Hm/rNaKa8oXottVhFlLFgKugRZ kiAgCAgC2wIBfjfxQhtrKPC7k9XUX8Z79DO8h1h7go/zO5rfo7zN708mjHxNcuGK39P8jmQtpKb+ FKAX5Ghx8CIbL3xx4nkJEzxmTlXIe6A9Vs3n9zvXxd/0+Hc9ngYi8/ubpYW8gMZ+B1jzwiGDSAcg r8a5n3COvwtHIfdF5nc0J36PXonM2iG8KCepAyFQOHbOCJfuus+MWd8b5bFD1pQU8yIE5Yye7u5e m2lW5So6Ztdg416XZRjfhYLGs3ZYdeYBhWOnprnVbudpbnUoNO1W1tVVP101e9SqwqKVOWpu7TmY s87B3LjQl6bvHYlasy464PlnH/n4nDzV1m4G4SxULPvAHvv89kDUDj1UNm3EL6mwYcYcC9ZGEFbZ nlA2Y/C3OSPn7N0zL216ecRgSbhDBgtHzx2juezjdI+WYUat3+qCxktVs4tLITUrBFm6FJ5nZ676 ashkT9EcX16efgXYxBKL3NMVpeAGOFHsBqnjQdx+MBb7b9WM4l/RRmFGmn6+y6P3MmPGr1HDeGbN tOK6orPnpNcu0f8PvorWXnroi89MnNhEqqcaH9tU+X40VnCzHTSGWKrlzKFzTp/uVpbm/AXSuJUr v96N5zrUfe+5BaquXuLVM/nvhf/WGpJF2W+ETe8LPip7EOHELtDBfTb2KFlkPEFK5QOxaMHb+Mvf A3/RzS5sd/9xX3N17qS7yeu1fPWxqeAezEs2kEq29JFtNRmEB8rF1+V/fY1bVx5Iz0n/6C80zYmR Bg+exeFF9g14WBRvFoyAa6IguJbmyvBSrCaYE6rVf1PI/FLVlX5uSNEgHYxFg+YASAhn0itk2f+1 eSIJdYjc+AtQoWyvW02vj0bifVXs32A3eNJNPac9Gq2PPAtbv6Q+qnNahU8qwlqHEjJ4ksgWhI9E aqM32rZ+71WFb79vGLn/8bm0ByIGvfeXbtN+UBTveIisV6ph8yFWi/wzfTXD59NP/0u3r/8H76he VdeHm1GzFJrVTn/Avn/D9SdO6DH9kXDQeAb2jB8ZGs0HM88HwQpDEqmEgrG+8JL8BpffxdX34/Bi a+D1nqmj74yM49WDhnRt/tShLlW5QFW0Pcmjk+Y2L78h/6tijx78Zzjsy7Zd6pW6qo+AcxlyRa2L YLs3yGd4/hkuDRZn6q7PQouth1DZlVBJ3VN3aWdaprIvl9Vi9p+uK5i6T0SrvCNo5J6UpruegbdR Xpm8/fquXx/odalHRaLKUWq6CzNt+5brfFO/TSv45M5o+aHXuXXt9nBpJU+8n7mx69fHu736uFCQ DoL00+c27Luvc0/9BlJWtueStGMRYPXJV5FZpZmfzdOQmayxCiUTqDfwgfckV3mxzwsETMpY5ZIn J2xXx5MSnlw09x7oi+MsAfwYeW9klih2RWaSxmrD96BudovNKkbfIbM0ndWVeFWaJxFJid6u2GaC yqvT/LIvQ/47MpNQfom+hXo+Rz3juF5sr8M22yPyijq/MO/AsVIc4zY5cb0HIc9H5jXlvXD+PZx/ AttHIjMGtzZdaU9cKz+CgCAgCLQVAlriPXMD3j8sPbsGv7xIxir3rEp/KjJPHv2JclGc5wmbIwvD sWrss6bFBhPDxDmWMvK7mRfueIGMJYX8nuf3Jr/LWULIRJDnTLcgM+n7PmVw/H7nyWGSfPKpVE2u 5PnkJanluH9MXLl+7sNGJ6+bANOZOLPvCIvf2poGKSDmtc2Zh2yiEjnVOgTADQ7KyUvTS1fXv5gk glwTpFbRKvx2Hxu3oqis9EXycmv3Tst0XRO0gu8Wjl1QqVD++5hVuEEEJ+OhOCYzPesi79gfjqZw RiUeqFsx3/SZpv0SvNFnutzqHx796PQhWGG+C9IQ3GQF951vsoXZqL6B5iCEKbAQs+EXUbmp5z5z f1VU9951tZHZuq48wnOSRz483Q/zrb9ATfITSMhWq5r216ws7XIau+BwncLZvsy0QG1N5Gl0fXKP XEqLWnSHbatf4Cn/BiQUE2A1oZ5teWF+Sr3Gzx1CtutdRbGXghh/AweKcLaonVs4cubRlYty8Qdh 3ARHiT9OmnTKc87jmpJAGB0C3X3sb43MqrzLMvPg+LHQtswG/qFq9gKXrsG+VecFmEZkMKky6xtb 5nZER5tIaNPRTOwxdq7LEYZtpGxJSQn+mIrLC49amQm+o6Nc67QPE/W3mgzy9VDbfPra9M+/dqe7 T1M1pQjOWNA55ZVlhlYCoVWWURe9F6wWtj6qyttYSZgBJyr1V9HbR2fm5p0FUPaBGNTWFXtKpEb9 nGelEKM+CiKZST49ytM6lHkpHLN+gqJpJbepaqGrYmbGXLemQDqhb8CYdd34yagJ3wvlVZ58EkIh rANZulzX1FG+cG4u9h+EfeICrF6cgLa6mab1plFpPX1n5ACeXFO4xr7ClWfPxPkROPdJNGpMwh/V QIjSHdGrErOviin2XLdLYemEfU/9AQuuz/xoPzDQ8zC+4ljMCkNQ+LqXljkrLIptvWEpSlcMZQOp H8B34wZigm0vDFWGv8cfRyb+Rgog5NUwDoRddReoiro0VBm5F6sdGQCja5gqXWT4lmB8D0F9dYpz Hw3y2lgNgWH2jyj7tcetZqmmkp+bm6uES41f8IfwEP4AecLODrvSwWi74SFDCJDI+z63lqMYZh7L rI8CIXdbGgim47kUyxG4D5bdDSs5r0WCsajH68rFQf7wSNrBCOBDzQsLzoID0jtNusPP2mupx1Ce SdgDzXT7X80NhVeLcZxzamLpfyMVEpT7Esc4N0282s2JyzendnJPk/7xS9V5sTbXNo49llKeiV+j hPNMWjlLEgQEAUFgWyPA9MaDySuTPiZmTML4/dMPmaWBbMOcfAcyoeIFu3xklhqaCQLHUjwmg1OQ l6R2GOeZCHJdvKjdG/usmrYamSWBbBIwAvkLHOdfVh/lxfhPsM/TKJ6MjkHm7wOrkh6C47x4xtoU L2KbF814PvMF8nXY5wU71trgOdZK7F+EX9Yy4TlRATKPsReOZ2JMrJa62TQ1WJSd139kLxuOYeAo j9QVyxCZCnYCaVlk626QwhjmRq0WYmy2fSkABCx440FSVXbUsPHkg9YbSkThp4OiKtW5reiRmbm+ UXXVkbdxh9jR25JuPTPHrF1unmB5w5gfuiLgKNNXTxvMQgPqPqZkPojRUYunDbgxJ+f5a3xFI8+B 0GTammlDNq6miYpBwHy47ncerza+vjZy3Zpvhsx4cPIZfVXVngBfG5+v+no3llSzOuYxmdnet93R 8JGQ4H1SXxs18ew42m/4AzKhwlmOhwk2igNWQer5J5+Sfa5tKV+v+abIab/H2JL/pme5+2E8nymK tRZtrironnnAupXmQbjm5ZyRC/p4vauNkpJxLSZT+ONh9UHVRoVJZBVbiWvmtUHCOHDvWjjVhv+l Nmhyk+qWLaqfyRDkDLzS3zQ1niTWO94MnQQJXC1UNB/GJuf1aSILB5yXXUMC4Xwmdf/ONYfyC/Gm jXXu9jUH8EuzoS0uB0cuz+KHs5PggZRX7po6zEj0DR4/V1GjiWqj9uNx9ljK1pASfWJpxgYJbbMK XbMJ5/gDcu5GTrPE5/yNXYvjrL7hJBBcVp3j3DhxDXEPkw1lgScTh6bkAfKacbyUwQTaIdFOvesa 47aJvsgpQUAQEAQEAUGgsyDAmhI8h2By1BOZ1dyZ3N2GzLM4JmYsOUxOMJmkHY/Mq/4sZWCtC1at Z9X9mc2AxuRsf2RexD0B+UlkJoFM8lhL4i7UvSIhiVyAfWZWTOLYppDb7IXzNTjPHqB5jsHqoY/g 2FwcY02PMLZZpZXV/s9AZmkKrFkckshkkskuNLScc3OQWYWfyaFjj7ix9NECT7GpaJfB39dxA8ae igVqzI4hI7A+fhFr0h4K53aj6r6ILVjYB4IfWNgkQk5tqk4511oErJ+gpQbWpbFGTqN56IQJfuWx T/jWbphADH2Obz2FcvDPbnB4UlpTHb4fd/E7H3ndEVh3QbLnSMxYkvfoR2ewNk5cctx9eB7uuAfX b8qXCPxGQj8wbP4dBPBzSMA+drm1v0Ot9XU8fSbbeUHLrmHRARVBlZVFP6pmwWU/tjUwsKSkzkBd GvwNxVcWjII8RYt5sNPQPvrig6kZLlMgeMF4sMhdsS5YYriJ/26oavYALIIM2CTIELw46teGYTjj hsCxDoS4Dhj1TV5o2PZuZhjeTaIuR5hShFjhcend+sQ+k7inRmVjG8CmZdnmMG3MXDhagfhl1SK8 M/h1EE9Ny7LUEVJe/ps310wb12AitskBNXNyqySDW9qYlBcEthSBZJi/uEvqxvouTetKepd2jvOr IfWNwLv8gkscT55vSb3OJc3Ut6VjaWF5WS5tIVBSTBAQBASBHYEAiBTb2HHmxOplqYk1M15IPZCQ qD3STF9ZrX+DhPKsAuqogaYkeDlwpHkNCeXexA7npsnR6kj0s9HiOY49lSyM7bewzblRtSk7zWqO NNfn9xe5LlRV1z2a7sq2jBhiiqVDkwtSQBS2jAiZkRDpK+ZT5urF8CQ4iNaMGA+jHg8IYWs0UJvr gRxLRSC7+qQPK+zXH0vPdF3Sc+zctyCJ+1pVdV80Fhvwn3ePvsHrITd8YOR6vWGmWt6MbC+ZVWEf /GhMCQWjZTB5IitmzVTdmlZfE90LDj9WhcI+W/XUdoEWWo7T1itQCkUd2AozSZmVOzW4K+WvhTf/ A3uMn/vnaJjgJXTwksZ3RkFbHqqvj7KUnGAr9s+c7PSDqyrsf2YffcLpVZ+88aLbrZ3Ra5/f7oPE byXUiy8K18cWRN30vm4YZbalLQZ5PAUkcjGcsuwJyWJX2Ds6ZiShUDiY5tHXuj3agTj/5yDpLyGS wGvRiHUG7PlCWJiYid/0WMQYbFR7l3vGzsnJI/1bTLp+zak0Tm7q6BEEdW+fxzs+HKXD0zLwLCvW VYVj506HKuf/CvcuecybpvvRz0cQFKUamoFnAK9HV88esKLHvnOvDHsW3NYj17h21bTBT3UdPXf/ 9Ex9dCRkj0/LdGuGW7uuMHfut2umDX4O/bwt6J53ZY9M44xVM4Z82GPvX4/2ZXqLQ/W0B+5BvjZ0 yM09+v/6DZzrvIWyT1Qrc4/JH0uHlk0b/H2PfeedBrO5Iugtwj7YtnY9ZMEERHiYtuqbIQ1CnZb+ VQgZbClSUm67IcAfjwiYHXxckQ8CcCwiOYmPMXnzNiMUdzTUEzQquSSElRqKQDfFB2td/B9XqGYP ZvhpqTQ/GMN6WKJNjo+0HVKDk5/t0JY0IQgIAoKAICAIbBUC7y7wnKVr7kfxidQgRaGsrn3IA5VQ iICcEBKwrSITzKC+eh2Fq9ZRzpIS5xu8ao8D4jF2RWV0q/Bv7uK4VKro0sK9574OMyOYcqkHGKYR UhX7TVo0r5SG7AnJtF0JsVgk27B+rK2OPA/RVwVCPPyGkAn7udyuSzWXdoppmiGI495FiINFoH3w 1kmPwUaPvdMSnD7a9sf0HG5hbPXqr7S0knE19tg5Z8FNyFVk2rCjNd9u2je41fiqpjL8PMiTI5mr rra+1uz6e+C7w1f5ySRI0Csvtq1uCMtmH4F6B0FW+GxtsPoxOLBhlVV2LnM8fFBeBRbK/gpeqa+L fsO6sM4cESEYouPnngUvlFdhbPvAxvCNdd8Uv4vxHKy7XRcivMYpsENku8eXu1O4HGNPx/ZXeAJh zjYJm+slcE6/Lb0PHtQDYO61pKYqXOLx6F1JMX4HddinLzt0XuCxj85YprvVEyG/2wV2jpdlVptP seog5qDLMdOcAkc3jvkZBJq7Kqp6AP4+fgrWRmd6fK5+tu2IxbGQpM5jsy2QVPa1AO1elaXw+yF/ hr4abo/Cfh54gYkXbVhKn4lonFVcFlXsAbK8O/58XoPZG/6U1L3hdJJ1AoUMtvlflFS4XRHgD0QI hpN5HpVOHeih0/p5KMcVp3fzawz679wgfbE6iiWt9d2Kgq31SNPogTHZ1CNdQ9hH6BGgonVBk15e UE8vzK+jIEhhYFQuHd7H55zDHy7/KTn///nLdfThknpKS7LORNVRqLcM7+al84bl0n6902l1rUGX v7+MVtcZhO61XUqILPNHjKIuYw87821v30GWERXvbW2HsNTUnhBwVlWUXBj759rqepuL9tRF6Ysg IAi0AAEFZlMRQ3O5avYlw9Y0l5tyewwg3ZPmEEBn+ZQ1dEAKVV8m5SDXwpStvnwVZa5YQJnd+1N1 rwFw9NfgFL1Ro5gKUAjfbgPu2bkeHd/t1AXipj2s47J8kfNt54VfLAaDj7o52BiOhnEuhAXeuGZQ wpkN6xHi2+/FvKHpci/vRwzLWVTm/5jo8uJy6vyjBSjt0CJrvhn8ATrAOSWBb0yjBkk1WEgj06k1 8MCJwlc30/EQ7LTYy62TAvC+if0bUstBavYV9jk3m5Z9NaiRORIIHNf5pyaF2b9Bcz4OaM2MwSz1 5pAozaayLwc3+B9IFsB4NugTi9mRWK2S1athHRbYoD5g9zIOcm6SBmPsTmwI9l+wgQ+DFV8NbmSO teqbQY+jHOcN0qppg9gUrsEcDtLCO7HPuZmygxuZsK2eXnTjxnDY0uOpkkHWFd+koemWVi7lOxcC p/v9rpcQHHdrRh3GWkkPn0rP7JtFYwpcNGlpmJ4GoWPJ3tG9PDQoS6cpIIP8kk5K91hylw0fTft2 9zgv9Yu/qKBavPD/PiqH/r1vF4coBr6rot3z3TS0i5se/LmaXgdBTOdKcW1JeZQ8TYhgLVxUnbhb Fj1yWA8KIRhJYbqObJIL5dp8ERMVQkeecncfRTlFI8Zb0ch4eBDaGhjlWkGgfSOQnCW2715K7wQB QWBTCLA0wgTRg0c7ywhTZkFPhwhaTVQ/42YWJiQXGqXlFlKwpozUYC15asphO8hmXBumenx3mcgd 1MNNfRESj+ncsnqDvlsXc0hd6npscj6wfw8P5UN1KMPF2kA2lYVMmrEmTKuwgOvFBbvlumlwLiJo Mfnjb35iIfaHtWH6uTRMuKxRMjC5KO7qo+HIPFmoQn0/rA7SiuoI+RKL1NvqAYETEdjFDYL3zzy2 yZMkCGxTBPQJEyYMRQv818gG0GnYP2ybtiiV77QIxA7qdvZfzViaPuKkFyirex2MbcO333472zgE NbiV3lxKqnlePSTNIYLvr4zQOVNrEK6EVwQRgG5FhDz4ZTXRpoSMr2XShkU8mromQvPwASiA+O6B cV3o4F189OCcGuJVQ07TVofps99gn8xvfqwYZuGV62JVlpRKefVvTmmEjnt1KaVhe9IJfSiKD1Cb E8EUUKxYFEbVCCoTlXf/5p4VOS8ICAKCgCCwgxFgfx4IQKyB6PHyrIlvWHyltnnVTwXk0YT9oM0O LnGtpbMCzIbmF0wED+rupr8NT6eRXXRoBZnO971HmkrvYx5ww4xqx3yjwSQEOzkQ1/Hib1GOixZU x4gXdEfke2hRTYxu/qacXppbSxcMzaLfD8+hSqw6z6uKOpJGbv4xq5Jmr4FNI771js4QjrFm0O/3 zKezoRlUGTJoQBcPdc9w0W/lYfoDNISmLq1zpIRtnRAKgZ0KnWSbXc40tdKz4cenUZy+tm5P6hME GAEWP0xHZokpP9VdkJuIkwUoQaBlCLj2gROxeDrRebgg3cLiAns5zVtdBu3szSR+uWeBoB1YGNeQ /HhVDPE54ZoNDLCBhKFMEC9pI24A6PzPqhupr2SuR8OS4j6QFHIqqYxROV7+SeHf+B5eCkWznRd5 GVRJZ68NEmtvp9bBqqbLaqL0y2qD9uub3ky0nM2NZsvPq4jIqXl9rPe95RfLFYJAh0Ngw0lghxuC dFgQ6NQI4KsJ1VAFhmRqWR3VV60lDV5D03JgWoXvWOpfOH9fEb+AatYtBYGMUAw2hfUFvUhtIkVk qd/IPJ2eH58NgqfQpdNq6Mn5QUerc3cQw2zMEfB5blBBTcLP3/fkgvLlX5bTp4vq6cbRuXTHmC7k H92FvlwRwnwi3qNHf6qiG6esi5M/TC7Y7CMdkr7kgjBzRJ4DTF1eT1OW1NK3K+ppEMjgO2f0p93y vPTHvbvRDByDc5KEyclWPQTVmCepT3xy5gEY2Nno0VFen7uAPWDWRSwnpJkkQWBbI8BkMBOZ4858 j8zujjtMin37zBGu+oV/dKbx21Jk02EQ2cEdhQgvitU7xYYnYE8W6YciAsei9/axf5sW+fitH2uz vHqmtRmiwy90lsRxWhu28UJev26Y/LCMyndRV9b54ISDM9fB2TF++UWfjdXB1w7JJzekhwOyXPTR 8hDdPqvKeTySFOtokLsxhV68dxWokIToh3X4SOBLk6opym3xxwAxG0EEt7HrGLZnQC6fjXUZT9ZH WQOHfgMpodgM7uDHWZrfRgjYcMhNKlaH1AoE/JWVj20Es1QrCGwPBCy3bik+y6vZ9qWa2zustnQF ReqqyJOR4xBDJoUmvIvGQjUUrq1AUO56fFw9tK54bwrldoW94HrLEv7uMl+7YIDPIYLvLI+ACIYc e362nPit2gApZKdwGzqBS17LY3ZmEJgUzIEJCKcsfMd5XsGRsBPTBmfu4Cwc40Bz33ieH/yA+QGz UDiAhKppzFk8HoSAG+xYjucbfF2rErcN0tutZ5px9R0HB56des6eiq6O8iBMeyxiUrAO0tP4Qvdr 8CAZbFUbclGbIeDC82NErKU9zcrzZ8wYs1OqbiUNkzImTpyIv9DmY++1GaJtXNG14Qcidtf++zgv m03H1WzjlqW65hCwFbWPqqgFlgkHL5mIVYu3mTV3Gim/vPFj6bxyBBOlzE1G9cR7lSWB1VG8BRHR s9CHoCx4ofNLPGn8zauDp/XzOSokyXT1dIuWwiaAncLwC/q1JSFagRf3Cjh8+XZtxHEewxJHx2cM 0sSZFfToD9WUho8NApbCGByre85SY5xuWlwPOsspwkFu8BXywM2yG7aMUai7RuC4yuG0yQUIx+4g 8Ynh39Tt5Npo8ljDlyjZe5BnqMpEoGYTmvMDVcz54Vm4+27qqlweOEFAEBAEBAFBoP0hwBHY8Dn+ yJfzuh2J3gljihONaNgXg5MY53MHtVBy1EeZeekUyetOZYP2oJpdBoIINg4rwZ9J/hYPzIqblfxQ YThaOZrzvWUTEXzHsR0CqwvzCnDiG6wnvIQnF4z3KkDcBHzSb/ldrlPPpAV1tBBEkm3+OZ0zJJvG 9UxzJIwramP0ly/W0jrYIza1GfRi7mHBPWM1XJv/fnQB7d0rDaYoNr08p8IxSfFwN1up4MBSSCw2 Kx6fOhRVDvWluSiGBXUTY0tOLTAVYW29jPZ30ztZj3j9UlFql+m9W8n+2z9eHdpLxT3e30+BL6BR 7R/mztHDP3f9+kFPhvtKikRAmNJqPYqSToMO+quy4PZ77/ycPgYKXXM2sZLG7+kavOAnLY3Q7rk6 XTLQR1+sidLssvjKYVEOjM9R6MbvYO+XQrgMvDyHoDxfz2Tyhfn1tKAChBQvci7Pq4iOJ7DEbWDb P36TBxP2ApmQwbG3Ma7SAAnMCwVpWPk6pzzbDfQMueiDV0odYjp6WSUNjlhxtdEGMtjk/qYSv0Zk cCPPQU0lGfkDyBh1KnXP73u+uqJ/sWXjC9TCxIJFuHoOwXtbqeNi2bI6wgsLTFyNwGXVarhfxqpB a5dYWwhSGxTDDVFwV7jPa2y9tVOANujIFlThgiUA4kZhDQb6WY6DMKywdIxkhchbQ+z43Alj1c5T bqWSW4lQasVrGGdJgkCnQ+DQnlXM/s7+31xrYFcl87hg6bIzEV9wD61bX7IRaD4KE4gg1ELruvYm 0+2Beii+6xx6wklxRuXY6sHBcAyk0UluSMqwzS4H2ByEv+MxfL8vHJJBJ/WFU5cEEXuspJY+XhEm 1RW/7ooROVSDRWW2Dbzy6wp6FudJ1yCpjLc3FzaIL82DEzlUWgeix8SywcN4yp1jyWENJHUXjMij fx3SE2cU+sPkZfT23GpHrbTVTBBvYQ2TiGWL69RrT3nzrHd+uVRds6r6VASIPx2qqyM5pl00gn5F zEPhXXJup3uYZMDbHYEOTQa3O1rS4CYRYKldLGjON6PRx/W+fT5D4a/VAQfOmlgVwLKg31F73NQi Gs9SWUP04XkhyocS/wUDvPTVEbn0TWnMUe/ol6nRZBiP/3lmDXT849JCTga/WJFzcA0f418f58S7 ml/onJOrgjeN6kKnDcx0VFA53TmjnKbCnoA9l7FUMAsOXMasXRn/MrHBO6K2TP0N0kBUPgwXNdgr bBKNLZlzg6h26Q2qPIBrPCiRW/y0cUtxp2gdyxmwI0RN9nnz/oVajMe2LMhLBjaLkztIwhpzwke0 t4L9/mFvSx7MHTJK7iM6aaZRuNTO9mE31O77TKZPCWdB23xFvwrML0G+eSm5vSdHP93Ay7ECvd2k 0kZ7GQmr7kFNkGMCrEXfIXJq/zjbsAHg5xkfsXW2qnKE73b/bMDBi6LwIqqBxTrSw4rasgVGrGHa f8x11/fO7PrZPTM+GLSufMke2hGXk2foeHKHQb4w9G7lZY7qZfK7FX+2Eu9UJoPQ8po3u4aKdvFQ b3gOH1Je75h4xEHDHxevHSpuml+x3pLCBYdxu8I3wJpfYtStVwZdN62SvlwZdmwBw1j47YJfFrEZ pS4qW23RNz9X0XPflFHU7cY6JLyPQozIc4pUayMmnrVRky4c0YX+e+QuVItF4KsmL6cXZpeRt+1i S/GwPLNf7YmYez3vGj16+r0r7LyDYPhyNto/Emt561Wg2ssfofRjp0RAyOBOeVt3zKAgkrq3jqy/ 3F9xYM2E30/glxi/w6Hw2fLE8XuwEEc3zK6jpxaEaXw3HQ5kQPLwkXhkXpC+Xht1VEVSxWbQtKC1 IYuu+KoSxxVah20+lvzAsIoJaxHfA9XQdxfXOyEluI6ksXgFO5dJqZAJIauD8pcBH3JnFB6sKnLa qrgZm4IBMZlgXd9yoDYomSDH64e9FXVtp0vb/ZRoYzh0pI7DsQP0qqBK36X9T0HX481PM/rcdTs9 iW3SDD8VCCzsuMDniWRHSAmcO86jAZCTC18dBePkc2BpvFjXMZ6Lhj7rvJzEWjUtXK1jFU7YAM6t XElH7nv+eu2ZL7bML+G67xHZHJ1gm7xTm6DGf2dBSPLmOfEE46kPvumD8U3/6icbK9AKFaHHRYlz qTon1Yie9yD/nSL/DV7jfhmyGy3YpRdV1YSpDGqiyWkAP2OsCXTu7l3okaN2ccrfPW0t/bgmSGP6 ZjiLy0urIo5EscUqPBt/ITR8UGCPxnqzTsy/XmPnDgR9dQKRSxIEtjUCbUoGJ4z262GEY/NiMWbi tACWfyR1JgTuKRuH1a2GtEUkMHkVv95ZYscfgXkIMv9jJWIKOiKk+HFW+3TU/lO+qSxNrIJKyKMl 9U5ZNjx3QggmynBxvubzFUH6YAlfuz7YLNcDb9GJVcH4BSou9LKHsyQZdI5uggBsLTfgjrq8pCC3 drLQSMrWUR66ji7N7Cg481PVYNfaMTrNE1ALYokOlfh9kTJB7Sh9Tw2p01H6HO/n1r54t9do+e28 3mZ9e7Xadu1sxeKGY4qx5RorakJKx+LqpmSL0WRbPs6pyWkF1zlOYbB63DBNSJkr8Caf5xEZsCm5 oDibBo0tpPvgR+Ch78vgnyCuXeTMQzBpOLx/JpUGDSfw/HmQEF6KUBM8pCqEmjj/zSX0WxlrFLUB HWzmZq2YNnh+291DqUkQ2DQCrSaDfx3vPxh/NydBiJ0JBYjlaOZxClG9R6dvsD1lwgT/OTSFrsdf cgZF6S6Qw5rW3owJR/k54mc2cvXE9wIbiE/QloK2zkVPRlIdDEx02PZYNAcWSc+hXej7bV2aMNaf hlqzaBHaL9mw/S2pnQkzeWk4FtpOJQ91g2HMMmidvTrxy8BPXA/aSicXYj5qdKyDa4wexBiadS+M stmoYzzqO4jq6Vcqpf+hf82+eVE2j3x0MOR0e1M1TZ/4ReCVjfUbZbuh3qMw4mLYZH448fMAr1Rt 18Qv5Hhg2MSL1nmhM3vYsBt8iMkeSxCTtoTNOZdlHX/Ejo9rFsWXl+Pl8bFKlmciWAvVkeld2T5g PaFcr8bS5MsSL9XQbqPebdDXxIEmxxV4VostnkXG4u+osNugz3frM/LbaCwUj4vRgsTdxyfOhw9o Poqrrfj2tqCVNi7C/rwVcuPfwvUKv23cRhtXF18bsHFfWGKFKMvNPWRt3GabVMcetvCnxPOjZv58 2qSJtq/EmUWm8VOSMOdt+ybavkZV11xOhztOUsilIzTA+qlzh+i6oynawVJcuxWd7iiPR2Kxbqvf GQYWdLG42qq/i5Y2nsDU+ZwzwInrnMNN8Oa5Ah9i76T3zCynWct9pEailAZ7Qv4scYpLE2Ef+OFK hzjy/8nrnMUTMMowbFd87DygpX3sYM+rdLdzIbDFZHDCQf5caLQ9DG2YU+GOYDK8E5SAuAxANJRz 8WfBkn0P5truVyeRenIBHYHZBxzxOpL5VpNBqqUjKI2eQQ2sMfD+BrdoFnnx93gN7I6H43X7kArt fEWjG0CqLrp+rP/gO6cFlm3VbdUResOkp6gA5Ldkqz2u7oq3y/XIS+CKwqtm0s0gsJdPGO/fH4Tw V2D5VxDo4ciHok2O//g48gZkkEmjpdEdeGmxDsPRyEzCuewGCWXzUe89KJMHonwkXl7MdJolg38d 6x8A5xj/AH5ZIISH8AI9ym53MrhV92srLtaxilDp8dGnPfvG3/HJwEUN5DHxQXc+EElyl0IG41+j +D/J38Ruw1cjZR7jrLlm5lPdrNeJvnuVSz4Fb6LPbMl8oWnZLbl2K6Bqk0ulr20C4yYr8SOG1ZBn KT83RBpeJDtw6sLmUl67MpesVT6yczfS60ov2T0qSR++aFE3MgwV8Up3YJ9bdn9Yj8BrGC5fpDof Tsh1S+0AhqXw5KjCYEo3Ql11VdU6jkNuS3UZsULcGY4Z3u6fDURSYfaga5ZZACKR9FXWsgdrB5UC cYPZoK0iXEQ39B0mH5hdbUHywjt2uGzpgOqa0t5q9/6k9uiD2IJwHYCHjFfqW37bkt/RjTTeZG2W 6/WhnfjD3PTrsr6wQwY1k2phClkDu8A0SPSbk+8x4eNQFo2+6Ym5AHs97Ujfry24fVK0EyKwxWQQ kqrL1HyQsnLyQ7o0MYkZCIcXkid8vONyl5KSgKl09b+GP8m0jwxyVEZBeIbiL+5skIwsSAu/BtV5 GZIsE8dH4vR++DZ9CS/7R6KeHArS2yBHX0ACOR5E5o84n47//uSUNegeSMsax16BmRdI47Lbvgpc yW3dNM7vUrrRZd41NBi7yyCRc+P6k/FHvQ/+gi3045OJnwbecvq1n38c+nQQSNmTqHcp2hgCieep GCsTpmwQqKuc9j30Z5zbC9Ts7okzAhH0bV+8D05R3agtSu8Dj8lcH47vjnGcjn6+iWMzGj1X8yBf HETn4HonAM7N4/y9lDz0qRLSQIJ0zwRpA5nFmL9ArRvXGzyYwuonIJJ4j6Gfo1F24wZnBmi0j65G uZ64E4cBg42WxQOxAiT6EoxxBFWADMKDc2f7u+DVQT258rwBGUz9MLSSDKZ8wNg+MaOuksZXrHBY 955Ev5vg97M0e8v/NhNyzma+gu31FjZQ5/bawc1PQdp/z/E8Mc7twUEI94PnT4g7gzdSwrXNJjBu D33ekhvcXnDe0j7DRVaHSvwMVXSg9xyDy31mbY+tcEG53e+REtXdHizHqI7pYAuS22LCZ2hhb1Zp n8L+ow0jek1m3tmk9xyN6QdCNqVlUjQ9y3ER5QSbT35fk9U3t4DaaHEVnUjajXB/Ur/PvM/xgkHs QGV5p4kGUHI/forLGlCayGB7/Qad0saDdDyMpt6x5BerRWi0ALDtVGRCEbTr+kNLDx6PMcflvx2e j5+En4GYpz5EvTHjXoa55MFUO3Fi89plbdXVCTnQjhuC+TTr8MEBLGajUfSpuq3qb+t6gJ1GPeB/ CE7fJ84OVDatf8JIfy7Go018bvOmcY7mH497EdUx99lUX1E2y3GkHS+7ycUY9DEH99fEBLIO969V T+eWTzgVOs55DdvUKBYaqzJCahjvRFyaxH+nF3GclMMPpzsP9/mPtDV6Fmtkn4M4LcYjcA91peMm kP9MFN0dg74HYYhZR/oTPJz74rX5ezysh/HrwvEKwp47NGwhDvlGAITrKMrDNQ8AakTspMNBWJ/D 1bPQr+74fQFXDwFck3EuE3W8ARL4OMjaJejnQWo2+fFgTsXxpVhU2kPNwX4p/jwQ5xTl1Yb2oUoO 0hnDtX/AudvRs5fQXyZ2k27a1/+AeiD9BTRuOB71v1AVsfFvIzIIz5qx5BHc7CL0eRjKVcHmmtsm 4FiO4xlokZ3Xb/Sm4obzg1SOB9GHP/FNRrtJEM8K9HkXB8tNvNgTKqnhCfvC+2cnXvbaXkPHx5YK 1i6iF0s+xwqJk3gxw1nQkCQICAKCgCAgCOwoBNxQ8USQgy1qfmqf3en53cZSj679Q47KJgcGnP4h okhADROr5MFCOGzpM4SCiDeogIixpHC9GQY3lVxkTWxvjAw6S0uJsg4pZLIHqYCjpp1KBBPaPA3a PYkFXexzVKM4cdw50/UgKu5sCAKIzsCs2IP/zJvG+79UDfojoDoTt+ZEzIYfo1X0J4g9bqPP6ByU fbG1aDgmXXV0BW7rIghm3my2nt1h0uWmO2HaFMbjYWJbm3Cg/11sByCggffa1ic26bJ0ugI1LLjt y7iwp7UJi6gK2Mo5jmDIxDw9k7JvPsg/RYnRdRBULWAtSTxmt6L+41mHb8LB/gXgCdeCU8xu2iYE RCOh33I6jEyOVupAugtghlVCvzTXN3CY8ZinnwIGcDSwrAI3Ogrl4kE7U1LCPI49zh6H8scCzzlg TyegCOKobHnacjIIoYnTTAtmyyhSB7A0mgQJVwFd66geRoidjDBJqgaJORXn/+p0Hk6i4eH3Ttin /Q83dG88mNPxqBxw+9SAHw/vA6qPxmGw90z8KvDORocZd+RWgId8HNwiq0aY/nE7yBWu/wOkmftb 6+hKPKAP8fUA/Cn07GKQqZtxTTUgh+Mm7gWShbUK3kfCjf0a1z+I9vfF0X/hIXiP/8Agsrse5DYC x9wLHHqlwdsxQYL4Cd2Nel7EiD6ABHCjqx0Y42AQxkmglhoeoIvRz1TnKy103YUOerfImVXLLZ3j dtSStgsC+Ch1FPuz7YKHNCIICAKCgCDQkRCod/vojjEn01u7QgqIyV5hrM5XaNZSVixM7FepwvLS aiONMhaWUM6y+VQ6ZDSVDxwRn8A0mFw4O/FhNyKBSY2cZNn1hC5eNkkGEySwERlMKdvIV0BHVUxp 2VPBxMyuoVcU+Iqw6ulv8KHxPAhNBubV+6EGFyZ4NeDBlUrYESb84JhCadQopuGEq+Av41tI7mYE HG9ekECxEZM28SUINXj/KH8a/Hg4WnrOuVqYLXnoX0qIPse5jyDVimwgAVMgZ/PBZKkapM2gdzEH Pg17d1trnVn3jcnRQZvP43jP6EKhiYG4tCvRPkvWrIY+sdYfz9prkV3US/XQ3WaIPkX7H6e270gk mdql1OfUyX48asneoJ+8kjHFEUTdhcdpKXjFPdA2PMFaARkh0QWWQf9SdRBbC2QsSItsN30ETCdh bj+ahTqpdwmkqTce9FLwhSU4fgTjv4m7yDZKi3A/ytF6P2DVPB+Y53CxPujHr+BOh+KaXthv9bx9 y8kgLJvAVPeyyiBQJnq0yYA21hE2oPBiwYaXYHqhu5nI74Iqwnqd5Wz4l89YjsyRYWKCxMNKLtnk JuDYFEnygMqVg6ydBhY+CMbBszG4f6OWQ/CyURM1rbdb5Lq5t17UzIQVhfG0x8mSjv/iW/G3koIR x1tOtq/hRFL3n20AI3jEHrPhQAdVhhMPaSltsD4QRwt2eXuACL6BOkylivbGgzMnFUcWmUOKhyUz R1LYQCidlQD0ppEYvxKYFTgyxFjqw+z80SA1Ei/H8MfGfzZ2gvQmGkW9jiJEE/FyHCsFj7mkbYoA q6V6WFVFkiAgCAgCgoAg0NEQwKz41jGn0JsDf0fpUaziR1fSeOR8K+hM7nheHQZBXKZm0QfevrTI yqRuP00jCw6XqvoNRQTUnVc6t8NuZZCOggnSwaAUD902NXB7Sj8cidSEcSBRPPMLOSQqG3PuEdhz OAEIzUkgIdeAGnaDCCeE+egjoJAPQdjRFZEnX4aAZDk7fcc1Yycc4l+MGeUfUEcFJtHP43ILwpjR jqSqgC6EBGxKEwyMxPx+Hea3K1B3WWJG6pgkXT/a39ftpZvQt/3QvgaDssoJMf+DEMw8gZn4bvZq el/xOpqJNzvqkT76GA/Yt/i9D8eeZc1ECKH3dtrvSueh/akTDvBfiUfwEtSXQV9Boy7mvwtc4TWM syv6/S14wC/QUjwudQ6dmGc/new7NP++UaJ0AkzDYo7aLcHkKkbTWEDkYLaf/23UxVpdHDC6ERlE mTedMmyCFuc1G9f6+zLwTOL+sC8QC4L5ZssmCPl/nfn7FLpsU3W25BlsDRm8GxZo+4N93zdhfwzM hvjSC9YbppUA5kV0PhsNZyQaz8Z+Fwg8g8oX9BqY7liIzyrwEP3AEjzMf3PV/WDF9hluI18Fz77O dSbWFuAXESsFDDiTRCfWip3uOFrJRlsvsc1eowGy6qdC+ZD0FQD4ebhxL6i96BKUPx436DWsQtyA OKV34IYxGWXx7gVQb3/yNngbxTFWBSXNQwFsT8bmec6fRNCx2eO/l7VOWz60vx8evv3wIH5Ob6Cf F6Ku5bh2Bf4I+uG3Fg93naOL7YUzF8RHxwPMTnUaEq5H7Bj6Ej3IUFZDddVF+2EF4wijln6+/cvA B1DPPAVEcQjGOIibxjk/zn2l7w+UvqD30LehqH8/nF+B/pwDpHYDPvnAfiTK3ghqzWq2v4H0TeFF sAm5/gMdBF2w1XTTUEeSWIM2D/Nfj5fAmygbRL1foeiveMCPQb/yUecZKLWHcxcr6Bj8IbHM9GW2 p2zJQyVlWo4Au/6MutNoRlZXSi9fRvCKsAKZVSVa87fZ8oalpCCw4xDgDyW/v1u9irnjui4tCwKC QBMEYu/022Pgp31HDEmLReiQyBI6IbzAIYAx6CHyqraz7g6nMrsbpdQzCOcMaUNpoZJBeQt+pLrC 3mR4EY5eFkTb9sGyMIdkK1UFpKi5lPTik4tZYB38SXhgcRYkN+aoozBffBU37nnMK68EHTsHhPAB zEBZVfEL5CLVRcOsGF2gBukRzCs/RBv3gPgdjpnLH+wYyJlF0xQXyGTUMbVqmizHgl2hBzG3/Dfq LwBxu0sNY35+tj/dXg5pJsGTPfxx4CuxBDOhmzAXfRxClEWGi1ZC07gv+pWMQcsCml2RyzCfXcYE FhGJPoa7o68whj9Rd1qC+fL5YBYPYmy3or5X4SDxFvTtVcf/Ryb8dNQ5Tik5IsJGCRpI41DUcS3q qEK5+zFPZmTx0MKYLJl4m3tjMnvZSIoH7NxoO8mrHGklh9NuiaelT3B3uPR64VmrnqMtnnCCaC0E aRgD+d5pGDTrq+6WCC3xAR6pCttFj+NGOisPGPEkEKl0KExqIG/3gqAtweLQGXh4ToFoc4Wl0lO3 wVgVN2UeyNrzeIDicVU8IJbxfcfeDqTuXTyGv1dy4NAk5MQSbSxG2RPqmlPoGdDtXVRvfI0BdT+g VqFtjfKhh7wcN/NAiMsvQdv740EKooYzXytPeNQMwY7QpDNw/jQ8vLuBRP0V4vVxEL3+5vSnO70D 6nUVaO3B3D6vGOBm/Z/lo2+hsn4CVkHG4D1WghWDFxJ3YS0G/xkyP2CNE8scTXoPjw1HOGXyy+yf Z/5RMPwPwfDZkyg71HnDuVCl36kgw2jzU6zGzEIbZc6fLksviUbhfB/0mdvlx4HF//MhxP4ef17T +YmDWDqM8ln4wxiL3VwHVw0Iq3QA9qfhCN7G9CXGvFRh/7BTUNZCPTpKlaOs7hDyA/DLHkWFDLbq z2zjF3lgk7G2az86btghFJ7yONsN/htvXPa+23JV4Tbuk1QnCGxDBGyo/Ii2wTYEWKoWBLY3Ai8v zbkZrgsmZsUwcYqugmiIPfqt/4QlZ7/1mIV3M+tpVHQNzfUOobT6GtIiYYr5MmRlqO1vWq0zU7Ya iFPzLbDlHivGsVyOlSJtSPWY6tSBHCpQHbUgQoA4AHPqvmo5BBldcTRKkyFtdGzyMH+fi2u6sqQK 8+xfWBSMNe7yWz8NNGsT58xq40557oBwaBW8/z8FPtDnNgh4Jnj9/RQPjbIQFu62zxMSt/H+u9Cr 06Htx/NiFjqxqDnuBDEXNNLCfB4unFlAhPZ/5fZhClp+W6J99O8gRxZnwq4OnvcxZ89CeTaE7QcV 11n4/b9NQY8697Ez6VUQTNZdPGniN4Gfcax7gtKx/5F4sjBLZmXahPBqI3UmtQ03LQpnlVd43Hbq 8DVoSG6sm+vrqtxs2Y0OdYvJINcEUWoVRK+PYJNz09Tg/AIGnA3eRrkQ7PWY4MRJTkoCwfwau5yd BPLGJOzshv24fjJPkDlvkBLi3H+knoCU7Sfsn9VQx7RACbavbfb6uD70S4mcLNJgfJoQxz6AE5zj fYxf80QiN6oW4/kKBzhv2Nf42E5v7hz+zDjd1Ow5HASeNzc5t3FHIyX0+5SyvHrBhsEbS+c6JwLI XziEnI1QJW0nBODdnWo0t/MeqYfSBibLnc6D63aCWpoRBAQBQUAQaGME0s1YjYpAfGGsjK/S0qhb rN6xG2wqAuEjLC1cq0KoAsZgQcxD0OmTtA0QsCHkKINowEtXQtr3FrTUvk/Eud4Tk41f2a0OWGBS O4PlUI6tFI6sdsyJFMzJLaiG8pko7Yny09UeYPgsxlAcuhi34VMcwYQjhAmHyedxkY+dtG50REwF 0ZbjZOaLwLvo2zD49JiA35cqY/RJDlQssZYwGoQrB9poVWj3RJXFJmFa6PgfNZ2esjQQQXxoH90H ShhKCIh85INkMC21fRDDVdBkJNhNvg57tfdQ0oe2R0YNmul4Cu0KoRZRFfBxnDimpr/u6z8EZOxF xQSSQYcIxgmuAXGOC8IilfaCNmIvYFyJ7WMgFV0BAUwJnMvsyueA2wzUu7hRpXEZXgOBw7h3x7iK MIYvMF4OJ+eYd00ogFkY/8dqvIkEYrs3juyC8hwNgW0XCS2zbmAyzkmr7Y1aRQa3wWMrVXYSBBQf tHnToX3LH4HmnKakHnO+JInPSXK76a+jfZ0sg9+G87yd3OfXXsr+Bl7FEt7GnHhCKZmb35o4g86f cJP+pxyK33Io03gzyQ3bCcdCWySCneQvQYYpCAgCHQ2Bq/z+nFyivliw+wHeBlkqwM4geCL8MTJP xPZHzkFmyQWrn/ExRAyiXfF+L709EPhsc2NGvXz9COSv0U4M+3tgm81GOLFEYzmOf/dXHMcEjo+v w/7nTevFdTzJZSfVs3F+Xup5nOPwLuz3gT9Q7+J8XTPXs6bRrzi32dAjlmW8YVjm7xXNM+Adz0By g+gVGTxXbUwHIyCIH3n60lfuHlCLsqlm1+EUK9gFAd3BSdir52a/+aiywXMoV5+ov+FYc9/8xLFm vIk6dTXnVCY5d3B+U/rFzSXLO4Cl1M27yW9+w7CT/WmMLntVZY+J2zI5Hi/H+s8AcbgNVOEDeOx0 QrzhiVyG1ebzOHgk9rx4Utl3h8YEEOHdMvUMmmxV0FNQBT0Y4xmGIRp2lKp0lT5N3FCPc8X6FCeG rNrYH36CVtHLCLd2BkjOD/CSz84Rv2s0TkT0cMhm0pzMhp1fNf0Z+7fk9sbfzCqomrrgtAXqrTBF q4ajxnQQntvnhWnyIGjUWfn0KOo/D+d+gebxGuQyDCQOZgH02WDTCJOw03D+e/T//LBB//HWUjHM Ws9HCfbMacCbKhO055yQERa9jTp+BDHcs6nfDbT9D/w158FQjN3qPg37SB+21sAci8PUsXDpaZyf ie0I+mtC6ngpm4rdtJ//T2ofugW6dFzmXpC4P2EUF4JQ9kM9TIbfAT7fgCieiUfmj2o3nFsBtViC +up+/n+i7DGQDAx0NAAz6Etc/x7u5zVo41ZHQ7HC0fSbDrvPJ3B+LO5h/P3Qn74HiXwGZVNtRFv0 mAkZbBFMUqgNEHBeHrHvoU6+eiHZ8DDWrOb0BgSxOTKY7E2TF3GjF3DiJd9QNJUc8istdT+1nmbK cR0NxLIJ4XTONe1P4mDqhy0VwEbfR5BBTwaZ6xqcyW7bL0Qb3EipQhAQBASBzogA2N8gTN7+ADLF Dhv+jsyaPmwOwpKKCF7tf0L+D7ZHQHwxCr+sPVSMvA775+O6XiBXjoOI5hII3jAcvxO5N/J45HKQ yAgmauwunp1yXoKJ71eoR0M/LsaxN/F7FpM71MtxkclxiY8JJnIeMqvBwQLFD4ucgOMpEtts03RL 4lwXXB/AsRuZeCbO8zGOE3YSKroQxz7aWH+Tx48dEFm2eoHrmV52bGIEtjpPpg2jolgpDTKrKdOO OMKcMrhkn6Pn0yJ3HmkgQvW1pbSycgVFv30nHnOwIW3qm49CDZ5DeTtxUao30WQ9jb7xietSiVyS 2DmELjkH4IudEw0/DdtNiZ/TTnNzkEYf+GbnOQrGb4cc34B8r+LuCrdBAjH5ECTnY5CkvUDfuoDI REAvfrzzi0AFHC1OxHP1H1AzjkP9IgjFN0YdlUCrjhcyLmCJHYhLT44DGLHohzunBiocD59eYj8U TucdCVZX/8nYdLx5QouOTaguwqgewajcqL+Rd1JniDGontbRVzB/csywEqT1d+hfJqz+FPT5BXjs /wxr5ExENTht+Q3HmLwl02UgR4+hjS6Q2M0AMcrGlY6/EbQfRfsX4LqHscsr7AvvZD8efv/R8PMx CvLMLkaE6vVM+u7O9wIhh8D6aC/chPoNvIki1oHyOV2E+tMcSagSl5caNoV1UGjWaGTPoSBuIzF6 luDNSsZwVGMY/0r479ApuQjzLq5lqWIIdyCGGtPRRycEBEjqLSj7BMbwc2KAz6M2NjMLof+8mJSO 7PhNwbErHJeRGfC74lwMya1FLyPXJ+g52zE2Z6eZAl/zm0IGNwuRFGgjBJzVxfqH+RslaRMIbLBC 27QsXmw9cMyNj/cSbPfE9l7Iq7E/I/Gh531ereMV5Nk4xh+bccg5yL/gWGoYk2a7gmt2wec5GyvZ DcbnODYYhXfD8Tq8OKagHhPHuN4uOPYzyi5KrQznWFWEPxycPkb5uJ5/IuH8AGwORa7EubiSdOPz /ILn8z8kJyrNdlYOCgKCgCCwfRAw8TJlm1eOjsfvp3zsT8L7aR0TOWwvvS0QeBfbtdjmjx2/l5/i rt3kR1xh9qYe334Y519uKtFLvFv/gbovx3lH4oL36q/4+RXvy0LQjFpMXJlg3ob8Ka5/D8f5m3E2 fl/jdzK2udxBKHc+9svR1nAcYx8ByYk5v5P5+8H1cF/Y58BuyMl3PcvCnsE7nh3obcoFvoP4rouU g3XTdTle1AcyqXND7TMMw6+P9T40A6QnyXSYIqmQANr1lVS+9Eda/sOHFA06nKIzJ2bBjZ0htjEa jkf5ksbxrp3nCo4WU5pip3WNYvxBasXkJElQnKIJx42NY2dD/TS1y4kyG6hcJsuAMDGxiZObRMKx Ru3cOdtRl3RUJptLIGKp0saqZtpvNJ/As27DDKtRvxPjYfx5wWSDlLjmh431wbl+WqACP580LZNQ 92zoP/rLxDfug6RJYp8mONTgXwS4s4kb5w3LQtqLgw3zN5Sduan+bck5IYNbgpaUbQ0CyW8Br6QO aU0FnegafjE1VqloZvD4UB+Pw13w8X8cv2wrOwl5EPZ59ewQfHRPwUTgWZS7EsfY7fESbA/gSQzO /QPHYGbrvHCaTZgcHIcTE1CeX15nciFcwypFrBL1IV4arKrExy7AD5O1mSjLq8u3o162zeVzmby6 zJMj7LITonE49jecT167B87/Huc/TKxs98a555IdQtkh6Otd2O+NseyHX37pShIEBAFBYIcigPeV hvdWFPkP6Mh5yE/jnfkKjn+Bd1V/vLsw+6Y8vMwngsg59t8gh0zAWOrn+ATAtUzENnDIdmcgsBjX s9rbBnMz1MmqdLyoVoP2WM0zubhWE6/SuYbJYEZCbc5RWkQqx0ZWCmhdsO28hxN9YQlFdnIf9Vdi exb6Eff52EwanZOjl39Xf6xu0aVgeIf5EAuApWsxGGPVxyI/DFaiz3yhaIgqr/VQFa2XbcFViGKt hl3hrNULvv15ycy3m4jPmmulUxzj71qrJDmdAh0Z5HZDIPnC2aw0Yrv1SBraWRCoSgzE+ZgEAo1X P3aWQe6gcbA6D3/MOX5nTwAcSxIpTBJYleHbWwOB1/ExL8IkYDRmCW9htdpZvcP5w/GFz2fJH879 DedubmoTgmPsQvpR/PKKMhM7fk+wA6JvkHmisASZCd4JmOn8HhOYZQkpHxNGhwwi7YPru6Hu6xLt voB9Xgz4IXH+DOx/x6pNuHYB+nI1fnmFPblKamBcD+L4ufh1VsglCQKCgCCwgxFIki5WwWTp2kN4 b63E9pl4Sf6M99VqvK8ewPvW0YTBOZasnY7j43HhDSi/NqGpweFVNuYojN/h/M5rcAaBa9j+j6V3 f0uMnxfqHDsh1M02iatRv87vfGwvwrFq7PfFNr+vi9G3t3GuN/cZ+Uec3y/xXu+O7WyUXYR9Jqtr Ur4HccuulFQ4NZiZ3i3zpEqqvxQSwDEeD4qABEbgFdu0rG9M23xoRcx4+ymv97J8T8YIM1L3+uG7 hlhlb33qh+4ezV2WJAgIAu0FgSQZfGTChAnxWHqSBIG2QYA/gvGoK5LaHAF8vHkishIfcF6dvhC/ l+DXjw97Dc6dk5iEZIMx3gey5qwQgwiy6lEpMnvu9eD3dfzCgWnjhHpn4nrWU2d1U0683Q2Z3xcc J5M91b7F1hJYD06uMK9FI91TauI4QA2rz9jmSQlPoJyEsqxelVQN4YkL95EJpkMG0Yd56ANPrFj6 KEkQEAQEgfaAAL8vWU2Lv2vH4h2VhxdXBvLteIexziOfS11cZ1vCK3DuW/yeh/KsDvYGyv8Vx17E diMVM0gQR+LYicj87WTbxGfwLvwN5fdC+cew7RBIbD+CY9fjPHsY52/tv5H7I1+DfBnO38+/OM/q eKwG9wHKs3ZOHs5xX7/CNquasu0hk9fV+D7cgu0Xr/f7f8J7nd+7ucgHoo61z55zyyI3ec+wCt0g gfowl4ZPAT4AoSjMJBXrI1z339Iu6ZOr8qpi/jlDtDG05AJVd+9mWb5DPlion2HZxk1HDohsVHWw PdxY6YMg0JkR4MndMcisx75Z3fDODJSMfYsRYDWQh8Ph8PQtvlIu2BwC/Her4SPN6j7zMUG4Fh/y e/GBZ09Zi/Fh/hHb97E6EVeUUNm8EseYbF2P4xaO8bL0HHz0N2avwJMRXgXnxOpIcDRGM6D29C3a OhAn0kHUeHWb3x2sG1/MJBP1MglkWxO2c+H+cPs5eBhYrWkhtnlyxF7NfkE/+/J5/LKDhTpcH8Zk aDcMbnFCnZT7wGPdpjYVmwNbzgsCgoAgwAgk7fcSaPwX77MsvLeCIFNJDyi3NEGK7bL2SbwTeY5l JAjdRc0hipcd2+3NZ4cW+GWbxCT5u9WxYUokbLN91zXcfvI9n3ivstoqp2k4xySQFw0dRxVID6W0 +SDOs023kVRlxRiYLDoJ5/j78a/xU5f2r8zrfZ7b9p7h1l0DNfjst9mzRSwSgefEd6KK9dDiAbHP 4ldVOf8GikvMyQt8c8xoaDcrhmiDuns8/Cx++MFC7UHVW3/HoT0VVo2UJAgIAu0IAX3ixInvtqP+ SFcEAUFg8whUgECxIwNekb4KH+4wfvmDz6qYw7C9NGWCwGTrKBw/FedfRb4WhGsqZi6V0ENi98Mc cLWRVgDqOxrHDkfuhm2WArJt4j2YqLCTgoNRH69+v4E6luLYJTjGZdn+5S2cOxe//dAer1iz17s7 8KthFvMUVFeXsOME7L+N80/j9yacvxHXdMH+3dgvxO8t+OUxsZTxZGSesLAK6XMsLdw8NFJCEBAE BIHtg0Dqe7a5FnnhLXGcF9QaOdDaSHnWpkhqVDRIGFOJYOp1m2o/oXK/0YU0nN+oedCz5/yjz6CF 6oVruw8+y63rfXxsOsgMNRpiBzav2yCB8weaLO1sNtlkTbcs8ySFHcbEvXP6ICm8zo6oR7w/L3bL kYMi/C2SJAgIAu0EAXEg005uhHRDEGgpAiBMjgtxniCAJLEb8kwcK0tI/JYnxXnJ+rDP6qBvIjOx gidjqkPZIK49HfvNqfF+ieOsSsoTCV6djqD8ZyjP3rjSsIKc9AT2JY6xLaIP551j2H8SP0piEnQ/ 9vOxb+CaKj6PvjC5tHGePZFei21WF63miQv2VWyfg20D2zxRuR8TD3aQw2qqydXtlsIk5QQBQUAQ EAS2AIGBc+09Lc19iUrWaWm6O4cJIFO5ukiQndq8aKj2o4sHmCy93GTSDfrGhN9/tifMyC0kFW/2 mlLWkFWGqrprEqSEz1qx+luPHKzM31xdcl4QEAS2PQJCBrc9xtKCINCmCDRRF2q04tzcCnJC5ZL7 0MhhAZOu5jrWZLWZ3ag7KbGS3Gg1OaGC1EDUmOSl1ol9VgltSKltJghjg4vpxL6zko5t7muyv5td UW9TgKUyQUAQEAQ6EQID53rGk2pdDkvFEzLdPi+TOAs0MBiNLoMU8FkrGntycbGysKWQhPXwAhel sSOyHiZiCmcU9ieXN4PqylZQuL4KqqOec0hRD/xgQey26c/e+AgczIl30ZaCK+UEgW2AgJDBbQCq VCkICAKCgCAgCAgCgkB7RWCCf4Ly8jl3HWFZsStBBI9M9/ig02nDK6hJUTP2i2GZz9SnG8+s6anA JrzZCBMbHVrBXrnlVbMis1XN3SMWqiczFiGXJ51yegygcG051ZavQlN2T033PrT3OXee+NEC6+ZD B0QaqZ3643Foz0aeBLLIAbu3OKEO7jjH5Y2hjkax7VIrQzkOrcEaKDUot1H1WZRj8wULZTbqcBFl 2Gae7flDKMeO03ZY6rfA7u4lr1q5mirXjIsE+82xd9XdrouiRuzjpUOUzwvn2F1yyRstKY5sdMxt 1fmiOZ5seBPwhCkM21mvXfntqtKqs/LYM3q7TMCuW3efV521qLImMi6tkaO9wqmetB7dKXdVOBxa U7xpG9iioiI195PKLpWVlSHgvIHDvtTBj56e49Z7e7NQth5lN7kI7vShf27aomW/1FaNydtqvwpC BtvlYyidEgQEAUFAEBAEBAFBoG0RyCkvdxWUF5748jn/ZK+jB/jcsASAN5gYAsYblgFCZv9PDVe/ srA4DQ7ItowEJns6pqrKmGyn/aho2tGxaIgsIwZVUd1ROfVlFZDLl0V1YCih6lLYLbgPsQxzzHsL tPvMcNldxxansVdWThxKw4/MYTS2mAyClI1MXD8Cv5nYfxu/14KgNTiwSZDFS3Gcvaf2Rq7HsVvx +xzKJe09Ccd2wbFbkPdHzsE+xwP+Pco0UnPFcXaaxuYPHPZDxz7byP8d5ZrVwmnbO7u+tj5z7RO8 uuca07J3s1QKZ3enMt9c+1p2x5bpTftLdbA+mDPHKMlwuxbGbOObnPKcw9kTbGv7s+uv2hGoe7Sl Gg8uHqA00gbiOkGsesTc5jtu1dVXM9x1Clme7r/rsSx3bvT2xYPtN1vbbvK6fvOUI1VSR7lV44GS AQo7tmt1GjhX6w+HDBM0Rdm7MkxdBvTIqwnOC/9r8SDbccCEtk53F9o3hxQtI8frpfR51mN55en/ mDGmqtE9LlzpyUyvNy6wFy46tFZz7Rt1G/clnscN+gZ8upKlXlBdEDrMHY3tibI3oFDjkCyJq1C2 n2rp5+vd7cOCocqivLyu51aR+VarB5y4UMjg1iIo1wsCgoAgIAgIAoKAINCOESiaU5hleMtPUe3u l+m6PsqlwlkzHLyEIbWDSugUzbIfzi5PfwOTWjiwYVPxrUsKmT+ZRgSEylZjEHLoHjiztqB+apvs YZSyu/Yhb1oO1ZWvoJgRy3C5PH/TlK6HfbDAvPnwAaEP0DqTQpakOFIPEKtC/JyBzB6s2ZnYsyBZ QRw/ENt7ILO6aaqEi+e37PyMJY73IrOn1U/5upSRsYl9FfKFyOxtm8Nf/BN5MrITKzKR2BMshwG5 Cfli5InITCL/nFKGN5nvMoFlh2rsnPEWZCahTpzf7ZH6zVUuyPJmPhGMhqYqVuzIqEqrdNW9N7ip Sbqh1IQZUivanbx1Mdt8xFZoQfd9u5tVJVVO94rmBLMQVUSBZCpJyilneo6ne+ZXRklxsckkJ7eS rKSUCxI/X8xlnJfhST+tPlQ7dexK9zfTekYazEu4Tt1F6XbEHhwxYj/UR2PH6zrlpCnuz1VFfbJw jvENpGvskZzb0Yf09qYvWrTIWjMurcH8ZHR5jkcPh7SDH70hNDEw0WYJWm3mKhedsmdo0aRZHs2V eX6GN+2USCw6ZexKmpnaftFKTzbEs9aanpGG+rgdrxFyX/pJvL7U+4K+6VgV+ULPdN9YW2n0yPDq H2uk3l44tfa5zILMYk3XXzRt68moHfybx/Rcke1Lu7U8r5ZVop9IrccXCkParPtM0/pSJROLBBZw 3UgKI+yWG3GjTfMr0lwHgMBv9A9QN/QCnK+3TXum2+36XcgyWBK91UnI4FZDKBUIAoKAICAICAKC gCDQ/hBgVUHVcp9leiou9GruIk3hiD1wChPl+bryrqKqD+vH7Dq5pKQExC1OCNoiqS79JzNmliuK VmCEwdGyGsLMQkWUOSKC3WbkkNuXTvWVa6m+CpqXqrIXJCSTP16Wf19en92/L1/6E9uNs7SO1TM5 hAXvc3xadn52HI6fgF8Oj3YVMjtWayCDIIbs8MxJKJeDH1a7a+T8BmXYxv3lRJlh+IWTbeJwWJCK rk8otwh7nLkuVifl1FB/siTKvZ8ow5N5VhVlqeaK1Lq25TYTuZg76/pwLFpVG42dmiRZ0JJ9g9vt M5cO0lTI5YB+JS1SM2gXlp4afO+hQtrP5XbfZriyxqqqrQyYp89SLPtv8webc/Nya28gfa9j+v9m zFQV8wDbq2aDdD5WUJn994ouNX/xuDxHwskQpXnSn11TH3oTdbKX8oakx8iC2DHKUUl61+ZW1mZW ajHFYklapY9snFJo13muK1wFoYvKQ6G8zG5Zrsz5yhRDif4Nksal5eV19ym2ffCzpwTGouy68rzq P0HG+X/WG/OO7O3OPMatuw+vw4JDmsv7wpq6EDvMu4qdIWmaFzfYLsokW8uYp0821ejExQPU1V26 1Nzm1lzXPHvOrYeh7JTUvpYMMHmhYd7oHJ9ufBPCAoRSiUd1eXhZKJxekHmQC86QItHwk4sHK6t7 zTHftLXQzbZio1+NySD6jftu/rPXHNpb87KQ2fGo1Ozthz1uCc6V7DrPPJH/NlTLibvcbML94Odu xq5z6WqoWrNTvo2W3ZJnTcjglqAlZQUBQUAQEAQEAUFAEGjnCLC6G8jVhQjvcI7P7emtOOEhFISH CIfAxt7ERP+R+YONL5xhlGAu2sapR23v+cs9S5aTphSwqigxAWySbNgnKpBQZhb0coghO5iJBGtw TPljwYBRNZXLf9Uty2DWuj/yYOR+IFxLQMiYbDyAPBAZxIBuwPFkSI6GVlCOJX//Qd4P+XyUaVZC h3Jc92vIrP55Jco1a4OFckw6WYXPjzKTmoMMZZj18jnWsT0D5VIljG2McuPqwlDC1Wyrv2Hbi3In 3bJuTXGgUQGoUjpshAlEJeXqGYqyB0S1pUVz5mgx1/DHISEerWj2UVDbZWL+vqnYXYvmFO0f1eel w6Z0L9ybL6FCeRyI2YQMT9qE0tzaz0IxE16/jf6QMJ4Ri8Wu9KTrkMQ2cVIOCm+7lToQsLEVeXUL XJq3wDKMJZptnL6wWC3fdZ72+0y39/5gLHJv0Iw85FPdxbqqTyLTzgRXPQ5dZkz74MFlcTZ6r+S6 dL2naYXTDZUeIUMdivOnmqZ5eTBmzASx7W659TfxnNcZqnmKSvogr6q9GDFscB7zEixQzACResar qJDobehQfeA819X1WuSP0GzuhtZcMcv4J9s35s9Xc6FOjUp0SBlNOEWiGtOywqqton/NczKXbrVY cmdZKi9GtCihtTaNDS9ksEWwSyFBQBAQBAQBQUAQEATaNwKQiAwj1XWJrSpnpru9eeB/mIkrFDIi FZgAvwoBxcOIEbjN1RaLEXx++QIvAt8rI9mBjBmNkOb2sOOYRgDyPtTjMLFmBzODKFRTSuGacvBW NQthKKjfHsdeV71u8YKyxd/zrH0gyNYy/O6JzCSRHbSwRG8Qjr8L4tXgdAP77DjmQWSoSNKJOPdh wkaQCSLH0mXC9yEyS4dYnXQ28gUo59i8oSyrox6CzISZ1QA5Lu9FyEwWHfuxRDkmmqzCyrETmVQ+ hcySwcPY8Q23ub28pWLwEcSPqsECQHblKZdyKKlGEk4InCAXjkuGfV4vvAVRBGVDlaEhXdJdygiX pkcM0/yXDaM0j+auixqR9EU0y92bssyKYI0V1IwH1gxQFkMq9SWiB5+FkCEFkD6Wps81K2wFxonR 0NzFg1RH5bNRAh1STDvNsE1IG2N/wBLALT6Xe0wwSiB7uK2mfVhdFK5lrOh/VgxWlkCSOb/fb9bn Kil7saMU6mbE8JSEKaQ4do2Watein6CFuo1QJ2W7/mZWYAUBD0S0hKWh/ebSOE3Re+HRWqVZCu6t pam6XoUnr4CvXzgoxtJDzs0mPao+ZnmtD6Nk5Ou2cnumO/0//eaFVuL6Ol3VFChWp6hxKi5LsTfq UEg3IOcD04L0cLMec5NSPtynzZZFx+NlNiFF3Nj4mjsuZHBL0JKyrUYAL0R+ebOB9mS8GBuFOGh1 pXKhICAICAKCgCAgCBAkgaNhz3SZqVmnpLm9mcwBLcw/I9HYCks1n7eN2OPzt3NcP42UabaiXGLG MK1GiAnNC7M8TOKbS7YFWQeYa3puN0rL6Yq4hIsdL6TujC7H7rrrXmErFo5WrCh5Htey2iXbX/0B c4mVmFuwHd/lyH2QmSgm00nYOB6ZCeMdKMcSwjeRuTzbEFYhsx0g2/8xcWRjuiko58Yvq6EycWA7 sPORf0S+BpnJyCUo80f8zkU+Eflq5MOR2UaQj++FzH18AeXYDpFjAf8PeZunS1/xlz1/1t9fKEjP /oNCff9GK1U/bOXCRQu0YgP+gQyyTJA/ZhGOZyCsEajgKFpvo7KmgrpWw4NsJs79VbWMUlt398X5 rBsm/SP8wpl3uHCZiviRTDDxYFk+ZiIWjOt4F1Jnn1vT1bAey2HvmXGV49Sko4jiguQutGiw8n2/ OZErVVX7TVHtu1B+XOy3+d9nedOOVsIW7D/NJ/rN1Xb36Po+hmlMz720fzj25vyYR3dnRDLr+/Zb QKRZ2v62aoODJdqw0b6ua0YsljthwgTliRMDparPxHqIug7kk2MbB8HIhlq2CjVik/9WRlg67Y7+ fwB1zkZeZrltQze0+QPiCya7ztWWd8nM3reuKtRFVaOzfa4cilmxA3Bqmk7qsRken1YVqv8i5/ly V+7vup4A6lfrjv74EdtX8vWGbqk6r8iYLJCNJ6hu5+qWfhQAXA61z7h03sET94OBxk9SYslq3m7L fahlRX/F3+/MFFRRFMVQuC0eLCGDbYGi1NESBNhA+0xkXjnbYjKIl2pXXMcvXn7Bs7coXsFr5Ho3 serHOvD8Ij8Y+X6UaWTUyx1N6Pwfic3TkPmFfy7KscF3o4Ry7Nqay/Aq4uco89eWDFTKCAKCgCAg CAgC2wOB3eZ5DsCc8Erorh0DD5Ie9gwKpxUID2HMtxTrKdhdPbV4VwWSrdZ5Bt26Mag/2pjRQx1U N6Aq6rFzN10dxzdkiY+mU69hB8DJTD+KwuEJVEm9gw68yKqvWFlbs/K3SUu/f/9BfI+TUq9bUCl7 amTpXWp6CTtTkHmem1S/K8N1MXzbD8IxDjdhYPssbLMqH+e42IyIvYT+iszqh0uQGbzhiV8meJzq cb2VUFlNwzbbNt6G4/cjM6FMqvGlEtQmXWzb3YkTJ9pFMc/fqoN1NmwDz8oImqcMnO+OWopqWGrk RopaleBsDunglvGo6OBT3hkITbDrPLpaJ+V207bvR0iQOkhsQxA6Pc8OVkCIdA3qvC4CqWNJHgiI BkkcXMQ6+5AkvoGQJCdle7Nfr31z3hPwA3tz6sgMl2EoYZcFQsi40OJidWW/ksjzOWmZl1a9s+BQ 0mL/qQsH9wB5+9fgBfr1kPx50P5UyAGvYWK5q609g4WNcZmutPegpjkXUjY3Gi6D0aHDYTCe16Gu eUK6N/3N58+89X+Z+i8To/bw36PT15iK+2Gov0ajhsn2pP9yyqvK5fne7MvW1VUcAUrMzooakmpZ vTWXOzBwvpIObNwul66srC69N5LpfrV6mc9SutQ9rGv69YMX6ueiDzk1kfp/Vxase7X78B7d8aC/ jH4vWt1938ED51b2t1XX8+CovNBAwO/iwQu0o0wjfA52wxm+jGdrInVfYns/kNOxYK6PaZqax6Fd YNd704B5dHGdahwFIe2QLhk5T62rrYDjI/NcqNQe51L1f5qqWcBlPar+n11/U66tj8VOWG8juuXP lZDBLcdMrmgdAqzSURX/u23wDLZ/4oU5Ay/S3xL6/eNwjOPzNDXO5pcyu3fulvhtbjWEXzRsyMsv 6xHIrObRXOIVRH6xQ0WBRiXKN1eOz+Ugs11C0w9N61CQqwQBQUAQEAQEga1AoBzhIUaXdz1SV9Ur QFMO9bo8DtNDaAiCx0Y4WLGeMKLGs3BMgYXTHUEC44MLk7EcThLnQt2zOAYHI2wjGO/PprXgbIS5 0BHyIr/fHlAvDSIu4UoKVpeqmQV9umZ363/dLiMPz357QcW9xw5Q1mKuwCp6G6jpJWz1mrXXw7nF Sfix3Sg8RJPbwoQwmX5q7pbh+oa5Aba3G/Hb2OOTiBl4NSRKd3oV7wBIA9UoBVdAfXNB0RxvRtgw RpFuLe8eHlpD3l/3Mwy2f2PVSfOtwjn6lEzdHAbyqBt2/Bo+Z+n6v1TDeM5r6MDKxL77ecuMTfX6 DJxXcK39fq+50b0y3O6esEpc3rRvpatyVxTkVo6DtG+9LabLutFF5mNglGvi4Shix6DPw71aWi6E wDWLi01W23XSwsHmpwiFsXf/zNxBRqxybVll7rLuBbUD69bqS2mwSYsHm+8NnEt7qW6zZ4TU5Qsd qZz536KVxutayDvIJkMxIpEF+HtY6YxHjQUq6soe8xpeSHcbm4cuHGK/W7ggPNtH6iAvua2wHVqw eDdeTAH1RO1VRFf0m2s/lOFxd6mrD66NO39hk0bf6oLS2uFY9ohwmI7uq72rIGG8BjaWKiSWIXgp dQE5T20mzQ97K+qNSn1PnIHUGhaXulECL6FXQoRohGKxiFfX3XC6q9Nab2l9f/qiLFgxyq0Zq7ks wnd8AyHj5aDjUZSNoqxXtWN2uLYCda130rSx52Njx4UMbiliUn5rEeDVM6gC0JPI/BJitYteidW1 N7HNnr2WILOef0PCS/Zz7HyOcsX43bW5TiSMvu9HGY5PdAFys/ooKMcv+JtQ7tZEO81+mVDuRZRh o3I2YG51DJ6tBUyuFwQEAUFAEBAECqcGM9O7Z540kAov1TVtDFTnHFAiRhRxAs3pEAA9pkfdk0qK Y5CC7DgSmLxTxw6IlE1e4J2jaSCDkPAxGVQh9du89RT7mzHJABGE7SBlFfSGg5lcx8FMNFTbRXN5 b3ArmSe9v8iecGT/+hflydgQARAsEJhIgqjG184TRBFOcvjZYKdBCtRf10+T1iCcBAz+voofW7/e vnhAhNVe2TumUw/2WbUSef0zBlu/RSuo3vG42jRVIQZfFSlYpFjfFvpXuZjq2WFPQ8Ix9Kf5WOtV xcq62VSVaLOKSdkcGrC+Pqhbou3G7Zf05JAVkYQN4/q+oh0QK0JuPlY77CKBm834MUYbjAfkEwsD 3M/155gAVuURjsePJUJvfN14GppcDMmjqjwmu/GyjAXKQV00OZ7EL4guJwwgcc+cslj4iKUsfqyv sznsW3pMyGBLkZJybYEAP7WsrsGxeVhFg4kdq23yC+EqZCZe4/ncJhrjZ5bJ26aWFlsaJIm/pJur i3Xk20Qnuy0AlDoEAUFAEBAEOhcCRSvtAqNeP13plnWpO+5p0ZlHBuF0A+pzH5mq8UhlXvY78cDh zU9wdxRicPzxE1TnTrfNmGMDqGqsPdkS/xjxHrOrfSaPbl8m5fYcxBJCqi93tF4HQOjywocLM44z Y7Gbjxwc2ZSEb0cNX9oVBDoEAkIGO8Rt2mk6yV8A1sln3XyOMZNMTLiqkVmFlI+nnms6eD5ngUg6 QU1BJFnVswh5GY4lvVixITinhq8iyrFqaD7ynIQEMfW8Uz5hOM4EtQplkitcLL3kfolkcKd5DGUg goAgIAi0fwSgNtcTziPOxUfvYp/L0x/eJZxOh6BHh5+3YmbkMcQ7+zg+kqp2OSC49Z+N4PNR2IO5 WVXUBVK3BVywYUyOiinGn5HbnTxpWQhWv5LCdZWkuDynwXJt/w8WqHeUl654+CzYv7VLIKRTgkA7 RkDIYDu+OTtZ19iOrwsyv6jZLfOjIF9z8MvSQsczGDIvGU5DZn3+ManjR9n9sc/G2aO5HPY5MKwj YUT+Bpk9guGwo/p5PDJLB/+Mfbb7Y4PdCcjsxKY/jvE17FiGPZxmI7+LY2z0/RYyYuQQf1yPxDFW NWUvZWwzyKqsbIN4CYiio0cvSRAQBAQBQUAQaGsE+i2wBnjstIvh4eMsj9vVi2ME8kpq2IjWQMr2 iqUoj80fEIFd/Y5XBd3c2FUyvofnkApICAtZVXTzFoObqJEdzNiwJ/T4KKf7AArVljukENLRbnD6 8e+8gl2O/2iuedOhgyNQz5MkCAgCLUVAyGBLkZJyW4vAo6jgPeQIyNQrIFbQDad9kFnqxp46l+IY Sw3PRnakfk0Se/t8GpnjBvE1LBFkPXYYHtMJyFwfpynILNVjiR5LIJn4sTSRXUlzXBk2bk5HfiFR H6+wcl18PfS26VjkpISRj3G/2QMV940JLZeRJAgIAoKAICAItCkC8Cq4h6KpCIqtnuZ1uXjx1CGB 9bFIGYwVnocfjMfmD47+0qaNbuPKDoV9GewGSzCmQvYoasI5jKLC8qIlhoMb6ZsThgK00peVT25I CesrVjnqo1BB3R/OTz7+YKF+XzRk/ONY2MBt4+FJ9YLAToGAkMGd4ja2/0GA7LEnrgZvXOw9FPuc GxKOsZSQ4/5skBLev+B5qtn0ZvIoyn26kTIsheTMiT8QT22k3OSUutibVYNHq/aPsvRQEBAEBAFB oKMhMHCuZzw8PF4KXyknprl9PmaAFmzlgrHICkjUnnZHY0+WFCsLO9q4kv1VSPsWBPAAJ/g8ssub tkHw+S0fG5BhN/ywQczu2pe86bnwOrqCoEHrg4OZG91e65gPFrluPrx/7I0tr1uuEAQ6FwJCBjvX /ZbRCgKCgCAgCAgCgsAORqBozhwt7B1+uG6rVyqafVi6y6exFJBjh4Vj0bmkWk/AMcxzcc+H7V8d dJNwqtYMBZ7yDSNJBlk5p21Sg4OZ9Gzq4kun+sq1FKxaA+mjPtQm9fUPFrqftkJ1gSOLlYZwEm3T stQiCOw8CAgZ3HnupYxEEBAEBAFBQBAQBNoxAqOn53iqC0InmJ6RlyNC/H5edzweOoLEMxGcgZho j9dGa19eU5wGDZYOTgIT90GNWvNMPVoBVdEusUg9eREmoq1T3MGMSpl5PcmTnuPYEkbqq0hzec5T 0rIO+GCecdv056//H7SHWu7KtK07KfUJAu0UASGD7fTGSLcEAUFAEBAEBAFBYOdAoHBlMDOzPvuU 6vzg5ZqqIYi0y6F6UAXl389M1Xo0tzT9jRljqmDH3tLoSB0Dm9UGLemm02+K5h7jxBt07AW3ypVM 8wN3HMyYUENNp9weAylUUwpSuIrDU/RW3O5Hx5xz14nvLzBvPnJApFF8u46BovRSENh2CAgZ3HbY Ss2CgCAgCAgCgoAg0IkRKJxjF2a63WeoSu4lbpdepEF6xSES6qMhSyPlXUOxH1k4IPa+A1H/qp0S qfOKI/XvL/CV6Ko6xuDYiIg5qOmurfEhs0mckmEo0rK7Ij4hwlBUrAYxLOM2DydL3eeDBfrdUZ9x 97E9EetCkiAgCECJW5IgIAgIAoKAICAICAKCQJshgBiB/XTLfb7iUc7zutx9VJaEMQmMBCH5U16z yHps/iDz8zZrsJ1XBAr8nWVEL2QM2KuoprvR422osZmQEkJNlLIL+0E1NcdxMGMbsUyEoQi4I3TU +/Osm48cFPuonUMn3RMEtjkCQga3OcTSgCAgCAgCgoAgIAh0BgT6zdV2V1XlYk1VTk9zewuSCpH1 sXAV1CNfMi378cWDjU6npqga0e9MHRTMJk8sHHTsBm2TQ0Rs28QOZphzcnsuXwacy6x1nMyQoo1W NNfkDxa6Hova5t+PHRDhsFOSBIFOiYCQwU5522XQgoAgIAgIAoKAINBWCCBG4BhCjEBbtU/NcKel I/CBI/cKGeHV0Id8JmTGnloxWJnbVu11tHp8RkFJrV69SiGlnwnJYDxW4PZLFhzMqKpGmfm9yJPG UsLlFA3WqqrLe5nbjB3y/jzVf+Sg0HPbr0fSkiDQfhAQMth+7oX0RBAQBAQBQUAQEAQ6EAK7LfIc oFrKFYZqHp/u9rm46xweAt5BF5JF/6tRo8+vGahA6rRzeAZt7a0ZV7ym7oMFvu8QGLBfjIPPG9GE 3eA2VBVt0ll2XGObcDADCWFuz90oVL0ODmYQuYPs/prL9ezk+cqJthm56cjB5q+tHadcJwh0RASE DHbEuyZ9FgQEAUFAEBAEBIEdgkDO9Ol6Xrd9j3KZ2uWgMod53G6FA0TE4uEhfjTJeKw2bLy4plip 6OwksNENUq2ZmqafwpJBx4mMC3aDjmfR7ZuSDmbSc7o7UkIOQxGqLecwFCdYKu33wQL7zmi4/D/H FqeFtm/PpDVBYMcgIGRwx+AurQoCgoAgIAgIAoJAB0KgaE4wPerOPEnP3+9SzVb3cbvZCQpRBOEh TNv8xoRnUHdYnzS/2KwXEtjMjbX0n0zDgNmkpcUiIScExA5LjoMZgwkgHMz0Jw9sCuvYwYxJXXDs H26165HvL4jdhDAUU3dYH6VhQWA7ISBkcDsBLc0IAoKAICAICAKCQMdDoN8CT75K1umGO/tSr+4a 5tI0DMIJD8Ex8z5VLPuh3MrMd+IxAhH8XFKzCFhGeD7p7lWqqu9iIN4gZeXvcKQcBzNI3qw8hKHI oLpKhKGoWgf/Mvp4xdY/mbxQeUCz7X8eOiCybod3VjogCGwjBIQMbiNgpVpBQBAQBAQBQUAQ6LgI gAT21i3rHJvMi3wuTz/NhciAGE59NByFXOkdBDh/dOEgOxGaoKrjDnQ79fzbEwYt2fudJQsUVd0l FkHweRhVtpdkQ8VX1VyUVdCHvOm5VFu2giyjzq25fNdaZvTIjxbpNx/av/7V9tJf6Ycg0JYICBls SzSlLkFAEBAEBAFBQBDo0AgMnGsPVHX3xZAaneNze7snXb+EYuFaSARf0UzlfyWDjW869CB3QOcD JSXWB7bvJ7DAA9iBjBmNQFDog3S1fZDCZBgKd1oWdem1G8JQwMFMxSogpQyGZeOkyQsznrPt2ASo ji7eAfBJk4LANkNAyOA2g1YqFgQEAUFAEBAEBIGOggAkgcPdtn0x6cqZXt3dhUkguzcJGpFShER4 vj4ceXxFsTKno4ynXfbTphmOAxckDj6ve9K2aez51mDQ4GCmCxzMpGdTXdlKCtdXsn3h2aZpH/zB ArqjPHfVQ2fl5cVaU79cIwi0NwSEDLa3OyL9EQQEAUFAEBAEBIHthgBiBI5XNO0SkL+ToA7q44Yt OBgJxiIrVJWeCBrRpxEjcJE4hdn6W2Kp0e8U2x2BraUnFgmSD3aD29+faAvGwWEo4E2GyWpOjwEU qimHlHAlKTYVqrr3vryq3se8X2rcfOTgiEiIWwCnFGnfCAgZbN/3R3onCAgCgoAgIAgIAm2MQFFR kRp9Z8Hhqq1crmh0ZJrbq3GYAwMqi/AOOp9U+zFDNV5YPEBZKSSw7cDPDOsr67z0CwLAjzTgUdQy IFwD494RISZaMqq4FFMhX3Y+udMzqb58FQVryti+8GCVlL0/WOi6NxqK/evY4kh1S+qTMoJAe0RA yGB7vCvSJ0FAEBAEBAFBQBBocwQKV3q82fXG8bF586/QVXU8bAIdIhIFKTGs2OyYojxKauwVkMBK IYFtDj+NK47UT17g/R42mSNNJoMgW5oKHt4+5YMJANA77qfmpuxufZ0wFOxgxjCiGZrLe7PLax33 0QLPX+Fx9L22R0xqFAS2PQJCBrc9xtKCICAICAKCgCAgCOxABBAjMMvy5p4BD5YXY1K/l093Ob0J I0agRdYXOP7fZZHadyJOoPGky5gd2OGduGnbsqeAgF9kGIjPCPzjwefb/4DZwQzWDWBHmIMYiRlw MLOW6ivXQLCp7W7aytsfLHI9GfXEAsf2jCxv/6ORHgoC6xEQMihPgyAgCAgCgoAgIAjslAgUzrEK sr2+s8jrudilakN1zZMMD4EY8TTZIPO/7ucHfVgSKIFLSzgz6aTp7ZWeQj2qD6OYMVBV1XxbsVVF AUJtncCnFIUGGrEIfm0lGq4jd1pmW7eyTetjKSEwooy8Xg0OZiLBaoRP9FzkChkHTV6Y9vk27YBU vo0RwGKQbYdB/stUxS6D6Hqxalo/QfK7dBs3vMOqFzK4w6CXhgUBQUAQEAQEAUFgWyDQb4HdTyf3 uapXOd+jufqqKkv7nEDxIVVR37AV8+F5A82pTtuBkm3RhXZf5/TpOXplQeQ41bbPdinK3iBphaRj WqjAGo57z2Kwtk4wD4RuKNlm1KneikXbuoXtUh8c4AAfw5EQ5vYcSMHqMqp3wlCofWFPeIFIl7fL bdgmjcS9CPP9ZUkwP6RsS2xXf7AwfRrZ6mvR1WtfOXZcGsLM7DxJyODOcy9lJIKAICAICAKCQKdG ADECh5LiuQROYc5M070Fcf1DkECIbmyFXlaU2KO/DVBmdWqQMPj352ijKD96t6a5xhNYoAKCpkJ1 1uVNh3MUHXxQc/I209/EJBvB58mTlo059zYgndvpBjeEocjp6kg4o/XVibiJomq8nW7BNmkGauNY sIACuQlbYti2QqU5G38lRyiKeoSre9c/vj8vcuORg2Lvb5PGd0ClQgZ3AOjSpCAgCAgCgoAgIAi0 HQID53r2BqO5lFQ6Jd0NcY2zts/hIcKrMTt/wVBjj8MpDESAMkl/f57nbC3N/R+QsVzLNOAQJccJ 8eAQQZUlg5j2Mk7bASomU470pSMn9N/iMBQuL7m6dF5V4458C5vre1z6yyFGLBDCIIVrKxBipIwU TR2mqJ63P1ig+g8fEPn7zjBuIYM7w12UMQgCgoAgIAgIAp0QgYELtEPIUkECzePT3WmY0/CaPoeH iC6AatfTlqo+s3hgZNl2YTYdAP8PFvgu1nT9YUxxNdgEOjH0mAw6WnGOWhxMJ3m7A4ylvXXRwQ/S JEk7GQL4O3H5MiH5zSIvFk1q1y2laKQeQnXfbR/MI+3wQZGJHX3EQgY7+h2U/gsCgoAgIAgIAp0I AY4RaL216BhIAa/A6v1haZ54eAjDMihmmT9alvWooUZfXjxQKe9EsGx2qO8v0PZUFe1eJoKa7naI oAtB1Vk6KEkQEAQ2goAjHYQEG6fdkJ7nwEa0evUiioRqSHW5J3y0QJ116IBQhw4rImRQnn5BQBAQ BAQBQUAQaPcIFE71pGV2oxOt+QsvVTV1nAeEhpMTI9A2p0O18eHq1fTqmnGxoEgCN7ydiuK5HnaB GZYRpaxufYQIbsMn3oIdJARKyNtB17YV43D6B6dKzfWO1SNZQzLudGnjickR23turlwrutduL3Hi Ymouyuram8qXz+XXjAYNhNumrvR8Oq5nJNxuO76ZjgkZ7Kh3TvotCAgCgoAgIAh0AgTgGTRPt/Qz 1e50AcJD7KHDwQmnYDREpm1/Cncn/11Xnv5u1ZiqKA3oBIC0YogfzfUMI9062oyFKQ3OTjxQeduU RDAcMxFlAk5lQGaYHLh0OHtxsUOZLUtMGIJh2CW6VKeOjZkHRtBeFO2le3WC/qojhQlFTTJTnMtw PzQQlDRP/P5z+SiuY9bFvMXnxpPQDH8xTBvxJE2H+HC9Prfm1NM0Wag/jDbjpmI2eVDOpbH70w0T lwlFDacs97lp0hNjba/2kE7/EtgGMWZGw+fRnPHoGDOTWGMzKq+MjJKopyVqxYwtJ26Hn61QBO0m 7sOm7t+WPXHNl+axcPtJcs7PQJLE8tj5+YjELDxb8Xu+qfEwIdTdPkrL7UZ1ZSs4zMiI+pB5KKp5 uy36uiPqEDK4I1CXNgUBQUAQEAQEAUFgkwiABPZWST9XtdQLfC5Pf47txqk+Go5hIvueaUf/e+6L t3wSCAQwd6sSNDeBgOWm/SDEgHcTBbHxcjfptIWlRrv3zaU+3Rw/PCAHCv22ooZ+XVblECSHVDl2 hfEps+NuJsGtkmTPcd+D0zyxPniP7jR/VQ2tKg+RG+QhmfgSA20xERyG9vqiva9/WQfPr4ZD1vYr 7kbZGXHpb5Kg1YUMmvFbqVNmUM8sKsZ13N+q+hiuXQupDRPD9USP687P8tLvBhc4/WbC98XPa0EM DIf0JBMTRpeu0KEjezikkonrN3NLaXVFyCGyDX1GJUwaeHz7DOkKYqPT9F/XcfQBBwMT9fCxa04o ol+XVtOkr5c4dXGwjlSiyv1IptT+OlK5Jpim3tZUfPm4Q9YdfOL1Jety9thja6LR5D6Ps1dBOl16 +CB6Ycpi+mlxBY3eLd8h3T8trnTqOXmfPrTnoHy6+7U5VFkbjePkhN5b3waTuYG9suicA3elJz6c T4vXIl4kxpkcV6NnItG/kQPyeIt+XFRJPfLSaI9duzRIICvrIs69T96/TdXT9JmLDzX5NK7HIIkb 9zU300Njiwqc+2Rgf/bCcqqqizqEkBcVBvXMpqF9cmga7mVZTbjh2Uh9zpveJ29GLgUr1zo33oqZ +6M9IYOpD6tsCwKCgCAgCAgCgoAg0BoEihZogyxLvchS6Nw0l7cwPqG1mQQitpf9umFGH1k8WJnO M1QQwdY00emusUylt+bi9X8bUo24jWVziSfVTNAO36snFeb66JH351H3Lj76v2MG04ezVtK7M1Y4 E28NxDw73dVAxJinu0EamCbFDJsyfSylUyA10+gSEI/nP1tIpdURh6wkJ/rcDkvVzgah2H/3QuqS 6aafl1RSTSjmkMG1VWFnO65yqdB1Jw2ln0AkPvl+FY0FETvv4AH0xrSlTrlzD9qVhvbOpsc+nNdA TpkE9MpPBzEbQjPnlSOX0fFjetMYkIJ/vfYL1aJuJjpMhNwgfFcfP8SRHr39zXL6HQjSTWfsTv9+ 41eHyCalokwceub56ORxfWlvEMyaYIy+KSmFlM1y+ugQOTyuXXN8tHhNHXlAkLwghzX1cVLF448a JmWnuR3iw33gOplwctvcTgYwqYc0lfvVVILJxxi/nHS3I12rQr1MwnJAmlmSGgRJ9qIOh/hyX1Ju cvKOM7nvhnvrdsUlqieM6eNIxuauqHaksl+ClM1eCM+ZkNxxn5MSQm6D+8hEXEGcFo+uOc+IC78Y vtN+ps/ljIXHxc8B942fF+43P1O8/c3cMhqCe3X6/v3ovjdLMNYYnT6+H40amE8Pvfcb1WE/w+ty JIhM/vn+M4kz0QiPm8fBuDOWLoyF22VJXzqeuXCUJYDriT5jtAvI71XHFtEM3P9Z88upaJds2q1X tkP24/deo9P360cjQE5zMcbHQW4xJOccj91pE43Wol9JSTFTT7a7jYdfYaC1bh35pSKSwY5896Tv goAgIAgIAu0GgQl+/65wxeG5PRD4FdtF6NheyCuRpyD3QB6PzLOHFRMDgc+THUfZEdjuhTwZx+O6 VBtJKDsMpzJQDmSICPtZ+DkmUe9XOL4Ix3gOyMeykX/EsZ9Sq8P5rtg/HJnLvYPzFU3Oj8T+UOQq nHunaVdwPU98uM+f4XxsU/3dknMD52ojMLm6zFKVU71ud5ekWl8oGl5rKvbLpmI9tniAOUfsAbcE 1XhZhJHIVzFx5VAOPIHdnFpfFNKvleVBh5zxpJkldweN6EFvTl9GfbpmOKSqAtKcLB8mxLhRL0xZ 5KiDXnTYIEoDAeQJ+lJIi1jtjqUvu/fvgnj2Gk0rWedIZJjksBSNSQlPuF/+YjGdNr5vvK8JBsMk jMlDfdh0pIs8OX/lqyUOYeLJ++wFZfTOt8ud8ukgXH86aQh9OHsVLUG7LI2DCjEdu/cuUCW16PnP FzntVIM83XfFaGIp1ac/rHYm/Xx+PKSQg3pk0jWPzaS1lWFagLZHQTp2CCSF81ZyP9ZL/vp2y8TY 6p1x7LFrXrOqqUyainbJQfu9qSDb65AoxojTfsMKHYLCY+Myz+P4z5DKDQdGBwwvpFKQW04fg/Qy 6WGsDBChLhkeuujwgVReHcVxaESjvyXLayhmmpQDctkb94WJ8leQkO6Fvh/7u13ofyA2K8rqaTT2 D9+rFz34zlyHRDIBZQLHY+yS5cG9sOg49HXmb2VUCPLP1z/83lwa0a8LHbpnT1q4usbpB0uLWXr2 yfernfvBdTE5teBJ9aDh3XFdniMB7gkS/ub0pbRwVa1DejnFVXDjtpR8bWl1mObg+VpRFiQvpLE3 nb47PYf7NAhEbXxxV+c895MXIbivp4zr7xBNBw88O5PwLFTURmgvkEi+T4vX1FI3kPAv5qyhX5ZU Oc9AkgwOBgF8dPI8+mFROSSTFZSZFietTJ5ZwpuFhY2H3v2NzjywH32C54KfoSyUOW7vvnFpOO7/ 9yDIP0KSmipR5r8pVhuFJ9nm9Ym3/E91h1whZHCHwC6NCgKCgCAgCOyECByFGUEmyFI95g63Ys5z H8bIulFdkA/GfOYInH8E26ejTD8QqSfw2wNl/4ljOSj/JX5rNoYLyp6Osn9BuZ9RZjr2VdT5T9QJ gkQlOHcXjv0fjp2M3A0f+K/xe+Nf/f47QVB/4HpxnvtzC1+PnI7zE3HsOvTFmYGi7L44diHqfBm/ R+NcIc49luwT9vfgdrDfLRInt5Vbex/7zdX2devapaQrJ/5/e+cBH1d1pv0z6pIl2XLvvSMH06uB UAOhBEggGyALYVPJZskmm7LZUNJ+m4RN248kbEIAk0DoLTFgusE4GHDDuMq2ZNmSm6xuaaTR6Hv+ 586Vx2MZjBuS/B4Yz9x27nuec8c+zzxvycnI6hW6Ie6IRcvU98zWSJQagXy2dggRQAVBnRk3pEDu mIELXY4Wxt+8vNgvqmc+v8arUP8pBe1aqXS/eXK5XD17+XNu+fMiV1UX9YrVWUcNda8u3exeXLzJ L8JDtYvF+LrKerdAas3p0wbtsshmmKhKELgBvbPd1R8dK/fQbW61iNmw/nleldwk0oaqkyFyECps /eQOCCmAdKBUDuqTI+WwyaMGMW2FEIpgDeid60lJSPJwW2Q/ahhqJUQVMlIkAoZqiBKE6yN4zBOh rRYRxNWys9hD7sX+ZimAT0hlzJdi9d/XHeMqtu/wZK1CJBtXVQjd90SArtLYvlu6wF0htZF228Pv yo0yN3ChTHK/pc/ikUWe7N39fIlcWoe571wxzf32qeWe6Fwpgnz9eRPc0rIajx2kFddXiFe+FDvc cFEF/Zh1H8aPHWeKxKEM3vtCiZ+Do8b3deM15/xiwHhPPWKgJ21/nbPOnSri9PVLj/CqJwonDZI3 bUyR+4zG8T+Pvuvdib92yVT3rxdNcd+68y2vNHfWGE8vKYAoz2dNHyLSXetx/e6V01zZlgYpdCUi n728wghG40R+f3z/Ej8fP7/+WK8g8kx9TarfvS+WuGfeqhAh7uXHEBK2HNmPIvzQq6Xu3y+b6tZv bXQv6Zq3Vm/zRBN1kR8CVsjm5xdudBefNMKPd5kwPHZCP/1AMcbdeMd8/0wNVg3J9D3EkArN9/t9 5RB+cz/4rYwMfnDM7ApDwBAwBAwBQ6AzBMSPXKZeLVpnKeDKsbp7UGQq+l8ibvq8RJ9f1OcztTGM DkS4rtPbI3odo2taRbYmat9NOv51nbs15SZLdM7PdfzExH4WIJXaLtL5g7SxWMdz9TpH/7h/Qddv 1r2m6/PpOm9R4prTdH7ej2699V62dXym3qbqtYBt9fMpvebq2mdly2ad+3W93xuSRZ2yXf3frP03 yNmQse5Tm3LzlLTYNSvOVRzbl1TE+cLcDMlJam1K4d4ci65UCYQ766LRezcVRzaZErhPEO/XRRCI UVpYQ1BQtlBnHp9X7lXBviJ4c0QiUHx2yCUPpeU8ERPcPCEGi7RdJcUGosaCH+LBO0Qk1W0R1ZCE MMlqS7LhxOeh+kBmHpdL6E43vV2H590i9QXgfFq4Mg/cNkONGfYXLNubW4PkLx3nJRSrsFdP/nQ6 MYfJ7ppcg63Y/H5ZNEtEXHeIsEDottY2SQXN8UpUmQgJ8WsRfdHoB9dK3h8UYbn6zLHud189UWNd 7+ZJkU1+9hkHZAmFCiQhq6Wb60W+av0YUcm8m6n6w2ZsR1Fj9BAfCF+qd7CfH5+Ah/kJ3FhR3Tjf /32g7XLZ+4YIFcdXS+kj4QyEHPdc359eU6Tm5YlEo7geoxcunSi79A8BT23cA6J90QnDvbKIYnun XHyxGZX40pNHuttvONE9KALK8zRFbqXc60KpnVkiuNjB/ccOLvD9v6EfCnJ1fzChhc8T9oPFn2av di8v2eR/1IAwnzxloPulXICnafsjY4vcrDc3+DEvlUJ7jhTwp0TiV5TXeuX5qyKby8tr3BN6/vmR gOe4pzUjgz1tRm08hoAhYAgYAh8mAtkiTpUiUJ+XEdfr9ag+36p3FL+r9DldSyMKu92uz5/ROwSS xAOn6iV+5TZqjXib3mtTB6F+cT/F3TT8t5t0HMu0fa3WSUfr86v6nJs4Hq5zq3W//kl99dHnZNfO Bm3jaho2SQLeJlogqQSkz6+yZEOZbKjTcoh9H/jX8ClLs3NjWbGL265e86V0l3VGTma276a1jdip 2NtyOvtjVVrrAzXj06Q49rxFV+qcdtVtFvEkBXlgTmlHnJtfWGvhjdscBBEXUhbyfaXGodLgJgpB grCFihmECpUKV8wgtmvXjJ/Eg0GQIAE8TJBJPtMHhKGfCOYVUmf+rsV6udwdub5+h87XeahAZBNt lg39pQDyuXJ7o3oRAdH9cBOFPI2SSyaEh+uIcUPtwoUVcsE1qI+QiIEaE/F65XJbhKANUJ+oodgO AWBsjAXXQ2wOXST5jPEoosmNMXANuPFi/P11j5s/M12ErkrqVFWHOgnBWVASuDDOkIskyho4zxYJ 5z1s4In7I+9g7OPmkraZDx/36RPiBPGQxB8yRyilnX1hGRNj4OXnJ2kQEGyIar5exO+N1o8BebKn VriG6iLEGVde8Hh0bplXaSGrYAYmYJCcFZbuOQZ5xe2YuEfsReFFvZ0jFXme4jBxDUaF/tnD7/h7 0+9dInXMXxBH2O7OmDbEq8SFcpOtknoHGU6dB3DiBbl7Q8mH+MHgKxdOdjOlhKKKNqrvKSP7+DhC 7GLeiWF96LUy9+snlsulN8994fxJ7lufLHbfn7nQPy9pPYwQGhnsqn8Tm12GgCFgCBgC3Q0BCFIG rpUQKRGnW/QZYjdDLylcbr5eP5Iq538qR7UTgePzN/U6Qa8r9bpPr91/St+JBIQRBkVDDbxBi7LL f6i4P93rcV24QX1W6NhEbW/V9pHanoVbqvYpm6RbpPPP1zaksZ+O99H7Sm0fo/dybS/U+6RE/+xT ujzXpuOokYsSCmGOzsvVEnWv2ZpIYO9YRvzTsaz457Myso7JVK0uWlQ170QwXpb+8ocNLfWPRYvz REC7dfjNzpnqxp8gCN49EldFLXwhBHzeVN3k1RKUGxokY5zUmZkvrPGL7DATJ8cgLBAgYg9Plusd CTjKtjR6AgY5gyCQnINYuWJlcuTzCZMGuBLFp62V+yjE84rTxvuHDPdKlEaIBWTxfqlHuA5+8tRR Pq7uguOGibiuc5VyHZ0ht7+LpTj94tFl7hEt6HEPvP7c8V5R+/jxw90rUojIaDl6cL77yscn+ete XrLZx8+x6P/7/HIlqBnkYwdxPSR2DHJWIjfG+18pdWOH5HubJyib6QBlKuV+G7bu8GQ1bBASX0oj sQN3Wl+yQF8cXGVR6cJkMSis4EHMJK6qjBdyijtpWHohxJN+ITZ+XvTuSyToWrbZzzb9kgxmm/q4 RG6PYzVO3DB9JteEAhr2Q79rRKJIhnO2FDFcPLElJFS4eDL3n5wxymfkPO+YoZ6wovpNUAZO7sfY 5i4Dv37uyxdO8liOUMwgbrBzRabDvyT886T+AnV15z28O6r6gXiC0TVKBlSu54Q4Qp63LXpBMj8n Rc8f29rgFUHIM1lBIdX/oljKp97Y4N1bed7IOItLJ5lDSQzD3GI3WJFZlueCZ5dkQiSxmbt8s8aZ 6Qlxlmw5W67N3Jv78KMH9hJHChHsqrUj9+evGyOD+4OeXWsIGAKGgCFgCOxEoELLLSlaDvXvCyJQ rAWrJKndq39sUe7WhkSQS/T5W8T96SMra1Q4XDaHE+ennTfq85ZkcHXuJ7R9lo7l6/O/6fPdusFd WmzRT1TXzdWx2dq/Vp//RZ/P0QtyN0uv67RvmO5JjOAz2oaR4ql2O0qmiOn3tP2E7LxH79/VOTfp naT6xAdCbr+s143aP1nvuJISMPQ1bc/U9av29BAMLmkfVBDPujqeHf+c4gGnpkcClaOpVcFZrv1p 6Te/z2hZ/Myq4mJtw1WtfZgIsNAlqQqxbmQIJeYsjFsLErtEFFu2xn1EMWIDpaDgokesIMSF2Lh7 pLagtPhyCroAteiXImWQJ9SbiGtMlE4IRknfKDuQxJ8+9I4nLJ546hiKGIt9lCKStdAnjVhDYhAr lahkrBb/kIY/Kb4MVz5IBbY8pwQnLNzLtjT5OLPpSvTST4lSnnm7QjGK2zzJIovlbCWcIcspBPM2 ZRiFjKIMvbu+2mcgJTMl7o/cj/IHkAJIF1knITqvKn4PAgPRoXm3SI35jlkrPbGDKKHU3fVciVe2 eN36l0VuslQo3Grvfk5xl7I5dK8dNwSRvt1nOyVuLsxiimoG6SUBDOMjrnGjyCfYb1JMJNsQudsU s4fLJcroLx571yf+gRSRFRVSG5VtrcLy/+k63FUhphAjEqbgXgqZRz1bK4LYKrUuR+OCmL6mDKOo dsTbQbRQXSsVA8n9cQlmXD9/eKknWrgR1zRGfVIcnhn/TGlCcX2FCDK/S9bVyM1zpR936HbJswBJ huSNlJrbJGL2Mz0TlPfAVvqn/APPEUl9UHCZY8Z2vOYNPCFwy4UDRNm7J2u+OBccuS+2PKLEM5TR mDC00P1cOL9bVu2PozTy/M1UPCbzACbMJzGNz+k5WVCy3f/8FXwPelYzMtiz5tNGYwgYAoaAIfAh ISBS9Gh4a5GkH+pzrvbtSOyDgO3WdBwVsFSv7ycOQqxwH+2sQer+TgZPlD29ewKpz6iFERG90K3z be1bpH1ZiXPo686ww0TimhwIXZgNVNd+NemGkEHiCkPbCV76Z45rv8o7uBVSIpsT6mJLZ4aqRuCo LJdzrRbC1+VkZo4i6x4rwaZYM30+Fo+1/W715La5wbXFexiu7f4wEIDEkcyDllponoUw5IXFdOj6 BznDvZKFPgQgdKfkeogSpIjMmPTr3QYTq2kIznYRk2dF0GgQQL+A1/5QmYKQsS/V9Y+FfanIEgoV DULhF/v6DElCWcSdEJKEGyIxjzRs8zboc51qE0IGGSPnMp4XF1f688JxQuZwYZyjDJWU06CGIElI ShSzlmwzRJUyEowBUgFxgIiE+xYLF8bLfSA360V+uUeG+uR8bEru1/ene4cNEoO76tsispRygKTX C1eSowQqJDGEUa+KsZ2dlebdMBmfv0+ihAbjAek31Q/9gxtxhSSlYf64FvJKP2xDjiDrpcqeulLP BOSQc7Jkd/L92Qd+ZGhNxq+jNp+MWCm1ksa5WxTvxzxB5JOVNs4H2+WKg6Rxf56vbM3YZhE94hdp YMtYGBf4MT/YG85beF9fykO4UcMwLGnCmAtFfMmyCumFAIfn8+zVNLT6JEHg87rcVYPSJoF6mVxr sGNyesAHI4M9YBJtCIaAIWAIGAJdCwGRLNaFIZk6IMapzw7ilUTyiOMLsiYkNe1DuQvJ4W737+ya lOs7tV3XEe/Ii/vu1r/KQ0xNy8j4vFZm/5STmTWIxTlANLVEa7RMfiAeid+xenwbaqW1LoxAKglM NTWVnHW4Q6bEzbGfxXdG+u7LTY4FGSX3vBRlAb6n5l1ZE2pheE5wv53ZJMOEL6kJajgPYhje27td asWfaktIUCGaNIgSBDdMZJNsW4gB+yB9/vzECeE4QoKVajen7anf8B6ekHTYEdi/065dcd7TuIO+ dr2OfsN+wuNhnT0yk/7vkysUs9ciN97MXYrap96/M/yS8QmfqdBNtLNngvNT5zXEEIIcqsPJ/XLf Xe3f9YkJcNv1OUp9TpKvSH5e3+v52+OD2Q0PGBnshpNmJhsChoAhYAgYAl0JgSkr0o9rSyMzqLs8 NzPbp/5jwdXY0rRZ9anva4u2/mFdcWR5V7LZbDEEDIE9I4CSiSso7pKQqZ6qitkzsDMjmWFhCBgC hoAhYAgYAoc5AvPmVWXXDxiqovIZw+Jp8ZHxeDxLGkRfOWNRKoPMNs2KBtsqr61oYzy+TkGJ/aa2 xa5XeYiL+2RmZUblc0ZaeZWHWCPvqpnxlta7RQLXf4BcM4f5DNjw9xcBlCBcA4lnfC/FaH/ug7pF shFcGH1imP3prIte+17qWRc12czaRwRMGdxH4OwyQ8AQMAQMAUOgJyBwz9IdvQblDDgv3h4/1w0Y Mb3NpR0hNS+/PaKkpYpFaleamQipZtRwk4uoFiDKn0p4q3K9ShBk5bmiWNSNaGtzQ9tiZcMy4j+I 5cUeXT4sUmMksHs+IRCdMFslWUIp5eALlieGQ7zW+9XZ29eRk8yFOD3653nDvTC5uDsZSknSAtEj Vg5iltyiLXGfWOZoFU+nfly9EtqQaCSMzwviv6gTSCmLuM9u6jN6+ohDJRFhbDqJBDO+Bl/CDj5D /rgfpScuPWWke12xaBsVA5h5AEsNMDaILPdj/Iy9M7ddcCDjKgliiGsLz2N8zB8xfIw5KK4YxNiR pIUgZeaTunq4xaIA9kQyu6/P3+F4nZHBw3HWbcyGgCFgCBgChoAQmFWSfd3gvPx/j0XSi2OZuS6z rcUVxHa4wnhUBK9JBQ3bXX68RUJgsFwUFXSNkUwXEzmsj6i2l0ojlkoJXBrJcHkkF8lIy1FKj15X DmsUEbTWZRBo37sciJAPCPz5xw732StJpFGsjJQnTOrva71BCEkIQ6kHSgHQK4SEFtbU4zPJOiAo qfvZhuiF6WJSC3hDhMi0SVbKBtXH47Gbt2KLTzgSFESPuxkqU/GRMX19jTqyRybH32E/vX9CpS/0 LLoHZDNlBSguTr09CFGFXB8pQB7TbxpHqewAL46FhIgxk3yF0hXEqEGGiZEkqQpZRSFZZM8cJ8JJ bUJq0WWm7zm20ZMz1eFjMGRIfS93S7JrDldduxlHDApq74norVcpBRLShIlMGCPQUiNvlGotYjuk jnIS81V8HUw/dswwN7Rfns/IySS1aLCvqOQDmUYpFwEmFIenjAYYpsZUdpnn1gw5JAgYGTwkMNtN DAFDwBAwBAyBroXA7JLsb2Rk5t4mDcjlt9a74ub1bkJbtRveVi8y2CIiKHVCJmeoOFqYTZ0Fc5uI oH/X3gYRwk3pvdza9EK3JKO/25zZe1DfjKzfzFodP74g2vvLM4o3UdTe2oeMgOhDS0D03ruFGRkp ur1RqftfUnZN0vmfMnWg++H9i0X82t3nz5/ojlRpCcoYNKtCyNB+FHLP8IQNlQ1VCyVrmMoDQGAq q4MSAGTjpHQAhd8pQ0EJCsoShKofROjYCf3cl1T7767ZJSI3dZ7EDeqT6zNJQmIoD3HZKaN8HyiI dz67OlCrE1yXe1OWYOrI3u4Xjyzz6tfxIrITVUbgZypNAHn7+qVTvbL3V9UqpAbdGUcOdj/4y2Jf 5gBbquqiyqCZ5S46caR7RPXtXn1nky8Wf+VpY3xNwV9q3JBFMo9ec+Y4N1SlB7ao/MKeksrERCap b4iSRz0+iCSJSVIJGOM5ViTtc6qJSBkGMrZS+gHS2Usxe5DwdNRCaKX+OOMjgzwppNwEdf2+LNyG iQA+rFIR1MkDC0pIZCkbDBQZtZAyGZDco1RqAyIJedwgkkvCGGsfEAF+eKBwZA9oRgZ7wCTaEAwB Q8AQMAQMgQ+CwE033ZQ2+7pf3hAVEZzQtNld3bzMDYwrnbwIXovIXkj/WHi2JmoD7uyfs5QJUmcX tTe7ga073FGtW9wFkVL3SM4ENydnlBSYrKuLjjv/Jldzl5HBDzIxB+ncSNzVs3Dd2xJpEAeIGxwL tQ7SRir+LTVR94rIEYQQle1ckY7xKr5epiQjtKff2uD6FuZ6wkEJBQrJo65Rm7BafXxCBIsahYvX bXejB+X7UgQrymv9ORBHCpsPEPFqEGHaVtfsC9xD3CCbDXLb/KjUMBTKO/6xyv2LipBTMqJC98mS uygNcoQ9KHEbqxq9CyT2QyapN7dOpQSomzdO5DAs1wD54xgqWlDSIc3bDWlDNWMckL3bHlnqfvXF E0QSR6g+YIlbJbIKoYMsb1QJh87IYGgT75efOsqdc9QQjb3avSBllb5xdUVRhegyzuvPnaByBlvc U/M3iABmuK3CgPtQKiLZVZb+IK8QREo0rFEpDQrCo3I+8tp6Ec+Y8It6tTBbTI86iJDConzqE1KU fZsnxZDEvX0mDtKj2a279WRw70T3Lj1OI4NdenrMOEPAEDAEDIHDAYGbb755usZ5pl6HZG324x// tPcR53+lX1bfka4+LdOVpxe4vHYpFooHzNICJyYz8Czkd+9UPQkD0QYjPm4wONokN9H1aQVuS1qu 39cWbXLP/eSsGx/avFrJYw5Io3zGs7feemvJAenNOtlrBFChUPoGF+VJBcvzLqTUbYMwfuKkkb7W 3QNz1rneKgaOcvg5ERrUuifkxtlHBch/fv2xnixSZ+6TM0a5H0lhXLSm2g2Wohak8Q/iUSF8r8h9 EyL25Qsne4Vunuq8vbSkUvdq87XhTlRx8RcWVchdc5OUutHuFLlT3vfS2l1cRSkmXq36hShxvvC9 FLIRUgv/6fQxbszgfF+P7/6X14pcSd0WCesrAnrFjNFeRYQAzlMx+bCGIgQMG4kxrN8RU2bNejd2 cKGPxSMWsUl2DVSR+tQWxj2yH4L5d8UuQqInj+jtCdtNV013S0urPW6MrR0iLKz69872RdBxfQ1c aCMimYGdjbh8qsVxN01IedR3HCSVdJII8MThhe7BOaUeezx3xw0ucFdLuYQQbxABfEf3gyByzyPk +muuoXv9FejxJxoZ7PFTbAM0BAwBQ8AQ6MoIiAjipHWvXsWuk3psB8P2FiV8Wfv2392kUz/jtmbk ujuzp7oRWY1uTFutGxZv8Cphr7iyJcoZNKfdU0PPUtGWWqQUEk3YlJbhqkT+NqXludKMQrc2rVBn axHbGnXrFj7taret+5qj2Px+tUSlwjgxV+4+va7ar+7s4g+MAESkt9wVT5s2yLspEm/37IKNnqD8 +sll7tKTRrnff/UkH8P31uoquSzmSfVqllI1zCtSL+l8lLcxIieQtDWVDSKJmT7WDVElVLz4jLJ3 /8vrvGJI7OA1Z41zR44tcj95YIk7Wa6qo0XmIDa++LsKt5979FD37FsbvWpIIhV+mygQQUoWayCE xD++u77GTVKfENQa2QHRQpVDYYOoEhsIcWxLcjsNwQqiHIOYP0/e/DkcVd3BRK1D/7NIEHKpmLwB 3n2Wtn5Lg1fiGC9EtFbF7ink3l8ur9gWeu+CJ+OHCCa79GLTQLnKHi8XUu6Jva+LsEZFXnGJxSW0 r8Z0x6xV7o0VWxNxic7VKD5wmcaMYomaSgvrOkIQrRkCIQJGBu1ZMAQMAUPAEDAEPlwEWJn1ieTm u8JbnnKR3gOVZSO6uyTXsdpMGJu6zUo03NfxntgXynvhytOrBzFXpqQxfbdtdHlb1rv10t7WKf4v Pb3d5YnWZYr6kUAmLdIuQgjNU9yRksewYI2huGhPk88pGtGfWgOnZ7rmgv6uumio2zGs2BXqHNTD oKXakbTM7pAeQ/t3HosoU2nLmjdc48PfZ2ewurZ20BGAdISEioydW1GUXin1RIQElbiIEvf2jlwe /yH1DkLyzcuL3S1/XugJ3ybFCf7f06u8yyWukEwxcX6oaJCgdQolLRQhog8UubBRz44vQ4Xi2JaX 17iRimsj3q4oP9snTFkrd0gUsMmKCUTlmlGcK5I4QO6kcqtMKIwVcr8cLAUT5QuNm1hFVLXVIqS/ EXn91RePd5+SEvj7WStFbqVqy6Vy4ZrtXumEOGEzY8SNFFdZ1MIg9nCAGyPX1jt0HUZC5Oh7B4lu eP47/nByp23ybqeMe5tcTE8rHuwuPmmE73+tXFVv+fMi79oJjiiAKHm44q6prBPpHuwV0TrdF/KN UhrT/ddU1HmbIIetUmCzRRoZ059fXOMJJPbQf0Cw0+Ta2uTekmqLe2iGjgckmSypgaKJvcwn4yaD qtHDg/616rI3MDLYZafGDDMEDAFDwBA4jBAQp1IK/aHjXaTfUBVKgwymOGjuiQzuRqaSSWFIwhIn 0Wein3S5g0bbYq6y71CXOXyyy6vd4nJrt7nMpgYXa250ER1TIJdLi7V6Moc26HU6qZftUvwoOdGW netiImzNeb1dU16Ra85ROULtx41OHDIYQzJB3YWsMrvJBLATMpid79KqOjxNvTxo7RAjoGlBSCKj ZqjkEd+H6+iVcr0kBg03zIVrqlypVLCZig+89pzx7t8umeIJ2+CiHCVb2eTVrKmKr/viBZPcHLlM jlFilMUiYYsUPwiJIbaPDJckfEHFgygS//fHZ1a78UMLfHKUm0U2V5Qrhk6EDYJWkJfhzjpyqFww N/tt7FutGLuzpw/1aibElGcM+/NENHHtfEZK4idPHe3+pnjEJpE9iOZlKhPREgvOe7esxqt/fMYt tbfcU4ljxP2U2Edi+iCakFoS4VRUNe1GpIivDF1N9RVyp4vgvbWqyru4En8IecP1NCTcKHbURvxf ZSb957PHu//45DS3eO1210v995Mb698UQ0hCGUpg8BVK9+Ve9K5t5gVSSQszuMZ0U4jrpzU/fBdR O9+WagtGF50wwmcaReU8VW629L9I94JgmmB4iL9bXeR2Rga7yESYGYaAIWAIGAKHOwIiXC2S5xRv 5+RqebDJIP2nebLW7mI5vVxt7lhXM3isS2ttlatnsyeDES0qPSkkUYKKD3IuJBBiSExhW3qWi8td 1BedUJ3BNFa+cZFHX4ow6Ht/yKCj7xgLemuHAoGwduCfni3xGUDzRYTmqJwC7p9t/DCQYAu8k+Rl thK4ELO2WUoYKhWxcstF5H720FKfIAbCgsJXKbWOHxJ+97cVbori5nJEzCCHpYolDGrhKWutCNYC EcrtInAQN9rry7Z6lZBYv+/PXOCTueBiSYNQkU2UbKO0QKmLuJKKeq/oURKjXKTsyX+UJxQzFc8U ucIFFbIJWXtRn5eKZJFlM2y4i9btaHH/LdfUAsVB4gYKqaRmIe+UcUBdozxDdX2LWygilVoHkLGE GToZN3F6lNtApSNRTGeN+2yWe+1tj7zrk9JQu3B7Q9S99i4lIVp3sZGv1T3Pr/HkD4UwbOH8/PGZ VV5RhFBDHrm3d4HV+fRJNlRcV1FimWefRfZQPGB2jy6JgJHBLjktZpQhYAgYAoaAIXDoEIgoJi9w 6QwUxFiWkmIklL1AzNOfPpsM5E4EMSR6EIS2QDn0/qPWegQClarFB5GDoBB7hgsj5CuZMEA8yIhJ DB+NcyFBqHzE6C0oqfL7Ua/CTJsQtqUiYjwu3q1RCl+ojvmYQT1jK0QeQ1EcF0rcSYlBhPgQgxg2 7o+7Y4ncJ72bo67n/tvqm32ylo+qPAbxjWQPxW7sCxPK4G7KNvchUU1yYz+kcp2IarI4z36IIJk/ iTs8ccoAT9QgxbjC7qnxrUC925vG+PgRBVUwbKE9ydcz1k0ixgyssyymHEOxTW70jbaPS2zia+4P 4zqK0pocZ7k3tto5PQcBI4M9Zy5tJIaAIWAIGAKGwP4jQHKMDlUv+bO6TtofksX9v6H10NUQ6EiK IiYDMUotaxDam6yAhfsgP0GW0N0JEIQjdGnsbMwcT1XZeOR8Zk2fXXPXFti2633o/2mpeItEeoKM nLsSHQhhxz3odg9ELdWO8M6Io/R61+zVPolNjtw9D2SDnO0NeQznqLN7c6xz/fG98T+Q47C+ug8C B/YJ7j7jNksNAUPAEDAEDAFDwBAwBHoYAiiGxPxRvzCMczyQQ4RM4kq6XP2HiVsOZP/WlyFwqBEw MnioEbf7GQKGgCFgCBgChoAhYAgcFARQ7XApPZhuj6kKJ+plS6zNu6nuSUVlsDElaSFGj+QtFqN3 UKbfOt0HBIwM7gNodokhYAgYAoaAIWAIGAI9FQESsATulEHWzpgybYbxemS9zFC5ic5i1fYXD0gV SWhQ93DxhDz52MVE2Qj6Dwu648ZJkpXUSFWKzR85tq87STF9lF1obG7bJd6wRf2H8Y37ay/Xh26s owYGxe5rlXwG7FIbOH5MtReJO3zs9TJfF/FAEUIIJtlAfVynOgU33FlTC8uTQAb8SGTDcWoVQl5J QkMsZPIxcA3HAdEN7WUcXMO9rPUMBIwM9ox5tFEYAoaAIWAIGAKGgCGwXwgExc4j7tOnjfHE5um3 NrgTJw90Hz1ysKtUVk9IFGUKnpxX7hOnEN8GUeCyMNEJBAdiAkGhJSdACRU03jsSyCQs9jmK9AfF 5SkxQVkK3DxfVTbT0s31vnYeGTEvVN1Birrf/XyJ6hXW7xJjyPUQoEtU069OGTgpLn/K1EHujGT7 RXqe+Md6X4jdl2JIIpuUtwi3fZZNyB6JdBkH5FTnQ4TCDJxBEpp2JbnJdjdeeoR7fO56N3vhRm83 pClUKCFf9LJRGH5NJTeo/0cZjj3FJQIJ9f9I+AIJfy+1EZvzczLd+ccN84lsIHRgAG7rtzYm4iaZ k7gbN7hAZTRGKftrs88OS7bYJ+et90mAyGD6iZNG+syv9AmpXLK22mdeveTEEa5fYY4ff29lWP3b /HJXJvsPxg8C+/UA28X7hICRwX2CzS4yBAwBQ8AQMAQMAUOgZyHgSwyIBEwbU+SJCyog9erG6kW5 ArZvuGiy+84V09xN9y70sXOThvd2vURCIB5kHoUEUbuO0hKQMzJ3UooBQgMhmajz86WOQcYgFOE9 m1X8nYLrX7xgovvRfUvcal1XLIISZLoMrqXW4FkqcE+NvotECv/3qRX+HqGCBUkbK8JDKYqf/PUd T17GDsn3Y/jD06s8yYGMfVt1/G75yyJvJ9eSLZVGmQzIHdv9VVuQYu+QIFSwDcKDUg1kSp06so9X 9VYrk2lDM6RY1VRErriW8ZDllNqIZB1lnBST5z7EMZKp9RTV9wuzlaaKiPQBmbvhoikeO0gdaiOJ cVKTxqAAFukezAclNe5/Za1ThRd/b4hmct8Q0wF9cty00X3cw39erOQ3De4zHx3rbrlquvvGH9/0 4z1qfF/38D2L3AYdg4SiHDJXW2uj7h8rtqnERYv73HkT3L9fNtV9+09vu1bNf1jOomd9Ew6v0RgZ PLzm20ZrCBgChoAhYAgYAobAeyLQLFdLiB9kAhJWJxUQQrK1JuoLlP/z2eM82fj0GWO8UvSOavXN EOF6RkrimEGF7orTRqu0xHYRqWx3sYqc/1H1ADdLcfrcuRM84aLG4HET+ru5KuC+TEXeA5Ijl08R qVwRy5EDe7mK6h1urko3sI2C1dzS6s4WEdwqVesZ1Tf8xmVHuKdUjB1SlS23VRpC3wQVqq9tjLkt Og9SBQEM7d8mUoP9kCCUxqAoe8T94vFl/vqrtZ+xs33tOSPdCZP6+xqLC1UmY2jfXHfjJ6Z6NZIC 8CMG9HIfP36Eu/1vyz1pxHZUU8jppSePdFNH9HGvLdvszpNraLmI8oOqNQgpXrWhzk0fV+Qefi09 oRymOosGxLdcmUpR+848cohbJnWOMUMkwSO8AlX24pPG+X13PVfirwPLxeu2ewKd6sqJm2i9yCmk botKbryxYqu7VGpgb9UkBKf6HTHVTqQOYYviGtM8IWwT4XxFhNTHYmpsPBfs280/175T3RYBI4Pd durMcEPAEDAEDAFDYFcEcGdr1YKPem2s1vhHPrFO3g0qVBNeYWH4DM5PhAH5Y37Bt/NFP5l60TVu gP4eOq41o48/stYzEYAAoPxNlqL3kdFp7uPHDXezRMJQxI5X4fUSFZuft2KLV8OI8/usiGKDSA91 Bgvy5L547DB3suL3UK5Ol/L3nbvellJW7wkhiVRCtYsC6K+LHKY/HvFunlz3blmtd+mEuPQXscR9 9JHXSqVSbfU1Ds9Qf6s3rvIxb0E9TOfGDSmQi2iLJ3UhgQntzx6T7vt9WvbXN7UE7pfJzy6fE9u4 heIKe/dzq0Uso+5oqWbUPFxT2eD+KmIHgfrtDSf5eoazF1T4rwrK5CgR2StFMu8ROSPjaFF+tvv8 +RN9TcJl62u9+22hCHSOiFajMAsb7p3eS5fvrMbz5BvrvTvmxOGFGnd/9+svHe9eWFjhZr6wVsNM SLg6d1jfPLl27vDj9dlTtS90Pw1dVekzUC45libCXOCKpIpec9Y496rs2rB1hye3+bkZnshCFmM6 f847mz32U0f2dseM6+fn84TJA9zvZ63sqK+YGrPZM78FPXtURgZ79vza6AwBQ8AQMAQOAwRYALaQ AEJry9H56a6PFnxxBTtVNLa5htaAFCY3FoV9c9JdodhdjsgcLmQbGqQKKNlGnsKbinSsN8eCUCdP +qqa2tw2KQetSiYyND/D9dXivVkqwTotlH2s1mGA8+E4xFCtmzSst38U/vLSWvfGyq1eefrJA+/4 GLRffOF4EYdN7rmFld71coeeo+nj+npy8sCcUk8Mp4/pGyhSUuz6iFTxOwQEJjkejs/PL6pw80QK UQe/eMFk9x/Di91/3r3AzSge5PdBcHAFRb0666ghnjARXxiSymzF51HoPnSR7LBfZJZ274uyX2QS 1RAXR6/qaT/fAR8zmGA3XF8ukoQSBknCzRNlD1KLEsePIZtrmjxBAgsa9xooV0zcSfsKh5OnDPT3 +L+nV0pZbfVkGSLH+eE1fHcgb5BK3EppqKpLpO4NlVvs8H693CD1uU2kjFi/sIUctkkksm9BcJ3v W//5BDL6Xp+hPrmWhiIK4QSnsYMLRa5b3YuLK90rInxt+ruC+D+S77y+fKuPD8VWxst+CtjXy35+ BCoRkb/mzHGe/L9bVv2ecY+H4/elO47Z/u7ujrNmNhsChoAhYAgYAgkEWBRGtZDN0+LtJ0fnu7OH ZrmqaNxvb9f7f8yvdauqY07czTfv6qXzv3Fkb3fluDy3vLrV9c+VSiHSeOsb292stY3ue8cVuWun FLrl21v8ohrB8I7F1e6+ZbXuS9OL3PXT+riGFsWT9cl0L5Q2uG+9UOFru+FyZ637IwApC2PBIA+4 Dj76+npP3nAdRNXKEoGpk+voDxR7B1H74WePFjmocRVVTT75yX0vr/N14olFwz0R5WlgUY7cSHuJ 6NR40gRZJAaPZ8z/QCECRbZNXEHfVJKVU6ZudzOk/kEecRFlH4SJ2Lfl5TVKJNPPE577da8wmUn5 tkY3rH8v7yLZoKnYaX+Zi3r70z2BaZWLZb2UvxE6lwyj2DNZrp24vNJ8lk2N0+OA2i4DiVWcNKLQ zVm6yY0alOtGD8wXmdrkSRjkiXMrtzd7nHDtfF7kGCI5EAx0PQSQPrg3pJZvCyQTRXGhyFqGGBwx g6iuX75wsieTxA3O17hR4yBn4BPKl9iIwvrFCyZ5LF5fJpKuL2t/xTly3tLSarfKJ69xUiSjPhYU EjfrzQ0+aUyOZH3mABvCuMsKEcEyXG91DEx9XKXGRkwoMaKcj8vsEL0Wy+bsPVW37/5fg8NmBEYG D5uptoEaAoaAIWAI9EQEJNTJFTTifnV8gTthQKb77Ks1blWNftHXonBaH2UXjOl4J1nge2ux9+72 VnfpM5tdllalvzujv/vJSf3cvIoml6cLVookXvzERr+gT9diF7WhT3aaq5Hq89XZFW7BpiZ3wbh8 99Clo9xTq+r0qt2jS2pPxL0nj6lRD413s9Tcoybt0GfIBYQHAoKKBvG//NRRytjZKgUr1z2/YKNP qHLn7NU+NvA7nyp2VVLseovIPSs3StS4x+b2khvpeE/qhvXPc/NEXrY3VHvSASEi8cvpxXL9VD+o a5C+Xz22zE1UHCD3+4OS2ECOIKQt+vGiUKrc0XJfnPXmRm8n9hKTRyxfkdQyFEMIYGg/9wmVSMjP 0yJFX1FCnOvOGe9LJ0BugyypZPMMymskN2L0jhShYny4o+L6yRggSLjG0jaIjP6fktUQj0j8YoHi HbeLTD+rmD9cT0mss17xgKhwIYGFCIOV/7FG2HqirWyov35imSenkGnwCIjgzgapxWUWAolCS3Ke HbJjiBTFRWuqfNIXxutjP0U+6adRRJO+IKnJMYWUE+HeFytzaL1w4LqVcgGu1fxecfpoZXRt8H2Q MOgBucmS2CYv/IWpJ38ZDoOxGRk8DCbZhmgIGAKGgCHQcxFo1gLuFJHAi0Zmuy/MrXNzN7U4iF5U 5G3Opqhi+oKU+M0Jd890r1AESkyDFnc1SrbhtLCevznqThiY7frIN1Sin1cyaCyHud6HF+rzA8tr /cXwy1yRxvK6VrmQxixusAc8YqEaSOZNlLCC3Cz38pJNIj1bPFnrIFJ6plCpHn6tzCeJeXMVZRMa vfJFkpPbHlnqlSPOx50TkoXr5v2vrPMZQSmBACH07p2JGoIoeG8rWQuqFKSHx4+4QJRDVLv/vGeB vyfqIa1dbyiCEEJIDPdqb4/4eMSaxqiPsyvd1OBelP1zZD9JT5JdUrkf6tiP71/i1Uvu84Dsg2Dl Sb17UO6tfE+8Spp45wvwN8UbloisEidJYhgS0fC9+OmD73i1j7Hhfokqh4oJAavc3uSPDZPL5xTF 393+pLKgan8kaRUe2haMo90TLsh3albQ1McMQsf8EI9IXCU2E3sJuUTZDFu6CCDJen6gTK0Q0WQi yD1Q+b5151se+8AG5/HeVtfsM8n2UYyk71tKZIXmmOymlkm0B3zpNQQjgz1jHm0UhoAhYAgYAocp ApC0wXlyZ9NCbUWt3MgU64eaB4tDMSS26dgBWW4IwYBa4ZXVt7q3t6oEgC6c0DvL/etRffyxa6cU uIdWN7j1ta2eCEwfkO2evGSYFoZKoV/d4r47Z4vbrrjB8UVZ7ktH9nWj5SJ6/tgCd/vb29yc9Y0u nwwz3NcySnT7JxES4F0Y9VChuIXJYZIHxjHOw9WSFpAmlMMgSyZuhTT2hcXPUdC2KM6OR4TYNshO cqMPyhiQtMT3qWspbUC8Gs958vkQE55TyGa4n/uQ9fQ5KZHUR6ROIrbrp43d7kX/EEKIESUuQhUQ F1fs4D0cF+98j1pEiFHIIYEkv6F+YPDDSrsnk8Tp0Q+EsEbKXrViJGne/VPvJ0wWQRXZxYU0tUxE 6kOTqgK+10PFudhbuiWYC1/DsRN3AGyPtrYGMZUpHUL2KakRltlInjvGRtkQGlcyPms9BwGbzZ4z lzYSQ8AQMAQMgcMQARZ125pxAQuSxyyqanGZpP1Ua5YPabYWttP7ZYr46Z98rUhzxQnfFBlkcZ0v 5WB6/yyXpcXht+dWuccVL8giH8WPeMGvvrjZk0wyEbZoIZmpjXKRybuWVruIFsAPL69x3zxhgPuG Xr+ZL3e5ThaZh+GUdL0htyf7O74/W09W0Hw8WSLeNHVgnBfkr9y18QypOuBu+9kTEsM9gRQQu53X Ym3Q3+6tM9uIyXthUaUKu1clCOd7T8eexpCMAaQP5fP7Mxd6N8xeKvKe4kG6G9lMHQeJbV6Ta+Xz yggaFq8/kA/KnsaRfA9sTiXg4XFUXdxYO2t70/eBHEu366vzx7PbDMPIYLeZKjPUEDAEDAFDwBDY HQEI2IJtMfdWVau7eXq+e0exfpt3EO/kPAmsb2l3v13W6FUUlEH+4Ycg5krJWyLieP3zW32GGOIG 6cvHCOrVJCK5VMfTIztLVJCB9KShuW5OWYOrqI/p1eJ+ePogd86YAvfr+VsSuQxtlrocAhnxeuZe XpSuvU0uvWJ3708Ju9wo9sogCA+umbg3vh/x3KsOoabqE1WNxDaoaqmxhHvTD31sV1kJWjLR3Jtr 7ZwujABu9+2RnWleu7CpezLNyGA3nDQz2RAwBAwBQ8AQCBHAO7NRC9Ub59e5/zm20L1wXl+3RkSN JDDEDf5gYZ0rrVPsEQxPCxdc+HARhQwQUpSnpDD6XwuawO2O1iyZ8WjFD86+bHhHNtE/LKlxs9fV u0vGF7jvnTjAVSqxxLCCDLdW5PN7r1R6lz4IaI9lGd34kdNidWN7XO6Smp/WFhGarFxYYTce0Xub HiiGnatc+zpoyNz7uXa+X99GAt8Poe5xHFfZ1ljU+e+UPrdH2iu7h+WdW2lksDvPntluCBgChoAh YAgIAcpIrK5tc5e/VOOOLFICDG1TPa20LuZVwuSkfyyUIX8/XRhk/0QlDJbNSgrDtq69fXGte2hV ve/HVy8TSdygvlALvzK70k3tl+VdTJuUan7pFpUSUFxZL19DzVpXRCDu4nNE9us0QYVRZe/Mye/T Fc00mwyBboFARDGgfI/iUtl9S0ub3S0M34ORRga78+yZ7YaAIWAIGAKGgKdrZPaM+LjBN7e1+kyA 7M0UAyCbaGJHB1aoHGVSDyF5FJ1PZnGcvlEZRktrKcAduJbyoh+IIi54CzY3+YQaxA1CLPNEDNsJ QrTWJRG4YHx05dMluU9JEbyqqW6byylQQfj8op2L2S5ptRllCHQ9BCJysW5tbnA7ara4tIxsF2+N zq3unfla17N07y0yMrj3WNmZhoAhYAgYAoZAl0YAIS8PuS/kZb6cROcmB26jHN/9BIgftdySySDn Qh4hiySY6bjWX29EsEs/GDIuPdbyo7a0tLPSMjIH120ukxul6szlFogQ4upm89fV58/s+/ARiOg7 E5ebde3mUv345X8Na4u0x2++ql9NkMa1mzYjg9104sxsQ8AQMAQMAUPAEDAE9haBcye3rZi1Kv6V 9vTIX+QXnFu9cbUrHDDCq4SRiBLKkGCmXQtca4aAIdCBQCSivLhypeDnkpbGWle3tcy1tUYdrqLt rS3f/NjE6AvdHS4jg919Bs1+Q8AQMAQMAUPAEDAE9gKBCyY2PfbMqsyrXHr27VI5htRsKnXZ3m20 n1cJ0zOzpHZ0VsRhLzq3UwyBnoYACbdiLa412uia6qpcdEetwgOhTpHG9jZPBH/fE4ZsZLAnzKKN wRAwBAwBQ8AQMAQMgb1A4GMTWx+bVZK2KBJzP4ikRa6MtTRn1m0t926jkEFUEGv7gICkI9QicLTW /RFoixF7rdRLem9ra9X3gh9JiJmOPZfeEvuvcydH53f/UQYjsCe2p8ykjcMQMAQMAUPAEDAEDIG9 QEAJZdY5F71mdkn2b+Mu8pn2eOxsLXhHxdtacyEzuIxa2zcEwty8+3a1XdWVEIirdES8raUlLZK+ Pp4WfyMSj907ovnt54uLi3tUXRYjg13pqTNbDAFDwBAwBAwBQ8AQOEQInDs+Ok+kcN5fqvpkD2ho OkJkcLiKTeZa7OC+T4DR6H3HritdKY1XGZNjUeXjqshtLlw2o3hTQ2BfcVcy84DYYmTwgMBonRgC hoAhYAgYAoaAIdA9EVA2xKjr5xbIer2i3XMQZrUhcNAQ2HTQeu4KHRsZ7AqzYDYYAoaAIWAIGAKG gCFgCBgChoAhcIgRMDJ4iAG32xkChoAhYAgYAp0ioMQdEdL8F/ZyrlWvVH+zRCH5jmvD7Y7zKATI 0aR3CsEn1xL0BeTDc8KC8hSX57JEvcCweLy/NvmVOKdjX7hNOQKd15YwJIw3Sz4vtGmPNifbHY5Q NQ2zC1wkJ98eGEPAEDAEDIGDhICRwYMErHVrCBgChoAhYAh8AASy2lua3I4/fds5yE88toc64EkM cbfgpJDoJd81ZV9yYpBk0pbgYjuJ5E5CtivBDEljwP92IZ5JlwQfk++dasduJ3dcstP6dhfJyHJt VeXhrswPgKedaggYAoaAIbAXCBgZ3AuQ7BRDwBAwBAwBQ+AgIoC09oZrbbms+Zk/HsTbdPuul3f7 EdgADAFDwBDoYgj8f3yYzjNdL+XfAAAAAElFTkSuQmCC --_005_DM6PR13MB233024BBB6C83FA92B77F995858D9DM6PR13MB2330namp_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=69626; creation-date="Wed, 10 Feb 2021 20:38:57 GMT"; modification-date="Wed, 10 Feb 2021 20:38:57 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA54AAAD2CAYAAAC+wFhNAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAP+QSURBVHhe 7L0FgJzHeT7+LO/eHjOjTidmZrQly5IZY8dx7GDDTZv236RJ3CZNmqaBpv2F7ZDjmEEmWczMfNKh dMx8i//n/fZWWp0Ft3d7sk6aSdaSdr9v5n2fmW++eeaFMXpZoIpCQCGgEFAIKAQUAgoBhYBC4OZC 4JPPPPPMszeXSkobhcDQRcA4dEVXkisEFAIKAYWAQkAhoBBQCCgEFAIKAYXAUEBAEc+h0EtKRoWA QkAhoBBQCCgEFAIKAYWAQkAhMIQRUMRzCHeeEl0hoBBQCCgEFAIKAYWAQkAhoBBQCAwFBBTxHAq9 pGRUCCgEFAIKAYWAQkAhoBBQCCgEFAJDGAFFPIdw5ynRFQIKAYWAQkAhoBBQCCgEFAIKAYXAUEBA Ec+h0EtKRoWAQkAhoBBQCCgEFAIKAYWAQkAhMIQRUMRzCHeeEl0hoBBQCCgEFAIKAYWAQkAhoBBQ CAwFBG4g4ulES/kJ7N97CCcr3QhPH4FJ0ydgRJIV+qGApJJRIfCRIOCBq6sNLY31qK06j/J6JzxJ IzBtRBKiTerJ+Ui6RDU6pBDwdDXg3KkjOHKiCOdaXLAk5GPMxAkYmxUNi25IqaKEVQhcRwS8cHc2 o+58EU6eOI3i6lZ0WZKQP2ESJg5PR6zlOoqimlIIKASGDAI3CPF0o6tsM9a/twnrDjbC4fZAf+QU ys5VYNm9yzA+OQyGIQOpElQhcB0RcNXg9PZt2LLrDJrainGwtBX1BU/gJ1+KR3SUIp7XsSdUU0MQ AXfjSezd/C5e3F4Fj6MDLqcHbmsJzp4oR/OKxZg+NhXh6jEagj2rRB58BBxoqzuD3Ru24XBJOapb O9HpNeHIvlLU3XEbliwuQJxauA1+N6gWFAJDDIEbg3i6q7H/b9twqi0dy//hn3BHjgmNB1fjhbd2 4eWdBUhbPgpJaut5iA0tJe71QcAAsz0OacMiMSY6G9HHT2BthwFej/f6NK9aUQgMYQQcTdWormmB bcJ9+PiyyRgeY0BX5X6s/+urWLM7HvakBMxINg1hDZXoCoHBQkAPU3gy8qYsw9i7M5CeQANB+xms /dmvsOvgDsSNzsWSNPXsDBb6ql6FwFBF4AYgnh6g7RwOlUTDNnwspuSEaVjGDB+NEfllOHDsPGrn 5ZN4mocqxkpuhcDgIWBMwLDpC/hhE52n4GyuxpYi+gcq3jl4mKuabxoETInjMefOPEyPSEZiuM88 Y00ahtHjIvHGqRZUN3cBinjeNP2tFAklAiaExaRjVExAnfY05OYacaC6hR44Lv6giGcoEVd1KQRu BgRuAOLphqepDmdiwhCbEotIP6rWcMSYopFY1oT2bhc8MKtYz5thxCkdBg8BtxtuZekcPHxVzTcd AkZ7NGL5uVg86Ko6g6NHumnBSURWvO2m01kppBAIPQIeOFurUH5qD17fq4d3+HCMTLGGvhlVo0JA ITDkEbgBiKcXXkcX2hhHYzcaLsZy6vUweOnKIaSTi2llwBnyY00pMNgIqIdksBFW9d/UCLjRWXEI G159A7uc+Vg4bTxGxd0Ar8ibGnOl3NBHwAtPZxG2/fpn+M1re1AYtQAPzc9CUoTKzDX0+1ZpoBAI PQI3wFtVD314FNJaKmBpaEUHdYwSPZ3d6DB0oyUlCWFmg7J2hr7vVY0KAYWAQkAhIAg4GlDKuLQN H+xDTcwozL9rIWbkx9LPRhWFgELg6gjooDPHI3/JI/j0yKVorjmN/ad24q3IcDw4PwN2BZ9CQCGg EAhA4AYgngboGCcw1rgNRdUlKHVMxDh52zdW41xtFToLxiPaZoLaO1PjViFwDQTCbLAyFtpotsIW ppbMarwoBK6NAF0EW87j2JZN2HawDpYJq/Do/LFIN1TjeFkVYmLjkBKh4tSujaO64tZDgJZOhnd4 dEYYDdFIGz+LH6Jw7k2c+fFxlJkq0TaPxFMt3m69oaE0VghcBYEbgHhyVrJmYPqyZFQePI21r6xD a4YO9SePo6gqAgvvzUZimMrJrUaxQuCyCHi70HSujEcP1aG97Sx2HziG0opubFvvRG18DOIzcxir FgGreoTUAFII9ELAjY6yHVjz7B/x511OZMybj/n2LlQe2oB9x9biz60T8bGVd+BuRTzVyFEIfBgB dydaK87g8NkW6Iw6GPU6eFydaCw8jHrGR+dPTEeUIp1q5CgEFAK9ELgBiKdIFIbUBXfjtrAteH/1 G/jd612w5E7F0rtvw+KCeNjUOWpq4CoELo+AuxHlu9filde34ozTDYfLiQhPNVY/twfWiBzMefQJ 3DNbEU81fBQCH0bAidbK86gsqoCTVpuyQ3yOjq3j4tkBl9cL88wZiLffIK9I1X0KgRsOAS/c3Tw3 umgX9u89ivKmbnSbUpA7fgrmrZyDKSNSoNIL3XCdpgRSCHzkCNw4b1VjIobNugdZk5ah2wnoTRZY rUYV2/mRDxElwA2NgCEJo1Z+Et+47XG46ZCuNzApF1NxudweeHUGmCwWmG+cp/yGhlIJd6shYEHC 5Hvx1C9X4UmduA16LmSF1hmMMJnNMBuUq8CtNiqUvn1EwGBHTO4MrMicjNsfcsElGdW1d44VVpOy FvQRRXWZQuCWQ+AGW5Iyi63Vzs8t1w9KYYVA/xDQkWgypjOMH1UUAgqBYBDgRo3RxI0ZFcMZDGrq WoWAHwGdnkSTyR9NKqWAGhQKAYVAHxG4wYhnH6VWlykEFAIKAYWAQkAhoBBQCCgEFAIKAYXAkEFA Ec8h01VKUIWAQkAhoBBQCCgEFAIKAYWAQkAhMDQRUMRzaPabklohoBBQCCgEFAIKAYWAQkAhoBBQ CAwZBBTxHDJdpQRVCCgEFAIKAYWAQkAhoBBQCCgEFAJDEwFFPIdmvympFQIKAYWAQkAhoBBQCCgE FAIKAYXAkEHghiKe7s4m1NXUor6dZ6hFxCIhKQ5R5n6eQOxlanxnN7o6O9De4YDXGo7IiHDYeNBx v4vXha6mOtQ2NKPN4YUhLBrxCfGIDesnjF6eu9jZipbGJjS1dMBpsCEiNgFJceEwDUDMi/q50NlY j8ZOwBoTh1hb/+T0urvR1lCLuqY2dDm9PKbDy4M7dPAaIxCXkID4aAuP8Ohv8cLZ2oC6hkY0dzjh 1YchJjGRddoQVFd5KGNdHWVsRafLw7TulI9n8el4Pp/JFo6oePaT3QxD0Lh60N1Sj9qaRrR1s8/D Y5Ao49Laf43Bg0+6m2pRU9uEdpcBlqh4JCZEwz6QTvc40N5Yi+raFjgMYYiIS0RKrK3/xxHx+XHJ 89PRjvZ2HtRitiOa49I8kCz5XsrYUI+6+hb2EWAM5zOeGNtvLL0eFxwdLWji89PY2s0KwxAZl4DE 2LDgxs4Vhq6HZ9Q1N7SgwxiNONZpDX7wAIJjZzP7uh4tnIc8Xj45fH68XhNsMsclxyJ8QP3eiZZ6 YtrIZ9PlhTGK+sfHItoSTEfx+J3OFjTy+Wlod8AtpyLw2ZFnCAYLLJGxnJMiOT6DqdMPKudMPj81 NU1odeh4tqxvXo/s77yuVetER0MdajiOOlxG2GPikRAfibCgJoxenc75o7WuBtUNbXDxmIiohCQk cF7r54wJr9sJR1cnn51OOFiLNSIakZx/+4OgX1JPVwsa2EeNbV2UUd4ViUiItcMS9JzGGtm/blcX Olr47DS2oJ3zuik8DgkJMXwe+6f1JYjyXdndyvd5sxdhcdQ9zNTPdwTfkW1NqK+X9wPf43zviOwe vRmW8HikJkcNrN+d7XzG61Hf3IFOpx5hnIvlmZTjW/sOqwfO9iY01NSjuYvHimjvHZFTjoVjxvHo OMTHRPRr7eF1tKGpTt69XXCbOK9zfZASFzawceRoRaOss1q64bVEIJbv8LhIy8Dq7GxAbXU9mjr5 joyIRxLfZxFBzUEBo6dn7dbJtVtHpxMuUzhiouz9wq+/qxJ1n0JAITB4CITgDRMa4bydZ3Dg/bfw l5c24kCZE5G507DswXtw36KxSLIF+brmIqL53DHsO3IKxYVncerwMbSPXolHHn4Ac9L6lzrf62xA xcldeOftDdi9/wiKG1wwp0/G3MUrcP+yKchLCHaRz8VeUzEO79iINe9vwf6jJWiypCBr2m1Yed8q LB0VB3t/FroB3eGp3of3f/FT/PJsImZ/+h/xzQVpQbxML1bU3XgM7//4e/jtziq0eCywGTzw8DXl ip2Hhz79cTxxey4i+jMMPG2oO7MXG9ZsxrY9B3CkrIVkfiLu/NzTeOT2EUgIpquaj+Ltf/8F/rj+ CJoSI2GhPLLAd7R3w2Afhtu+/i18enE+4oNJ+87FU0f1fmx48228/c5enKlzwpw9CQvufwD3Lp2A XHs/yKe3Cy3nD2Htq29izbp9KGq1IH70LCxYtQp3zCpAuj3Isa7h3oXaU9vwzgsv4e0tJ9FozUT+ 3Dtw32N3YnZ6OKx9X0H19GIn6k4fwrETp3Cq9Az2rWlARMFifPy792BcRNCVaXV6OmtQtn8T1qzd hh27T+F8mx6Rwydj9vJVWLFgPPJjTUGOTTe66s7g0KY1eH/Tbuw4WgmXOR0j5y/FfY/eiRnZ0f3Q O3AQN6Nk+x/wf/+zEcVpj+Ofv7MCU+KCGTw9dblaUL37j/jiT95GUWUH4iLM8Hjc3BRLpKz348kv 3IPpKeYgdZe6ZcOmHEc2b8CWrTuw9XARalo8SFz6BD75sfuwPC8siCeyCxVb/4jf/+p5vF1l5kLe AIPMPc4udHLjpnvS0/jhV+7B0qzwIOqUS7nRULgL695ejVe2HMHZWiA2eypuf/A+zuujkRzWj+fH 04Gm0zuxZvU7eGvLcZS32pE5bjbfFcuxZHoBEvtRJTztqD6xDq89/ybe3lmCdnMmJizh++LBRZiY ERUk+SQpai7H8RPHcORkEcoOH0CRKx4jH/giPjMrjXNnkBBql7vRUXUM2zduxPqN23GsuBotljQM n3o77r5zERaOT4M12GnD2YI69s0H72/A1q0HUdTogi1nKuasvA/3LhyPvOiBLQ1cDSfw3q9+g99t 9GDhP34djy/IRny/qmzG2fd/iV/86T3srjMgQjY/vCT1pkxkznwM3/jKIoyLtfTv+WksxP6tW7CR mO47XYqKhhiMW/owPv53fCYTggG0EUXv/wU//+5fcTjcBL2VJJvkycuNZWe7CdkrnsLnnr4fs9OC mz88XRU4tXMN3nxpHXYeOY+2sFTkcV6//7EVmM1xGeyySJs1OjlnbFuL1a+swe4TtXDG5WPC0jux Ytl8zpnh/dgc4DqmrQx7Vr+EV1/fiMNVbtjyZmEJ126r5o9GZtAvnw40lhXi8P5jKCo5jiOnz+Fs yr34h6cWc+1m78/Do+5RCCgEbjAE+vUqCLkO3iYUvvkmNp92Iv/xb+PTOUY0HtmGrTtfw0uR0fj4 zCxEBiMpd3Jbq4pw7FwL9FFpSI8/gVOuNlqsaAnrZ3GQLOzauBa7DNNw39efwLBYA9orjmPPB2vx Gs+xWrV8BkZEBvOyoiAuJ9zh2Rhz93is+nwUzJ3FOLT9INY8tx5JX16OaZkR/XgR9CjoKMGODTtJ 4mmpi8pEbbuzn5rzxdLF3VZXNOZ+/BOYP30kks202AiZMIQjltaVYJa4F4TwtqJ8/3t4/oVNOJ8w BfOeXIFPJZMwmmyIpHUyJpj+FlkokCdiIhZ//G7MvHc04mXX2dCOczu24oPVZ5EaQwtqUIs+WgQ6 yrDvpTewz5GH277xEL4W50HDiY14bR8/xih8/s5hsAWFqgcdJQew4+33sd86Aw/862PIjHCg8eQW vPbB+3jfrcf9txcgKihuRwJyfi/WbNiPYxG34Us//TLiuktwaOde/PF3mxHx1HxMzbAHtzDzdKG+ +DRKKpqgT0pBsrUFXQ1N6HJrm/jB1aXh40LLuaPY/hL7etgiPPJvn0NOBBfT5XvwwboNeKfNjQcf mYbUoCx/HJcc0saofMz+2FzcH0cdG87gyM7NeP69JJhXzsWs9P6ebepEw+FdJMgncMZBi0p1O8e/ m5sttGAE1d/CGRxwdLehY8I9ePTp6bhvVCSJJxelHrGCxdBjIFjCrS0f4ao9iR2vvoJnd7swas5d +PLDWYi30QpEi2JcbLB6cww5LUgfezv+7gv3YXqqFSY9N5a4MD+49m2stsVzwR/MLpDISB2bT+KN P2xGoa4AD3/rkxgW1o6KPVtIdF7DW/FxeHhKGiKCes6daC47iHdf2onqjIV4+nufQYqpDZW738O6 De+jyRGJp+anBGkBdKOt+AC2vrkbtXn34hsP5SKG8/CB9VvwxlqOqRWLMCUxGCHZN62VOFtcjpIu OxJS4tDA8dNIy41YkvtVXK0o27cGb53yInf5l/GxUfEwOWpxasMWHCCpb7c/ilXDIoLzRnDT5YBW 9+hxK/DxhY8j3u5CU+F2vLF+K9bR4hu3cgSig5qHLmrm7SjHyV2bsPVkI6JMtAZ6SBQ5dwTJ4H0V 0quhq8mBtIkr8YVFqzA72cDRz41PnQVmeyySI/u3aeOoP4L3X3gZ75aakTftUfz9E2mItnJTVZ7J GPHnCaJwg9Khp5VvwmP4+ufmIj8+DGZuFng6irD+2XWoiQlDuJhQgyodqNi5Hhs2l8G48LP4ty8l wNB0Enu378OfnqfHzeNzMSU9LCg5ve5GnP3gDawr9CLprq/hB1+Nhr75NDZtOIJ3XgZiPnUbRkSR OAcjZ1clSna/gxeP2jH2Y9/Ck/k2tB3/AG9sW4/XXWH45IpcBLVdxY2lxspynCls1bw3MlIbcaiV lvluGUCqKAQUAjcDAsHOhoOgM5dzfFHt3uyEPn0ilt0+Cbky6yd66AryNl47UIrbxqUhMioIUU2R SJl4J54ay4WivhNFq8voKkobWFBvk0tV1YVnYfTMu5CWMBGTsiKgLcNyExHZdho/LDqPwqpOEs9g duR0MMYNx+TZw6E3GHomexLstnacffM4qqvnoovEM5gaL0jsbkbR2jXYXBaG5HkrMI9uVN16up7y gv5BoIclLBYZw8di0ujs/hHNXiPHUboLOzftRWH07fjM40swJdXWT9l8FevCczD78TjoohOQntxD tNzFqD9kRE3qPNyXHYvIoIgnXbzaa1C6x4v0VZMwe+YoJEhDGW6cOrQRhYfOoZbEMzOoJ4KWyaJy lO73YsLX52L2KFrl5P68KLSfeQ6Hyk6ipHk4xge14utG9amTdHEyYMxt3BUeF8UKsxBN8njqmb0o WzIaBSSe8m2fiz4KeQsfQNZ8cRWrwfZCBw6f59993mP96idzTA7GrPgYJo4dhzz2j7b3n58IR+Hv sbPiGEqapiA1IZgOMiI8JR8Tk/Kh546Cb1wnI9pdhmdfq0JxdWu/iaer+iC2biSmYZPw4Codjm+n i7bsbPSz6AwmhCfnoGD8JOQFN2Au36K7AYUHtmH1Hjemf+xx3DsnD4nBGVN61WtG4oSlWJIPROTk IK5nqu0orsDuhmQsokdDboL4EARTXPA0lGBnVyziJ8/B0gnDNd6RH9GB6rbV2FRWhzvHpZB4BrHM FWtnRTG2NaVjxf1zMH+kb1QPT3Oj4mfbcWrjUVTOSkZ2UG68jajiM3m2MB0z7p+N2flRHEsZiHGd w/oPKnC8pB6TE5OCGPN6mFIm4fZ7xmGpzoCu0+/gnc37USYW5P4OIZ0ZsXmz8WBGInKH5SFF2+nL R46uEuc5TjedqsPtOeIGH8Tsbo1Bwsi5WDbKiAtdkKVH+XtvoaLwPOqcJJ79GVPcRC49tAMbj7Yj c8lijDl5GF2sZwCPDzcQbYhLzcWoiSMwLCgWc/nx6nXWo3j7u1hXFoNJy+/GgwtyEBkEdB+qVReF zBlz8dAwI9LGpFwgWu6io3g1Oh9JuaORGx3EONcaaEHliUa42zMxc9FsjImV75Jg72rF5p+XoHrZ RDhJPPveRaTrslmxpYaW7Zn01JqKAm0Rk4Ww1ma8u+kIDpTOQPaYOIQFIWpnfQVKDp1F3MSHMXvh FBRI/+QAFYc+wJl99EhYmI2RwVSoj0XW5KV4dBxddl2VKNz1NvbusHIDvr8PTzBzlrpWIaAQuB4I BMHmBksc7l421+AMdy/D09OQ5H8BRMQhJToZcUckboKxHSSefX43ML7CILEV2sTqhsmg7/u9V1DT HJ+LAn4uKV1tqK9zI9JCK11/4jz1hks2gT0txSg9X4HmjDTGNNDq0B/IxZXz5Eas3t6OuMmLsKyg DH/eWkxnzAFM3HRZdXbV8wWzBe81H4aj1QtbQgZGjy9Adry9HxvZtHDvPIXSQhsWf2UJppJ0DrTo zLHIHKG9nXuKB60njnNBWY6ouUuQzpjRIN6nrEMPg8QMJnlQ2FKH6hYgIZLOg1WVaKQFz5TYn00B Iwm8CaawTlTWNKO9h3h62jrhdNWhsqUB9a004wW14uMYLOcY74xDbop/m8IKe0IiCtJr0drRxvgt 0PIQDMJ6GDmmfZODmQvTgT4/RoTF52Ds0pxLn8PuOtR36+CyRCG8H4FqOj4/fLQvlO5qEogzjYzR ykAiLdz9Kl3F2LVpF4564jF/1XhEHtiHU6yo30+P8A261nZWncSBDU7Ywh1opWN6YsFIjByWgfhg jZOUxVlTjFNnzqJ52gqsmEvSGVTfXg4VIyJScy51l3dUo/jUIew15uLuLM7DQbfBMWONQorhJLob K1HlHI50kxuNVYx1bdAjKcumzctBFRI5k9mMqO4K1DcwlpvbKdLLLocLzupGdHGjqKHTgyx6oPT5 XdHdyHtoiU3JxjLGdPruMyEqma6c1cVw1bSgjQv+YEIJZKPByo8Uj4mbikGq+SFMGLOdWDATiZco 5URjfSdjc01I5rvCIDGFwRSdnhue/FyYLhn2UHgaFWbG9NJKG5wl2l8JZSLp3LqpBC0jbseqXLqg Fh9FRf8djXwV853WeO44dq95H1XsjTZdLHJHDMeIgjREBY0tY08baNFeV4uMSXdhybwBkk5NQCvH SwY/FzvA212F4xt2oy1uAsaNTA9q/PhqscBOF2IPvbbOVfKNExsDY6fENdfBlZqEMMlXEEx/S1YG PeuM9qKN8dz1jL1FvIwZB5zdTWjpZsxnbQdc7rgg3Dqc6GRuioZiO3KmxiHa7/pkSUVmhh5VtXwe W2ipDIZ4ynvXRMuzPD5Os+Z5oYpCQCFwcyHw0RNPiYVob0aFTYekcLrP+PE1mmDxmBHeIItyca5h nov+YM/6PXS77PfC8UptOqtx9IO38EGhHZNvH4VxKcFaBAIq5g5s4bZ38fyzr2NvQwRyH/oKhmVE B7GbeWH1gI7Kw3h3QxG8U+Zh6R3jkVlTSQJlIpGwBkm8/HXSMmu2ISzGjraKszjZYUVHE/vEewD7 D47GrIVzMW9ScnAup11VOFvjQklnFLLOvI7fvF2Mmi4rYgumY/68iRiROLDkCb7FSgPOnKhEcVki Fj+cwoQZQS7MiJY5KhsT70zD9j88h//YuhpZ3BWpP1OGhvT5uP+BfPAVHWQxI75gBMYsOoOX1zyH n67Vw2qjG1a4G7XHKtA4bIKWzyW40oV2bn44G82wXkj+wkU/rYBh0Z1oYpITJ73q+reLIZKE7vm5 RLXOUux4cTV21kZixLIZGBasm3oASJ6OKm5kvIbf/mU9jlTHYcEX78PYjH6YRryMJ1u3GftLwzHs tpWYnduNwiNGxjtaYKUbXr+WQLRWWcJikNldhvqzXTiid3Dhx8XeIcbQjp6OxbfNRH5MMKzOgeaa GjQXdiJvfAV2Pv9/eLGiAe22bIyfM48W70z0JxS195jrrj+HooMliJ4wFdnJ/XH5ZyKdxLG4Z8J2 PPfOL/H3R95CbhQJ3pkGOBLn4VOPpiAm2ClTF4a4rDG4fVQRNrz7azyzngtUzk0x9lacLKyCO2FY 8BZ5JgBqYxKpSiFvAcmJ9OzzqGYH9G10lQ7ugbzkag9NfZKnacClF+lsOkkX9c2laI+fjLsnJKL/ +YCcaC/fjzf/9CLe2XQS7ePuw6em5SEp6MHOeHp6CmzbfQZVEdPw2F0TkFSxG+e4OWSyWmHtu2nu UqgYY2wj6cKpEpTTetri6WQiMQeOHjmMPfnzsOqOMcjgrlqfp00vE9bUlOJgYxySuNG788+H8GJJ A7wJwzFh9hzMGJOOqH4tNALFdpLcFmHzTjNS5mdidEZ/NsGikTdnJA4V/RWvfvvvsTUvCaaGcpQ3 WJH26GLkpUcFvR7SmxMxevkYumifwOv/9W9YzznNEmmFh/HDxYyfTe/JJ9b3sUqvoA7JWWChW3aA 5ZwvG0sEV2zN3ehmEsZ+F7fv3aOKQkAhcHMh8NETT660ddxljepwwcJEMBKJ6DNUcjFtYPbPKLqT cEHQ5xfLoPePz3qx54P12F3WheT5d2DhFMYFDeRlxTgWl2T5jMvjItSK+PqDOF6aguhhiVp2vT4X Nwnsppfx5zdPQp9RieYT78HLl8rmoga0RdbhV9V3YNnKCcgMD8IiIP0RmY0Jdz+FdF0MUjJpTQrr RkPRbrz+u3excwsTPmTdhVlxQQBAC0NjezVONHQj9VQ3XHUNtGp7mK2xGdVNTtx9xzSMTw0ufqU3 Rq7q0zhRVYPK7DkYmxSmJRsKtnhcnWit9yDCbEU445Tau5ghNy4dSR4dnKWVqB8eiWDUlvaNsSOY uIRuxYa12LC9EDXdBkRmpjOrbR6imM03xh4MCZEaTTCHM57Vxgy0WiCVrBjdzKrpoauwDRYjFwTB jKFgQQr6ehfazh3ClvU7sed0OEYuWoClM9MG5L4t2W1dXOBYU5hUKTEajoMnUJzJbLkj44PYEOF8 c34XXvnbm3i/CChorcDZtxpw7shZHDluRcMvW7DsnjswPz8uuAQxRjs3VJbgM/YumDl2crmhZO2s xLH3X8WL+zbh5ZgMfHFJDsL7vNDnopYbddWFlThnK4Q33MmsvsxKyv9t+lsznG1LsWDucMQH8Th+ qAu5aVNddBr7zsRzkyQVSRF9Fi6gKi4YSejqnTa4rcw4S/rW1WWAPSkeVvqsl5AsT0oJp3E/mJmd Lv8kCDMeuguGjeuxfl8xarstSE1j1tCRVrijEpm5O0hZaUG1MkNqJOPIXAFBmB6OqQ4mgoqlh0J/ OVPQj0ZfbnDVo2jnFmzaegT1aRMwd8l8jA4uhuDSVmRTli8fp55W+GHjYLY1su9PoSRxIrKDqdfD d8/a1Xjj1c04m1yOjv/YAmdtCc4eOI6WUi/Kz9+PRxaNR0FckDOxLhwpU+7AnTndMCdmIyc5HPrW s9j5zjt4d/0r2JSXgJWT0tHnXEgyV7TUoritAg0ljD2NYYw9s7W72vZjTVM330GLcdfs9CDmjct0 moMYntiD/ZF5WJybhyBzCvVU6GDGYWbqdnAM2unx1c2s91Zm12aG4Ai6wDc2ZCE1rCfkpy/jRq7R 2ZAw8Q6sMsUxod82HCpphjuSWdoTcukd60EaN3yDc0KgZwy9C6zRJJiMGeYrp8da6qYlnmsMJiI0 B/V891URdZ1CQCEwlBG4AZaknKBikjGi7QhaKqtQj9G+RSiPSaile2dNLl1hmCUuyOXExT7R0drH 2dTAOEojLX8DK92oO7oZ76/egxJLDmbeswjTcyPgcXcyFbu4h/RTSksSRi55DP+yhNJV7MQrf/0L Xtqdj0weO1AQBKP1kl7F5i/A449k0W3TrblSuTvD6ZZDchcRiagIC11XgkfAYIlG2sgJSLtwqw2x zDq8aMoWvFjOeDpaL4MinrS+2vm/tLB0TH/gCSzMtLN/6Rp7cjV+9Z97cCQlBdmpBYgOXtSeOzpR dYykrqIbBavyGf8WzOLW3ygTGlQcwZrXWpF4z5fw2XvH9Vg4q7DjV39k4qtN2Dc+H0tTgnVD1WlE fspdT/MjbXnRSavvz0/QbSwpF1nBZRbi/eGIzzTC3dKI0rpuzNH8LulO1sSsrKUJyLHRJXhAw57E lc+OQdzCmfynH8MnoBfbUbX/A7y+phC19gIsfXoexqdYoeORLV20/PbruBLWbghPx+hln8e/LWN+ 3/Kt+PN3/oo9++OQmDMHeX12ZeUYsaRj6v33wFpUz40BuiHq6EYfzjT+tNhERobDHowLp19rPd0u aYmboAUI95SwFIyeOxEZtduxs5zWSnc2iWdfx6gRZloqwpmIK3H8bXjsnqm+ha27AjuYwXrd0b2I zGcyrLT+M09PfQmKmdW4JHch7kxP6F+cuRxvdHYz/nLGiNQV38D37871bSg6mMzkL6vx+kv7MT43 iTG6wXpiGEjgR2D2ffKRCt1o2v4sflPBnbtxI5j4rK849vSFLYZkNRLZVeW0pPE4J/o+61hnJ92D S7n5ldEvl/qLXW3SMgSL2z43rQb0HHKmaC7EttffxbYiF+Kn34mHZg1nxncvjxlxIYKhHv16NmmR D8+ZjY//02wK3Ywzb/4SPz20D96kYXhyfDAzsBnRI+Zh+V0JOO+kFxPHc3d3BCJs3BCIiEKU3Qpz v7K0c1MgLR9jLr58GIich8lTR9OD4DA3L+kKTZN0n4mnnh4M7O9ED0MzJqzA449NZmS4TJmn8daP VuPIu8w7MDEdY7kICXIk9XS6F10cOyc2lyBxzCoMG57Qj1AUeU7O4eD7x1HaOQNP/PRBTI+R3mVy u2Mf4IUfv419x9J4rNdoJmQL8iWpi0DK2CV4VD5ya3ch3n/+XWzpysCY9IggsyPzSKiocMQNb8OB 5ma0dDE1hyzevPWoOq9jMjoe4RZUVsheuphk05Su6iFZuwWJk7pcIaAQGDQEbgDiyYU7E/dMmwKs qTyB7XTfvCPfiIYDR3HmTAdGzM1Egi9YM4hC11ymvHTQx9Dt5jmZbTzLs70drS3N6OiwcSHARYCZ L+og3iye1hIc27wOb64tgSdrLObeydjEFL6qj6zGc3TnnD1lGuZnBZPfledDNlajhhk9GXjBWC8u FHUdqD/PuIhmMxJybXSdDEJAoqMzRCKDu8MZxNJf3KdeQ8t6uodm342Hl2cFgWHPpVxAdjZXo7TK BXtcHGIkXTzPY2yrPoadhz3QxdPKlBJk/9jSMHZCDmrpIllbzXNR4/SIYlKK6rpmdJKUmhng0f9l M+VuL8bRU7R2Mq7svmFxCHYt6tOcxINxwuHhzKrY1shzEjtgpzu4q43norbzZxOpc5Cb90IyPWJd cDg113FPF4/oKTyAdW/uRUsaXZan50NbXwRVmEBqZC7sZw7g5DYei5AyHvGdhXRFYzr60eMxJ51n JgZVn1xMOZ10MZRMrt4WtPLZae/Uo7W5Da1yLqq4wTN2re+jk9ZXZpw9sPF9vLazHtasqVjGLNAT M7woXfsajrZGIm/RMowPynxMC3RTAxoanTyjlmegWiiPuwUV56tRzeRICREkjEENIiaFSRiFhav4 uYDXORz62wcwOOxYdd8yTEkO1mWOmZEdLagprUKrKQoxsTwL00gLk6MJ5XuPoaHBgzHTExAe1IKc MY5ciI+YfRZbOpp5vmwzYuJNcPKc3YY2bmrESWx733vmw0OjGzWFRTixtxUj7xmGdNbXr0JPFj3P fo0AY9Ka+Yy3pCCWBNlV34Cmbhf0dN23MKtNcJL6nh+Z10ltmHilFhWndmD1mnI4smdjlRxXErSw cUjOTUNu2kbsO3gKmVHDEdt+Fnt5rEpcxjQMy44LntAxptfh5PmD9NppaWFMYjvfP60taG6K4dmG fH4s3AwN5uXj7UTtia14/40dONoYgRFLlmDRrJFIrNvF45OYATRyLj4/O41jq+9ounkmaDPPh2wx xiA6nJ4RBsbxt5zD+apubgDZ6XkR5NJAH4m0yYtxLz/+0nZmM9a6dahc/BCtiMOQ2g/TsberDufO M6O2IQLx8RGw6DkGGKpx/EARjldkI3eZnBcZRKfTXTs8YwwWT6OujNavrmpGNFlrN7Ggsw304fSO CWre6NW2lzH3paewpSQBIxfw3dhf1wNa4a3sAwNjWhtr69BKrwETQwHqG1vR4Y1gBl6JfwxCb21a pyWS7x6nmCblTOXas4w734JtxQbk3DYVw2PMQY51Hc9oTUbW+HS8t+cojiaL50EY2pgL4rBLD9vY kUjjOzO44lu7ORm3LefWtrS2o7Od7x1t7Sa5O6i3kNFgqw1OCHW1QkAhMIgIBPl2GSRJmMlsxL13 oHHdRrz/y2/irZpu6JjxdTqz4t1PN5rgEqNQRh6dUr7rdfzyr+twmkdCdNaXodphw5b338OfbcyE ufgefOyJGbQG9XX26kLNobV448c/xp9LbYgfcQLHdr2GXzqEzNaicuJTGDV+apDguChXEY5s2oyN fImeq2qgK004whMLMHHcMjw6Mx9pffe/+3DbTsbQ/ZGW05dWY0MjyaPlCP7h4EN48nMLMCI6CAsy X1DddYXYs4aLnlNnca6hnanxrYhOo9tTwSwsWkC32GAz9umiMWz2THjDtmHtB7/EvzFLXwNTr8fm jMaYlbdh5pSMfiRj8EPA5Al88ZfxCBjzNGYRpa79K2bYUsbijieq8cGmd/FfX/kNmtqYHCYuBan5 s5npcw4mxQa7cG5H5Z738PJvXsGOZm44hKcgM59uTmNux8NzJmBkv+KEdbBmTOdC1I1177yJH3/l /6HRGYHUsdOx9Mk5GMVzPINdnzDbF86u/TOeX70dh2va0HyWxKnbiHWf/QBhKSMw6rbH8KU7RyLJ 3MeaPa3McrgWv/zZb7G+0spxcxSntv2JC4xOurt1Im3+Q3hqTrCxPFw40Z1617sbsOcMLXQ8skJv imAM4HBm5L2HJJ7Wr/52Pd1CG45yk+nFv+Av6wpRVWXFsW+dxqpPfZLzUWpQiVc8ziZUHtuKzfuO 4HAZF/od3VzcJiE5YyRmzmEW4mmpCO7oVh3MCTx7b2EnmjeQdP3kRZyuaoGDVt+8/FlYNnc2JgV1 BmGvp4Ox6yW0wp7sHo978hPA/Cb9K7SkheXMwyfnbcTGLS/gu1/+KeqadQiPTEHO9BlY+shkDGMS rb7OwJoQbs7ruzmv/4XzemULzPFZyM7OQ97kO3D71LF0Oe3jeLxEIyOi8yZg9soGvLX6b/jhX8+h WcdjHCbMwKqlkzAx6HTBJHBV+/Aij+p4c9tZODvqUdvIDTX7MRz6XTySsxfjwc+uxNyCmD668HIh znjoPX/+DZ77235UJ+fjRNkerHmW5La+FGXRozD6oakk4kEhCU93M71C+L7dcRxHCyvQwoW+ITaT eDIb79LZmB70ma0BoHacx8H1L+IXz72Pk6dK0b27DDvueBpffGgBN2uD2xoQ4ll2lM/PjoMoqWQy snbOd5HxSGGfTVh+H+YXMLN8UESRCd7iCjD/3nps2bEfL/3bX1FW0wldbDpyJi/AooXTkDeABPie 9npUlJ5Fw6jRyMtJBqNT+1eMqRi3fCacG9fh/f/9Jp4l+dZZwhGTORpjl92PWWMZyx2U3oyXbD2F db/8I95iYr9KI7NNp2Ugu2AUZi6fgpmTGe4Q3BDS9NLZuWkzdRnurH4P2/7wbbxSx/PNY5lI7vY7 sHhBbpBHg0mNTSjb+jZeeO5dHCbZbOSmVVGjBf998G/4Y1Q6Jt3zmHZu+kByAvSvQ9RdCgGFQKgQ uDGIJ5fGpphxmLGUL+aMcSiu5eSVmIWCUblIZTxi0IXZ22JypuDOe5NonXLAwBg9o44Tr5yp54lC YkY2YoOyChjpvrYQ9307E7NcjO/TLKlyQDRj68xhiMocjpHpwb1Q5VAzOxfxE+dzJze/BnX0U/Ew i2pEUjaG52ciJXyAXWOIQfb0JbgndSKW09XL67GSNGXTNct/dEsfUdXbEJ46HgvuSMCISTXMukq3 XS/dsxLSkEPSlM6Y1H70EAyRORgxi5nwkkfiTGkNWt02RGcMQ0F+Khe7/VlA+vXhwjxtOpbdP56Z kNOD7OdLMdEZopA6g/FFyQUYdpb743RpM0cmISM/H7mpUf2IG2Usc/Z4zHs4DMMYk6i3MsFFRgZy clMRE9R47NV3tHRnT5iLe0iKR56ppFUyhlacfIzMie3j4rZXfezz+JFzcLslD5M6vEwOQgs0Mxu7 OxmDzWMY4pjlNCIoK53Udxs++8woPO5gHXx2fM8PFy7GaCSRPOT7z/Do47CUTJLRaaMwfVkE0quZ kVH87eRc2fRs5GvZYgcyhpiFl8/mlOVPInGWi67GtN6ZYpDKQ9uDHZpGayLypi9GeNZIjK8Vt0Ba +4hhYmYehmcnI6ofViBWgNjsyVixKgkjRo5DeRPnjrAk5IwoQE5iz1E1fcaxd9/HIX/Ocnxqgg3Z aTwbsr/1CBEyx6Ng4W10y8/D6KIqnmUppIEWkuHDmIE5PHgXROodk815/b4kNHBeN0Uk8H2RzSNq EnnOaD9WzX7dTOJ2eTseiMjFuKIatBvikM6sqflM4BJ8smVaZSIzMXn+SsTkkywYmRVajvuh50i3 U85uzcRw+iMGM7vrzMkY/+BX8cziVrQxDtVNq6/veBIdSVQaMoaRNARTIe802uNJrhdiWfwIjKtt plukF8aIFGSwr/LS+qN3wEChdT915AI8+pnRcHglPwPnkMR8ZEQGvxOkt6dj1PRFfNZHoKaBmcC7 uVbg0V7JubnIy6a3QH+6XcZRwTwsjs1Gdn4xKuk1YYhORW5BHrIS7P16n114+1gSuKn6AL46Nw5p zPje/8J46PTxmL4yHgnDi1HC7MpeI2Oi03IwvCAT8UG78XAOszCkadGdMI+cjTZatSMTUpCVm4W0 uLD+557jSLbS9X3h3XZkjpqEsjonLIm5yM/PQEq/3Gy5AZ03GYsficVYHgOnp4XTYqDHDPMXuL3M 7sy1UXywk3D/O0HdqRBQCAwCAkG+rgZBgoAqzVGpGD6dn4E2I8kiUkdiNj+hKVyIJuVhpHxCUyFr 4QvUziNj6AqaMixklV6siK5PKWOm8TPAuiVbnSxS8uUzwLp6387zVpMLGGNTENp6ZRxlBnVw5dXa 5xly2WMwm5+BF57nKGdPymfglV1aAxcSsSS1s/gZeOHGTfYEzOAnJIXPY3jyMEznJ3SFsX7hccgY IZ/Q1eqridmG43ju6Ex+BlQ1F908gzCKR3XIZ8Dz2iWySKxjFkbKZ0Ay9rqZ4ygulZ9Q1clNkYTc ifyEoELG64d2Xg+Qia6cicMn8TNwOfXhyRg5WT4Dr0vIpWzOpE2YGRBjP/B6dUYbNzlz+U7jZ+DV XVqDKRyJeROxKC8EFbOuGCYUiknOZfaHUBZu/HJQjpNPCKvVMQQjJnVY/y2dl8jCZFpRGRg5jZ8B yygx7Dwjc8ocntwZ6sLM91GZKJjKz4CrtiCS3iBT+VFFIaAQuDkRuKGI580JsdJKIaAQUAgoBBQC CgGFgEJAIaAQUAjc2ggo4nlr97/SXiGgEFAIKAQUAgoBhYBCQCGgEFAIDDoCingOOsSqAYWAQkAh oBBQCCgEFAIKAYWAQkAhcGsjoIjnrd3/SnuFgEJAIaAQUAgoBBQCCgGFgEJAITDoCCjiOegQqwYU AgoBhYBCQCGgEFAIKAQUAgoBhcCtjYAinrd2/yvtFQIKAYWAQkAhoBBQCCgEFAIKAYXAoCOgiOeg Q6waUAgoBBQCCgGFgEJAIaAQUAgoBBQCtzYCinje2v2vtFcIKAQUAgoBhYBCQCFwSyNw1Dsrrs2N /9QZ9Nlej9sJL3Q6Hdzw6s974e3iSaht0OsrPUA9PJ5aHvfcALgaXV3G2rlh21tuafCU8gqBIBC4 PsTT64Hb44EHBpgMfHz7UbocbjjdHjlOu+duTgVeL//Obzg7hKZQRs4qOr20Epo6vdRdk1KnD1WN mt6hrZMySoUiIbEMheZe9jZVJ5Y3st6g3hRSUz1UcvrrDB2WrNE31rW+CUXvDKbeocQyhM84YbOZ DVwr8BnnPAKDiWsIbcQPvHjdcLkpq57zG+eOUBSvxwWXR0cZDTBQzgEXjh+P1Mk52EjFQyJmCOb1 D+nl4Tzv4YqPehtDIyS8bhecXj2MBvZ/KLqnR283R5OJnROKKuUZ97g4NvmY600yTkNRPHA5OdbZ 34YQyckFOVwuLwxGyhgaMLXnUXskpc6QgMn6iKWXfW4whah/2OeCpY4yGkIiJOcLLjZc7lDqzVHE /tHmN6MJ/Vxq9Rp4Mi5ZJ989MheFRHWOdbfTRcVlDIWmfy7obTBq47I/w6iTrwiu/W4z2yLT3Y6u izholflq9P2V/+V86nJ0dnm9hlqzVV+xyzWrlA/aMb3es6nLhj1zu7d3hOIJVnUoBG5GBK4L8fTW HMR7Bwpx2DILX5qbDrsxuGnhZHkz/uPFI2hqc3CuCrhXI0sX5oTQ9E+o6/TXF0o5Qy2jyBbqOgdT 78HAMqR1+jZE+vX2u9wo1rAcjDpD/PyEegxpaodAb1Yh2wsPLsjE3alV2LH+ELwLHsXMvGjYQ7DC d5dvxfMHG9GcMAt/NzNx4KTB60DD0Xfwx6IITJgwAwuz7QOf29rPo+jAB3ixdRLunT4aI+IGPvX7 5vUzOGqZiS/MzeC8HgIxz67HCye6EZ03B/eNjh54hd1NqD68Gn+ozMPcSZMwK9068Dqbz2LPgb1Y 0z0Jn5k3DElhhoHX6TqPfW8ewpmGBMz5+FRkmIN7R35YABpqWo7jnWeLgJwRmLeqAANHswP1pw/i nRcbUPDwLIwfHosBo+mtQ+Gm/dh92IrpT8zAsBjLwJ+friJs/Mtx1BrSseiJSUgcKJRwoqPiCN76 YxkSFk3FtOlpCB9wj7eg8vABrFvjxJiHZ2BsZgQG/vg4Ub1vLQ4drYJtyYOYnm6HZYC6e91NOPve ahxDBrJnL8CEmAErDmdrGQ6t/gCVGTMxdcpoJA94ELnRdHonDmw+CPf8hzBjWDwi+vNIyn6+19sp pNPtDCCel1NZNoH1BivJeIZ8dAbjdI/LQZLudFg6cXoXZv3WYWv83dzuE20DR0zVoBC4uRAY+FzX Bzx09FCoqD6Hw3Y3LEGSTqm+uKoVjW3d+OcHx4bQutkHwdUlCgGFwE2BwCtby3D8XAsejG9G7ZlC YJYe5hCQTgHH4GrA2cpK1JEshKRKnRm6zkocq3Ig3WUODf5mL7oai3GofgTuoFUgFEWn65nXw10w h6ZKmJ21OFPZgaTUkCAJWAzwcqF7uDIeYzyWUKhNa5ITjXVlONg1Rqs/JMXoRlt5FUorrZg1YNKp jUpa5zpRdbwSXmsuTCER0gx9RxNKDlQh+R7DwEmnyMQFvLOuFqUnwjHBGALSKXVanagvrESZiSxp gMTLB5sJFncbzh2pgn6yF6F5Io3QtdWj9Gg3ctzGEJBOn5xorUZ1SQmiOW8MlHRq3UOrpKO6BBVe OxJDNNRNJhday8+gKnwC+yoUA5PeEY5G1J09Dfd0zuv9lJNUU2/qq7FUvM7o6aJZWv0qCBnV6c16 g2mM3mD4KTqwdItu1qfm6rdXhkJLVYdC4GZBIETLhd5w0D2jvQZnz5aivLYN3pp9OHbkDKptG/Fe ZAbC7RGIzMjHyLQY2LRJoguNRYUoOVeLRrc8+eKGYkJYVCqGj8mGlw90VJgZM0cm3iy4Kz0UAgqB 64jA4ZJW7D5RiHc37cah0jLotq6BvSIBkdZoZAwfhvREO7T1vqMJ54tLUHK+AQ7NhZ9zmc6G8IRs FAxPRjRXJmI/dTVX4OSZMtQ0dcJVdhBFxxvQUr8Oa82JMIXFIC4rHwVJ4XS9pdtfWw0KT5SguqUd HvHvpdueh4vihPQc5GdzDtSqdKClphQniyrR1tGG2mMnUHE2AofMNiSUR8AQnYzMnFxkRXPZ63Wi vaYcp8+cQ1M3XdY0OTlrWpORMywTmQlhpB2iSwuqz5fgdFkD5S3Dqf1FqGndiW0RLWiKt8GanIe8 zBQkhFEmLqzryktxprgGnZqRWbb/uXiNzsDwgjTEh3GhLFj45/U6mdf34/jRQlRZN+G9iCJEcF6P 4rw+IpU6yZvFy3m9+HLzegqyC7KQGEF3Z4ZQddaX49TZ89xc7EJ74REUH+9Ck+MDbGiJhSE8Dsk5 w5AXT52opocWzKpC1lnXii6vb5Xo9dgQm5aF7LwU9g+/cHegqaoUJ4qoS1stKg/x3VPpxT6bF2EZ YTDHZyErOwPpESKkBw4u1stPnMX5dgddkcWNTke3zygk5+UiMyUKNumyrgaUc0FfVNEMb9Np7D1U iFrHVqx/twopUXaEpeZhREYiIn2DCK3nilFaWsFrpCNkkWqE2ZaArIIcpMRYIfuvXmcLqs6cRWlV Ezq6y7D35DGcaazDxve8yLCFwR6XjeH5yYix6OkuzP4pOoPiika0SQiDSO4xIzIhAznD0xFnFZdF jrWOOpQcO4vK1lZ2/wluthTBa/FizYY6RFKn+LQcDM+RMUd3R+p0/sRplDd3oluw1Po9HAlZOcjO jEe4tjrgWKsqR3FhGepdbag+dhBn6+ph3BoNd30CrJZE5ORnI4PjySB9WVuOMr73Kzt9ISZewdIU y2csl89YuO8Z87SjvrgYxeW1aHXV4NShIzhbYcPWDyyojg2HLSoTw/LTkEgBRKfupgqcLS5DVWOX b+OZi349n7HYnmfMrCe+JB7n2Ifl9S3o7j6LwyUnUG1ow/r1TiQYwhGZmI0RwxNoCdOAR2tVEU6X 1qCpw0n3UV+fG2NS+Ixl8xmTDQo3uhsrUXqyGFWdHWg5dwSnq8vRuNcOq1ms+7FIy8lBTlqERkS9 Dm5osc9Pn2uCg67IWpVEJCwlF3lZfMZkoePtRktFKYrOVqDJ1YjzB4hlpRO2TWHoKImB1Z5KLDOR SquvPL+utmqUccyV1vZ4bVJvncXOtdNwPmPRCNM28V1oryaWpZWo7ehE5Z6jOFpUDfum92A6G4mI sARkjshFaizHHHXq4obJmZIKzkUOn9usuHaHxyMlJw/DOG/Ido+X/dxQfhZnzjeitbMOZzmeThCz rg9i0BVjRkR8OrKHZfjmDZc8a8U4UVrHMezR6hQnFUt8JrJysnqeMXkk61FRfJbPbTs6mopw6HQp Krp2EMdWpFrtiMvIRnZWIjglwNPViIqyIhRVtjDcQKYiVmi0wp6Wh+HpCYjm8yDPbRfnjbKSclS0 dqH++H7O6+XwbFuLsOokRHNeTx/O+S2577Zp0v8IndcVq6eb8kUXsJ6wFF8skhaao4W99Pxb+9Jf esioW3N3JgEOi1qh62z+d/781CXXqX8oBG5xBAaNeLobz2L7mjfw3m4u8hw1OFPVgBpjBf5wyg57 fDby7ngcaQnRsMmqy9uKyr1r8fb7u3C0izEU8gJ1RiC1YAE+kZnOhZ+8+SVGiS+c0AQZ3OLdrtRX CNxaCOiMRm2R8tzx91B5vgloeR6nIyIRGTEatz8Vi9iEHuLZWYWTW9/FKx8cRpMWF8eYQ2Mysqbc jaczExBl4mKYi7DumuNY9+bb2HGiCrqOChyt6UJ3WDl+d8gGS/poTFj5OLIShHgyJq6+EJtffwXb T1fCQdOgzuOEK3w0pi17AMmZPZtvJEt1hTvw6otbUFbbTDLGRWyTGc1Fp1EWZYV1xHysuJ/kk8RT R0LXULQXb/9lDU40tNO4JZTQCG/8XNz3+J1I8RPPzhoU712DP71zFO2tdWggsS1yVOPNol3YFWFH /LyH8MidCVxAcunsbEDZ/g144ZUdqNXiiRnDpItC3Kg78GRyAuJ6iKe7Seb1N/HenlLourm5WNWo zet/PBUOe0IWhi17DKnxnNc1ZtWKCpnX13Be7+C8rrs4r9/7VDLihXgKCSg/gHdeWYtjJMiOphIc q3PDdqIULduJZdZEzL+PhC3ORzydxPr0+tfxyt4i1LoYw8fvXM4kjF96F+5N7SGeJAFVxzfihZf2 oraxAR31RTjbVgRn0WEURloRMWUl7r4rqWdRLGSpELtf/wvWlrbQSME+Z2yt2VaAeY88hJgEEk/h +m3ncWjLary4/iT3CEhyqklK3OfwQlEUomMSkbLwETwdF0/iKZRBFsLbsfb1tdjdLCRRYg5tiEmZ jpVPJSA+uod4dnFDYtNqvLHlBCrdrSTUNWjosqP62f0IsyUhc9Ld+ERaPImnmVypAaXb38Wrm46g hGlODNI/jhgMm74M96akIlYjnhxrXNTvef0FbDpbiSZnI86ebuIGwWmca9gMg20UJi+5B8lZMuZ4 v1iC33kB75xkux7G/Uq36zMxddX9uDfJTzw70XB2H9b9YTUOkoA11tWgqLQTZW+U4ODOKJiiZ+K+ J2KQrBFPB5pLDmLri69jY7WD0hA3twnWiLFY9okHEBtP4qkxqiaU7VmPN9/ZjWInN1nKqlFRY0IV 3WOj7NGIHX4nHn8iDgnh4ZpOnZVHsentt7HpaL0WauNlzKEplc/Y3U8gI4510prv5bg48t5reJ+u 33UcdyVHSYR0kaj97R6YLNkYNuMefCY7DhFCAN2ddBneirfe2IETFR2M/RUeQ5I4ZiFW3pvYQzyd aDt/DFtf4HNb28Qwn3oUFbXA5i7GqVNRMIaNx5L770Wyn3h28FnbR/f4d0+gpdOtjUuvzorkBQ/i 0Wg+YxrxbEfNsR1472/rcJybS001NSgp8qDs5TPYHcN1UdoS3P94LJI04umFo4Eu3etew1u7KzSr mk5yXMRkIn/FE0iKi+ohnt1oKNyJtW9txJ7KdlrNucFFcmfmhthRWxRikyZh1acTEadtdtDSWLYX H7yxHjsLm6k3hWQnmXMmY8G98cjm5o5sDLi7G3Bu33t4ed0xlDa0orXkLOp0JJ9lZ7DHGIPcqbfj 7sRUbkZxzPFZqzy6Hn97cx8qGhxaDg8PjQcxU1bgnnuTe54x6tJShqMbXsVr+8rR1NqEujMlaDtN TI/uRBSJ/ITl9+BezjMR3Nhzt1bg+NY38cKms+h0cs0neRhscUhf+hiejInrIZ7U5dwhbH3rbWwo bkUbPepqymu4KcR5PTIaUREjsfTJh5FD4tlX3wkuhh1sqcjt7G73uhwXAlwIfThh4SiTPQp9mMFk 5cYUn0kSTF9sqcv3d42M9hBUxu+66Xrr9XgX78GspKn67dW31htXaasQuDICg0Q8mXQhdRoe+cJE PECy6Cldh99tOIytYcvx87uH80XKZrmrZPa73eriUHD35/D1Oz8N5ujoKRLMbiQxNXP3SxITqaIQ UAgoBPqHQGd7J8ZPHIuvPfQVvP3SFuju/3vcMZZExUjyYjaRIPbUG5mP+Y99FTMf5kLiwlTERTmT EZm5atY89+gKG5a7EJ/957n4lJuWkROv4YdbalCfsQI/Xp7Bupg0w2TucT/lfYxleuKbU/AYFyMX 66R7mInt+t3CaI3Knvkwvj3lAS6s23Fuxx/x/aPRmD93OR4ZE83NNyYu4vVa+/pwpE29G18ffyfn y4Bgas6XZupyYVKPzMGUu76I8XdyYd54Cvs3PI+fNi3EF5ZNx4xUK5Mh8XrWqRVLOsat/BS+f/uT F2WUVFbU20Ky7IOH83oK5/Uvcl7nRO0uXY/fbziE7fbl+OkqzuvWXvO6Ph4j7v78Zed1k6VHTp0F 8WNX4GsFy5hYx43mA3/Fj3Z3IGHcSnx5ZrKWZMggOPX0jzm6AHM+801MfyrwnSBJZHiN35/UmoT8 BZ/ED+ZQl/YKFG99Fs+UjMU9Cxfg7uHhtDobNSx9xYjI7Fm471tTcBffVRfClIm39I9m/BDN40Zh 2cfzsfhjvIKW3tUb1uIv3Qvxg7vHIyeKi1DB6UJnRiBz4cfw2TkP4lMB7zPRxWQ2X9BFH56DWU/+ A6Z+nBd1ncSaX23FgZp03PUvSzCcAbN6vYw5X2/q2T8THvkqRj/AhW7gO1Ibl/7+4d+Tp+Deb42n LiR+dbvx2+8chXcsv/vsZCSw/wxUyCcmLTLx43D73/8Ai0hoLo4iJmESGS8MogikTb8Ln514J9/B zTi3axOe+2k1Jn59BeZPTYOdlkLThTFnReLEFXh8zG14+IKQ4n5ILAOfMXMKxt37GYxc9TSJaTn2 vrQR72+14/ZvLceE5DASJPbPBZ2MiBq+GJ/8+jx8/OLioGdc+J8xPp9RJBpf/lcsJAFA+yG88P1d dLUdjof+dQEytCQ2Ro7jnofNyP6Z/Ri+Me0RbTP7wmNOLC+OCwtiRy7CYz+Yh0e8nWg+vR2//f5p pD20BLffmY9oEnXt+e25WR+Vi8l3fQ1jVwgBuVAjxHp24RnTxyCHGxRfmcNn3FuLoo0b8de/dGPm 15dj9sh4CN3UcNJu18GWPg33fHYi7nw6YPXDTXiDNrf4J6wwpM14CJ+bfB8+o+tC0XsvYPPOMkQ9 +GXcPpxWUW6eSX/6llpmxI2/C58fuQKfvkRv2vqoi9/D2xiWjjGrvoxnVpA8Oapw6I+/w05vAUat vA/zE4k1N/Gkz7UquUEyfPGn8f15JF8BU5EuUG9eaU0ciyWfGokFT9HqWn8cm3//VxTnr8BtS2Yi h4H2vjq1GmGMG4GFH/tnzHmo1xwsMvI6X6EuY5bjYwVL8Ait8lW738GG17bAc8/XsHxcGmIZRyHz el9Jp9Toiu0qcTUaV1ndDqNO30VtrF7Z5HNReo5Juw4uI2FLdne3x3qcXUm8JZ2cOJsXjWCcZ6rm qReAgZBRDv4w7hOl8FpFPC88aeovtzoCg0Q85b3GRQ0XIlo8RBhjN7gT5jKGITIyHNyc7VVkkuAu UmiCJ271PlX6KwQUAr0QkN1oWcyGcyPLyNWCzhqO8EgbbL2RkkUy4/YYbnaV0kPIuFDVlkC0Bkrm UI+JbnD2DycC0smiV/M9vVqV3GjjLrrvMj3sdCdz8z6jjfOlrbeUvmut/Fy9TlnI8iMXOcNgNXnh 1FtgDY9gnb3k4YLWaLJon6sWmde5cai1bOe8zhWtzOvhMq9/KLaKljkzl9P8XLlQF0781h4V3ZRL sgPr2T9hYWEfuk0jMRbb1ftHW5xbYJPuoZtlGBe0Lj3JVJjo/WEspX/MbPeqaArx57jQejzcRmLG Ot02hEVGsk7fgvlioU4kB1Z+rtk/MtbkIpNYm2hB8nJTIzIC9t63Sv/wHXnNLu9572rBc+HsH7r8 efVWihyG3mgKliYCf/X4T99Yk71iMY/ZxfrqIGll/0RarSRLvfTWNpT5ufog6hkX2iDimBcvAFpG OS4jxLzcq05t80M+V6tT06Wnf/QcH15uEnktCAunJfHDo4g6cXxc9ZH0PeNmbRCZ4KZXgM4lmxEc 6xx/HxqZGrmWz1WF1EijfNg5HJfUm9ZbC5/xSI7L3ssibVzKs3aNucjXP1KnieOGMshcxzojOE4v Fcf3rFmI8dWr9K3HtCeF/Wzl2k3v4RzGuS2sN5g9z1rYNeYN0cVEXTQ0wznWxRGZlsOwyDDYegmj bdDIs3atqahnXIiVMdzKTSJuXHnotqvN68Ewzp4um9m0WzztKy+JC/Y92ucv9Kr8O6DuN7tG2lJs MTEury6bLsE/NRrNU8XSGVC8Rq9RjmNQRSGgEOhBYPCIZ+CTJzvvE83chWLMTsCOkOoFhYBCQCFw fRCQFP5eWFIKMG4pGVISF9xiSOjHAuVSeTmhxY3EwqkZaI+O0DwzBl4liWfGVKwy2jAsPkRTtCka ySMW4oHOTKR8iG33rwe8EdmYMsGkzeuhSV7DRWnSWCyd6qTbYYiEZHxuZO483Mf4vYKYfmYd6Q0P LarDx8zBQ65kRGovtBCsKnV0YZw1GZbWaMT4gi371ykX7pJAuwxMXUmnzZSUqxONPrdkZL/kY8HD ycigZXKgEmrNesKRPGYc5nFzOoVsIRSaQ5+AMUunII1/RoakQlrhYrIx+z47ovKjQzTWrbS0j8a8 e93IjrMEWJz73BmXuVCHyLyJmKDPgjVW4mMHXrxeG5ImzcdU2svZ5aEp5jjkzl2CKMaKRoZCSKJn TRnBPjdxrIeB+2vXrawKO8FTWNBJsCt2uWedJGmeet0aVw0pBIYoAiFa1Vxde11MPmZO42eIgqTE VggoBIY6AnT5d9I6mTwak1aMDqEyTEqSNAG3i+NVqIrOhOjc2XggN1QVsh4mtkkftxyPhbDKwZjX rWlTcEdaCIU0RSBuxBI8GsIqEZ6G0RP5CWWdxkQUzOMnZHVy+8Oeg5n354SsRrGiRmWNwW1PhLBK PZPATJrKTwjrNKdj4or0EFZohDVhOBZ8bHgI62RCnfwJWJofwippO48tmMZP6OrU6SOQPmMpQopm WDIKFq4InZDc6ovIGINJ/HzE5bqspz9iHVXzCoEBI6AelAFDqCpQCCgEFAIKAYWAQkAhoBBQCCgE FAIKgashoIjnDTg+Kioq8MYbbyA2NhZ33XUXrIylUaV/COzZswd79+7FuHHjMHv27KArcblceJsZ FauqqvDggw8iJibmsnXIdW+++Saqq6tx5513IiMjI+i21A0KAYWAQkAhoBBQCCgEFAIKgZsVgZuK eLqZYbK0tBRdXTwK+Aolkskg0tND6TgS+qGxdetWfP7zn0dCQgLmzp2L1NTUC40Isamvr79io0Ym asjOzmamw6GXqUnI29mzZ5lpkKniqIMtIBFIW1sbysrKtKyDeXl5zOXSt0i6X/7yl/j973+P++67 r1/E8+DBg7jnnnu0VOkyrr785S9fFvuWlhZ87Wtf08afbBQ8+eSToR8YqkaFgEJAIaAQUAgoBBQC CgGFwBBF4KYinkJMJkyYgFYenn2lMmnSJOzevZvngYUo0cQgdLzvPCggKirqQ7V/7nOfw2uvvXbV Vrdv346ZM4deRG0NzzUTq6QQa7Eerly58oKeovPHP/5xjZAeOnSI2ZEj+4S8Pz1+f4m4kN+IiAgI sUxKunIgn2x6hPPcOVUUAgoBhYBCQCGgEFAIKAQUAgqBDyNwfYinq5OHKnejS8dDy+08Wykkmcw+ rIyd6b4XL16MyspK7ccTJ3iYMwlDcjIPgM/K0r6bMmXKDU06RUad7soATZw4EeKKK0XcP8XCZrFY MHbsWE0vIT/Dhg0bsmPdT7ql3wKLWDz9xX9NMEpeDdOr1TN69GgeHF4EIZaJiYlXvFT6wN9Gf9sK Rh917c2MADPwdragwWGg1Z/HN/BMOlUUAgoBhYBC4PIIuLvaIWc1e+0xPPKHxzEN0hpT4a8QUAgM HIHrQjw9Vfvxzo5j2GVdjGeW5SLCNDizghCDQGugWMxWr16tuT1+//vfv4CWxOy9//77mnXtoYce 0r7v7OzEf//3f2sxeuLmOmLECBw+fBi//e1vsWTJEo3Q/uY3v9FcQVOYnl6sb36X3bq6Ovznf/4n 0tLS8NnPfhavv/46xF1WrGVS/+TJky/pqfb2dvzhD3/QiLGQFHGnvffee/tEiL/1rW9BPlJEnk9/ +tMoKCiAWDnFutfQ0IAf/vCHmmvoP/zDP2juulIcDgd+8pOfoLy8HF/96le1a//rv/5La1tcSf/0 pz9h//79EPIueEmdgUVI7rPPPquRXrEeLlu2DEuXLr3iCHQ6nRpZu1wRgnzxoO5Lr/BbontbpP3/ FhdbIXnr1q3T4mDFgv2JT3ziQiUnT57E//3f/2kxln//939/oR2RubCwEH/9619RW1uLkSNH4qmn ntLqkrKRh3m/+uqrePTRR7V7nnvuOQ0bibGVMdDc3IxPfepTyMnxZYmUPpTvz5w5o42HFStWXFGn gT+mqoZbCgGPA3VH3sDPT0ZhxoxFWDk84pZSXymrEFAIKAT6joAbjae2Yfu7O+Fe/hksGp2EqOuy su27hOpKhYBC4CIC1+fxdLahvrEB5+zdITqvqm9d6Cc+vQmQEM//9//+HxobGy8QT4nf+8UvfqFZ ERcsWHCBeP7P//yPRnLEtXPnzp0XGn755Ze1pDNCOoR4/uhHP9JI25o1a/DOO+9cuE7iC4XQzJs3 T/vu+PHjGlnctm3bhWukjdtvvx1/+ctfEBcX1zfleJXEREqRmEiRXwiTECQhmEL8hg8fjqefflq7 RkjuP/3TP2l/F8Il10m77733Hn71q19pOvrLCy+8oBE0v7uu/CZk/PTp0xeukTaE8P3v//7vJbGY coGQXyHSx44du6wuQsYF66uV3m6rgq2/CFkUEinySwKmhQsXXrBov/TSS9r3U6dO1YinPxZ0165d mj6B8bEffPABnn/+eU3+TZs2afcJgRcrsvTpqVOnMH36dPzzP/+zRuSlD4V4in6SaCgQM9Gnu7u7 z32nLlQIXBkBNxydjTjfqENzt5wMqsqgIOBqxvlTx7H/cCk6jSbo3C54ed5p5vgpGJ0Vxw3SQWl1 0Cp1d9bi3NF9OFTphDV7HKYOz0SMdRA2eb0eOFvLcYKON1EJiciIs104u9bTWYeKs6dx4kw56rqN sCXmYsz4UciNtQzgfFsn2muKcfJoIUoqmuG0xSA5byTGjMpG/NBLZdD3/u+uR0l5M1p5xmtBXgxu ZlX7DsrlrqSHSFcLmmur4OlywnMdz/EcmNzqboXArYnA9SGeOj0JgAHG6+j/EOiO2ds1MyzMdxJy ILkRy6NkLBXi2TsuUMiiuOr+7ne/Q3FxMX7wgx/gwIEDeOuttzQSKdY4IYxCaoSMfO9739MI0TPP PKO5/YqlUEiLEGBJQCOkU8jfww8/rJHHf//3f9cssGIFld/76qp5OR0lBlIIoVhDxSLoJ55Sv5Rp 06ZpGV7FwidFCJyQULESinxiTRXiJRZcIczym8SVynXf/OY3MX/+fI2wCxkTvYRgShbXwCJyCQm7 UpInIcVXKn6iKBZqscL6i7i7ShFsBDOxRIplt6SkRCONYoGW9vx6ilxSl78tId633Xabhs369es1 a6VYpmUD4fHHH79Anvft26eRzZ/97GeaRVssxbLpIDj4x4VsWkg/S7//27/9m3adyCvWVlUUAqFA QKfjfGngvDkIvCEU8t0Udbg70FB2AlvffA2HystQH8ZD6IePx4LE4cjLIPG8gZT0utpQy42/eksS EjPSEHcZFuJxtKL2+GasfncPjo94Ct9/Ognz0kOfEd3rqMWZd1/AS+ezMfOOZcgk8ZTirD+GzRvW Y82eMjg7WtHm0sFgT8YxEvulK+ZiXF4cgubBnlZU7t+BbbsP4HBpDRpqW+AKsyP8CMnt8am4bdkk ZMdaEVTGBnoUtFadxuHWSGQycV9GRAiWQV31fNefw0l3KiZy7ERbQuAe72rAyS3vY3dVPJZ9+l5M ZqcHpecNNH4HXRRZYxrYj1cJUxp0GVQDCgGFQJ8QCMGM26d2hvRF0dHRePHFFzXSJkVccCX5jZCe QDIkf//5z3+ukVEpYjUTIifurVKEPInlTbKeiitvR0eHZkmTmEwho2KBE+LZ14ytlwNViNkDDzyg EU+x0IqMQkbFsilFXEKFMPmtwGLtE6ufuBJLEVfa//iP/4Bkc5W4SiHYQjols65Y+0RmuV8yy4rb sRC93sRTSLjoI5bYy5Wr6ecn3Tt27IB8ehf5XUitWJqFSP7617/WZBDiKeRSEkeJTmJBluIn5+JW LW7YsukgrsWCzdGjRzU5hXj6S2ZmpkZ48/N9J3sHWnlFb9Fpy5Yt2m+PPfaYRsClSOytuB7LxoUq CgGFwBBAwJKCscufxLdHDMN7b7+OYzmfxGcWjUaCTYcbju97GlG87nXsi5uHuSmXJ56mqFxMeeir sMT9Dj8ot8PlHQwtutBedRzv7fEgY14+JuVG9WBFr5uaUpyt5Pth0iP44h3jkRbuQFPhLrz35zfx 9u5Y2OJmY2xMMNTJjZYzG/DamgOoi5mGu788B2NSwmFyNqB0z0a8/c4aPG+y4bFlY5ETDHn0Ouia uQbPnhmGe29LIfEMwVjtOI/T+1bjFx134Af3JZB4hqBOezZmjE9FReNpvLX9HIYty0HsIIUphUBa VYVCQCGgEOgTArc08ewrwZNspkLe/MXvDht4vxASIUWBsZH+ZDT++ESxJApxEyuaxF/2LpLVVUpf LZ5X6mGJKRViKxY4IW8im5xlKRY7f1ymn5CJZTYwGZHfvVYIlFg2xcIrRQipWGl7FyHXvYvULd9f yeIpbrNXcin2k9V/+Zd/0Vxo/UXcmsW9V+r2XyNxpkI8hVSLRVKIu1g4Z8yYoVl1A4vo6Ld0C/GX JFNCPP2bAv6+FMKZm5t7WWj9FlT/Pf6NCLlYCKuME0U8+zTvqIsUAjcIArTKmYyQY6hM2ucqpNPN kJGS49i7fS+OnK5Asz4cCQWTMHXaJEzIjYdN70bzmW14b9127O9KoytoLobpKnD8yCkUNXgRlj4W cxbOxrS8BNg0/uWBo7Ecpw/swrYDJ1FS50JYbBaGj8xGsqEG+4/XwTBiLu6fG4ea9/6KF99eg4Om 09i7byPSbF64nGbEDZ+M2bctxrR0GwzCM7k5ZjQZYHC3oPrEdmzaWYi9p86hQZ+K0TPnY+GMEUgh se536ahD1cm9OJ08BncX5CP5guVVB2vqZKy4eyy80alIjxAFbYjJLMCEiVZsrW9BXasDiPFZR/tU PDU48cEB1OoyMW3ZIkxK7WFz5jhkz5qD27qb8JtXDqFwZAbSx8TDhE40FJ/EYb7r9heeQ22rEbH0 RkmKiEWMLh6jVk1HVlgbqva8gd++8D62F21B84Et2EE3YC/dhz1JozF9wRLcMS6JdUmRJF+1KD6y D3v3H8HpihZ02tJQMHYqZs8YiZx4O2QB5WouwYEPXsOzL63DoY5C/OhgCpLC9HCT+FuHz8Nti2Zh WkZ4j6uxA22Vp3Bgyw7sPlKKRr0VYQmptNpyQzVtCmaNHYGCWD+oJkSPGYvc4/U4unY/ymek0rU5 SOtun4BWFykEFAIKgeuHwC1JPP2kSxIK+YuQkSsRPrEOCln0lyslzZHfA6/zx2D67xNLnfwuFjlx gRUiJLIIoZH2JTOtlKvV35ehIWRSCKYQTyFsQpTkiJlZs2Zpx80EFmk/UG+/a6qQQ5HTj5FkBhY3 VT/pEzItMvtjVwPrlOQ9YmGUxDuXK+JiLDGklyv+vhFS57fCynX+TL6B7sUSiytJhEQ/qU9caKWI BbZ3cqLe1ld/PKYclSLFX6/0mb+PLidfIFaiv79IH17JwtuXPlPXKAQUAh8NAh43SQcDw+T51fKh XS6209uAU+s3YvO2s3ClJyIhJxdxOi+J40lsff48mlfdhjm0ThmtkYizNuPgn9fjPVMe7r1vMtJj 6M5pbkBN+R68/AIzFX9yMaamh8FRcwBvvrIFJ2tdiExMRiYjQAz6blTueBEvbyV5ilyET42xwGSw ICw6FrEx0Yi1JCA5LR3pDHn3uIyITIhBON06A6mku6MdVZvW4p2ycVg0NgFxTHpnLC/Ehk3dKEUk vrogLXiX156u6WypR+mhSmQPn4+M5EBToQ6mqCSkXXICmBedtIIePuBC2phYpEQHE6XohrelDCeO hSF+1DCMzexlQtTFITFzOCaaN6CuoQntrnA49r+GlzeXodEYjYSkdFhj9LCHtaN4/X6sP50A/azx SM0ywhweg4TYaEQ0RSEhOR0ZSRat/72x8YgJY6xvj67OhjMkfG9jQ7UVtvAkZHJzwcUx0n5yLd5s qsLMhYsxK80GHfvHHhmD+LhohNuSkcL+SbPTq4j1mOOjmJXa0FOnF+2le7Bx/Rbsq49BZlYeYozM wEp34op9H+DdM+zPlNwA4ikVpCE7KQKjPEdxtnoBhsVbYR/AvsFH84SpVhUCCgGFwEUEbkni6Vdf 3EmF5AlJkXhNfxzhYA0QcVeVxDhCbsQ1VKxu/iJurbLrHkiCBiKHZGeVzKwSwyiZfaVIUh8hk4FF SKIQNn9mWP+1Yr0TUiaZeqUIsRIrrZBaf2lqarrs2ZWio+h2pbM2JenRtYpYhgNL4CaB/3uJyRU3 WYmv/MY3vnHBBVdcaXsXid0U6624CwuJ9bvxCnHtK+ZCTsVqLP0ocb/ipvvJT35Su1/cb+UcWVUU AgqBmwEBhgk46nD6aAO8UdGI8+7H9kPHcDZqGj52xwwUpEbB7O1G05m92PjW+1i95wQSUhMxOX0C ltzVif2njNjZNhy33X0vpqfZae3qROWWl/HTX9WQKLXDmd6FwnUbcLIuDPnLHsY905Lho1YO1O54 nrGMtahIX4LlMwuQYNcjYfEKLCuqQELcfMy7ez5GXCnxkZwBLRuZiXkYM2cp7lw2BgnC92rW4Ud/ PogDxyvRMS8VVs08Gmxxoru1BZXHbEifEIWYq7qo0s22aB+2v78OR+1TcPvEEciNDMbNlvh3d6DN aYPRHN5jIQ6Ul1Zdi5mEnHG6TF7YXnUUm94qQkPCeNz+6HJMjfcvbRpwPGotNm7pIGmnddtoR+K4 pbiPVspjZ/Nxz23LsTT1Mji46lB0dDf+trOTLq4LsWTGKGQy25Sebr7nDr2H51+i1VKfhRGPjkVs eApGzVqCex2dKO9YgSfvG4Psy3JsN9qrS1BSXAXX2Ntw+4oJSOVmg6upHIVZUYhyjcCwqN4dG4aY lDBE5zSjrL4d3Y54HhcSbL+p6xUCCgGFwI2DwC1JPP1WP4lffOSRR7SkQpIox2/t81u/Av+8WrIi P3GRa650nXw/ZswYzRIp5E6scpIZVYiMELhXXnlFS1TzxS9+8cLo6M95lf6bJaurxB1u3rxZI2Si Y+9YTLlWdBbyJNfJjr8kOJJy3333XbBojho1SiNaYsW84447tN/Pnz+vkXUhtsuXL79kREdFRV3R otnXod9b9ythsWrVKvz0pz/VzmuVMmfOnAvxmYFtifziuit6CemU2FexWEo8rL//Av/03xvYp4KV WDwlfnTt2rXamBFsRV8h+X6yPJB+6ys+6jqFgEJgMBHwwNtWgu1/PQrPyHyMTTuOQzvfw4am/Ti7 9dfMnEkrKemknolqupxdqB+Zh5Xt4hVD4tDegc5Yun/SDXeCRjqldMOtsyLC64ZR5+aGZyNK97Yj fsRkTJ/iJ51ynRkJ42Zh0aJKHD3rQXcn64y0MmtnJ71PutHNPzvkSOOYK+guHiwmK6LHj8H0yfk+ 0qkVMyxmGyy07l7+kKu+YClWYb7j3BaYmciFua8uX1z1KN61CR+sO4amlLG449HFmMJAyuCSBNNK GJmErISdKHfWooEJw+MuIVxd6G6sQ3lZLFK5YatrOoWdHamYMHoiJl8gnSJeLAqWrUD6LAeMsTaf DI4udBBLh2DaLmCGf1iPDmaUPb4Lr28+hvTTu/H+b+g66yIZ5vyvQxdqy5MwLW4yGphYPlZWUd2+ Op0ky+1t7LML7rKBVRsQnT0RUyY2Yf2u5/Ddl5j510E8jeGIyxyJ8fNGI/IyMZx66mewGLUxd12P BejLkFDXKAQUAgqBIBG4qYmnn4z0tp4J4Xv33Xc1ciTHb0gRy5mc4SnHofQ+hsWfUMePrd9NM5Bo iMVSSqCLp9/VVuTwW8sk+ZBYDyU5kRzf4S9iifNbAv3xhuIee7Xij6EU4tqb7Igcco6pEEopQsgu F7sosZYSEyokyl/uv/9+fOUrX9H+KRZOyeYrR5PIUSOBmVuFSPstokGOu8teLsRXjiqRcqX4W4k7 DdRV3JNFfn/CH39SIX8DfkupJHwSq6ec1erX6zvf+c6FhFH+TQfp00B3WrFC+/vWPy4+85nPaAmm JAmRHIHjHz9iPZZ4094u1qHARtWhEFAIDA4CFiuJlMR5mi3cjPK3QTJDltJVz5j8Jm445dqRkDWW 8eMLsWpCMrkgWReNi14Xs3e7ddDH5GBsYs/NZpOWkVjmkYt2Rbp4cpNR5hMz2zEbIhCXBRxpPs9N sFZk5EZo8YLcCkQL3WKPHzuDJsNoeC/J0ulCN8mPN5DwkfR2OplfwGyFxcg2TWbWb+J7SE9iGGDV 7GnbQAJq7pe1U2QzwWJnXGt+J8qYEbi9i19dkjSXMatNpThG74/NB2oRMWkFHpw3BlmGOhTziJfo 6CjE+oJb+1CopC0dI6dbcbzwDPYdGY/MKUk9VmG6GTcW48TREzidNgJTsxIRY6pGVmcJmsrP4Zwj HZmXWBxp6QxjRthALEniXN0ueJg9+kLhJkJntxsevZnurHqYIxPoIszN1iVTMCHLd5wJqTfc3IDs doQhITsPiQEQe/n+cvF+GC427nWRkJKHytiyGDtQV16PpuZkTLpzChbrnHTdJfH0tKOp+AA+2HwQ +xKSkDo77YKeMh7amxzorrUhNTqMG9V9gE5dohBQCCgEbmAEblriKS99IRZimROCFFjEFVSIlrie CmmTo1IkXlAsoOKiKsdpSJk7d65myRJylpCQcKEKyTwrlj9/AhvJsCpnXwp5ESujv0gGWcmIK66Z fjIjBFOOOZEjQPxZceUaaVPiKAPble8DXVt7jyOpX2ST6/yJcwKvWbJkieYKK8TpctZOuVZcb+Uo FUmKIzGZYhkVwhpIviRZjxwfsmHDBvgTIImskojoSu60/Rnzouuf//xnLcZS+iOwiFVV+kL0CdRV /i6xoEI8BQvJdBtY5PxRsXSK/rLoEyutEEghrJMmTbpwqZBtcbsVIm02X1w4yFEpktFYMPT3rbgg iywSqypkU7AQwitZdeW7y8W99gcPdY9CQCEwiAh4OtFcU4WTO/bi0PEzONO8C1tN9YzRFILB8wAb juBEdQOSxoQhdewMjC2hsaxWB0sE3SLDfHF7Hlc7vI1NPEqrFZ1dDji8zTxL8xhOnTiF+qhIHD6b hNEZdl7DJD8HD+NESSes+4Yhk8l5hi2ZhqMvMebv+b+hdmo+0iNN8HTW4My2d/DuxtPomEObag9J 1BvpbknracNJZuJea4czI4xun+08u7AWrfoY5EyfjdGxjCEsOYyDh0+iuNyJ/SnZKAjPQZS+BVXH jpLMHkOxLgyHT6ZgQl4izykN1t1WBxtjGdNGW7G2rBajaxzIucDwSJgLN+GVX/8Nb58A8m9bhGHR HtQfWY/9B9bgDcNifOLORViYEURyIR5okzVnMSbVrsX+ta/i5VqeB8rkREYvj1g5eQKHT5kx695J KMhgYicPvYnmH8aLR9fhLy/UYTrjMcPNjLvvakTF6TKeKcoN1vuWY1wyrZ5GEsvoBMTWFOHIpnWI r0uAWedAR1MNzndFIiFvMpaOSsHIMTPw6OkD8FhoKQ5nnzPxlBwR6epkoqTKFr4TWtHlTWLULEtY JKLDI2Dbuxvb13eiVSzdJOdNPGKtVp+O8cytMCa1G3XH9mL7q4WwPnQ3FoxJQaT0r4OJhRgHaqBl 22ilO2/gkPfWoKy4CafOZ+K2hHC6SA/i86CqVggoBBQC1wGBm5Z4CnZCvK5UhHzKWZCBRYhFIHEU IvLEE098qAohiX5yKj8KGRIS27tIJtXAjLGBv8t5mPK5XJH4ysu12/tayaAbmEW39++HDh3SkgPF x8d/qK3AZDryd3Gjlc+Viril9napDfX4FBIpxO1yRbLGXg4TsT4fOXJEu0UIpj9m01+HJCkKzD4r R6BcrkgWYPn0LjJOxD23dxGLrN/t2P/byJEjIR9VFAIKgSGAgMRwbnoVv/rdOyjtopvkkefws/Vc +Gt8jK60bifadLNxT3YswuPysXi5DYnbNmLd336B/cxq204LoDU5H+PGjucmVg6sFi/jGrfhpTfX 48zxCrhJ+F5K4tEaH8tGx561+NNbm1HS7kXtSwZE8izOu2cuxSOfSMbOHduwbfXv8VadB2HDmDE1 byqW3ZuK9a0W6LRsR/TwtMQjf/5KzGt6Fa++9N94q1GH2KRs5I8dh4lTCxAvpLX1LI598CJe33AC bYxhfKs5HOkpd2FW+BG8sZoZVw+W0eG3nl4+sYj6/FKMiwvefKYPj0NKwWhYfncSZcNyMDEzB75T sTtRV3gchUeOoqzRhOY11ZSFGNKttYsUPXr5ItjNwS43mLAobiwW3GVD3O5NPDbrD3j9eA3csSTU 0+di/qMLMHd0EpjHh1bGJIy56yGY0rdi7dur8exrZajpZFbdlGEYPWM6ZsyaimHMXqtJoGec55jF +Nj5N/Hqa3/AD//WDG98JnJGjMOkyalIlnNJ9TYkj5qJ+2ip3LB5K17/6QGcqWmjLkySNKwAYyYz m3F+2EXLZHgWRk1dhMdLmVPhTz/F651umNKGY/To8Zg4JYqkVDYzHbDHJSM17TwqeEzMXz84jdKa LriNcciYNA+3r5yDuWMSL3FJdpWdRGFDNSonL0FmjDVId+Uh8AwqERUCCoFbDoFg3wS3HEBDVWGx Gv7nf/6nZt0Ti2XvhD5+4inHkAzlbKxyHqfEx0q5++67h2p3KbkVAgqB640Az/Ect+Ip/HD+Y3Rf pZsq3S/dkpxHK3SBpO3JYAqDPTyM5Ipus0kFmL4yE6MW3E+XTFpE6VWjN4p7LrOe0l1XjmLxjFiG z3xrHp50MdZS7jfbmaSN8XmLP42fzeAmppBar4mWwwiESUbTtHFY+NB4LLjfBZebLZLomJoOY+27 q7HNbWY8qN/+ZYQliYmLHh+G6fd0oIv162m5s2htW+nGy+ssPMfzsW/jpw+QrFIND4/qCI8Ig5UW 0Sf+cQoeppuuyKSnThGR/Xz16yMYpzgZy4f/GdtOH8fh/BQmT2JGeMZJZi58Ev80/RF8tSdDsO8d Q4X1RljtEcz4GjzRlftNCfmYeHs6hs+6m+69DKqkK6uFWdfDmWUnUAu9NRUjZ96N7LFL8DBjY10e OSqH/WNn/1kFy4sDzGDPwpSVT6Fg/kN0hRX3WBPMFmJpo8sy3a61Sxl7GT1iDlZkTsCCezp9bs7g cTXsI1sYr9Ncqv11mmBPGY/lT+dh9kO8ln0Juj1baS212ejeTDdo0IKbvfRePDHvTrgYaevkZoeD /UizNkzWcERGkFhe4kZdiYN7z6KylfkZHmSSqT67KV/vB0m1pxBQCCgE+o5AP98+fW/Af6WWpCX4 29Qd/URA4gwlllViIiWBUu+jYkaPHo0vf/nLmjXU7+Lbz6Y+0tsksc8XvvAFTQ9xPVZFIXBzICCJ ym4OTW5YLXQkc+E8euMyuWUuLzPJJ0lbZCw/V1BKiGZ0LM866V3sUUjs9bW34zyOHTyNsspGOOly Sb7GeD+ez9lUgXNNBkwYl4GU8ECypoPRFsGjMK+QTlZPC2xk3KVhl5ocRkRR5tAUyhCezhjF+Sjf y6O/2jppG5azJfWabJFXkm2AjeuMNoTTzfaaXcX4TFtkLD/XblDry7gr96WvBsZ60o1WPtcu3Ghg wzFXbJxEWEgrP1q5alZg/t7FbL0R2UiZlIv5ueFajKkqV0FATZhqeCgEhgQC14d4MpOf283zEbUd Q1WuBwLitvrtb3/7ik2J66pkgx3qRTIUByZpGur6KPkVAoKAl/Olk5tHknxElZsTAW2d7GL8ZeEh FDGWtIVJirw6O6JSR2La/GWYPi4HibYrpY79CDFh1qWwzHl4OMNn0Qw2UvQjlHxoNR0+DPOWDuvJ pDu0RL/e0no9briYY0PLuny9G1ftKQQUAkEhcF2Ipy56GKZOZhY4cwIsgZn2ghJVXawQUAgoBG4B BGi1icyegbusNuQlXZI29BZQ/tZRUW9Pw5h58rk018BQQaC3F81QkXvIyHlJVuQhI/VHIKge9vRR GH+7FZ40JnhSCZg+gj5QTSoE+o7A9SGeMcMwYyo/fZdLXakQUAgoBG5RBOgamcPEJjm3qPpKbYWA QkAh0GcE9IhIH40J/KiiEFAI3PgIXBfieePDoCRUCCgEFAIKAYWAQkAhoBBQCCgEFAIKgcFCYMgQ Tzn7Wa/cdAdrHKh6FQI3NQIGNXfc1P2rlFMIKAQUAgoBhYBC4MZHYEgQT0nC4GRiorpmngimFpA3 /qhSEioEbjAE2uQYBlUUAgoBhYBCQCGgEFAIKAQ+MgSGBPEMtxlR29yNT/5k24eOBfnIkFMNKwQU AkMGgeYOBxZPSBky8ipBFQIKAYWAQkAhoBBQCNxsCAwJ4jl1eAL+7wszNaunuNz6Cs/M4qHMPP0M 7lAd08LDuo2s0+vm8S8hOcaAx3XzYHIDUXY73do5bQMvPAtM09sbOr3lDDY5udpDLN2hOfJGx0Ox jXKgOvW+eCj7QLQnlgYefi5iCpYDqSrgXj07R4zoHh5fEar+0RtZJ48Q8hDLUMip47jUG5iqz0MZ Q5QuXvpHc12n3nLW+cCL9I+c5uel3qHqH+rNE9r1TJXv5tgcqJjxkSpD7MD7WdWgEFAIKAQUAgoB hYBCoH8IXB/iybPKahra0GKIRV6cNehzv6xmPUak9z7A2YHO6hY4TXYe6G3rn/YfuqsNTeVdsMRF wxYWImg6mlBX60FsViwX5aEoPN+voRntLgui0/pyqHVf2uxE6/l26CIiEB7Vc7h1X2672jXs8/pz DkRmxMLEw9EHXkjhWpvQ0GokltEDr85fQ2s12hx6WOMSeMx6KAqJXH0V2i2xiAwP1aHtHeiubYQr Kgl2c2ikRGc92lsdMKalIDQ9TlrYVIkWnkNoj4rmgfKhKA4462rRZY9HhC00Urra6tFU3wIkZCCW z3hInsmuepxrdsBliUN2dCiOeffCxXFZ3m5EZHQs4qwhkNLThY6mGpx3xSA1NgL2UAwjRzNqmtvR oo9FLuf1EEgJT0ctzrW6YWKfp4SHQEgvz49uqUJZlx1x0dGIsYRgLnK3o6mpCTXuaOTE2yF7dgMv XWiubEab04L4zOjQPJPuVlSXtsNrj0BCkj0Ez6QHrvZmVJ53MItoLKLCTEG/yz+MkwPt9c1obNYj hu9IeyjeFd4O1JW3wKGz8TGPgmngnQNPdzOqyjphSYhBTLQlBGPdzXHJMVTjQSSxjLSGYsb0wtFc i+aWLhgS0hEbinkDLnTUcF5HGMJi4xAZgkcS7k40V9WgKyyWWEbAHIJH0tXegOa6Znjj0xBnN4dg XIZg0KgqFAIKgcsiEIpp5KrQnuPB2P/zx7dxpLgWblM4F3smzcI04OLhC4vutx6DGWGRlhC8VHnw sKsLLU0uGMOsJJ6Uc8BCuuHs6EJ7uxe2mDCYNUvlAIvXic7Wbjg8BoRF2WAaeIW0ejnI6RyA2QJ7 hDkEetNy2t2F1hYPLJTRajYMXG++AB3tXejs1sPGOs2hWKDQHulsb0OXS8eFbjistNAOtHg9TnS3 tsFptMFis4J7JgMuHmcXuto74bFGIMzis9AOrJDYdLajq9sFvT0KNg6igVfJhVRbK7phhiksDKFY R3k5Lrva2uHi5pLNZsbAu4deAt2d6OroBuyR1JvW1AErDnidHWjpolXWYNPI7IALg9rd3W1oduph 4Vme9lAwG45LRxdJotuGiDAzLKF4fjhftnU50M0FfkyI5nWPgzJ2e6A3hyHSEoLFOD0PXF3E0sX3 hJXz+sAnTG2+7OzqRLvXhmhiyWl94GWQ5/UwzusDR1Pm9W7O6+7QzeuyMcDnsbNbF7p53etbG3D7 AmHR1hBsKNKLw9mNtmYnDHYb56JQbFiRxHdxbdDm1bC08Bkf+FQUOK9zfpP1xkAr5fPjaGvjvG4K 4bzu7JnXiaXVEoLn5+K87rLYkZYQiU+umonpY7MH/lyqGhQCCoGQIxCCVdLVZfrre/vx6pazsNts 6OACrTA0/oxsVFz7uGD2dsFzrnPAbng+LegWy7ezt7aDbpcDdeyT+igfZ35xD/XWtoTE7VLTm6tl nY5unBXdIdKb7rvE0usljp6OkNTpcw+l3nVtocOSeutF7yrubIboURCXU3Fbhqc5hP1jZJ3cFKGV KRRyyhjS6fmoemi94LgMTZ1clEgHid6hqFDGurjvcoPA62kKLZYclx5aMUIhpoxLH5ZtIcOSFULj cd72ELmV8ymX50fnpoycN0KheE//GNBFt+XQzZcyF+nRoYUmhEJMn96CZVuIsJS5UvrHSRz5TIZC SG0OppzopN6hGZeDOa9Dnp8Qyan1j7zPQj6v85EM2bzeszaAg+/IUM3BPXrXhnYOvrA2CMm49M0b vnk9lPOGjPVQz+vy3uXaLURzkaa3zogwYxMKiyv4DvIo4hmiNZKqRiEQagQGiXhyN6/6MN57dy3W bmhFeHgkYqxdWJp60rcDF6JJNtRgqPoUAgoBhYBCQCGgEFAIKASGGALcEDlalYWKlnCUnGvAu/vP Y+mktBBYvIcYDkpchcANjsAgEU9qzYQgTofsNnrh9JqRYK/Bj+54ToyKinje4INCiacQUAgoBBQC CgGFgEJgyCDAYN6vvfYUzjaM1QwcTib3U0UhoBC48RAYJOLJLKkpk3HPpyfjoPtt/OmdI/DEMcOp Q1yUaO5UFs8bbyQoiRQCCgGFgEJAIaAQUAgMRQS4rnR79Dz9wI3UpFismpoxFLVQMisEbnoEBol4 XsTNQ1/7AQe43/TdoBRUCCgEFAIKAYWAQkAhoBAYKAKSC0EVhYBC4MZEYNCJp5oAbsyOV1IpBBQC CgGFgEJAIaAQUAgoBBQCCoHrhcCgE8/rpYhqRyGgEAgCgattCA80BX8QYlzxUpHPxY/IcqVZ6ko6 3AjyXw2DUMstOEmdglModJfQKPc1sB9oH/fGoK9y90e2axk/AhPeBcrhv+9ysl3tt4Fio+5XCCgE FAIKAYXATYqAIp43accqtRQCV0aAGb4kj/+VildW9x9hYgZp2pYKpP4dyWcjcP7/SIQ6PkyqxIdf d5nTCT9q+a819OS4gw8xRIl9F7YXRBHyo2dGjcxPA9YsoPKXQHuRL4Fbf4tgHzUVSHgQ6DgKVP2R crGhaxFDEV3kuZxqvWWRa7Xrel4/HjJnufdabYhs4aOA5E9QtlOU7fd9k+2yeAcIxbMktbOfRACt DzRge76TfhFm36toY4/Ya799hM9Kf/tZ3acQUAgoBBQCCoGPAAFFPD8C0FWTCoGPDAFZJ6d/HBj2 M58I7jaum7u5yA4jGbD5vjv5JFD9qo8cfBRF1v1mEs/M/w9wVJNQPUsC2ot4yjXZ3/KREIOd8lsv Snr6s7znrx+d/FfCzE+cRr1A62QU5ePHHwDfshc4cjv7gh10LQIWWL/OTIL+ecBOQta4Bmgj8RxI ERnj7gIyvg50neE4oKw8//KaJWI0YEkn8T0MdFdeWQet/kXs238CIkhwef4emrcCZ77Ee89enTRL n4ueGf8AtGwn8eS4uFqmOr9VcvRLQMxiXsrGXc2+e4yRPuLbSbyO3e17HuzjeB7DPZTnEBCWBIx6 meMwkd/x99ZjvvEkdZp47yjWaR3Ge1dRlp7frgmSukAhoBBQCCgEFAK3NgKKeN7a/a+0v9UQEGtY yy6giAt/WUSnPEUCMBloeBeofcu38Jff/a6WfutZoDunYCb/lt+EJPkNdbIw918faAELMCJ9iMzK b36DkdzrJ7tiSRIrp6vhw+TCTyjCRnLxnwPUvcbPBxfvbd1/8dgmf9uB/eyf9UQHP5kItNbJ3wPv C9RL6vG7e8rfL5E54D7Bpbf1TyPUJDL2sT4CVPpdttPlw1AIthAjqdsvy5Vw88un4dbOupp82glm 8pvfRVlku1Ydfiz9OsqfFbQwt+4kgazwkU6/AVxw8//d7wLtby/3ez7CeuJjQNnzJKE9YyMQd82a Og0Y86aPcJb/p0/vpMf4/Xwf8fSPB788gfpImx6nr0bBT45LkOv9fdCbsPv/LZbRBo4PcxyQxc0K IetlPyDpLGN9xM7jYJ+M8Y0l/waGo96nu43kMm65j3hKkfaix5PI3uYjrY6a4DYKAvFQf1cIKAQU AgoBhcAthoAinrdYhyt1b3EEZJHedoJWHX40CxwX0UI8m7gwL/l/vkV8JBfg6Y+QCBzhtXS3NJBF JC31WUUb3vEBmHQnf+di3MkFeiwX4bJ4F/LqaOT1rCR+IRfkvK95E902+bshnHUdIKmV+ni/EAr5 RJOI2GktkyK/Nx/s+3FLXrYppZ4ylfz2Yiyon/AZSDDilpBwJLNOEhYhZkI6mtb6XCqTKGMLCZaF affNCT5y4mzxuSEn0EIm38s9okN7qU9uwcxOMhI50+dq2XGSv9P6JroYiU887zOxLrEkCx6u1kuJ id+dtvscyc9PLpJEP5GLmUFZ0mi9fJ+yz2FdJKpaG7t9fSPtG2ndTSAZMkT73GHFYi1FZBWdE1fS Wsn6O09TR14nJK+VFtU21nNJHctYVyzvI47N21hXcY+sVEb6009kI0nKhCxL38uftjzWX85/r/e5 +qZwLMh3UoSQgd81Uf7uqkt1F9njaVEUC/U56n7qO77fK9l34jItskVwPEhdIo8QQ3MM9eHY85Bg 1xJPP37Sn5GUJXyK77dG9qmDmxSXczOuXu0jjHZaKlNpDTcSt8pfU0bqK31q4/eir1YopMjk4r/r XuX45BgRQl3+Y59br9Qfe4fv0noS6K7aG8+y3qOJ+kMhoBBQCCgEFAI3GgKKeN5oPaLkUQgMNgKy ePYTEL2YpuTfJE3kC1pJ+RRdIf+Zi/PfAMcZP2jmwnw4/y4Ebs9wn2VuJF1ZhdiI5UnIiFiKmtbR XfR+rt35Xfa/kRhMJyEgOQmfwLrjfdatY4wdbNzMxTpX/DnfpNskLa9anCYF8nQCZ/+ehIykIKjD fv1mO94mpEGzNpLoFpDQJD7kIyZ6kh0pHloYD6/wkcSRtMwJ8Ywk2ZNyiCSjiSRyBNtPesJHHqWe LpLOU58k8aEuiSRWUq+QUvldiNARftdKkj7yzz5i5Zb2iMf5n9OF9Gs+VXpb43r3sfwu16V9mW08 7CNSQsjNKb52TlKeKhIhM+UZQQtewgM+Mu0k8RGCL+RTCKSJehY858O6m8RNNhaEXArRPUK9mw6z Xspe8CsSKJJSv47d1PHMV2ntfI39T5ffgmdJLN8GDpJUJhDDLPZVE/UXC6Al0yds4eco0x/Yh//I 70f4NBLZ49jO0UKODxJPvwX7gr495u2oWcSK46N1H2WlHgZ+BANpJ47E+QxxKCZ+USSho/7Ga2h9 bcju2UBgHREknGPe8PWDuMzWk5Qe59gSfXpjLW85Ge9Gkli/mV7Ip4x3jahehq3KV0K03bSMysZM xET2CS3pJmIdf7dPjuo/Xrtfe/ez+rdCQCGgEFAIKARuYQQU8byFO1+prhC4LAJach7hFn5Cxz+F YEpcnPwmH2edj4ScZbxdJYnGmBdpHaK1L/E+Eq7f8Xdan2RBL0Rg1zgSqqdINElGM0kshXjG0WqU 9R1frN5BWt4MZAGTafHM+xFJhFioSEKvWXrkE7JnJCkWsuAgwaogGYqlpVNIZ81fSEhIpHMYLyqk pvhfaMnaSHJFciNFSKfEGLbs8LlOZpJ8CemsIPk88Rla8GiBm7CF93+fRIRWzqRHfWRHiGAliUcS CaCTRDOSxETkaKTV9BCJW7hYCUkcJYaz95lyQlbF5Tb3mYvWSrGuiSXaRYurFNkI2EuLZ9wCkkDi mUX5a1+nTiT2Qjpb95BI3s0YV7q25tJlVQi1xriIiYMxlrZ8n7vsNuqZ911asIm71NFC+fP+3Uc6 y0mqzrAPUmndFqKZK9iTwEmfSfH/KcRdiiWLpJ06Wkhkx7CPsliv9NW+ecB4kkCpUwhjBevSifW1 VwdK/9SQRCbStTaCpHMS5ROrYfnPfNZTKRcsjz3sUbCSDQktNtNf+JsQconlrSM5HkvsxB02+XG6 L/dY7QMu7VeyJWm+k2S8eSP14viOnE38STzjOQbCCvg9x0TbQUU8e3Wx+qdCQCGgEFAIKASuhoAi nmp8KAQUAr0Q8BPOHgJ6OXzEUtpFi1olLWed4uq4hsRzgS+7qhR/xlKJF2wnEWp4j+SNREvIi+au SEuaFLGIahY0ljZav4S8SdIZcfO9ltXTT+iiSNDCSfyELIgFrZLEU6x8UtpJ5tpJXMQ6K0VzLQ3Q S9o8TOIrOlhJfsW6J+22kIyGkzALoRNroFhvbek+UicllaRUSGLN6ySetH7Fk6BKCad1TAiuxBWe f+HyR5wImRLrW8rTPlIqcrcfYpuUVdxipVSRbLaQCOtJ4CTO1cy2xcVWLH1Salh3O62A537qI3Lh tDr7i57utm66+JaQGHZTL7lWiGfYKN5PC2I0XVfl93P/4yO+Vc/xd1pmxXItFtIPZXHtkamW9YjV z2bz4SnXm4hn23m2LL6sLFKfm5bXy71ZpJoWWlyPsu/F0h1Lgh63yueee5btl5M0Xgj4DbBiX9TM 9zch80L8ZHNAPGRrX/K56MoYsFIeW/bFO1z1PgIZbJE+cVGn+rd6iCcJp5F4xRA76bBakl0XZVRv 0GCRVdcrBBQCCgGFwC2MgHpt3sKdr1RXCFwegR5rk/9HIUqBZO3C9yRF4lKqF4uY30pKEhZYJAZQ CIc/e6u4g0r1llTfVWKFE6IWWDTi00uGywnqJ2nF36Kli6TAP5sJZ2naSNJFQpROC5xkW9XcSkkU xX1Uq7qHTHWe9Vksxe1S3GrFJVguGEHyekEGVij3iq5ltM5ZSd7E6jiGbqli9ZIswI276Xr6eboY 05ooBDvzGyR+/0oy9d8fdrUVYthBkrmPJNVFUuxXNdBCKO7H8m/RUcOfuGnu0LSUSnHQjVW7j//R rMuBePFGSYwjH1HTHwMql5tprTWwHklq5P9d8JJETlLktysWtqHJJP/pGRMyLvxyaOLwt6t1ndwq bsnHaKm10z1XMhOLFVncdWtpDe1Nei8cb9JLKIktlqLpJ9ZeFrk2nv08gi7P/iLusMdone5PET1k HEnfRy/iZ4KPeIoFViyhfRii/WlW3aMQUAgoBBQCCoGbFQFFPG/WnlV6KQT6i4B/8S9kR/ikkAkj SdmHziuUlbd/9d1D5D7Upv/3gD+F6EhsopRixpJW0WIlMZ9aQhuSpe5GWrBGBtR9LUWEBPGaQEOt xOWJa3DHcVrAWFcrXWnL6EraTItdoKhimfWLprl0NpGoppGs3EfrHAmSgT8KsZGP/NZNUnyEsYTh JE1ZdNuVjKziPnyEbp7FtNjJMTQJtOgN+ylJFQmoWMzaGe94OZLiT97jV++SawJxk79TaIkdddb4 rhYZ/fqahSwHWgiJh8R96kiUpf/MSb57hICK9VQyw4rFWoi0/C5vAa1/WSQWVOIfL1t6yxRwkf88 VS2J01X6Swyj8rv0QfNJknP2v8SFChmXZE3+rLWa5VSuo4xSd293ZUngJEXqErdbn4Ikr3T9baVl 11/ERVfI7lWM95dI6+8TqVfUbT/lc8WWhEJpX/RZnJs2+MjzlYb8VdRXPykEFAIKAYWAQuBWRkAR z1u595XuCoHLMaJOEgIpQt7Cs0ms6AYpcY1+sjgg1Lial0W9ZIpNpqUwhu6WVYzDFLfRcMZExjMm UVwo/QTkqm31rPw1SyU//tnMSZIolkFJKOQmgekqZi0kjNELfDq0l3+4ViEZLt7XvNnnQioWrnq6 D3eTjMbw73J+ZNVvac1kXGEHyUjdWh8hEeIpFsdYumJKvOj5//W5HWsJjWg99PRYEi+02EPehEyJ dVVHl1f5ykNm9KFrA8UU3MQFmHGRqX9HnO4iyaWFMIXWPDkKxG/1k1uEwBsifJbX0yTFErMqpYXu qZI1WOJqxcU1/at0cf0O66D1MYzYS90dZT6X1T6Xnv4U110pQojlnEuIRVX8YHuKn8hlfsFHoCWm VforhXiKVbftEF1iq4k3LdBSBMvI931xwUKiL6mLlUUx5jKNODQQa7E+S5HkVg4STSc//tLD2X3/ DNwoCVQw4HsDZRcSLmRVSKiMJc3dlsQzkThJHZJFWfor0ELdZ7zUhQoBhYBCQCGgELh1EVDE89bt e6W5QqDHbZJA+M8vFC4nx4rIUSDinjqD1johBQ66rcoxH373ViE2BnFx7CFSF+6nhUqKkEFtrS8+ rPKn5qPpI0R6/r2KGWWF4Els4Uxa2bSsrLSWiTXpHMmb5mpK4iZE4Io+jT1mrNwf+qyL/iJnSUoM oMT32XJYN01nljhfTGUSLZMHF/LKnnvlaA9NPn6EHJX+h8+CJtat1M/53DeFEFYyZtNF+eyM+xz2 cx+5E6uhHClTQUIqZ0RKJt/cH7AuibHkPaWUqYu4BVoyRUcptuHEtvSiC7MkAjq4wEeypPizDQve xihfe5KJt+YVEi0mGJIjPmaWsG/2+hIj+Y93ESUEO5HZPp7XMBZTCLBcI0l8RMfi75IcJvviPlNJ BKUtcRk+TX2d4p7bg4kfmwt9y9hOP1jSjyKbZo3kl1V0aY3heJEkTGlfYtws4zY1i/HFbtGuszEx Txpdkof/sqcqYiWE8Qxlkd+rXySpJpFM/oQvkVLbYd/YkFhSrZ/EMkpAZZyIG3X+L3zfV9DaXPtm jytwQJuX/FXIInUQPPwWWvldc//u2cSYsP7ipkf9G7RkM+ZXngUvx7rgIGS03u+ufaV21PcKAYWA QkAhoBBQCFwOAUU81bhQCNyqCAghKv9PWp9e87mkytpbvnOQsB2n+6PEs8kCvWmjLybTmk2LFC2T Uo6S+IiVzU3rkpCLGhJJIaj+eooY4ygunmJFk1lGzqI8dq/PXVUYhlg0z3zdl6TFmulrWOL2JHZO zlDsplVSa4MWR7GmBZI3P0nUZCc50NxlexiOkJd2kpVhJCTijilkrmwTLZhUbipJmBztItbLJhIx cacVQu2vW/QXoqjpTnJqJJmU0lVCuXi91C3HvdS93kMGSYhEv05iIs0fnOfLeCoXSuxoyx7f/YH1 S9IkSa4jbrDiXuovkiVYyvmfkNiwfjnTVHCTWM5j9/gIqlgKXWzzGMlQ3DLeTxLVRN2kHklq1MY+ FLIuZF8wO/UJ1sF+k3NV5bputiF1ttDd+DD7NprYCLmUfmzZRpnpxiv7BHLOqWAjbreCiWQGFmLa SUuv6Cmk9vSnfZsCYk2We+ro4nposW+MSJ9J8qFAV1R/n8m4qCN59rvHirVYjmkRUi+yyVmjR0hg xeIpZFss49JngpdsArTt7nGDptVWCLlYZ12Nvs2SC/GmF2G98DdtXNOieoykVjDqPHNxvAuup57q sZJLn/R0mF9/GYuHKZMkppK2RLfA8XiZ5tRXCgGFgEJAIaAQUAh8GAFFPNWoUAjcqgjI4lli1Zr5 EZLgJwryp2RsrSJBkKIRMpKSJpIPvwWrmtYlKTKDSD1tJCUt/PjraSSREaIm18t3Ti7Yq0hw/ff4 22okgfDy4y8Xrm+i9atXG4H9pMlOa2MzP4FF2jTKjxIgyCKWyzCSski6ktryfBbKTlpxu+lyK+di yqWBVjmRS0hxDV04/cV/jfzpIqGroaulv8j1/vslfrSJHym96/V/52qjXrSY9S7+65tJOJv48ePo IinyXy9Ya8SP5LOKhFuKH8e2Ul+b9iyfRU/cRYVo1e662Af+a6UO6V8/vv56/Hp0kmiJO7Jfpt59 K1a/Wloppcg9fhLWRFLo5UeKf1wE6ql1C0lr3cZLtZc6/G3Ln50kvO0vX6y/juTTX2c3dZJ+03Qh KZcx11uOS2v3/UvaFtxqSVAvd30D3aZl7PSWV+QRQhso8+V0u1yb6juFgEJAIaAQUAgoBC5BQBFP NSAUArcyAoGEs/ei+2qzQ+/fetcTSOb8C//L1df7Or8MQhSuNTtdSXYPGYRkmM34Z7oLi2Vvvi/m Uo4eqaAlVEjnldq9mqzX+u1qdfZVr77gdjlsNMLcQ67E4isupfKFn6z2HuNXw7c3rpfDOZi+DGZc ybW92wtsq7fcgVbVvjzHVxpT1+q7a43FvrStrlEIKAQUAgoBhcAtjoB6nd7iA0CprxC46RAQMtJR QvfJz1zq7unPbBosWRkqAIle4pp7aNFFia9FqIaKbkpOhYBCQCGgEFAIKASGPAKKeA75LlQKKAQU Ah9CwE8uA90nb1bC2Vt5v84qDlE9GAoBhYBCQCGgEFAI3EAIXBfiKesgvc7L5In8myz+esfS3ECA KFEUAgoBhYBCQCGgEFAIKASGEAJMcmbUe7i8VDtuQ6jXlKi3IAKDTjzl6DmDzoMOpwVbzozSCKgi nrfgSFMqKwQUAgoBhYBCQCGgEBgMBLiareuIgEnP5GeqKAQUAjcsAoNOPK0WI8wGN2raI/H5t3lY uCoKAYWAQkAhoBBQCCgEFAIKgRAiYDM5YDN0wuX2B/SHsHJVlUJAIRASBAaVeLZ3OdDW0Q2TyUDn By/CzXLgvCoKAYWAQkAhoBBQCCgEFAIKgdAiIJQzNy0+tJWq2hQCCoGQITBoxNNDH9uf/Gkd1u46 CavZCJ1yuw9Zp6mKFAIKAYWAQkAhoBBQCCgEfAh4uebsdrjwseVT8en75ihYFAIKgRsUgUEjnk6n G1v2n4Wbk4GZrFMmBVUUAgoBhYBCQCGgEFAIKAQUAqFCQOwaOq4zuxxOxEXbERtlD1XVqh6FgEIg xAgMGvEUOTUXW68HFns0IuLT4fG4Qyy+qk4hoBBQCCgEFAIKAYWAQuBWREAIp8ftQlPlGc3A0UWr pyoKAYXAjYvAoBJPzbuWE4HeaII5LFKbHFRRCCgEFAIKAYWAQkAhoBBQCAwUASGebpeD1ah4roFi qe5XCFwPBAaVeF5QgOTTS2unfFRRCCgEFAIKAYWAQkAhoBBQCAwYAQnl8qgstgPGUVWgELhOCFwf 4nmdlFHNKAQUAgoBhYBCQCGgEFAIKAQUAgoBhcCNh4AinjdenyiJFAIKgeuIgMvtZfw5k5/RU8tk 0IcsA7dk9na5GGqgB4ysV5UPI+Am7m7ir9friNGHXeUUhmrUKAQUAgoBhYBC4OZBQBHPm6cvlSYK gSGNgBz63e30QMiIv5hIRixmAwwkJvJbl+NSd31+DZvFCKP8hf/vdvAaZtTuXSwmPY91MkjI+SXF yTbDrSZEhpkgJKex1aFl4h5otJC0IzInxdu0w8wb2xxwujzopPxCsMIoc2CR67spt1zjF1HktRj1 ECeyji6XhkuYxQATvwvUo6PbxTbkN6OWXEPaCCxmXm9hojeBSOpoZ13ShtRjYxtS5N/+NuxWH56B UAk28ntA17A+HbH39U1fil9m/9Fa8u9wm1HDv5MJQVo7XZfgLm2KTpExJrTxt7Yup9amKgoBhYBC QCGgEFAIDE0EFPEcmv2mpFYI3DQICAERQpkQbcXE3Fgkxdg0q6ODJKy0pg1Hihs1MpmfGomxOTEa 0REyJcSkrrkbu0/VoqndoVkVh6dHYkx2jEachFj5y9GSRhzmRyya/iKkMzclAp9fMQIjM6I0wvbN P+zH8bJmErWBWSi7nC4sm5yOL901Eu/tPY+fvXEcw1IiMSk/DlWNnZrMkhRDaJTozyh4jM+NwYj0 KE3uLhLoPYV1KKlqQ5TdhAVT0xFBcrzjeI12v598CjmcPSoR6fF27GKdgs3k/PgL+guRPVnejMPE UEeVYsLNWDY1jfgZUFTZgkP83kA5jGzztkmpiObvW4/VoKGlG4YeC6TgbONZzEsmpMBOkigkViSu ae7CrpN1JIxOrT+uVVyMwxJdpW/EwilEe+WMdHxiyTC8Q4x++fapSyzODm405KeG4d8/PhFFxOHb fz6ojZPLWUav1bb6XSGgEFAIKAQUAgqBjx4BRTw/+j5QEigEblkEhDgJAVxMUvPYolykxoWhmSTS RdOaWOPE6vfXjcX47fuFmDUqAQ/Ny9GwqicxEmuYWNyEVP33q8dwrr4D88Yk4d7ZWdo1Da3dGrmT IoRl/9l6kh6fK60QIHHxXE5yKKTz/X0V/JzXyJTJKOcO+w4k14oYU3tIovzT/5t8J4RRSqAlTqyK UWFmrJyeoRHBrceqISRqbE40nr49XyPSO0/UaC64UrlYRB+en4O7Z2aim0RRrJqi253T0/Fj6nWs tAnLp6RhBOUU2f+2qVgjinJflN2ML6waibgICworWjA8LRKfvC3/AkZxkRaN4L29+xx+895ppMSG aURbiuD897/Zi5LqViSFheGJJXlIjLah8HyLRm5tBp81VKypCVFW/N3KkZo+cp8QX5Hx5Llm/M+b J1BMYujfDLhgKqWsgosQV8HsE0uHYRw3Bf68vgi7T9dpdRsIgmwYyIaA4C0uz0KQ5T4zCe4Z6iT6 Txker5HyvWfqeL1PLlUUAgoBhYBCQCGgEBhaCCjiObT6S0mrELipEOikm+jMkYn46r2jNNLx8zdO YN3BSo2MJpLsTCXhqCeBFJdbv5vn5qPVeOYvhxBPUvWtR8dhHK2gQlyf/eAM3VJ9RPD17WX439Un NeLqP1xcrHYXi1cjPPFRFu2rPSRC+0hqhDBKOx6eP+y34glpcpC8CdkSQiTkT0inyKjFbmoWy4vJ /B0uN2WKRR6tqcXVbbTWtWrXCYGTIq6xgUXIXGltG3717ilsOVpDmfX4h/vHYAotl6tmZGqyCXkV 4jmN372965zWtrgED0uN0EhnUWWrZtkckxWtVf3OnnP40UtHMW98Mv7loXEaGd9Oa6nIIFZQAUVI 67yxSSgi8RSdhJzL70Kcezu0ijet3NfOzxf/3y7qQOvwI+MwgRbqldMy8HOST7EYC2Z+11upR+QU y6l8N5ayFZA8JsVYNRl91l4fJoKZtG0W0s//ibVb6pI69xTWa8Rz8cQUbh7UXYL1TfUwKGUUAgoB hYBCQCFwkyOgiOdN3sFKPYXAjYqAEJNIEr0H5mZrFq//fecEXt5aosX8CRESq5v8W0ibWbOI+TQR YiKk5TwtnAeLGjE6KwaJPWTmwjWS2If1y0cMi4HumWIpjLCZ8U8PjcXoTB9R+/t7R+PeWZn41z8d EFaJhxfkYPH4FO0+kWP1rnKsP1gFBwnpI/xtzqgkEuQKjfDW0t33v187psUhyvW8hK6vYZoOJ8qa aCF0XnBb7d0XfhK7lYRTSJqQreYOB07T6ijEU9xghTzvP9OgkbARmVFIo1X4LImmMLAZIxK0Knee rNXa8Vt4BSA9Zdl3up4WzTbNEpqTHKFZRYU8l9CFOYmuzXfQkrp6dzmTIF2MLb3ceBHo/TGffky2 H6/ViGdmYjgibSaNGAvBzU0O14ijWE6FTAtJ/e5jE0iSI7Wqn759uGa5/i43D8QSLCUu0opvPDCW bsJxKCMJ/x0t3Gd4v8h6+lyL1vdC5GW8tNG1VyVrulGfaiWXQkAhoBBQCCgEroyAIp5qdCgEFAIf CQJiQRueFqVZ6eroOivkyk4CIwlnNNfVHkuikBNxF/UXE90zxcV2RGYk5tK1Vorcq5G4HludWCcl YZCQNmEtQoT8pFTiC51uNz7YX4Foxk9mkTjtIHHbS8uigQT3CytHaPWKlfFsRSvum5OFr94zWrME vrPnPO8xk8SF4+llw7W2hTRrbqYUWKyl4gabGmvTfqto6NBcYq9FlETOSKNJI8pjSKSF0LZ0OLHx SKXW7rm6do2Mjqd1V8jZ0bJGJEeHYUJerEbexArsI7E+lIRItvL+VLrWirxSqps6tT/FAimkXTB7 YG4WZo5IpKW1uk9jQDD0JSfy0i3ap2M1iblgKhsILSTNf95QpBFSIcVChMUN+m1aYB8m2RRXanGz lZhbcZeW+6TMGpmADYeqKFO9pvvf3TlCi+lspLW7sa2b13ZpumQm2DXXaoaoqqIQUAgoBBQCCgGF wBBDQBHPIdZhSlyFwM2EQEKkjxS104olhEYsZ5JMJjspXEsoJO6XL20p0eIa/Ta3GSQpL/3LAs19 U4jer989rZFEX8Idn13uDibjuW1ymkZDK0mMvkMSIwTJ7y4rZE3iHmeMiNeI5+YjVXiLVk25T0in xC7+96vHUUni2ERL4pfvHqkRIiFHkl1XSiktiZI0qJYESmQXAiruwkIi00mQNL34/bWKEEszkxn9 Iy1+4jbsd/HdeLgKB842aG7GQpx3nqjViGc+3WtFTYl5FDK2j2StsqGThPeig6zodBdjRheMS2bc plXT51BxA++N0sSRK9/fdw5LJ6XwugwcL2+64Ap8JXklVlPkXEhLsMi4glhJ/2w+WqW5Qz/z/CEt rlYI7ngST9lQyKelVbISi+vz/DHJGvHcRpffN3eW07LN7Lk9CYzEYvu9Fw5r7tMFGZGaS24GMaxl zK24AEv98XS9DuM96qz4a40o9btCQCGgEFAIKARuTAQU8bwx+0VJpRC4JRBo7SFmYvmSTzvjHyWZ kFg076Hrq7hnSkyg381TQDlZ3kJr5Xk8SAuaZGGVrKpCJIVU+l1NhbB9cKCiJ0OsmwTwUndXsQxq x4b0ZLkVshhB0uu34p2v6+DxHS4tk6xk1pWSEGVDJK2HfsupxKLuZfyhXKOd/8lr5DchilH8Toq4 mV7rCBAtAQ/J5xs7ykhsKxFFne4kqRPSKET6/1af0rL2Hi1ldl+SsJEkdFkk5qOyfSRyH2WQo0Yk U61fNsn+O4puxELeV5Ngi8tyW4fPFViKkMHSmnYt7lPItmQTFhLpT5Z0ucEnyZjsYUYtQZKQv1N0 gX1lWyl2Mpuu1CuW6vtpHRbSqCWGYvKhNrohC9biPu1vW34Ta3RgHKlYvCXZksStiqUXcRdjZkUW P9m0MeHQ1WS8JR4apaRCQCGgEFAIKASGKAKKeA7RjlNiKwSGOgJCNKqbujT3TMm+Ku6p+0kYt9B6 Ka61k4fFacTTn5THr29VY4fmzimk7p8Zp/kks6UeKmrQrH7+Igl93qQFU0iOEDvJwHotAigESXPN DSiBhFcSDIlcknVVipA8ybwaeESLfC8WTP95o3IsS2Adl+szaVesqNuZ6VaKkGghvt/52HjNuihu qs3FDpSRAMtRL5OGxTLGNBHTmHBH4j5Fd7+V1O9qu5akWwirkFFJZiTWyt5HxIjFeA3djZdMTOVR KakX3F6vNK6E2Iv77j89u0+LexX9pW5pUyyZzzw+QTsKR1x4O3guZ7Y3/BL26CeafnIc2I7IIv3j /2j49lyg/dlzs1h+eyc+GurPgZJfIaAQUAgoBBQCtwoCinjeKj2t9FQI3GAImHgshhCsdUzaI9ZN SehTQUJznvGMQi7ErVOKPw7QL74QoJhwC62NdVo2VzmLc0YB3W9p1fPTFSE3YkWURLJCuiRrqpDK y5EejdewQXHbFXmkiKuvxH+W17ZrZ4NKkXhNIV6S8Md/T29IhUyLlVGOdpHzRO0kvD7334t0SZII yZEkmpWXdYXT0iqxixLLKERciKsQZbHeCoEVd10hZkLyDvBIGCGed0xJRxoTGElMZBllDMyaKzJJ G5LsyGLyMqaTcadky4FxsnKNifhKJlxxMxbyKe30Jvm99RNNRA6pW/pHMBUZxaVWjmoR+T77Pzsw Njsav/j8DO3MzgvFH3/ao79YmK9FIgU6IcyRtLQKExWifSGB0g02npU4CgGFgEJAIaAQUAhcHQFF PNUIUQgoBD4SBIS/CfESwihET7K4/tfTU7DnVJ1GyibS4imlQ0tm40viI0Wse+K2KS6ZO3mtEM/l dBcV11o/wZvO2E3JVCuETMiNnOEpLqnavwPYjt8KKOdJCqE9xMQ1YkGUGMVvPjJeywgrZ2g2tjnw Ol1hhUT6CbHU1duaKfp0kxxV9BBYOerEd96nnFnpa1hcYCVZkUZ2STI3M6OtWG3l/M4jPLNS9FzI Y1CkvMezRYUM+9yI6VZLovnxxXka6ZSy62SdFv9poeVVmJkfIyv/LRjJJ1BfP4mX6/0uvquZMGke 4y/F9ViSGwVe7x8Ycq1Yj4VI+uv16yNaNbR2acRW3Gy/TUutZAuW+kQ2IeoOJnMq4lmfcszMKsae SmZeSdTk7y/pUz+WIrsUaVNIuJ1uunK+qJyxKjG3gRmKP5KBqxpVCCgEblgErrWZdcMKrgRTCNwi CCjieYt0tFJTIXAjImBiQhyx/n2fiWXkzM5lJHnTaL2UUsgYQrFqSpIdK61eFbQinmKSnMLzrSQl ckSKntlYqzCOlkUhPRJrebayRbtGiJU/463UVU3SsoskNTAbqhAsIUNiXZQYSgvJj1j9fswsrCun Z2hZWROi4jXSKrGMR0hKxcLnl0MS31xi0esBWAiUWG6ljKHlT+JQhbiK9VRkE3I4i66yUoRYiXux nDn60PwczOb3YuWT41LWM95zy5FqZssViyUJH8lxJTEQgi1Hi3TS1VhkEwIoiy3BRFxgpY1yktXe rsXyb9FPfhdLsRTRp/B8M57fWMTzVBNIIB3aRzLf+ovgJFZNySYrGXolG3EgORV346MlTUy0dAJ3 zcjQNhAkkZGcYSrWXBcDNIXYv8YEQ5I8Ko/JkSQbrxBPSUQk8pyjvKKH6C7Ze6U/ZcNB2hGLs2Am sbZCPgNluxHHtJJJIaAQUAgoBBQCCoHLI6CIpxoZCgGFwEeKgJCKTsYECtHaSLfPwCIWRiEtYgVb y2Q+7zMmUQiUkE4hkUJY/vH3ezWCIvVsPVaDTSRrvYuQGrHYXSRTOlrigGfXFPqOQOE/xKooRTKo /p7fP/vBGd/lPZ6yNhJUKZKRVUhU7zr9dUs9coalZNEdTguguNGKi+5RWjO/+us9H5JN2pbEPT9+ 5eglbqTiIiw6+cmtWCuFhP7irZMX6pB7/fGd0q7EbL6797xmZfRbZgPlKmHsq8jgJ+46Ia1eHV5k 5mD5SJHkSIFxq/J3IbQS2yl0VI6LCTweRrCXPtrIjL+ySaBB1uNerLXD6wX7BiYQ+tErxy6QVmlH khvJUTCCpfSxEFvJFCy3y3eyKTCz56xSIehC1HvH1H6kg1c1rhBQCNxQCFwrpv6GElYJoxC4BRFQ xPMW7HSlskLgRkPATyR7x2D6LWuymPDHRAYGBvqT0vj16f3vC3pewf9KCJPQ0UALnhAbr89z9eLt AfdfTo5APEUXIWrrSKQfXZCL+WOTmRSoyZc4J8CS6L9Hczmm5fdKugfWLWIEEq/ebrHXkk3cfoXw XVKnkHYh3T36Xs7V1k/s5b7LQSm/C9G9XAyt/3qxVAbG68o9Wr3aXy5KJJZdKRKXK8mlxPLcSCvs dm4q+ONrb7Txq+RRCCgEFAIKAYWAQuDaCCjieW2M1BUKAYXAdULgcqTnAkG7Auvpfc/V6uitxpWu 1XjQFcjq1X7z3yZWSDkntIqZdsV11R+jeTUY+yp3fzDqTTQ/hMNV9L2Afx+Cp66lw5VI7eXk8ydU +unrx3GeLsYNTL6krJ3X6UFUzSgEFAIKAYWAQmAQEFDEcxBAVVUqBBQCtzYC4h4ryY/kKBSxgAa6 +d7ayPRdeyHrNczy+xaPxVEY9h03daVCQCGgEFAIKARuVAQU8bxRe0bJpRBQCAxZBPxZbOXIEFX6 h4A/zlNh2D/81F0KgVsRgT44ZtyKsCidFQI3DALXh3jSv0qnNzCJhQr7vmF6XgmiEFAIKAQUAgoB hYBCYAgjIHHrOr3bp4G24/ch6tk9hNVToisEbjoEBp94clLwuJxwdLTwzLqeyeGmg1EppBBQCCgE FAIKAYWAQkAhcD0RkLhxj8ulsU673YQtOxhbX7qTGbLdiIuOgN7VOenb//qvf/3uM88oy8f17BjV lkLgCggMKvF0MSsh0ziiu70JXW2NqhMUAgoBhYBCQCGgEFAIKAQUAiFDwJfwjVmzrSY4DjWh5a0T cBo8aNXx6KcI65e/8IeTx3Enfh+yBlVFCgGFQL8RGDTiKckg8rOTUFheiy6zVTujzWpw8Rw6nxuE yW3Rzo9TRSGgEFAIKAQUAgoBhYBCQCHQXwTocAuXwQGDFYhx2dFl7ILD4oHNYzF2uRx3sF5FPPsL rrpPIRBCBAaNeBpIPP/lU8tw7/IJcFcdwLqDZVhfOwKxPCDco/fgeMp2dJva6SPhO7NNFYWAQkAh oBBQCCgEFAIKAYVAsAiIGaPb6kS5S4fT06xIbhyBMdsSucb0gjYOFecVLKDqeoXAICEwaMRT5I2E Gan1dhia7MiJtcCoS0V4p4u7Um7U5dWjy1YLuFXWx0HqW1WtQkAhoBBQCCgEFAIKgZsfAR1DOD06 NJOBVo9pQ3dRJsbuMgNd5Jwqs+XN3/9KwyGDwKASz1N7KvHjR1cj3G5D/JNhMEc74BGLJzefDA4D 4z9JOj2DKsKQ6QglqEJAIaAQUAgoBBQCCgGFwAAR8Fpg6qI33Ud8kgLdfz0unatzgNqo2xUCNxUC g8r6DCY97NEWhFn10DPd9Uc8B9xUHaeUUQgoBBQCCgGFgEJAIaAQ+OgR8Hp7JS3xerREu0a3Z/LR sSOLxpw4odx9P/puUhLcAAgMKvEM1E9SW7vc3p7UQjeA5koEhYBCQCGgEFAIKAQUAgqBmxIBvcMD o4PrTjPCB11B/aX5SjxuHvGi10XovbpfdZ5I+MedruizPHP0GMnoOeg9pR6dpQrezg6jzsVzRq1d XVaIZfRixs1G6Iyprs6ZTbvlrBhVFAI3DQKDTzzF7Z6mzqTYWKTYrXC0dPCA35sGP6WIQkAhoBBQ CCgEFAIKAYXAjYIA151if2waHYMmV1e3tdzxwmCLpvN6inUGyVkS4FnLta/eYIrkZyJ/m8jD7O/3 MtjMy4RHBvnTa2hyew2tOnibzZ36BlpNL7BXHQ9+0DVamnZ45+yK0Fl+NUa3rmawdVD1KwSuBwKD TjzlxF6H04O75s5GOh/C/ztzDHYeraKKQkAhoBBQCCgEFAIKAYWAQmAwEGgeFY0OfUvX239d8fJ3 n3lmMJq4UKdHp3vX1dX2DZJMvcftvPg9LZ+a9VMKzxrV/ugxbPLaaOj00bSEZuh45qislwOLXm+A 2WBa0d5WP3eLfdYDc7u3Nw+qEqpyhcB1QGDQiafoIA+T3WpFuMeh4jyvQ6eqJhQCCgGFgEJAIaAQ UAjcyghorrY6j+7O764NJ9frGkwsPjl6ybbnjqz9V53e8AxJpN4rMZ69S0+iEx7wov3iZbLNqxUJ CmV9MFrCl7o6O+ZAj7cHUwdVt0LgeiBwXYinKOL2MJct3QtUUQgoBBQCCoGPGAGPLGm46JHM4oNV tIUXd/h7dvl7Vlqy2uJf6VGm5+vnctcMljyqXoWAQkAhMEgInDjxjMfjmXOYLrfdnPNsHzJf9rNd IbDksTB6YJFpUxWFwFBH4LoRz6EOlJJfIaAQuB4IkKi4GAcuO8OmMF+D8m9PQH4FHacto1W2gq+H QBfbcHHDnF4bWhHCJjIEpksTEuVs98llsl9bNn+WfSP1lHrdzDGh3efPL0EM5Bqp1xRMbgzeJ3KI jAaRsfeGnxdRlgiYiGODo1Uija4t6zWv8NfRI7v0n3zkbD1ttcQPdTQbbUiyRPNoPQdqHfQaE900 YirXXMyrcc3m1AUKAYWAQuAGQmCHZ9ZIgxG/poXS5nH1vCeuKp9syl28QFxt5RM4X8u/jdZwdLXV F3k9pv03kLpKFIVAvxEYVOLpYRbb7k4XjAaGTou1U60r+t1R6kaFwC2BAAnmwuRpiCCpe6tqL7mL G8tT5yDXngRLj3XuVNt5vM3fNDIqVrPBLkKgPE5MSxiL2bEjtWlsf3MRNtYe6SFW/IYEKoyk6uGs pWgk6XutYkfPfHe5Sc9HyhYkT4WZ8q+p2oP8iExMjcnHq7yvSwioWAVZ59KUmYi3ROLF89vg1iyF 15hEeY/ZYMZ92ctxqv089jcW8pbAmHohs934wfjPYmp0PpZu/zYau5sGbvmUvhCc2LbIbTVY8L1R j6Gadf/o9Cv8qhs5EWn4zYQvYExkJo62lOGJ/T/DV4etwvnOevzkzOs9GwnqJTHYw1nVrxBQCAwC Ai6sNIaHJzs7Wy6pnPGbmrusfC5lmv7L5P3hhdvR1enRuTt0/gRDciPQ6u1oPuJ1634407y5ZBCk VlUqBK47AoO6arNFmJE5Og4Ggx4mG3ffOy4GXF93TVWDCgGFwA2OgBA8B76UuwI59kSsrt5HwuLB t0c8jOkkZcdJVqLNdkTT+ven8k344qFfwekl4ZFdYi12psfqpr2vAwjM1X6Tey4cMNzLLVRDi1kJ STqfokw/HP0EOmmpc1LGCKMd/3DsOfy+6E1aPmmldHdpJPF3E7+ADl4zrOEUKjuZhPByrqwkZgZa G7838mM43lqONeUbcXfqdHwmaxneqNylkdwIWj7/ZcSj+Eb+PTjXVY/XK3ahk99fSiIv051CgEn6 /nfcp/HL0vexv/44yWCPNVFza/XpK9dEkCj7k1z4agrA4hIM/dbLQJx7sNIsmy78K3UJZ33/eOwP mvw2WlSlzw41l/rw5TVfyr0Tk6PzsHLX99DS1aRZOoXI7yRWF62j0m9Xk0O61kf0P+TGe4OPbiWe QkAhcJ0R6HkVdFlsHnA/bzALX0PjvYGeOTJDCeGUpEFuZxsz1tZ7Pe4azl2FXp2u3KA3nONUV+vS earhNUqa22bOkw6nzqi9vPhf/mnseOc7C4u/+93vhsItZTDVV3UrBPqMwKASz+HTU/DMBw/2LCp0 6NymEnL1uWfUhQqBWxIBHVrpXtrspHttTxFL37Nl6/DJvf+tEY6vk4j+iCRwQ90R/K10TQ+5k11l E/mLHNot3hU9xJMkUIjphd/k30IGxQooFkTNaio70UKqxMrIewPJIrMTJoYl4jsjHsHm+mN4YOf3 NbK7MnWW5i4KHevSYnDMeCxjPk60nuOCwYC7Uqbhl4WvXp54Mr7SaGKyNRK1g83FlMFDMm3HsdZS tDvbNIvln6Z8HRm2BLxbvR9ZYQlBOcNK4opG1tMhllONgFMnybLo33EnMRQC7bOg9hTNYknsxGIp RUiu3BtoUZb6BDeN6Mv1Qj6NWgtiPY3hhoCRv7l5T6OjHXM2/5OvbQ1/CzcTknGqrQJbhQxL/9KV euamf/C1529HW7gF9IHm2twTD6pd6NdFXl293HtvyedFKa0QUAhcDYHrxtj0wjAvtqZZOHVo93ic P/HojO8aYToxzbCu8RJZ/fujvf8MuGjmd7+rOlghcFMhMKjE8wJSjcew/VQ5Vp9IRphZHaVyU40g pYxC4Dog4M8CKITnlYrt+G6PFfRvRasxOmYEfj7uacSbIzUX3e+dfhm/K3pX2BNGROXhf8Z9ComW KLrqGvF7Etj/LnwNLhIaI0nTZ4fdrVnimLIe5R21+MLh3+BQ42kSsItJd8wklTaS0eL2aji7uW4g SXzr3CYfCZMYSlo7cyOzMS9uFP7u8K9xF12Fn8hchOfYluY2G+jqyn+PjynAf5I4F4Sn4Et5d2Jl 0mSMicqGnXV9Z9Tj+CEJ6/PntuC9im14Ou8ufDH3jkvy8wQHt4+oLaVM/8G6E4jDGxU7kWyJoeW2 h3iS7EVao/GDUZ/A/PjRPPNcj+0NJ/FPx/+EWhLFxakz8ZXclfhD+Xp8OW8lcsOSsLb2EL506Ndo p+7/Q/fZefGjNOvpwQU/wQf87f87/mf8esLncbClGD8m3r+e9EUsih9LS68exxb9D54tXYefsu/+ MvWrtHiexk9Ov6QR1BjGf/54zCcxjdZSIfDr6g7hX47/BU0dNViVsQBPZCzEa5W78e8jH8GR1jI8 vOe/SNZJYjVSrYpCQCGgECACsifGqS9xSxVM3c5wd/u5b+IufG0wsaGL7CUcV4gnYz1bPXrj72bq lJvsYGKv6h5aCFwf4umox9mSUzhWG410un3xVKOhhZKSViGgEPjIEBBCo5EkSbRDwhhnjmBspAFF JCNWcxSenfhFnKc76q9IZJJtiTjJGFCxXqbaU/Dq9G9orpw/L3wZGfY0fIeERTaXf3j0OTxd8KBG Sn9Vsganms9iIt0+VyZPwaGGE7yih3iSrFZ3VOO9moMaSRQr4i/YTiVJqI9QiluoB/PjRmvWvrfp HmygtfUPaV8mmczBXokDNQaQIl7T6mxFKWXv9hTgrco9qCOZLYjIwNbmEzjZVIxOxmC+SJInSZXC SUb7u2OvLYNIOickjMP/3951wFdVZO/zWpJHGh0p0lQQGyg27K7Y1l6QdVnrquuqf1fXvhbAtbv2 srp2xcrqWrFh7wqCCgSQ3pFAAunJK//vu+9OvHnc+96LJCGQM/yGd3PvzJmZb26Zb86ZMy/tdpl8 A0L9HNq6B/6mRnZS6VyJWM59/Fh7eaH0CneU62Y8jfoH5O/bHG/hevQXo0G6s+QI4LJHxwEwcf5I Jv4CYjngRDgmKpeLpz4ozy36SHYBwc+BtvSOOa/JXGh9qQwd2mErTPeDeEO7+gzS7FzY3zKTZppv QWxD6MOhyLeyGpYwqGcoCybUQy+2yrsW/ZONSYSrBoyQh7Ae9eSvb7A0xMf12FMGA1eaWs+vWJ7A xuk1d6PdpVqwIqAItDYEskprJacm7q8IxPttpLpxc86CdEvzN1LdtFhFYKMg0EzEMy6xmnWycsUq KV5XJfHls2X+vMUSK+8nPgxuRDLx+LVR8NBCFQFFoJUhQNPWrUEiD4Z5ay60jdeAMC6pWiOvLP1c 2uUUWqaoE36ZJC/Nm5Awl4Xmk2TqTDj62QIatHFLPpVl5StlNsji8T2HyYk99pbHFrwvZ/YejnWk k+TcSbcnTFFBaPNAfhLeau0AOTUwOz1n6v2yBoTxUmhI/9rvcLl77uvQ5L0iFSTD0Jz+odc+IKdT pAoE+J2VU2AuXC2Hd91FJsEcOGESattSgVTNg8Of++a/JXt12lYunf4E1r7/IiN67idPgZz9l052 8npAk5ptm7tuSGck1r2e3HNfSzP5x8l3yhoQW5n7huTvc4P0gwlxFYj0ntBEHglieU3RszJt7QLk iFsE+jrg3A+OgKqs/Zdjcsm0J+QZ1g949Ap3trSjYWD22YpvZXa/30tHYPf0fPQBNKjZOR0tU+Q6 24T3UzhQmgPNbR+U+fiCd0CqqyUXMmjyS3w5oXAQ8DoIdblo2uNY+7pIYmDO762aKucB7y2ACeXx 3HUzn5fnWA9gKVjz2+LejTekSzSvIqAItBgCcTi2jAVo7t/cKzxbrElakCKwySPQbMQz+stP8vYL /5MJ3ywUf22xzFm6TGq3aSf+XY7C+h4lnpv8naMNUARaCIFKuKY/uOtgaLoS5qifYK3l6VPulWXQ RAZhAvvg/Lfl6oEjZHiXIfCg+l846PkaRCYqA2DKSic6/xn8V4v4xfCvAFuXfIb87eH8pme4kzxJ zSI1l3BZT81lubUdSpLZJsoox5rJC1Dm01hTehZI1lis+aS56nnwzLoDTGeHIf7tp8ckB2lrQeZY xnHQKt4066XEWkrLIU6CCJ6I/Gf1PcQibw8POd86PxAeX8/sfZDMwjrPn+iQpwm89Sa0gQF4ke0j M8uWWt52JaeDtW3Lkupii7BH0eatgVMOyvsbNLrng+QxH73tLoTpMQlnEF4v1kH7+lUJnACRlMdD loZ578C2kgstZBU0nUxP09gAJgai3HYmOSBfCGloahtGmqoGm6sntMbsL8q5EtrWy0DwSYBzQC4X oJ9pxUb5XLv6UfE0VBD9ReKpQRFQBBQBRUARUAQ2GQSaiXjCi+2W+8jpf99VTqqJSgxrncZ9MU2e XjEMYx6ux9lk8NGKKgKKwEZGIB+OeF5Y+pn8DV5s4cZHSqFljEODx/WVEWjUxsK77BcgelfA/HMc nPLcAvJ5Y9Ez0hFmnVOhwTvu25slAm2ZD6SG2rUarAnsDNIXpJv7TGygjBMekNhv4RjnWxAfmn2e 1GtvuQKmqYeCFOeBWFFDeBG833IhATV77UDI9ug4UL6EJlSQ3oSu2B5lR5DBUjjgKYC2tGdeN6lF vSIopzCUbxPUpgKd9M1prEsC3FB2Ici4pRH97k75uWwBuGq2ZYJLDWM1tLysK3EiqU5obn0WCaT2 0cjm9cTfvz3QDHcNMDnhu1tlcfly1CML/RuVamBTXbtOsrsOSarHby9LcyoCioAioAgoAopAyyNA 4jmvuYr1h3Jq8kKyTvq1l7xpeR0CxdldfLURTrk3V5EqVxFQBDYzBEhqSIJWV8OxDz2q0pEMTVFB c9pBe8YwEZNbExd9KPfveY38beuj5JY5/5Mp8Bj7F2gW60Doiuk9lh5bQZ78IInl0OBVQPN3WLdd 5AE6tqFsEMJCmI6upWawnpBigQ7IINcjrq5YkfCCC9PfNSBCNBPtArPeI7rtZnnYvfvnl7F1FDWC Uax3zJGHhvxV/tRr/wTxtLy7JjzMPjjrRWw1MsjyfnHaJ5fKUQNOsLZWoSlsOetBkkqHOXYZ1EpW 1ZZZmkohMc1wTaNl3Iu81KCe0nt/i4ivrpgL69QtZHvsG8pAR0IzoA3NgddZOmD6cglwskgycuPv xLYl6QMpJ7WVMWgkuU8oHTBlHugJBE6HYF7bHp5uOwTzrH1SG9ZjQyht5jXRlIqAIqAIKAKKgCLQ fAiQeA5oLvHXHPj8NlKTdWwMg7XCVfJkx7PqTg7mFtxZh/VZGhQBRUARcEOATmpoImsCj62/aX5K 4snIAOJHr7V37HCGvI51hjST3R+eZT9fPRPmnlXwwvqRnAPi+cpuV8g4kFJq8XaHBnIuCOTt8Nj6 6ML3Qfj+JI/vfgWcC82TwR23ldlly2QMNKj16zxBoo7A+ssbtxslLy39QlZVFUt/OAKi3LEgkN3g DfbALjvISHhXfR3kVwIgbSRreOeN7LWvnNRzbyvdSqzjtIgvTUaz2ssgmNZ+Te+5IME7QaNIK1wS WRJjktwR/Q6T7iBhh4MY94F29moQ0yUo+2WYEZeTlBoMXAAkUadJcjY1lJD7X3gBvhhknA6G3kYb 9sd6zm3ze1nyiOsXWEf5+ZoZ8sDgc6Q/9k9dhT02t8H17jDLPXvKg+C5PkujS5KaCHFLdi7yWhpj tHc69iO9Fo6A/jX4PJkEx0Gvg2zTTNaqg60HDSf1K4kxZVhpEN/DutLv4eTpEZgf313QS0pqymW7 wj6Wp+IL4MQIO+LZ9TB7D+jzowgoAoqAIqAIKAKbEgLB66+/vtnUj6uX9Ni+a2HhzVxdVTVPJsRy /GWq7NyUbg+tqyLQwgiA3MyEV9SE1pHBZ2ku6QX2Vy2kfQlkZToI42sgnWf3OcRar8h1iHQ+w7WN c9YtlMO+ul5u2u5PcsFWR1umrLOxPci78FBLEnj77JfhHKhaLoB57H6dd5AfUc6L2MKkwdYcIE/v /DJZtsH6wxEgkVnYt5NrNi/88VF5aO5rMgrlcn/Pj1dz3SE0hGYPUGgnH1s4UXqDNPaAox16xjWk LQCyNQued39Yt8Aqi95hvymdLVFre5MEqRuJsgaB4NbA6dEMkLrTsT3LIhDFD6BZLaf205N4+qx2 fgt5i6pWWcR2Mrz0njzpDmtd6jlYO8ntaF7Flir7WVun+Kw1qSO+uz1xve+h0AbXSFm0Uu6b+xYI dA325CyXL0AmiVVC2xqQ+WjPpNI5Vlls88ML3sX2MD2A0V4WUX1lxSSZjOtz4Hk2sWbWJ9PXLZZi 1J0muZQTxS89686rhCYZ/VEGM9tjYBZ9w7aj5Ny+h1tEnA6d7oQjJxL5X6AB5jYv1v6pmZhIt/Ct q8UpAoqAIqAIKAKKQGoEmmmNZ6LQcH4QQ4RKDDSiEqajyFhMN1vTO1IRUAQ8EACpAQG5Dt5VE6ap eF2AmJ35/d0JopG8VyM9zoJs3o01nXfTyynT0BTWMsdNvNqmgKgc/sW1vzoMsq6znByY4EbkHnim vQfbeySc/9hmpYY8UoDfD+JVJtdDQ3p90XO/OgmyCdc47Oc5jppOq8xf9/6kKfAbIHdv0NGRtd+n rcHFMdeZngKzWqu+OZ3k33COxD1HrXQgtuUgeMd8fWMCAwabqFnpk8tJRhIYMf/RX91gt5MOeOLy P+wL+j9oO612kuDi9zE4SrLKhGnt6uo1cJ50v40x2sL2MaLen4BU7//plYlrtkOfB+e9JQ9iWxnT tpUgxaO+uy3RJpYBufVttL0EXzbtsURtrX7NsrzlnvTdLYk8Nj4r4NDorMl32f3HPqFpM3BAHSeA zE5Y/o1dj2b9dOkTqggoAoqAIqAIKALNgIB+vZsBVBWpCCgCG4CARQKd5pQ0r/WQRyJmmbBaDA3H xgGOnd42b00kIMEx121ii32F6/NaZNWlIIs4OtKZdaZWWluO27pLkNaEJ1u34GiTJSbZ45qjHvWy G2Fiapkkm3IThN541U1gkKh6fTAmsbbn3QQ5NJ+HBJFsgE1yH1lp6Z3WrGWl5KR+Y53WgyMpzXr1 gFy/3RDrJ6keG3CbaVZFQBHYvBHw18YkUBsXX5avMYvON29QtHWKwEZGQInnRu4ALV4RUASSESDR cZxL60zHpPcgZlZ+T+ZqX0pH6rzKSKprg6bY2j+3Dm7QJhcZKeucwR3jhlmyzPWanGl9Wb5bu5Py r1cHr3a69b9bf6TCOgNMNIkioAi0DQQ4B4bXxeqhnWHgUVmVO6f24bbRcG2lItD6EVDi2fr7SGuo CCgCioAioAgoAoqAItAIBMr750ulP177+h3DPrjovvsakVOTKgKKQHMhoMSzuZBVuYqAIqAIKAKK gCKgCCgCGwUBmtoGfTHf3vdOzoWRRtVGqYQWqggoAg0QUOKpN4QioAgoAoqAIqAIKAKKgCKgCCgC ikCzIqDEs1nhVeGKgCKgCCgCioAioAgoAoqAIqAIKALNSjzhjD+UHWhnbaeCEICTw7ju46k3nSKg CCgCioAioAgoAoqAIqAIKAJtC4FmJZ6haGxFTaDq0xj2zgsHZZ0/Eg8Z55JxH/ets2Pbwlxbqwgo AoqAIqAIKAKKgCLQHAhgbBm3trryJXaqKghHpbQ5ClKZioAi0FgEmpV4FpyAXctlyf6mUv7KSL7Y uykFo1kSiGJT9VizVqGxeGh6RUARUAQUAUVAEVAEFIFNFQEQz0A8IL5IlDv/+grnVoWlk5Rsqs3R eisCmxMCLcz6/DC39YkPGyztNfc47LMEjWeDjeI3J2i1LYqAIqAIKAKKgCKgCCgCLYqAPy7Buizp +MUCya0I5dXWrRsjx8g5LVoHLUwRUARcEWhZ4un3L4/H45Kd215yoh1QoXSbtmuvKQKKgCKgCCgC ioAioAgoApkhYOkz/NhKpXq1hCr9vrog9J0aFAFFoFUg0KLEs7IiMj4WW10YysrpFa+taRUAaCUU AUVAEVAEFAFFQBFQBDYPBGJY14ntO32+mrozfcFwIVpVt3m0TFuhCGz6CLQo8Qz2iNRKSdAHU9s+ MR9XfMPUVoMioAgoAoqAIqAIKAKKgCLQBAj44FeISzxLBxYGw/MhsKIJhKoIRUARaBIEWpR4hkuy /hTMLbiD5rYhXzsY2tIeAm8IDYqAIqAIKAKKgCKgCCgCisAGIQBPtvAfEvHXSclOASmoqJSsImtL Pw2KgCLQChBoUeIJjtnD7w9JdXmxFIeLJeqPqHOhVnATaBUUAUVAEVAEFAFFQBHY5BEA6eSuCQXV nSWeHZB4UH2JbPJ9qg3YrBBoVuK57uVeO4ZChX+Ox7GP54yVt9Vd51+bFcP+SngPfNPvTakC+dTt VDar+0kbowgoAoqAIqAIKAKKwMZBwF8r+eW9ZPjMUyRGgzo1qts4/aClKgIeCDQr8awT/3aFwfy/ xeI0c1jydCTHVy22xYOfu/rGsMMSowZFQBFQBBQBRUARUAQUAUVggxDArn0cX2poMQRGjx6djcJq x44d22I0H2XmoLzqFmukFtRkCDQr8QwEpKYysg6zTlEJSygC79YOmwcemthk7VFBioAioAgoAoqA IqAIKAJtEgG3caVuGN9ctwII4N8h+xjEmTi+FGSwLFVZSDMA10chrkR8Jl36ZFnIn4VzNyHujuOJ +L0BMtRTaXN1cDPIbVbi2Qz1VZGKgCKgCCgCioAioAgoAopAGgTiEvSDp8T9OQpVsyGwJyTvh9gb kThbxBOkkPwi7EIsL8b5c+3aLMPvq42sWQjpD0IcgkiNpy7ibSSAGzu5Es+N3QNaviKgCHggYKx2 zHeFPvIdSa3TG+Ob46iHVx3guTtRtUzq52ynLdvnyEdZJjjPu6GWslzIjFRheQO2tAvlomrNZI5G +QxwJFcfIhgfxGoTZQZRtrX8gmn0E6SPvyKgCDQHAj7J9odlTZe1d3bxydPNUYLKtBCotHEg4bQ+ ViCd3fHzAmI+ju8G+XTivw7n8TGQNYhLfgOGLKPczqcb5fwGADd2Fv3qb+we0PIVAUXAHYG4bT3j s9eBx2yyQvJFggVHZcJjJ8FpbixJqixyZ5M21sGP+vn4KrUJIuttRRIr1j0N+WS7KM9ql7EYQj4e szyrLHvrKXrLCJDQeci0CJ0tKxkLEL8DthgqA/N6yXNLPpWyOny7Dba/FTcLD9QzwCU+hCAmPXO3 QA18srjyl0SbYhHZu+sQGd5lsKyqXSdPLvpQCkPtJIB2Lalc1XwE+Le2SfMpAorAZoFAAO/lX/qF vt1q1JIfNosGbTqNoOaTWlCGgUnVvg5/v464GoR05qbTJK1pUyGgxLOpkFQ5ioAi0DQIkNiBQN01 +ByJgshc+uNj4G8heWToRbJ7+20k4PdLDsjmp6tnyJiZL8iCssW/Ep+mqYGLFBKoGuka7iJjBv5B Du462NqH+O1fvpexM1+U4mpM3lJ7F62T7dtvJU8P/ZtMKZ0nZ025j2zMnVyhjX7kuXvwubK4qlhu Lxonp/Q/Ug7vuouc+v1dmK3PkjPw96m9D5T20FCuqC6xyvpgxbfQGiZZjgGnEDB6ete/y7clP8td P7+SIMNODSmI50k995HTtjxQ3l75vZTVrt0w4okyt8ztLu1AOn+uWCYxtD0cDMsru18hVZFaOfjL 66SurkIO2mJ3GY9zcyuWy4KKlfL+L1NlHPqytK5SjvhqrERIXJtL+9ps94MKVgQUgdaOQBzv3qzK GDeNbxMB2sWd0NATET8DqXsffx+H44Ptxr+CcxNxjrOhPH8IIrWUb+D8xwYgXO+K49MRuZZyHK4t 4DWc54zn2Yjd7DyTXECtQbrtcP48x7W9cY5kczZkUQtKk9zdEEtxfjHOVeB3a/z9J8TJ+PsN/H0A jo9HJEf5DJF1r3Epb71Tdt79caEP4jzED5D3q0zyapqWQUCJZ8vgrKUoAopAoxCIy44FfUBKqMGL W+OGvTpuK+UwFX1uwYdSkJUvZ/Q+SCbsea0M/+IaWVa9GinwPY3CpNNoDamFM6acJLP11yAtgG+q 08yTmrsorX8QqAUMUoPnGK1Aa1cIE9Hnhv7dqtd98yZA8VknJ/bcV47tvoc8Oud/kJdnaShP3fIA 2aWwv/QOd5bb52wps9bi22c0gvUYJDSBWYGwHNJ1Z7l/3lsiIGk7QXbHrDyJ1KyTw3v/Ts7ue7C8 svxrqYWp6skgjP/d/XIQutEyaXVRog31gRj5ZLf2W8uaWmgyjcktsYjie21pT2ulAnJW15bB4ZvD F4Oz7cTEkgutKbbBsvKy7iCVlnmshQ1JL/BEHS8HaWaZe358Ccx4K6UOae+e+wa0qVVSh/Yx/xFb 7GaVu/snl0u8uliy221h4be6rqwh6ST+9Wa6rIfdB5RDM13WK4L6kExbdWgjo8lGPTeaWBFQBNow AnTycy3i5yBgJ+D3Lw4szqbzH/xN5z5OYng+zp8NcvaMnXZ3/N5qH/+M3wX2cT5+/4UYRixETCae /KjgZS1nIJ7vKJckkHEFIokniTGdA9FE93vEHxF/hzgacZpNHOmwyIS/4uBJnD8fdTRmvY7LiUN6 ucXPzYgXJV28BtduwTlkbzmvu+tVUE/UI6DEU28GRUARaJUIVIGIJIhnIkRgkvrOL1PkrhnjLNI2 de0CeXWPq+T30Kg9Sg0ftIJ7gcR1ySqQOuT7HoRvRRWXkdDsNS7DYO7ZNbtQKPeLNTOlAmafQscT IEcdw51AoLaREExjl0OzOLlkdkNtIEhmn/ytZJ9Og+QfRc/KnT/821qreO/8dyyTUQm2s0hT53Zd 5UgQrYcXvCt7dhgof4CGcWwpv920u3Wu24xa5HmPjttJHkhUQSgsQ7oMkUH5vSxSuGVBb/ls1U+y /+prpBSaQq7N/K50gby/9xj5XZedZFLxNNc+q0Bbagx5s4niMMjtlJ0vM0rnSCWJpDOAEPbI6y67 gjyyfrOhuZy5dj6O/dIxp70Myusp3wCLnYBN95yOsqhqlfxEbEACd4fWd2toPEmUR/TaT5ZDa/sV 2vr1mlk2ofTJHuiPwQV90fq4jOy1t8xet1i+X7dQviqZJbUklPWdWy290fYhIOzEakbZEpmDdDRV 7hruKFvBfJca5L3QhxGYN3+J/oswf7o1r63yztZKKQKKgCLQLAiYD+bekL4P4teIpYjDETnev9su 9Rv7PJ30cIZvLMjZ6yBmMINpMKP36wc4kZEfEBLP5PO8xg8c4xeILH+YXRY/KHMRjbmz+RBSlnFg YGZCqS3dAZGEdAYitbXUsJ6OOAFxvC3T+WNknImTFyGSnJKAsh4k3yTBJLWfI9ILroaNjEDzEs+o LyuMQQm3U/HJykDMj5vM7XbdyCBo8YqAItD6ESB5CVPrBcJGkjenYoVFTDvjbx8IyLXbniwXb3WU LKtaLVvkdJDLZjwtj0P7RpJ0/XanyAX9fm9pRntAEzkFpPSMyffIIpCbHTptK0/B9HOXwq2kHOaf tSB+5/74kIxfiG8UTEcTwQctXoVFWveB5vU/+b2lvGatlNHElnWiWStI3B64tiVI7M0gwtcMOBFk ax+5Y+7rUm6RXIezHWhf9+o2VB7f+f9A6DrIeX0PlzN7Hyw9cVyNtl201bFyCcktNYwg0sy7um6d ReAy0vShDTTjvXH7U+XvWx0N7WOdzAMxzAJJZhusLzW0h3t120UeQR1oLkvCmw1z3X/MeFaeRp2H FAyRl3a7TD5ZPd0i0d1A2qlxHjX5Lnlr6RdyQq/9Za8OA0DWg3LTdn+Sz4qny+R18+UZYEnyPuLr G2UktL+7ddhasliXbf8k45Z8LFPWLZIXd70E5rkr5GSk4djjwG67ykNDzpMg6udHZH9eMu0JeRkE fliPYfLI4PPkY9TjSKSbV7lChn85RlZUYA2ptd5VgyKgCCgCioD1MjUfLJFHcfh/3OsSpPIlHI+w rznPYxbX2tqkF2JPRBJPhze79TA119zSkFDmorxXUR61oVgDY4XHce4GhyTj1c4pwxzzGsyH5Ezk oSnuETh+DZHmwUcikng2YBHcSsXWdhot6VOO8j7CNXrdHWrnV+LZCh6TZiWe0VB0flW07MUYNBXQ B6wO1sazrNtHgyKgCCgCjUSAXzVLm2c5xQlCs7irpW38CISnV34fkLWj5MKfHpVxICsF0M5ZGjGE E3rsIxf0/70c/tU/5RusyewK7dnn+90mVw48US6cfK+M2faPsmVOZxn84YWyBGRoLzjBsYLlGMgO IJcLypbK2FkvyZ07nC5fH3Cn3AVy9t+ln8taEFCwPMt096juu8lMaOsWli2Sl2EieybMgWl2+ynK bRBgYvvhyklyxYynsGb0ZPn91/+UEhDbj/f+p9w/fwLMid91rOPkmtcYTHKHWGteP1wFy6R0ToGA 08EgbFduc7xF4J6a96bs0XlHeWLoxVIB0kttYz6I5AOD/yqfYa3sud/fY5Vx5aBRaN8ZMnHVFFkH kklt5lYwjT3+mxtlHrB5dc9r5LptR8q7KyfLNdMexfV82amwjxz51Q0WDnUgjDSxpcaZ8q746RHp FMqXPTsOBFm8TpZXrgRUWVb5NZZpbUQ6tesm/wbpfA1rVy//4WELppt3Okvu2fHP8sGqH2QdzHa7 oK69cjrJ4I8utEyF19FLbqBZP1+NvDs1uSKgCLRGBGJZ/lqxHW23xvo1U51IIOlNltuNMMAxgEU8 uabzLsf5qfibxJOf1w5NUBdDIDHkrw/ONSHpiuBHm/UutRN+it/piFy72g8kksTUsU6kXhzXc9KT LsNWSHc1fjkryY94R/v8IK5vhWxVf6XrhWa+3qxf7k5HL/kO9f+D1QZYnvurY3kCT/oaFAFFQBFo LAKVICqjoGXbLreHdAUJGVLY1yJ/363+SbqFu8oarBnk+spvYIY5G2aZxuPtcT32tKZw6VTn1C33 twhpZ5ChQflbSh/I2LvjILkTmtEfV8N8Feazby6DhQ7NZ/20QPp1AjlOR0Czxss0aEmvHnCCPDrk fGsN5tnf3w/z01lSmNNFjug6VG6YjcllaPzeWzkF2rmVclyPPeRTELUG5rYgaD6IpqaR5q9c75gP MpoPDevKmlI43sH4gNuOMIB4DeiwjVw3cCTWT76VMLNtsL6zIZKJGsflUBDVWeVLLbPfCpD1CYs/ kqdx7mSYxdZgzeSO0FZuC/NWaifvBwFlvr4g5Z1AJvvBhLYaDoIs7etPj8k3cEZEc+VXln0t5/c/ 3MJ/2dq51kQAyXApSHMdCK0P9XdOY9ehz5gmhn9ME8Fa0QCIJ9NY6VCPvTpvJ/1gojwwr4fcD0zj SLst1rr2RBm9cZ7lViLd5dOfkp9L5iS00Jl4C27sDabpFQFFYLNCgBYiuWsjW8Te6NfJP3I+HQG0 lcDXq3O/LKem0qn+cVMFeS2eT6UJTca1qRbg0/HCSls4yazXHmBb4poxf6H5MCPTss40vSURx5qV lNrctnJvbPR2NivxdGldY27cjQ6OVkARUARaDwJczkcnNWuhiSvDuseExpEO7/xYX7hKzp3yoNy8 /Wkya/i/5Sls2XHFtCdB4mB2m91eypCH5p78GsZB9l4EufwKppv0jhsEiaFXVgnAN4HlcMi8FpNe VySjIHwTl30lE0EkD8NazvG7XS53QDN3yKdXytHQdvaCme0W0LaOgDfaGAgWtYaHwUvtVSBz1XRu RE0lzWDxe/tO58gpIMNh1OeLfW5BXYLSA3lv2+40y4PtF9RsQnPYE4Tsld2ulCKQyBtnPmdv3+L1 /TX95bOIG8u3WkESTae7KJsxhrM0naVpax2cCOVYjpgCsgKkl7guAr69wt2gmayzyKfl6MfOSwxD bIcxiwWqNLetc9PCJqVxeq+16gVS2Q39Q8dI9G6bYzl9Csh8bMVyGxw2rYB5cPfCDlY91lDTnewU qvXcnloTRUARaFUIxPHOrZA+c6I3V0Rqh2CBximtqnrNXxnnR8JJBL3Omxpx7SW1giSlWOdRH2zv e42ueGM0jKynU6NJh0FGk1kKbWXE9q6bXIlinKC2lOSTDpD+g8h1MuYjTpkraZbb6NprhiZHoKWJ Z5M3QAUqAopA20AgDPJED6/Xfn9vYr0kSYjxXAtiMnHJJ3AaNEOOgrOhe0Dq2sFpz0nf0HmeSBHM X8/iseVwB689OAvC/h8yEM5vskGaumfDysh4TqUHVwbLq6pjyQwd89B8lx5vQZLewRrQ57sPk4O7 DbZMew+BE59yEOPjQEiP7w4tK8pqB+3c1tAiHopyXoPGkQ6QqInlTPzjC96TYVgTugwk896Zz8vB cERED7n/gPOkn1Ff1rUd1neO3/0qiflicvSX/5RSpBU4Ikof4taemXRWZK0LZbuBEU2TuccmQwyk jw6bri16Xn5c/iXkwiuv5f2WbQzDoU8vixBazpPs4LfqTlQSuPAaiWzCtPa3zSvGka8W5Pey6U/K vF/gfwJ7fNbXA8dZHQZZ9bDIrgZFQBFQBBqBAN4doXjcl7T/VCMEtL2kcEggVYj4IFgOgh63yd7f cOwkoqmQIQmkppFaSq4fzTTwJX8Wyvve9mC7P/7e1s4Mb3NWcJt15bYpmJm0yGZv5OXfGlopAko8 W2nHaLUUAUWgIQK/OhdKONup92gKwjgQnlPpYfUtaEBfgmnpMSCEu7TvZ5GhN1Z8J3dg3eIBPfeW j3FMrWb/vG0kFzLmw1HNAmhLz+t3uLyw+GNrP84h8FxLT7Ofw6tsQgMKQgUyti/MVPthPeLzSz6T ukiF9GzfH1u8DIQ56zJL03kw1obe8vPLctOMZzDUoZdbbMGSVShFB92PbVf2kteW0akeJ1zhZQ1k bSpMgrmX5XSsB/1g8SeyU+cdsBVKmbwCxz0kwfR6++xuV8D0NU8O+vxqWQaNZ4KUQUQKQ6bEJZ98 irWv56Nd9LI7fv7bsmuXXbDedZi1BpPaX3qWLYcW9rKtj5XT4fGWBDIL8rk9Cs2V+Xe6QE0yNavt 4dW3GKa0jbGvstLCOdCn0DyTfF4Kh0rnWYQbTqTQZq6N/QLXqJ/VoAgoAorAb0GA71qsa2iM1u23 FNPa83i9mp3nzTE90MJzm0U8R4EEco0m9/Y8rBGNJAmkFrI34jGQQW3pMhBCepNL1xenIQ3Xc3J9 yomI9kdYXrbLbzADiXQ+yF2H3xdx/QLEk3HMtazv2+n74ndfxPu4j2kj2qBJmwkBJZ7NBKyKVQQU gQ1DoABkJsK9JO3QAdrCXJrDJgcMLNqBSN0GD663wLtqDYhVT2zBceV0bEsGzeYz0DQehC1I3tzz avkRW4WQxnSCJvGOOa/JTyA2/8DawSd2uUjmH/YYiGcJ1iCG5Ho4Efqc6xrNXp/QDHaHSejtMOW9 CQ54KrBnZVeQzZVIfxnWQB4Ixz3dsP3IyzDD5Y6acaRnKAGpfRdbwJyCtaX0Fru4AuSRW7igzoXt ukAj2VPex3Vqb7nm1NpixCJ8cTm972EgjUMtT7Kvoe40hyVhnFQ6V86e+iA85eLb6tyLFLnqMYK5 6gSQ7AlwavTSrpfKnIF/EH75l8Ljbw8QxTzguAjb0VwN7epN8Pg785BHZBHWo3aDV9255SvkD9/d amkz2QcJTWNCz0mvwh2hGU1oQX1o2/fwFny4zD34IZQ3Sc6Yej/6KNtaq2q0xSTxHZCHWktzrj36 0krjC8nPWDN7zcxnZTTWsB6IflpG81pokH9YtwDm0DMsc+BC1CNYX48Nu680tyKgCCgCmykC5gPZ Hu1zagbNWJ8aSydxM+f5axFPkLNVIG5wqS63I/JFfqqNFT3K0uyV27Q4zW6M5xbKNuR1FY7pMfcf iF0QuW/oWsilCZJZi5lcRxZDM19uo7KfHU033YmDdxx9xj1FGVg228kPLj3n9kWk99tz7OjIIgnP dRo2OgJKPDd6F2gFFAFFoAEC1t6MAbkVW5JY2i4QD5qFXgJTzMUgJRbZcu7fCKIzpeRnGfHd7fJ7 bFFCcsN9Or+Cxo/7a67BusUTv7tNRvTYyyI01OSR1FjeYbML4EzoS9kPawoPx1pMbuXxE669+8tU h1dZ1CeYJS9Bmzobax/3hUY0G+SR2r5Xl38jK3GuM0gptxn5mXtu0kTX1A9E7abZ4+U71I/rFOu9 0aKcapj0Xop1qD9xv0qst3wOmtQwtweh45y4Tz4H6Tr/x4etOuWQrFohLkuhlbW8+zpMYHnMNZKX gkQvAbnketVyrIkcCUz+0HNfIdH7CvtrEr9hHQfAgy4mpGGy+x94u/0eZHz/zttbxHA1zHPfwvrV KpgMc0/Ps6Y+IDOpabXKj8ubIJcLgFUxt4cBtu+DnB8Bb8GDoZ3kOlm26Z9oL3+tPIDuIWig6bGW ZsjUVLMvr8FeqNT2Jrai8ck9s1+Wb4HR3jA9ZiY6WGI9YvZ+razHgipMwju3pNHHRhFQBBQBRcCJ wGv4g6QQ+3zJAseFt3FMr7XJ55meJK4CscikB/n8F0jifPw9HJEv/w8RSTxJCA9FfNMh+zEcL0Kc iUgzXZJXbnFCksktVfhRJjl8G+fjOM+81KZSI8p8zsAZTpLVTojHIsL5gnyCfK84EpGcch3nzoif Gy+1+F0J2cfjHCOvDUSkuS/rxe1dPkgqS//cSAi0NPFsjCXWRoJEi1UEFIGNjgCI1ATLcRACCA7N bF/CmkiLuEGDtl4AgZkBTeAMaDCtQNLDtZhkPiArtVif+Sy2KUloE3kdBM+Sg+sgaUXIWwSit961 +oKQDmXTPHYqCauxd6UM1O8jEDJrbWRWYg3nr9mCMguaxVnIl1jfaVsNoX30LPvCAkzisq64ZpkB k2hDHsv6Hnm+XzV1/bYSA5rcOokn2sF9OBtgBAJcXlshj4LAW/VlOSC1i7DXZqIM1CUQkEnw5jvJ bPdiOVBCm5B3WeUqeezn/yXKsjWrP5TMlh/oVbf+XFw+AKn8gJ6ALUzD8uZieMAnBiwDwWoXLd3s 9rMv/wfnT1b9rTSoG8r7Cus7v7IwYLfY/YzzC0HmH/sZS3asNhurq/Vh0TOKgCKgCLRlBEC+YKYj jA0CzvNDst7HBOf5MbvcDTNco2mrMW81SWiq2sBcFemoiXRqI620OE8y+5BLXVzraKejNrSCMkEi nyNRdclP7Sa1qYzJ7aSDBprcvmib4P42xwNt+SZqgbY3K/Fc93K/3bNC4cuiGEyFp8+/NDbGT7tv DYqAIqAIpEfAJi71CUlcUgXL2ZDRDCYltMgaJ1k9ArWUljOhNME1Hb5tbmTYEkVS5ayX8zsIcmbq RELcQEZyvnQVs683wIhkE+3GWtEGoV5raNfFIprJZD45r0nr0hbLrNZheUWCaNrOX+u6Cbac+no6 8LDa71YPfKbq26DjiAzvBE2mCCgCisCmgoAx/6Vm1PqIu5HOxjRmQ/M3pixN2zgEmpV4Yve2vgXB vBOjmO32SfimWJavNu2y4sbVX1MrAoqAIqAIKAKKgCKgCCgCisCmiQC1owzUZtKjrobNGIFmJZ6B QLy2KlIOE7Ao58Op+FRT2834ZtKmKQKKgCKgCCgCioAi0FoQ4Np1LrhoLfXRergi8BbOcv0oTWWx p5aGzRmBZiWemzNw2jZFQBFQBBQBRUARUAQUgVaMAPcejjsX3rfiurbRqsEsthRNt506tFEQ2lCz NxrxrA3Aw2EQGvXYRqtCG+pmbaoioAgoAoqAIqAIKAKbOQL+WqkL0PGpD97Hsb9wz7rRvYsiT23m rdbmKQKbDAItzfr8Ziu3HZbtI3VBkM+4WkBsMneLVlQRUAQUAUVAEVAEFIHWioAvKtl1eXDrFhO/ 3y9rewTntBu5AntWaVAEFIHWgECLEk+8BiJ03x+AZ8gBa/YQH/aq01WfreE20DooAoqAIqAIKAKK gCKwiSMAx9cxX0zqQjXYfSko2RWxsI4zN/E+1epvVgi0GPGs7pKTG+nqf6964eqpfn9wy2pfWYJ0 wvg+NfvEW8TnS+9DP50cmPln1HOtTk6aV2bG7VI5Kfs/3hbxyfDZInAp8clQTrpni49oUzzrTSUn 42crzTssYzlt8R7EvaX4pHa61yT4ZPhsNdWz3lRyWuqdkTHGTfWsN5UcfWes9123nyZ/PCg1ZaUr IxJbb1/LjMaCmkgRUASaBYEWI56RrmHZd/4HNHfYefQ115k9e6T/vHmh7Z6e4dzorUFDZ5y6XdW8 /v3p6SplGDp5clb3N5a77CyfyDZ7zIDK2TIAO7ynkTNxcnb3z5d7bug3e8yRFbMTLp9Thv7jJ+Zs N73KY1NBkTfHHMk9Te3d7L1FDR8/Lydn+gxXOWFfTnz8dcPphjoTOWHI4ea86wVbDuuTlpwP/8/k djnLlrveN9XhnNjEK4ZntFcr5ORCTv194KxUdY/u0YnnDDXutVPiPPzWiXk5VdWu9trVPXIgx8In XfCNuHVyblXVclc5y3t0j0w+Z2hlOiG47hsxdmJeVbzadSBZvX1O3cQRwzNxFe6HnFxvOdvVThzR H3bq6cLswJFjZntufrl8n+41k4cP5WKYlGEAdnkcMOZNbzlH7V09eWiH2vRyZgcHjJltNnlcL3mm z3q6d0bGz/rkErwzvkjxzsjsWR+a5p3x5pgBuAcHpH1nNN2zPhHPevUGP+tD8ax393jWw+HusfFX WM9oBu+MiXjWq92f9Vb3zugewbunCZ717fCs92/BZ138R45503Oj2iZ71jN+Z6R+1pcf1R3vjKFp 3xnpnvVM3xktNT7Ad53PRNpnXccHqb8WTTU+GHrr+Kyja4oyeQ7Tfb70uiKgCDQRAs1KPKMwtc/J ypN1tcUSi8XuLXml92qY19ZdPP5Ja7ASDuVLVd3aT9qPWHKHV3sGHvXL37OzpxxQVQcNqUegnJqa sjcLRi76j1eabbYvvu747Km71tR5jylsOc9DzvNecgbssOrWUFa7QbV13u8yq101ax9pP3LJG55y dlp9X8if1ac26j3ut+pTsfauglFLPvKSs+VOSx4L+LO6RKLe3/BsbOheV1H6z4JRK75zk7P76PZZ W7689Gm/L5AXjXlxc59kBbIkWFZ1edZpS2a6yam8dYvCHZ99Yrwf9i2xmPu311rki03tg6sqL2h3 7opFrnKubL/F4PumjaMD9FjMfVzr9/uwTU88Vli88izfuTXFrnLu2GKrnR8cNy6GGzHmMT72oy6x eKyq208rzqgZW+N6c1TescVOwx+ac0OqPg/4gygjWnLHj6efcf3Ysa4TAevG9Npr95vHX1lV582F g8A4EqtZ3v7ExX/xmsted13xobvfPOX8VM9EViAsdbGquYUnLrrY695Zd37vEw/NXXBqKjm8d2rr Kn4sHLH4Gk85pxafdmh2/gmpn9Fcqamr+LJgxKJbPJ/Ro4ovCGdPOSTds15VU/Ze+5GL7vd8Z+xY fGV26Ie9UuFsP+sv41n3dDoxYMdVN2SFcndK+86oKnuy4ORFr3g/68V3hfxTtqqNpn5n1FSVPQA5 73rJ6bXT4oeD/uzuqZ71cAg415TdUjByyZducgaNnhbo9cqSJ/AEtvd+1rGDdwhzgRVrr2k3asWP bnKyr8xu1+vZac/6ff5wqmfdj6UV/qrKiyFnrpuc+D3ZnXd8dsnLfp/Pn+pZ59RacOnac9pdVLrC 9Vkfs0XvwQ8UjRO8d1I+6xKpy/qx7ox2Y1eUuMmpvbXXtkMfnH1brfU+dX/3WM96PFp+8E9rT/92 bKnri3fdNct22/Xm9temunf4rEdjtavwjP7Z81m/5pcD8axfnPpZz8azXruw8MSF/+f5jP6t19GH Zi84K6Uc9HldbWVR4UmLr/CW0/tkyDk53TujpqZyEp7R673fGb3PgZwj0z3rNTVrP8a9fKfnO+OY Xy4Jh6bsn15O2et41h9N8c4YHQpNHZr2Wa8pSzk+GLhj8W3BUHjbDR0fbLNj8QNZgewt040P6qpK 7sw7ednHGzw+qCkdWzByxeTfOj7gd936dpWVXV5w2ooNHB/4MT6oOg/jgyVu9YlduUX3zMYHsVhB cfDPcq7uC+k5eG6CC6NHj86HmD3sF+YkeKhd2wRi60VAfgf8sSsiJ/S/gnxvMtCUBbdBWcC6M5q9 CyIH8F8C62aZtGlW4glFyfTKSPlDuF/OzQ913DX54xoOFuCNUE5tpyfxjGYFDs0Ldz4kEPJUHkq7 YKFUxco5mvcknrEs39H5OV2GhkLeCjlLjlRQK+tJPGNB34n5OZ3714S8CSzlVPrKaN7hSTzjAflj bk7njlkxb8VVO+BTLuUTIceVeC59aq+ccOHS0wqzOwdAVjwfk5xAnhRL1YtI4Eo8P+6fUxAIZZ+c G2ov0biXctkvIMpSEl/xIHrC9cNSNSDcMS+ad1wokIOBmTuB9YFN+nwBKe+y7CbUx5V4VvXP69Y+ 0PkoJIQltgeBhYwoyijrEbuyQJa4Es/a3Kwt22d3OYoDbDoacAsgyVIdqZBl/Ttc3ElWuHZqJD+r f4eszkel6vOALwsTLKvkyv4PX9BOVri+GOuyA4M65XQ5KhDyVLIJiIWU1CyvmjZt0Hk77FDk2vi6 LN+QzmHK8X4msv1hWVW1lIN0T+IZbefbIz+NHOveiVdtBTmexDMW8u2bTk44kC+V8Sp+QDyJZzxL hueHO6dsF5+JyngZO9OTeEaD/iPycrrskwpn+53xC+R4Es940H8c3hnbpXtnVMbLiyDHk3hG/b4/ dAx32qIm5v0OZ33Ko+VfQI4r8cT9EOgZrDwlL7tzONWzTpzLpfI1fjTc7vfJ/Ufk+gI1p+RldcHz k2KyKtBOSvxVj0OGK/HE89I+nJV7Uk4wN+WzTpJW6l9+J9TcrsSzrEeXzrmBjscE8Bxyv2e3wPcF XgRS2j/arZ24E89Il2APfCeO4vsi1bNeB/JfM7T0EpSzzq2syrxQ3w6QkxUjNu7vjIAvJBV1pYL3 5oVol+u7J5abPQD3zlGp7h0+62tqlkfxHj+/52lfun4I6nIDO3ZO80yE/DlSUr1sDSrsSTyj2f5d 0z2j2ejz4tji7SHHk3jGsv17pZPDd0ZVfFEPyPEknnhnHJhODscHeLZofeRJPCUUOAz9Pjzd+KAi XsF3sifxjIZ8R3fM6bJLumc93fggGvSN6JDTue8Gjw+CvlEYHxSmGh8Qn1XR8vfQro/d7uVGjg84 5nElnpmMD/hdD2J8UByPPAA5Gzg+8EtJl+U34NlyJZ7l/YPdcjMZH0TrMM6ovbxAZLXn4EgvNAUC JIXv24KOw++rTSHUIeNQHJsx+e9x/HYTy1dxvyLA/iOPIhEYjvhpc4DTrMSz0wnzp6HSfy15tc/2 VZF1uRFpSEYi1sc9PilNwyaX1RZ3rop6E8ZIDBj53QdI9bLj8hU0r76amDdhtORInINI7+Dzfbqu dnVpbYpBJOXEfL45qdvl+7CsdnX/urg3YSQ+AYm7kjPKXhSMxLYVea+sdk23SAo5tVGMaaLx5V71 KZEOte1i1R+jXQWxpD5y5gn5ssUfch9oWekiVVWV0eg3/mhFCNo/1+I4ZYW5Uc5BlHrVJ1InZWWx YhB3v/cgEteg2cA4CKzRI0T9gTXA+HuSaS97QD8QhsazMpwjKUxXY78Am+9T9TloOQfOa0o6SNTT ltQfX8r6YJLE89YI+rLiWNG8yIt0MmNI/D+X16z+tjLiPfFX668ixYdVeIpbOSIz0smJBOGgQXyu AxIj2R+XH9LJiQbrxB+Pu5IhIyfgC3wHOd0xWeVZ6RgGE0yXql0sp7x2TVZVSjkR1Cf1RtVo9yfl tavLqyPe74xYFP7SYjIjZX3EN7GsZs2A2hSTTJTDfvWSw/uhdHafd8pr1vRMvDfdA3HOrhNPD449 5i2vmT+44N2KmjUdIp6TTCK18DgerAss8yqH+tDaaOUnkWhN2JMwInMALwy/P5sE3zXkVYXWrg2V fhPw+XywYHB/Z3ALPlwL14VctZTMFIzIamDzbRyTUZ7POggsJsTqCsu8b4x2EVnJexkaxBTPaJCT XmWdSjpU1YirAlb8Uf9i3Dvfprp3OFD3x2Tlw/OG117vPk8goajMSzxb3s8EJwRhSTQ/5bNe55tZ 7k/zzkCfQ85Pae7ln9I963xn+GO+r1LJQSd9Dzn9U73DonjW/XHfNynrE5OvIacg7bMe86Vc54d2 f4b+iqR71vFOTY1PnN/1NTvURrwnmfis+yK+WSn7K+57F+3qm+o+JD7BmH+elxzeV38f/NQEPBfd Ur0zrP6KRl1JHmV3wH3+S37VBxWxNfkRzwllPIO4D8ORupVe9em4SsrW5q/9siZSGUz1zuBEU1hC nmQxWBUqKQ+t/jYxMe142sF+8fG0lsv4OT6Ix2LZkXaZLLVJeavqxbQIOJcWuS6pSCshdQLnEqhW tQ0GNIScYNsHkffZB9AQZrAEagPRaN7sBl/+NhvWzUo8DT4djl24nxdW3rqfRI4Oxy38B37+kS5d uusdj0+YIXmSAruC6eSgPmcwqeeCtwzltD9uwYhM7p9U9Rk26luOjjgDlDakanfP04o4+39gWiFp EnQ6egVHYXtuqJxuJyzhx3TohsrpdPR8ams2WE7B0ZbZ4tB0fW7drykq3enoRe/g8jvp7jGKGDRo kP8kD1ljTyiidu0Vb31nIiP7fDTkeFVp7IiiJ3DtiXRyWN+Uck4oug9J7ksnh6qLlHKk6EYkuTGd HF5PKef4Iktj47lQ2wYkrRwpOo9J0/VXWjnHF51i+iPVPZ2BnOMzeSZS4vyS1I0tKjosEzmjrxvt k/Evud8/t0gZ5BywwXKmj1gx9vrrM3pnjL7uOtRnvHt9po+YAzk090obEvdOBw85J00de/3YjORc aclxf77wjHKmeI909w4r67uabfKU8yaSvJnumaCcNM/6c0jyXDo5ad8ZUsTZ8P+kk5PBO+N2yLk9 nZy074zji66FnGub4Fm/qIme9T830bM+Mu2NbL/jvPp99EvjZWzRwqMzkZOyvx6WqrFFC6j9SBvS vDPW4J2xd1ohvJdTP+uLMn3WMylL02wwAs65vrRr/n9Dac0t/zdUqT4Lv+3Gims7HKdWXG1ISS2T 12BNzVFz9KXVihYhni2Dl5aiCGz6CLw5LzwyEPdf9c7cRbl7emiA3vaFccXjYgMI/LLnnIWexDNz OT4f5Hh63mxpOdBEpqzPBOBjqcjShJaT0w42m2n9f1GznKZdOemFoM1NJWfPU2/FveO9/d0EX2b1 SSnnjdskczm3oT4et3Nj5MyZn0LOrahPBp0FnFM+W5iugN/SjPqraZ7RNPXJ+J2xaT3rmb570j8T TfXO2DSfdVjZ+HEfer4xM39GU70zYs3yrNPMlyZUMLN/fVV3GXNau5o2q+WEBo4vyC0QK6F9KzUd ap/vgr8jOF+vTcb5QpzLwTlLU42/2+OnG+JKZ/7kGwPp+vFTgzRUEqR1xob0vZCOc/eucu1yQ5C3 Cscca+yAuAp/u5uUOCqE9Fviz46IVKAsQx7LjBDnOa/FNpfgXIM64hqd7/HaapPezsP1qj0Rqbmd l2qNI2RwvqarXRWON7bEOWJLmVEcs73URRQ7NaF2vk44v8bIt9tM3Nlv1jIQu11swwLKc/aBLRtW 5LIC1+L4m3OGxIFt9bQwsstmOpqfLkqW6ywj+dhRBrFbuCFrbZV4pkJarykCLYjA60vj7WGjfG8o J7trVaVPqmvT6QNasHJalCKgCCgCioAi0MoQCAajkhcG1/BlX9plReUE6e/uE6OVVbu5qkOLPK5h XwSicKqDhNCq5CESDpz/M85PsUknrZ62xvFZ+B2MeI5NYJh/HNLdm0R4qNXj2u3dEINIQz8mnubn uL4/rtPPBNeBkoTNxrm38HsHZFtLJ/A3CeDTiJ1wfBl+/4RIi8CP8DetfNZzPILzJIZsK9ckst40 eeVyslm4dg9k088BrRzPRlyGc380JNYmeWNwnrI/xd8Xknzi9wK77J3YNsTJOHczrr3OejqDTfyI 5+GO8//GMSc97kakf4SHEYnTk4g3O9LRX8aJiOwD1ouklRaHxPornKM1CK22DkDkIHAaziHZ2K8p A8esG9Pw+iX4mwYf7PNtEFfi71dZXhLZJV5sH8sdgkiT4KlI+x+kG++om+sh0hHrM+289MvDvHci Ly1pGh2UeDYaMs2gCDQTAiUdQhKuzqusiMnWvRbLNr09l+U2UwVUrCKgCCgCioAisOkgsKqkQCbP 2Eayw1D2xayBelsOJGGDEKm1c64OohZ0RxsYHjNQS0ZCSA0YCShJpQnUvu0GcrEY5OJ/PGkTxJdw SAdkJvwFB66eJJH+EFyjU8v2iFSn/4A4DHEI4iCbdFE7SS0jCRq1gDTlH2ALZ92oXXNzGEJC+4id bil+pyPC5YlFQIdCNsvhQuuBdiTJfNBOz3JItKmtnIlYh/RcVsMlQwxTEEnMuOTiD4jrEU+co2b5 d4iUxUAtbX/7mESe1/dF7I3oxItJhiCyXmy3CSYdNcOUa2TxOs/1JolHX9CZHWXvjMh+puM1yjIW aew3Emc6m7vHIf8uHBvnc/SRQW0pzeeHQ+7pkPuUI605tKzG2E/4IZFm4CQDNbLsr1MRlXi6AKen FIFNB4GcKljQwltSVVh+t/tPcs4JnjtrbDpt0poqAoqAIqAIKALNhMDkGVvJ51O2l6wci59kZN7e TFVpDWKNt0pq3pxYOMmhOeZ147WMpJOaSJKv3RGvQ6RiahSiRTwRqD00JOoxHFNLyTW7Y5IbDrJC E95/IrZHpPbxLJImnD8Nx8xLTSXJ43t2PekpkSSOpPMzRBIhdii1nSSfyYH1ZvmvItJBKfNTa0gC zbKPRSRZonaxO/9G2f+2tYskpcZE9gWci+Ea68PwNv62/KbgHMldFjWkdr76OtDMFOepPaQWkcSM WFLrSNNjOjLjnsrGvDfZ4ZDxPOY0CTdaXdadhJT4kyD+DZE+Gdg/xOtluxImL8n2t4hjEUlQb0Ok jD+ifvfZbeMEwPl2vnPxS3LP+j2JSEJ+EdL+F2mTTdQN4TfrxL9A2gORjkSdkxgFbtjY5aT8UY1n JihpGkWgBRHwYcFNbZ0+mi0IuRalCCgCioAisAkiUFmdjdXxaZf0b4Ita9Eqf4zSRtrk412biJF4 9XXUwjgJnYtzlyDtWvzSVJVEiho1ZyBRIoFloMaQRI2E6kvExbZcEkAST2fnTcXfJxmzWGZGvvU8 5eI6yRZjfUA6etKmmRiJV3/KwLkPcEzTXdaFZOlHxCPtTKyHmd03JGsA8pCMTUB+aj49A67TLJbE m8STbXgD54gN62w0oalEeF27AnL+ZcshtsYZIDXTyYEa2xORnm1huTT9PRaRGlRqtEnQj0KklpRa 5wmIJJ1sL7FnW7dCpNaUhNkZjBbVYNMXF0eijNdQXkrv3l4NM+d1dJsOIb2uCCgCioAioAgoAoqA IqAIbBoIkAg1ho1PS9J4WQ5uEELUauGXJsw0z2SYY5NOg4RzyyNTJomMCVyPSI/1ljxEQ8pIjhiY x5Cc952kMxXUqBc1fNTIHoRIE9P2iNRuMhhH18/imMSTZPQA5JmNXxJeBm5/UmofU8NKE1eSMGoV pyMtNab3I01tinpwvaMJBh/+7cS+Mf3AvJMdMlc5jkkkk2X/bEinfY3OjRhINMNoA7WYBmdiQ+2w uTdMfTkhYDTAzqYawj8OJ0leab79DOJMyOU5rvE02tsUEK1/SYlno+DSxIqAIqAIKAKKgCKgCCgC ikCrQ8AQOJIGp4lqKvLERiSvjTVy4jQzBdGgLJMmec0lSU5ycJIkahmX2fUh6aHpKX+N2agpK2Mw UR9qVLnVVD9Emg6zDJKuzknt/hx/T0UcgngoIvfKNmtIaQJsBbTxecikBvcixIMRaVJ8B2JfnL+I JqselXPWPTmNuZZsKuy6JtYh37kL13ra3qR6cGIgy0GOnX1BjPm3kcfJBJoxs3ye5y9NfNnuaR7t IzZvo4xjcP3viNQW07z3BuKI82enIeauYpV4eqGt5xUBRUARaAQC1fic/ojP31aYM+20IYY2jSgz XdIohgg/wKVDN8wH9+R85WYefoEj+YUwKBoyBKMut5VBm2n7a7Cyi/28JYyxups5/0a0tRbD0qlT sUgIOoQedM/RxgM3Y/I1ejjcxkHT5rcGBErtSlCL1cFRIaP1anQdQS5IUrhe0awH7Z9Edtxkz7EL 4lN0L8iJWSfqVr7zSUv31BlyR++7JJ1LELnWEm8vy5nS+4i7mEJQbjnq+gb+xhdB9kEkCaM2lPWj 2W99QNoJSMv81IjeikhPwNSW3mund6u7IeGst7PuhtAxj3HmRFNYpqF2tiWCH23iti50vsRQgjgK 58w64IzrgDwfQc7HyECT5ZsQqR3mXsP3ICab6KaVq8QzLUSaQBFQBNoSAl/ic/Q03BZUwEhlR6wK +Qv89hXSUCdNWIEdx46CQcrDcKJ+7LHpUjfu+mwYCFEuiVU/fG7PwWeXJCFdIBk++WR4doAPv8vo qD6D8CbmkV+i70IEkjfGKhjUcDDeDvPYt8F9wUcfYaEOVpVcQNcKCCQud2GVT58+cANIP4BJ4dFH sTEa5m7POCODCiDJszCQeuedxOCfmI4YkVm+d7Fi58or8SXEp5Bku6kC5f0HLhkMDgabK+D0foCZ P/corA5DkBiGS9nG+KupKuWQswoGWcTpGrjS+L//a3wBzH80XEhcdRW8WdCdRYrwOlZsvfIKpssx Xz4cfhFPhW9Dv5vOo/HVaBU5Vq7EaBPDTd7Hf/5zokok9mxjW5rMaBWdoZVoLAL4QliBGsczQBao BTwA8ZbGCnKkD1KrBVkzcI4Obrhtx+X4+078ct3n3Y60hnzNwjkSHZLfvyDtl5CBJ8tah0iCuDPi T0kmu5lU0RBP8/Wjtm46yRTk0gstvkDrBbytLG0dTUtJmBgmIo+FFfLxzcx2zcS5RfjlutWJ+CXx ZEhFhlk+A9+Ah9skj5pEaheN2eueOM+1lMSEb9cD169is5wx2tKptvT++D0XdeFEALXYbBcnDbri bzoySg4W1khHU+aFSEOy/g3+pqaZOKabJPBslBLPZulvFaoIKAKbGgIkVtdeC5d7jyU0ZiSb47HD FQnQCy/g7ey2CsLRSJKkHMynkmA1ZZiEVRnHHZfQog7EypkJcA9QVJSoUyZlsU7BRrzp2Q5qSjnI JgmfCfcFLD/X4Zz/PbglIBkzxJPyv8Oni4TxRMw/O8srLoaLPvjoIyFMF9asETnlFExH4xO3HY2p EEimvsEqolswdErXDl5ne5taW0VtIIk/cSjA8IX4MGRCuO7E8IyacGLTXIH12JB7L5P8nIg5G34t v/4au7vvkLg//gUXGJ98gn0KsFFB2Lnaqbka2gJy+R7gs96ZRnt2IBHdB/qSdKS8BaqnRSgCqRD4 EBepmcxDPA8R00LWMc/RxJUaPzNNROJgzGeTvxDmvNMEl+v7Tkfkk06PtSRRfEr4NmwgGyRlIQgK TVVpkkkT1+/wN5318CvCNzvtMoYiUluWqh5sq/OLaupDonQCIk1iaQpKU94jbPnMU2/vgrpwz0k6 HsI0mRVogurcMoB1IonmliU8z/ZQFgNNU4321j7V4IcmqmaNKtexXo74IMq8GrI+wDGd/XDaGiMJ obkz8ee6zS6ITmydbXRO4zmPnX1k2pds12P+pmxDDJ/DMb6q1tY5dyPS4y21oLCPsfAjliTeDKYe zG9I/vU4HmJrg7lmlG1iwJfA20TXTuP604jhSCoxek0RUAQUgU0bARKDG/HpeOqphBaHoRIGRvff D3seGPQY4slzJZjLJenbot6IJpHejfBQ40VNJa8xvSErHOCSaJFQUmO4GvOjXfA5SiZXrA81jV/h 08nBvTGLZH4er8WcawfMK5t85RhiUEPTseOv9WF+hmX4PGfhk+IcVCf32hH45DIyPPQQRg4YOjyD IYeTeFKGUwvMNp15pshppyUI6e40yLEDySvbfgKGCdSSlZbCC0R7dxJ58cWJ/CQzRpM4A/Psr72G kRPaxXwMxI3aR7aLbXcGtz4oK8MUNOagWW9ibAL7hteIFfuU9XNed8ql9vv559fXXLIuJKLOfNQg UsNJeSTRjHPnYgSIISDvI1PHpfj8Mw3PGeJGWcSI9wXrR+KeD8M55k0Oy+HDkQSQOLhp49gm3h/M 69bnyflTEfbrMfygtnMidAF72rqARdAP8N5gfU39WR77iu13lsl7kuSVWDM9+4/XTb1ZF/aP00yd 6aktZvuJKbExzxzPUzvJ+5KTASawn3nN3CvmOSMxZ1paAbBs3jdMyzKczx3lP/lkol7Myzay76hB X7AgURblU5aTbFMm76V0E1Tr96KeUQSaBgFqpUAQaIdCwkdyR20epk7ldkQSCLzFrP0tGaiZo9aP tiF4izUINGElWYUdT2IfTcimF1e85S1HQdSU8c1L8nEz4oWIuyHi61gfSOZYFq9RQ0miw8A0NH+l dpGBhIz1oHkwtaTJAU+VpUEkwSPxYcA0oLVfJew8LBNa1vFFRGoZT7d/nXIexR8HIJLzzEMkQTeB sl9BpFYU06ZWYB3/y3PUDjoFJR2TmNIs96+IfAvxLV1qp3kSv8Qb05XWNZrfEiu8TeTfiHizN6hD chtNPZiO/Wj6iPUheWX/8JohiEyPt6h1nr/Wul7Un9vYwO5JxiAeiWi+zsxH3PFWb1AP4s2JBGOS S2zYjmPsVOxTaj3p2dgqo7FBiWdjEdP0ioAisNkhwMH/449j2g/zfoZ0spEc0F+OOUwOQBlIgEaP Tqwj5ECaZOpWfHa81sWRLP7jHwkyRRJxwAEJLRG1eRwAsyySNGo1qUWkmevBBzeEl4SSA24ObDnQ 5eDcELvP8NmjFor1ojaUgaawH+KzSnkcPDMP1/+NHJnQllIeyeT556fvRtaRg2wOqJ3E0y3nfvsl CA7LdRJPkjVqi7jGlO0bNQobw/0Ptjo01nEEDup5nlpnp/kqsWJkHxCD2zGEeuCBBGFjWy65BKMD DBm8tKHUYN+Mzz1JGIk6zSfHjk0Q5ymYg7/00kQ/UjPJ+pP0upE0lm80nc56/xfDE94TH2B+m/Wk Nppmq9QCTsN8ONtEHGkKe+CB2CjvvkQ7eF+w39g/vM94Hx0EoyZODhAjyqDp8Mcfw7YNxm00/96V c9YIJGEXXZQwiea6ziMxnCCBcmJAjfiYMQkCSIL1VwyN2FZOEjA/MWMammyzbsn5nW3kpAgnZniv GdLJ670x/Lz66kTfEBv2C+9vyuLf50HnQo0128cJCGq+aYb+xBMiNB9nG3md2uRHHkmQOuLD9jOQ 1JLs7rUXRmoYqpGc0rz5+OMTbeO91r9/wkqB9xgDcSVZZ9sY2PZDDkmYnLP9JM68h9jnLGsehqG/ /32ifJJO5uUzyHodg6EWcaLWn5NPn36aeG4og3VluSYwPUkqrSQ0KAIbCwGQgadANN5G+Tsj0rz1 B9u0koSLU5A/23UjSRuByKm4+Un1/Qv+7oO4jOsEzTUcvwDZJI178NFCnIpzEVubSXJlZJPwkKDc iWskfXiDWWSV5IlpljsIHbWVeBNYRJZ1TA5v4cQwRNaDpI2yS/EzCrK3xy/eADIL52bjb3IalmdI rZGFJ9gik6wjtz1h3a3A+uPnOuTFG8DCjF97eu7Fmzx1sLG5CnmfRMp+iMT7R1uuRYJxjcSUdZyC 9GwrzVeZpsSBAYmcaeMcR6k85jQf+806b+NNoos3tyy262+y/BMH1HASZ5ZvBdtM9k8otwf+HIRI ko9RjMx1YoG/8UURjBYs0mn1Ba7fgXyUORSR+LIeNG9ORcgdTVj/UIlnSnj0oiKgCLQFBDignY9P rzEdTW4zNUFffAEblT8mBvzUCFLbcu65CULJQXky8SGRomkmB73/xOeARJUDX5JNEkOSHA5yOVAn EaK2z5iXOsvnWjMOiknmaG7Kso2mhWVTe+QkRCQ1HGwzkGTwGuvHstk+DuRZ1m6Yn3YSxA3tZ7aH dSOZolkt8SBhIakmWWCg1olkxc0sk6a6vE5y5hbYByTVxItaaJJT9gknBqhF4zpWo7Ezvy9iDpyE i7gNw2d91qxEn5GMkeixjt9+m9BIk3jSMY8bwWa9eH+QNJFEEXeuOz399MRaQNaHfcjy2PaddkpM YgzFp5oaW5JRkiujhSZRZbkklsSNRIykjiST8qlhY/1IoiiPmnjWm3nYp8Tz/fcTpJb5eZ1rjI32 kPcX07Bee2CIyIkHrq9l+2jKTLksm2s1SaCYn8+AF3mnqTDv30MP9e4bruPlOmKu9d0ZwzfmIUkj niSntBCgyTTvV04EUB77hoSUuNKk/eWXoR65EAvHMIlBQk1Cy3byHh43LuEAiXjwfuY6Z97HxInr WimbkzK0SKDG1QTKoBaWzwUD7w2WyckU1oP3IjX1JKN33JFIwzpSBvHgea5n5rNCU1tqPvncknTy l5MUlM9JHdZdgyKwsREAKcAbrYE5KQnEAme9bOKwFOcYGwRcI3FhXC/gGidJ2bkAAA/eSURBVLWO eMP8GnAOT4h7sInNZFxldJNHAkOimEwWrbQ2scJb1DXvdJxldKa1iF9SwDSTRTpZFjXAbvVgGzzb 4d66+nLxZbHWcLrJJYFtQGLRpp+cCb3aaPeRRbaT0mPq0NJ6Jp+ntnKqV11t4muRX4+64su2vvks 8uHrYGk5myQo8WwSGFWIIqAIbMoI0FySZM2Y57m15Z57RPbeOzFIN4EaNJIPkpJkB0QciNOcj+aq xtSVBJIyqKkkSaMmjJpIalW8AokDnfmQvJLsUPvDwTY1PBzMk2w4TSR5zhAIDro5EOcgnZpEBmrN SD7fwLx1UxJPyqbmjKbB1PRxnSy1gCRp1Cgx0BnNTw0+ub+2mpo+tsNLs8rrlE2tGYkCA8kkCQ41 VySexoyZ7adGlOe5Ps/gy/QkWCSZlEPsjAaYGjCvQBxJVvv2TfQl/zYmviRuJMPUpJI80qyW+JIE kWhSi0Zt2facm0dg+STnJNjUtlGjzDTUorMt7FfWnaatJGYM1CBywoOTHSTBn3+e0LJS08lArR/J HvMxkKSxbEOszdpXEltqGZmf9wP7y5mf97NbYLmU7Wbuy/R8dqiR5MQGtZwMxJrt4/1Pssi+IYb8 m88AA/uT2ldqhxnonIpaXBJ1Ek9j+kxtLwmf0RgbjSTzkCDSARjNlul4y3n/m7awn816aGMmS3Na ThAwkIyb+zL5mSK2NPUlaafmmYETSiSk1IBS+8oJED7LXsTcHVU9qwgoAs2NALR1mBoSvJmtgC+T ZR6sYSMioMRzI4KvRSsCikDrQMAMSr0G3qwltR7JA0uu++OgltoTQzwNCaTWimTAkE7KoDmsWU/I v5mXjlrSBWonSWY4wKV2hyaANN9N5ymVBIkEiANyE6jh4SCeZoEc9FMTSm0QB+QkiFyr+VsDSTLL oiaOxPPttxPty2SLDmNS7GbOyvpwcoD9Q0LjDIMHJzRYzsA+YFpqpJLbw3qR0Jg2sz/cNM1OedTO 0VSYpMnNoRC12ocfntBM04yZW+qYQOLNNhnTYGJOjRrNsGnCyUDsOSFAAsp6k3yThDn7jPiQ3FC7 RqLnLIN97Jw0IUmnFpeaXrM1CNvJMkh8mX/rrX+Vb/KzHm7B9I0htslpSP5YL2Puaq7z/qc2l21i PVgH573Ae9HZTmJLQm9M2w0pZz4T+DyRDDqxITH0um+S60qZXEfqXJ/NZ9fUMXmdq+k//powaFDi 2aaWk8Tz1VcTfzvr5Y6knlUEFIEWRqAryqPGFF9MeRTaO7ypNGxMBJR4bkz0tWxFQBFoFQhw8Esy Rg2G0TI5K2YG7ySYzkBCwsG4m3dZnktOz8Gr2ZrByElFdpPBoaaImlSaItLskGSIA2mniaRximLy upEJ1sGYu5J0GUKxoVuQkPyQFNNskoSPayipmcsk0CyV6zBpFupFxkkuqP1zBkMgk8sggWC/Oc0u mYbkjXIMgSQ+xCNVMJ5+jQOo5LQ8z7ZSK0aTT5ZBzSQD5fNeMOXxHmC9aNaZvJ6X6an55HUn0TGk ivXgZAOJopNoJf9NYksN7r33rt8qkl3WJ1X+5FzUDDI9TX0POGB9mayvG9amb5xYO9tFbAzJNFjx nJP8GdLO+9qkT8bGue+ms28p082sm3KSZaTyUJz8jLF+1HDz3qZWl5NA1LhrUAQUgdaFAIgmSedB ratWbbs2Sjzbdv9r6xUBRQAIUGPC9Zs0PzzppIQpHQMHsSR61KrRqQo1eRxsGi+aNNcjaaUJJk1a GcxAmhqQMWMSWq1tt01co6MdkkRqnsxgPVUHkJSSiO2yy6/klpo/DnxZZ2rGSNaovaQZILVONKfk QJkDaUaSStabDluo2SF5oEknTYTpzdOsv2zMjcC6e+1pyO1UqPnj2ktqr2heawIJGgkzSWayWTO1 ujQjpgmsWePHfNTe0fySWkXWl2akRvNMEsq2GTJkSDZ/SfyogeJ6QOfaO5ptEk+Wz3W4mQS2l2TN az/Xm25KmKHShJYm1DTLNriSKLJfDLGhppKeT7m+0kk82RYSyFQEiGSJa2SpsaMG3Hgf5jE18mYC hDjSlJr3pNG4G2JIZ0LEkXU1prpMy3uI5bsFrqelRpcm3ocd9quJKu9F4sl2sF10BkSzVQaztpga 6mRinAnmvzUNnwne4ybQrJ39/Fv34OSzxmeWZN4ZeM/xGeR9zokG4qNBEVAEFAFFIDUCSjz1DlEE FAFFAAjQOyq1VtRccABN8z6ay3KwzwE+1wlygM4BJ01sabJIhzh0GkMiSlJlPKcSUK73IymiBpBE k9ofkkI6YOFAnlo2s62EVwcwDcvl4JemkSQn3EeR6/RILkhSaN5Ih0V0ZsM6kUDQ4QnJFyMH3PQg yvV81JDSXJf159rSdIEDarYpWWtKEkMHNnR4Q7LDdPTISvJO2SQhJIskXxycm0BNKNdcEkdDesw1 yiHJp6MZyqLZLgPX3pH0c/0gndSwf0hmSaB4jbia9aumvuwzYsbznEQgVsTcbGtCz6PEzqT3MiF1 4sOyqOUy+3iSUJJ00HkQTXBpbknyzHqSPJMoc/LBOIXad98EYab3U95rdFRDU2CmIbmmcyA6AyLJ cd5HrINxIsX6slySO2LLe47Ekv1LE1ajYeeaR5JRlsl7l+3jBAbvSeLL/LwPSRxJ1Ez+ZO2ws/1c L8u8vI+IJ8kk12KS3HMNMfuGkw4sk/3PCRe2iwSXfWGwdmpaWV+nxpPX2HajjWQePiPONMnPDCdn zFY4rC/7m2SY9wyfGa435j1oJoZMeuc9zWvGIRfLYhlGC87+4EQJ16GyvdTkU5vM+48TGDQlphMl p8lwuudKrysCioAi0FYRUOLZVnte260IKAINEKBJHrfGoFaSpImDcmpy6CzFaOdInOi1k85iqHWi Z1DjoIeDWxITs86LBIWDbqYnaSHRobbOONrh39RCmi0y3LqDMrnNCzWrJDgcmJPUcPBrzBE58KXj IZJOei7lOlKSQspnGpIBOmVhHbjmkqSVMpzr5rxuBZIikpVkhz8k31yryMjAQTwH/wwsl8SKONDj qzPQhJakyLm+0HmddafjGw7yJ09OkLCrrkpoodkWkmXWmxpVahHZLhIws4cm8xMDY15JgsQ+o8kp yQQ1z8TTbNfCdX4ksun2XmS92VckKIbAkHiR9JJckcQZ7SUJJck/nd0QPxI/kra33vrV/Jb9R6LC SQsSI04UUCvLdrBdvO5cw8m01FCbPuNkBI9JdqnZ5X3Fe9E4vyEOnOSghpKkkngQO1NHOiqiNpoT I8zPiRZ6j021RpFmxHQWxckBOrsiKWRf0tET+4nb47CNJM9sA0kZvfwaQkZnQcTaue8qJx+cpJLX DDa8L4gfJyqMKTnvAbMFkblvuKaYecwzynpQy817hOnpwIgaULNFDnFleqejJN4n5jqJPbHmOk4T eA+yniSezjXbnFwgdsZJk75SFQFFQBFQBFIjoMRT7xBFQBFQBGwEOFCl1o7RLXDQyoG1W+DAld5S nYHklM5m3AI1kfRcmi6QTDg96SanN05vnOeNtpDnqGFj4PpQaigbE6ihc/PUSa2SMUd2k0eHK4zJ gSbL1A6mCsTMaDDd0pE8ua2NZFqadSY7HzIObtxkkWjRLDZd4OQCyZ1bSCbRNMclOTOBRJy4J2NP rS5jciChTL6PuMaSW8k4A8kRownJ9aBGjoTXK5AwGu/ATGNIayosSNZIWhndghv+Jh29+t59d8Nc dJTlDFxjbLY04XkSO0YT+HxyCxRn4D3F6AwktE6NuvM6CTGjMzg9GpNYJmPNPqHn4uRAiwhOZqSa PEqFp15TBBQBRaCtIaDEs631uLZXEVAEFAFFQBFQBDYIAVo9UGNNDTsnSzQoAoqAIqAIpEdAiWd6 jDSFIqAIKAKKgCKgCCgC9QjQDJ6m+TRr1qAIKAKKgCKQGQJKPDPDSVMpAoqAIqAIKAKKgCJgIUCT arO+WyFRBBQBRUARyAwBJZ6Z4aSpFIEWQyAe90l2lmO38hYrWQtSBBQBRUARUAQ2HQRywzVw/ITF vxoUAUVgk0BAiecm0U1ayTaBQHW1T3LC/txwtXwyeQdZVYIpdQ2KgCKgCCgCioAi4IrAiuL2kpNd Cw/GGM7GYspA9T5RBFo5Ako8W3kHafXaDgI5HXKi0SqJ06vizAX9ZcpsXTzUdnpfW6oIKAKKgCLQ WARCgajktavBNk7YCFiDIqAItHoElHi2+i7SCrYVBHqU9F+7KGv+/ZG6yKmhYFRCAWwaqEERUAQU AUVAEVAEPBGIx4JSV1c+J+KvxU6rqvTUW0URaM0IKPFszb2jdWtTCOywQ1EU+9T/47Ol7TPY3bFN QaONVQQUAUVAEVAEPBGYOLxD7diiophCpAgoAq0bASWerbt/tHZtEIF9e66oboPN1iYrAoqAIqAI KAK/CYF9i1b8pnyaSRFQBFoWASWeLYu3lqYIKAKKgCKgCCgCioAioAgoAopAm0NAiWeb63JtsCKg CCgCioAioAgoAoqAIqAIKAIti4ASz5bFW0tTBBQBRUARUAQUAUVAEVAEFAFFoM0hoMSzzXW5NlgR UAQUAUVAEVAEFAFFoMkQ8PmiTSZLBSkCmzECSjw3487VpikCioAioAgoAoqAIqAINB8Cn1XuVZiV FW8fj8ebrxCVrAhsJggo8dxMOlKboQgoAoqAIqAIKAKKgCLQtAh8VnlEvoRLsoLxYCeRSD62Cu3m j0s38fm7x6PRHUNZsrP4fFtH62qSC/aJL+Jv2tqoNEVg00ZAieem3X9ae0VAEVAEFAFFQBFQBBSB DUDgu9gufeLx8O2+YKhzLFJbLwlKTF9WdklHiUlQ4pFCkM6wxOMdQzn5AuIp8VhEYlHGOsH5+nw+ nw/H8Rqpi5ZK1gZUTLMqApsZAko8N7MO1eYoAoqAIqAIKAKKgCKgCGSOQCSSkx8IxA8P5eTlxSK/ ai5JJeOxGP8XwS/NaePxmNRVl6cUHgjlSDRSM+OdGw5fOOz6sZlXRFMqAps5Ako8N/MO1uYpAoqA IqAIKAKKgCKgCKRAIBQpj8eCqyI1FXkuJrOZQQctpw9a0GBOrtRWli+O+WX02OvH6sLPzNDTVG0E ASWebaSjtZmKgCKgCCgCioAioAgoAusjEJT82phURWA/mzk8IJp+f0B8gSCsbgOC9Z4SrauORmsq Xo1FozcMC3w5NXNhmlIRaBsIKPFsG/2srVQEFAFFQBFQBBQBRUARcEMgXuXKOK21mr6AlcPn90Oj Sa0myWbAWtsZramq8sVi82GOuwTk8+uYL/jmhNGrJo8dW0T7XA2KgCKQhIAST70lFAFFQBFQBBQB RUARUAQUAQcCNJuNxWNrJFa3VHzxuC/mXxyPxYv9Af/CaCQ+F8s+l8JnbbFUxxbs2+7LtSbrMF3S qfeRIuCJwP8Dth/J391qA9QAAAAASUVORK5CYII= --_005_DM6PR13MB233024BBB6C83FA92B77F995858D9DM6PR13MB2330namp_-- From nobody Thu Feb 11 00:23:44 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5EA3A120A for ; Thu, 11 Feb 2021 00:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CFqo9ohlAQVC for ; Thu, 11 Feb 2021 00:23:39 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 0A59E3A120E for ; Thu, 11 Feb 2021 00:23:39 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id f1so6919166lfu.3 for ; Thu, 11 Feb 2021 00:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=DyO/ya0EPq9JdaXovvUe61KZfxA952FjeO7Vyn4Gs80=; b=EleMwHWxsoHHr45tdrrrJUhKlGTeMjmhe/4kpI2R76iO/Hk6wpUigDQiaOGq+1saNf CHLzQcTxVhRKPEdczQFX3TKO++RUUCRiBaN+Grk3cDcBKvO+XvwJUUFa+One2TIRkwI/ IlVuVWyOqdzv5qG+DL7E8zWYA9r9tfF+lXQunYJGoDERuDs4dgsaUhdB8oLW11RjKvDg zjV1z/h6rlmwFyVeDhzSQ3OYjdf5hE4licZJDlQfwdDQ5vZgoUC9gf9wVIU12f5MR8+k uUvFaGUaS0qObHfSG3cfrSUxhql8ALXzyTer9kosBADcqtMGwiU2eb9SUhCMv4bvbhh3 teBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=DyO/ya0EPq9JdaXovvUe61KZfxA952FjeO7Vyn4Gs80=; b=OLR67/QLPKzUqhKTJ5/GoTgpNgcXoDUg5Qz6FU5Rg/kkQc0xp/hEklwQVmS2Ecg5h5 9wVHl6d4OdH2pVwEdYb+JrtNsu08mXk7hsuCetVIJa3CwcZEQ9YqTRtjM6alqLk5qcd4 E+n1Q47RY0TK5NAcu/bViQYzL3k1PtK4DC0beEnyiFmuFfxM6xfhrRo4do3ha8AKObHO Z3i0OpK97+peZ2Qz6O/jkJ96zSWGjucgk6W0B5CdVOVgW6oa4f648H0JSPMrNqw1JSqh W/Kd2jnUuqLgn582NPHYLf/1UjPWhRCNjGOWkTFRFtEihQWyH/gfZMBXVaPEglYtO04/ G3Rw== X-Gm-Message-State: AOAM532xL5z4WmY5Tj+lESzSmLdMtDya6ojiGe/BUD4d8WJxfLWOSvwR CqzhkvhOs9NtvgSV0rHIR6M= X-Google-Smtp-Source: ABdhPJzgHCASud7pkm68UgAWjxXgf2lVSQfYt6c/uUJBVAwMa30lB+Z79yEmRUXTjEyh7odj5gRn9w== X-Received: by 2002:ac2:5a50:: with SMTP id r16mr3749209lfn.623.1613031811953; Thu, 11 Feb 2021 00:23:31 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id g25sm797146ljj.64.2021.02.11.00.23.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 00:23:31 -0800 (PST) From: "Valery Smyslov" To: "'Christian Hopps'" Cc: "'Tero Kivinen'" , References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> <9E9A8E75-B269-4CFC-904B-272F3E1B59A4@chopps.org> <034d01d6ff87$db060140$911203c0$@gmail.com> <252DEFA7-AE92-4974-9ECE-2B8BD742FED2@chopps.org> In-Reply-To: <252DEFA7-AE92-4974-9ECE-2B8BD742FED2@chopps.org> Date: Thu, 11 Feb 2021 11:23:34 +0300 Message-ID: <044101d7004f$30cff370$926fda50$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0442_01D70068.5621BF50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEwzZDjYo4hMYjGJNs7372CsQemJgHa0ryfAWDZU54BtpmRgQJDC4D+q2VDyGA= Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 08:23:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0442_01D70068.5621BF50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Christian, I agree with what Lou with regards to it going too far to recast/redirect this work any further. I did do a round of changes based on our agreement to help with future uses, and while it's nice that this work could lead to these uses, those should be documented in another document at this point. The focus of this work has and should continue to be traffic flow security. Here we disagree. My point is that you define a very good mechanism that can be used not only for IP-TFS, but for other purposes too. I fully understand that IP-TFS was your primary focus and I agree the document to remain focused on it. However, if the document is kept in its current form any attempt to use it for other applications will look as an improper use of mechanism, because the way document is organized highly ties the mechanism and its application. A compromise and to address your concern that other uses might look improper I've changed the abstract to include this final sentence: "The mechanisms defined in this document are generic with the intent of allowing for non-TFS uses, but such uses are outside the scope of this document." The introduction to include this final paragraph: "The mechanisms defined in this document are generic with the intent of allowing for non-TFS uses, but such uses are outside the scope of this document." And the "Packets and Data Formats" top level section to start: "The packet and data formats defined below are generic with the intent of allowing for non-IP-TFS uses, but such uses are outside the scope of this document." I believe this addresses your concern about other uses looking improper. That changes are the very minimal ones and in my opinion they're not enough. The document still looks like a mess, because it constantly used term "IP-TFS" when describing a generic behavior of Aggregation and Fragmentation mode. Few examples: 2. The IP-TFS Tunnel As mentioned in Section 1 IP-TFS utilizes an IPsec [RFC4303] tunnel (SA) as it's transport. To provide for full TFC, fixed-sized encapsulating packets are sent at a constant rate on the tunnel. The egress of the IP-TFS tunnel MUST allow for and expect the ingress (sending) side of the IP-TFS tunnel to vary the size and rate of sent encapsulating packets, unless constrained by other policy. IP-TFS aggregates as well as fragments the inner IP traffic flow into fixed-sized encapsulating IPsec tunnel packets. In particular IP-TFS never maps the inner DF bit as it is unrelated to the IP-TFS tunnel functionality; IP-TFS never IP fragments the inner packets and the inner packets will not affect the fragmentation of the outer encapsulation packets. Likewise, the ECN value need not be mapped as any congestion related to the constant- send-rate IP-TFS tunnel is unrelated (by design!) to the inner traffic flow An example IP-TFS packet flow can be found in Appendix A. And so on. I think the text must be cleaned up to be more accurate with this regard. I've incorporated your other suggestions from below. Please see my comments (I removed parts where we are in concert). 9. Section 2.2.3: When using the AGGFRAG_PAYLOAD in conjunction with replay detection, the window size for both MAY be reduced to share the smaller of the two window sizes. This is b/c packets outside of the smaller window but inside the larger would still be dropped by the mechanism with the smaller window size. I wonder why MAY is used here. It should be MUST instead. As you explained there is no point for the sizes to be different. They remain different mechanisms and the user may wish to have them treated differently (e.g., logging replayed packets). My question was regarding "MAY" vs "MUST". Even if these are different mechanisms, what is the reason for having different window sizes if both mechanisms are employed? I may yet understand that reassembly window may be shorter then replay window (you will just have a penalty of dropping too old packets even when replay protection allows them in), but what may be the reason for having reassembly window longer than replay window? If you have some gaps at the far left end of reassembly window waiting for missing packets, you'll never receive them if replay window is shorter - they will fall outside it. So, it's just a waste of resources. The implementation may wish to allow the user to have replayed packets logged (one can have a very large replay window w/o consuming many resources). Well, I probably was unclear, but you missed my point. I'll try again. The current text says that if both replay protection and AGGFRAG are employed, then replay protection window and reassembling window MAY be of the same size, which is the smaller of both. Since MAY means that you think it's OK for these windows to be of different sizes in this case, I wondered in which situations you think it's OK. You gave me an example, for situation when replay window is longer than reassembly window, which I can reluctantly buy (I still think that it's a waste of resources: some delayed packets will pass the replay protection, decrypted and then dropped because they would fall outside reassembly window). But can you please give me an example when it's useful to have reassembly window longer than replay protection window? Consider an example when reassembly window size is 100 and replay protection window size is 10. For simplicity let's assume that reassembly window at the moment is filled with packets with odd SNs starting from 1 to 99. So, you are waiting for the rest packets with even SNs from 0 to 98 to be able to complete reassembly process. But since replay protection window size is only 10 and the most recently received ESP packet has SN 99, you never receive packets with SNs from 0 to 89, (because the will be dropped by replay protection logic) and the first 90 packets will never be reassembled. It's just a waste of resources. So, I think that MAY above should be at least SHOULD. Or leave it as MAY and say that reassembly window SHOULD NOT (MUST NOT?) be longer that replay protection (for the reason outlined above). 10. Section 2.2.3: Finally, as sequence numbers are reset when switching SAs (e.g., when re-keying a child SA), an implementation SHOULD NOT send initial fragments of an inner packet using one SA and subsequent fragments in a different SA. Two issues here - first why SHOULD NOT and not MUST NOT? In general you cannot reliably reassemble packet if it is fragmented over several SAs, so it will be dropped. Why do you allow this? Changed to MUST NOT. Then, IPsec architecture allows several parallel ESP SAs to co-exist with the intention that kernel may use any of these SAs to send packets (e.g. for improving performance, see draft-pwouters-multi-sa-performance). I think you should mention that in this case a care must be taken not to fragment outgoing packets over several parallel SAs. I.e. if a packet get fragmented, all its fragments must be sent over single ESP SA. Covered by the switch to MUST NOT. Well, this text is explicitly about "sequence numbers are reset when switching SAs". I think it's better to generalize it and say that "packet fragmentation MUST not take place over different SAs". This will cover both cases - rekeying and parallel SAs. It's explaining the restriction. This adds information/justification w/o changing the actual requirement. I think that's a good thing not bad. If you have several parallel SAs their SNs are not reset, they are just different... OK, I can live with this, although I still think the text is a bit confusing. 20. Section 6.1.4: 0: 6 bits - reserved, MUST be zero on send, unless defined by later specifications. Add a sentence that these bits MUST be ignored on receipt. They must not be ignored. If they are set and they and not understood then AGGFRAG mode will not be enabled as indicated in section 5.1 Section 5.1 is about USE_AGGFRAG notification, here we talk about Reserved bits AGGFRAG_PAYLOAD. How they are related? As implementer I have a question - what should I do if these bits are non-zero on receipt? The draft is silent about this. I think maybe you mixed something up in your reading? Section 6.1.4 is: " 6.1.4. IKEv2 USE_AGGFRAG Notification Message" It is not about the AGGFRAG_PAYLOAD. You are right, I somehow mixed up these sections. That's probably because the description of USE_AGGFRAG is split over 5.1 and 6.1.4, that was a cause of my confusion. I'd rather merge them not to confuse other readers :-) 22. Security Considerations. Add a text that correct functionality of the AGGFRAG mode requires restoring packets order on the receiver. Since this is done by utilizing ESP Sequence Number field, the ESP header must be authenticated, and thus the ESP SA MUST be created with authentication other than NONE or with AEAD cipher. I think this falls under the non-IPTFS use case. I'd like to leave it out as it would be confusing. No, it's about any use case of this mechanism. ESP can be used without authentication (although it's strictly discouraged) and in this if AGGFRAG is employed (regardless of IP-TFS), then an attacker can re-order packets on his/her will, by playing with SN field, so your reassembly mechanism won't work. You think I need to state that things are not secure if the user turns off authentication? I think yes. You may have ESP SA w/o authentication, it's not prohibited by RFC 4303. In this case replay protection won't work (it may be OK for some application). What I want is to stress that AGGFRAG won't work either in this situation. Regards, Valery. I would think that's covered already by: " Other than the additional security afforded by using this mechanism, IP-TFS utilizes the security protocols [ RFC4303] and [ RFC7296] and so their security considerations apply to IP-TFS as well. " Thanks, Chris. Regards, Valery. ------=_NextPart_000_0442_01D70068.5621BF50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christian,

 

I agree = with what Lou with regards to it going too far to recast/redirect this = work any further. I did do = a round
of changes based on our agreement to help with future uses, = and while it's nice that this work could lead to
these uses, those = should be documented in another document at this point. The focus of = this work has and
should continue to be traffic flow = security.


Here = we disagree. My point is that you define a very good mechanism
that = can be used not only for IP-TFS, but for other purposes too.
I fully = understand that IP-TFS was your primary focus and I agree
the = document to remain focused on it. However, if the document 
is kept in its current = form any attempt to use it for other applications
will look as an = improper use of mechanism, because the way document
is organized = highly ties the mechanism and its = application.

 

A = compromise and to address your concern that other uses might look = improper I've changed the abstract to include this final = sentence:

 

"The mechanisms = defined in this document are generic with the intent of allowing for = non-TFS uses, but such uses are outside the scope of this = document."

 

The introduction to = include this final paragraph:

 

"The mechanisms = defined in this document are generic with the intent of allowing for = non-TFS uses, but such uses are outside the scope of this = document."

 

And the "Packets and Data Formats" top level = section to start:

 

"The packet and data formats defined below are = generic with the intent of allowing for non-IP-TFS uses, but such uses = are outside the scope of this = document."

 

I believe this addresses your concern about other uses = looking improper.

 

          That changes = are the very minimal ones and in my opinion they’re not = enough.

          The document = still looks like a mess, because it constantly used term = “IP-TFS”

          when = describing a generic behavior of Aggregation and Fragmentation = mode.

          Few = examples:

 

2.  The = IP-TFS Tunnel

 

   As mentioned in Section 1 IP-TFS utilizes an = IPsec [RFC4303] tunnel

   (SA) as it's transport.  To provide for full = TFC, fixed-sized

   encapsulating packets are sent at a constant rate on = the tunnel.

 

   The = egress of the IP-TFS tunnel MUST allow for and expect the = ingress

   = (sending) side of the IP-TFS tunnel to vary the size and rate of = sent

   = encapsulating packets, unless constrained by other = policy.

 

   = IP-TFS aggregates as well as fragments the inner IP traffic flow = into

   = fixed-sized encapsulating IPsec tunnel packets.  =

 

   In = particular IP-TFS never maps the inner DF bit as it = is

   = unrelated to the IP-TFS tunnel functionality; IP-TFS never = IP

   = fragments the inner packets and the inner packets will not affect = the

   = fragmentation of the outer encapsulation packets.  Likewise, the = ECN

   value = need not be mapped as any congestion related to the = constant-

   = send-rate IP-TFS tunnel is unrelated (by design!) to the = inner

   = traffic flow

 

   An example IP-TFS packet flow can be found in = Appendix A.

 

 

          And so on. I = think the text must be cleaned up to be more = accurate

          with this = regard.

 

I've = incorporated your other suggestions from = below.


Please = see my comments (I removed parts where we are in concert).


9. = Section 2.2.3:

 When using the AGGFRAG_PAYLOAD in = conjunction with replay detection,
 the window size for both MAY = be reduced to share the smaller of the
 two window sizes. =  This is b/c packets outside of the smaller window
 but = inside the larger would still be dropped by the mechanism = with
 the smaller window size.

I wonder why MAY is used = here. It should be MUST instead.
As you explained there is no point = for the sizes to be different.


They = remain different mechanisms and the user may wish to have them treated = differently (e.g., logging
replayed packets).


My = question was regarding "MAY" vs "MUST". Even if = these are different
mechanisms, what is the reason for having = different window sizes if both mechanisms
are employed? I may yet = understand that reassembly window may be shorter
then replay window = (you will just have a penalty of dropping too old packets
even when = replay protection allows them in), but what may be the reason
for = having reassembly window longer than replay window? If you have some = gaps
at the far left end of reassembly window waiting for missing = packets,
you'll never receive them if replay window is shorter - they = will fall
outside it. So, it's just a waste of = resources.

 

The implementation may = wish to allow the user to have replayed packets logged (one can have a = very large replay window w/o consuming many resources).

 

          Well, I = probably was unclear, but you missed my point. I’ll try = again.

          The current = text says that if both replay protection and AGGFRAG =

          are employed, = then replay protection window and reassembling window MAY =

          be of the same = size, which is the smaller of both.

 

          Since MAY = means that you think it’s OK for these windows to be of = different

          sizes in this = case, I wondered in which situations you think it’s = OK.

          You gave me an = example, for situation when replay window is longer than =

          reassembly = window, which I can reluctantly buy (I still think that it’s a = waste

          of resources: = some delayed packets will pass the replay protection, =

          decrypted and = then dropped because they would fall outside reassembly = window).

 

          But can you = please give me an example when it’s useful to have = reassembly

          window longer = than replay protection window?

 

          Consider an = example when reassembly window size is 100 and replay protection window = size is 10.

          For simplicity = let’s assume that reassembly window at the moment is filled with = packets with odd SNs

          starting from = 1 to 99. So, you are waiting for the rest packets with even SNs from 0 = to 98 to be able

          to complete = reassembly process. But since replay protection window size is only 10 = and the

          most recently = received ESP packet has SN 99, you never receive packets with SNs from 0 = to 89,

          (because the = will be dropped by replay protection logic) and the first 90 packets = will never be reassembled.

          It’s = just a waste of resources.

 

          So, I think = that MAY above should be at least SHOULD. Or leave it as MAY and say = that

          reassembly = window SHOULD NOT (MUST NOT?) be longer that replay protection (for the = reason

          outlined = above).



10. = Section 2.2.3:

 Finally, as sequence numbers are reset when = switching SAs (e.g., when
 re-keying a child SA), an = implementation SHOULD NOT send initial
 fragments of an inner = packet using one SA and subsequent fragments in
 a different = SA.

Two issues here - first why SHOULD NOT and not MUST = NOT?
In general you cannot reliably reassemble packet if it is = fragmented over
several SAs, so it will be dropped. Why do you allow = this?


Change= d to MUST NOT.


Then, = IPsec architecture allows several parallel ESP SAs
to co-exist with = the intention that kernel may use any of these SAs to send = packets
(e.g. for improving performance, see = draft-pwouters-multi-sa-performance).
I think you should mention that = in this case a care must be taken not to
fragment outgoing packets = over several parallel SAs. I.e. if a packet get fragmented,
all its = fragments must be sent over single ESP SA.


Covere= d by the switch to MUST NOT.


Well, = this text is explicitly about "sequence numbers are reset when = switching SAs".
I think it's better to generalize it and say = that "packet fragmentation MUST not take
place over different = SAs". This will cover both cases - rekeying and parallel = SAs.

 

It's explaining the restriction. This adds = information/justification w/o changing the actual requirement. I think = that's a good thing not bad. 

 

          If you have = several parallel SAs their SNs are not reset, they are just = different...

          OK, I can live = with this, although I still think the text is a bit = confusing.

 

 

20. = Section 6.1.4:

 0:
    6 bits - = reserved, MUST be zero on send, unless defined by = later
    specifications.

Add a = sentence that these bits MUST be ignored on = receipt.


They = must not be ignored. If they are set and they and not understood then = AGGFRAG mode will not be
enabled as indicated in section = 5.1


Sectio= n 5.1 is about USE_AGGFRAG notification, here we talk about
Reserved = bits AGGFRAG_PAYLOAD. How they are related?

As implementer I have = a question - what should I do if these bits
are non-zero on receipt? = The draft is silent about = this.

 

I = think maybe you mixed something up in your reading? Section 6.1.4 = is:

 

"6.1.4.  = IKEv2 USE_AGGFRAG Notification = Message"

It is not about the = AGGFRAG_PAYLOAD.



          You are right, = I somehow mixed up these sections. That’s probably = because

          the = description of USE_AGGFRAG is split over 5.1 and 6.1.4, that =

          was a cause of = my confusion. I’d rather merge them not to confuse =

          other readers = :-)

          =

 

22. = Security Considerations.

Add a text that correct functionality of = the AGGFRAG mode
requires restoring packets order on the receiver. = Since this
is done by utilizing ESP Sequence Number field, the = ESP
header must be authenticated, and thus the ESP SA MUST
be = created with authentication other than NONE
or with AEAD = cipher.


I = think this falls under the non-IPTFS use case. I'd like to leave it out = as it would be confusing.


No, = it's about any use case of this mechanism.
ESP can be used without = authentication 
(although it's strictly = discouraged) and in this
if AGGFRAG is employed (regardless of = IP-TFS),
then an attacker can re-order packets on his/her will,
by = playing with SN field, so your reassembly mechanism won't = work.

 

You think I need to state that things are not secure = if the user turns off authentication?

 

          I think yes. = You may have ESP SA  w/o authentication, it’s not prohibited = by RFC 4303.

          In this case = replay protection won’t work (it may be OK for some = application).

          What I want is = to stress that AGGFRAG won’t work either in this = situation.

 

          = Regards,

          = Valery.

 

 

I would think that's covered already = by:

 

"

   Other =
than
   the additional security afforded by =
using this mechanism, IP-TFS
   =
utilizes the security protocols [RFC4303] and [RFC7296] and so =
their
   security considerations apply to =
IP-TFS as well.

"

 

Thanks,

Chris.




Regard= s,
Valery.

 

------=_NextPart_000_0442_01D70068.5621BF50-- From nobody Thu Feb 11 06:02:03 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB603A1613 for ; Thu, 11 Feb 2021 06:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 dXkrWXqYq80Y for ; Thu, 11 Feb 2021 06:01:59 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id B8B613A1611 for ; Thu, 11 Feb 2021 06:01:58 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8BE5660C05; Thu, 11 Feb 2021 14:01:57 +0000 (UTC) From: Christian Hopps Message-Id: <820F6E88-C832-43BC-897F-8BF61090CA20@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3E9677F4-8589-4755-828A-DF92E1818B63"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 11 Feb 2021 09:01:56 -0500 In-Reply-To: <044101d7004f$30cff370$926fda50$@gmail.com> Cc: Christian Hopps , Tero Kivinen , ipsec@ietf.org To: Valery Smyslov References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> <9E9A8E75-B269-4CFC-904B-272F3E1B59A4@chopps.org> <034d01d6ff87$db060140$911203c0$@gmail.com> <252DEFA7-AE92-4974-9ECE-2B8BD742FED2@chopps.org> <044101d7004f$30cff370$926fda50$@gmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 14:02:02 -0000 --Apple-Mail=_3E9677F4-8589-4755-828A-DF92E1818B63 Content-Type: multipart/alternative; boundary="Apple-Mail=_BBB7C41A-319D-471F-9C60-F190BD159006" --Apple-Mail=_BBB7C41A-319D-471F-9C60-F190BD159006 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Valery, I think we're getting a bit too caught in the details, to circle back: > I think that in its current form the draft is too focused on a single = application for > the Aggregation and Fragmentation mode - IP-TFS. =46rom architectural > point of view I'd like to see the draft first defining the mechanism = itself > and then describing possible applications for it, focusing on IP-TFS > as the primary application. > We discussed this with Christian off the list in length and came to > a good compromise regarding naming of new entities defined in the = draft. > After re-reading the draft I still think that its structure of the = document should be > changed to better decouple mechanism from its applications. The discussion in the WG over the last 2 years has focused on providing = a better TFS solution, indeed this is what the work is chartered to do. Your excellent observation that this work could be used in other ways = was spot on, and is reflected in the current text. Restructuring the draft to focus on a generic encapsulation solution = goes beyond the WG discussion and our chartered task. If the working = group consensus is to shift gears then that is what we can do; however, = the document is in WGLC and it's rather late in the process. I think = it's best to move forward with the current document as discussed in the = WG, and let the WG discuss other use cases in future documents. Thanks, Chris. > On Feb 11, 2021, at 3:23 AM, Valery Smyslov = wrote: >=20 > Hi Christian, >=20 > I agree with what Lou with regards to it going too far to = recast/redirect this work any further. I did do a round > of changes based on our agreement to help with future uses, and while = it's nice that this work could lead to > these uses, those should be documented in another document at this = point. The focus of this work has and > should continue to be traffic flow security. >=20 > Here we disagree. My point is that you define a very good mechanism > that can be used not only for IP-TFS, but for other purposes too. > I fully understand that IP-TFS was your primary focus and I agree > the document to remain focused on it. However, if the document > is kept in its current form any attempt to use it for other = applications > will look as an improper use of mechanism, because the way document > is organized highly ties the mechanism and its application. >=20 > A compromise and to address your concern that other uses might look = improper I've changed the abstract to include this final sentence: >=20 > "The mechanisms defined in this document are generic with the intent = of allowing for non-TFS uses, but such uses are outside the scope of = this document." >=20 > The introduction to include this final paragraph: >=20 > "The mechanisms defined in this document are generic with the intent = of allowing for non-TFS uses, but such uses are outside the scope of = this document." >=20 > And the "Packets and Data Formats" top level section to start: >=20 > "The packet and data formats defined below are generic with the intent = of allowing for non-IP-TFS uses, but such uses are outside the scope of = this document." >=20 > I believe this addresses your concern about other uses looking = improper. >=20 > That changes are the very minimal ones and in my opinion = they=E2=80=99re not enough. > The document still looks like a mess, because it constantly = used term =E2=80=9CIP-TFS=E2=80=9D > when describing a generic behavior of Aggregation and = Fragmentation mode. > Few examples: >=20 > 2. The IP-TFS Tunnel >=20 > As mentioned in Section 1 IP-TFS utilizes an IPsec [RFC4303] tunnel > (SA) as it's transport. To provide for full TFC, fixed-sized > encapsulating packets are sent at a constant rate on the tunnel. >=20 > The egress of the IP-TFS tunnel MUST allow for and expect the = ingress > (sending) side of the IP-TFS tunnel to vary the size and rate of = sent > encapsulating packets, unless constrained by other policy. >=20 > IP-TFS aggregates as well as fragments the inner IP traffic flow = into > fixed-sized encapsulating IPsec tunnel packets. >=20 > In particular IP-TFS never maps the inner DF bit as it is > unrelated to the IP-TFS tunnel functionality; IP-TFS never IP > fragments the inner packets and the inner packets will not affect = the > fragmentation of the outer encapsulation packets. Likewise, the = ECN > value need not be mapped as any congestion related to the constant- > send-rate IP-TFS tunnel is unrelated (by design!) to the inner > traffic flow >=20 > An example IP-TFS packet flow can be found in Appendix A. >=20 >=20 > And so on. I think the text must be cleaned up to be more = accurate > with this regard. >=20 >>> I've incorporated your other suggestions from below. >>=20 >> Please see my comments (I removed parts where we are in concert). >>=20 >>=20 >>> 9. Section 2.2.3: >>>=20 >>> When using the AGGFRAG_PAYLOAD in conjunction with replay = detection, >>> the window size for both MAY be reduced to share the smaller of the >>> two window sizes. This is b/c packets outside of the smaller = window >>> but inside the larger would still be dropped by the mechanism with >>> the smaller window size. >>>=20 >>> I wonder why MAY is used here. It should be MUST instead. >>> As you explained there is no point for the sizes to be different. >>=20 >> They remain different mechanisms and the user may wish to have them = treated differently (e.g., logging >> replayed packets). >>=20 >> My question was regarding "MAY" vs "MUST". Even if these are = different >> mechanisms, what is the reason for having different window sizes if = both mechanisms >> are employed? I may yet understand that reassembly window may be = shorter >> then replay window (you will just have a penalty of dropping too old = packets >> even when replay protection allows them in), but what may be the = reason >> for having reassembly window longer than replay window? If you have = some gaps >> at the far left end of reassembly window waiting for missing packets, >> you'll never receive them if replay window is shorter - they will = fall >> outside it. So, it's just a waste of resources. >=20 > The implementation may wish to allow the user to have replayed packets = logged (one can have a very large replay window w/o consuming many = resources). >=20 > Well, I probably was unclear, but you missed my point. = I=E2=80=99ll try again. > The current text says that if both replay protection and = AGGFRAG > are employed, then replay protection window and reassembling = window MAY > be of the same size, which is the smaller of both. >=20 > Since MAY means that you think it=E2=80=99s OK for these = windows to be of different > sizes in this case, I wondered in which situations you think = it=E2=80=99s OK. > You gave me an example, for situation when replay window is = longer than > reassembly window, which I can reluctantly buy (I still = think that it=E2=80=99s a waste > of resources: some delayed packets will pass the replay = protection, > decrypted and then dropped because they would fall outside = reassembly window). >=20 > But can you please give me an example when it=E2=80=99s = useful to have reassembly > window longer than replay protection window? >=20 > Consider an example when reassembly window size is 100 and = replay protection window size is 10. > For simplicity let=E2=80=99s assume that reassembly window = at the moment is filled with packets with odd SNs > starting from 1 to 99. So, you are waiting for the rest = packets with even SNs from 0 to 98 to be able > to complete reassembly process. But since replay protection = window size is only 10 and the > most recently received ESP packet has SN 99, you never = receive packets with SNs from 0 to 89, > (because the will be dropped by replay protection logic) and = the first 90 packets will never be reassembled. > It=E2=80=99s just a waste of resources. >=20 > So, I think that MAY above should be at least SHOULD. Or = leave it as MAY and say that > reassembly window SHOULD NOT (MUST NOT?) be longer that = replay protection (for the reason > outlined above). >=20 >=20 >>>> 10. Section 2.2.3: >>>>=20 >>>> Finally, as sequence numbers are reset when switching SAs (e.g., = when >>>> re-keying a child SA), an implementation SHOULD NOT send initial >>>> fragments of an inner packet using one SA and subsequent fragments = in >>>> a different SA. >>>>=20 >>>> Two issues here - first why SHOULD NOT and not MUST NOT? >>>> In general you cannot reliably reassemble packet if it is = fragmented over >>>> several SAs, so it will be dropped. Why do you allow this? >>>=20 >>> Changed to MUST NOT. >>>=20 >>>=20 >>> Then, IPsec architecture allows several parallel ESP SAs >>> to co-exist with the intention that kernel may use any of these SAs = to send packets >>> (e.g. for improving performance, see = draft-pwouters-multi-sa-performance). >>> I think you should mention that in this case a care must be taken = not to >>> fragment outgoing packets over several parallel SAs. I.e. if a = packet get fragmented, >>> all its fragments must be sent over single ESP SA. >>>=20 >>> Covered by the switch to MUST NOT. >>=20 >> Well, this text is explicitly about "sequence numbers are reset when = switching SAs". >> I think it's better to generalize it and say that "packet = fragmentation MUST not take >> place over different SAs". This will cover both cases - rekeying and = parallel SAs. >=20 > It's explaining the restriction. This adds information/justification = w/o changing the actual requirement. I think that's a good thing not = bad. >=20 > If you have several parallel SAs their SNs are not reset, = they are just different... > OK, I can live with this, although I still think the text is = a bit confusing. >=20 >=20 >>>> 20. Section 6.1.4: >>>>=20 >>>> 0: >>>> 6 bits - reserved, MUST be zero on send, unless defined by = later >>>> specifications. >>>>=20 >>>> Add a sentence that these bits MUST be ignored on receipt. >>>=20 >>> They must not be ignored. If they are set and they and not = understood then AGGFRAG mode will not be >>> enabled as indicated in section 5.1 >>=20 >> Section 5.1 is about USE_AGGFRAG notification, here we talk about >> Reserved bits AGGFRAG_PAYLOAD. How they are related? >>=20 >> As implementer I have a question - what should I do if these bits >> are non-zero on receipt? The draft is silent about this. >=20 > I think maybe you mixed something up in your reading? Section 6.1.4 = is: >=20 > " <>6.1.4 = . = IKEv2 USE_AGGFRAG Notification Message" >=20 > It is not about the AGGFRAG_PAYLOAD. >=20 >=20 > You are right, I somehow mixed up these sections. That=E2=80=99= s probably because > the description of USE_AGGFRAG is split over 5.1 and 6.1.4, = that > was a cause of my confusion. I=E2=80=99d rather merge them = not to confuse > other readers :-) >=20 >=20 >>> 22. Security Considerations. >>>=20 >>> Add a text that correct functionality of the AGGFRAG mode >>> requires restoring packets order on the receiver. Since this >>> is done by utilizing ESP Sequence Number field, the ESP >>> header must be authenticated, and thus the ESP SA MUST >>> be created with authentication other than NONE >>> or with AEAD cipher. >>=20 >> I think this falls under the non-IPTFS use case. I'd like to leave it = out as it would be confusing. >=20 > No, it's about any use case of this mechanism. > ESP can be used without authentication > (although it's strictly discouraged) and in this > if AGGFRAG is employed (regardless of IP-TFS), > then an attacker can re-order packets on his/her will, > by playing with SN field, so your reassembly mechanism won't work. >=20 > You think I need to state that things are not secure if the user turns = off authentication? >=20 > I think yes. You may have ESP SA w/o authentication, it=E2=80= =99s not prohibited by RFC 4303. > In this case replay protection won=E2=80=99t work (it may be = OK for some application). > What I want is to stress that AGGFRAG won=E2=80=99t work = either in this situation. >=20 > Regards, > Valery. >=20 >=20 > I would think that's covered already by: >=20 > " > Other than > the additional security afforded by using this mechanism, IP-TFS > utilizes the security protocols [RFC4303 = ] and [RFC7296 = ] and so their > security considerations apply to IP-TFS as well. > " >=20 > Thanks, > Chris. >=20 >=20 >=20 > Regards, > Valery. --Apple-Mail=_BBB7C41A-319D-471F-9C60-F190BD159006 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Valery,

I think = we're getting a bit too caught in the details, to circle back:

I = think that in its current form the draft is too focused on a single = application for
the Aggregation and Fragmentation mode - = IP-TFS. =46rom architectural
point of view I'd like to see = the draft first defining the mechanism itself
and then = describing possible applications for it, focusing on IP-TFS
as the primary application.

We discussed this with = Christian off the list in length and came to
a good = compromise regarding naming of new entities defined in the draft.
After re-reading the draft I still think that its structure = of the document should be
changed to better decouple = mechanism from its applications.

The discussion in the WG over = the last 2 years has focused on providing a better TFS solution, indeed = this is what the work is chartered to do.

Your excellent observation that this work could be used in = other ways was spot on, and is reflected in the current = text.

Restructuring the draft to = focus on a generic encapsulation solution goes beyond the WG = discussion and our chartered task. If the working group consensus is to = shift gears then that is what we can do; however, the document is in = WGLC and it's rather late in the process. I think it's best to move = forward with the current document as discussed in the WG, and let the WG = discuss other use cases in future documents.

Thanks,
Chris.

On Feb = 11, 2021, at 3:23 AM, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

Hi Christian,
 
I agree with what Lou with regards to it going too far to = recast/redirect this work any further. I did do a round
of changes based on our = agreement to help with future uses, and while it's nice that this work = could lead to
these uses, those should be documented in = another document at this point. The focus of this work has and
should continue to be traffic flow security.

Here we disagree. My point is that you = define a very good mechanism
that can be used not only for = IP-TFS, but for other purposes too.
I fully understand = that IP-TFS was your primary focus and I agree
the = document to remain focused on it. However, if the document 
is kept in = its current form any attempt to use it for other applications
will look as an improper use of mechanism, because the way = document
is organized highly ties the mechanism and its = application.
 
A compromise and to address your concern = that other uses might look improper I've changed the abstract to include = this final sentence:
 
"The mechanisms defined in this document are generic with the = intent of allowing for non-TFS uses, but such uses are outside the scope = of this document."
 
The introduction to include this final paragraph:
 
"The mechanisms defined in this document are generic with the = intent of allowing for non-TFS uses, but such uses are outside the scope = of this document."
 
And the "Packets and Data Formats" top = level section to start:
 
"The packet and data = formats defined below are generic with the intent of allowing for = non-IP-TFS uses, but such uses are outside the scope of this = document."
 
I believe this addresses = your concern about other uses looking improper.
 
          That = changes are the very minimal ones and in my opinion they=E2=80=99re not = enough.
          The = document still looks like a mess, because it constantly used term = =E2=80=9CIP-TFS=E2=80=9D
          when = describing a generic behavior of Aggregation and Fragmentation mode.
          Few = examples:
 
2.  = The IP-TFS= Tunnel
 
   As = mentioned in Section 1 IP-TFS utilizes an IPsec = [RFC4303] tunnel
   = (SA) as it's transport.  To provide for full TFC, fixed-sized
   encapsulating packets = are sent at a constant rate on the tunnel.
 
   The = egress of the IP-TFS tunnel MUST allow for and expect = the ingress
   (sending) = side of the IP-TFS tunnel to vary the size and rate = of sent
   = encapsulating packets, unless constrained by other policy.
 
   IP-TFS aggregates as well as = fragments the inner IP traffic flow into
   fixed-sized = encapsulating IPsec tunnel packets.  
 
   In = particular IP-TFS never maps the inner DF bit = as it is
   unrelated = to the IP-TFS tunnel functionality; IP-TFS never IP
   fragments the inner = packets and the inner packets will not affect the
   fragmentation of the = outer encapsulation packets.  Likewise, the ECN
   value need not be = mapped as any congestion related to the constant-
   send-rate IP-TFS = tunnel is = unrelated (by design!) to the inner
   traffic flow
 
   An example IP-TFS = packet flow can be = found in Appendix A.
 
 
          And so = on. I think the text must be cleaned up to be more accurate
          with = this regard.
 
I've incorporated your other suggestions from = below.

Please see my comments (I = removed parts where we are in concert).


9. Section 2.2.3:

 When = using the AGGFRAG_PAYLOAD in conjunction with replay detection,
 the window size for both MAY be reduced to share the = smaller of the
 two window sizes.  This is b/c = packets outside of the smaller window
 but inside the = larger would still be dropped by the mechanism with
 the smaller window size.

I = wonder why MAY is used here. It should be MUST instead.
As = you explained there is no point for the sizes to be different.

They remain different = mechanisms and the user may wish to have them treated differently (e.g., = logging
replayed packets).

My question was regarding "MAY" vs = "MUST". Even if these are different
mechanisms, what is = the reason for having different window sizes if both mechanisms
are employed? I may yet understand that reassembly window may = be shorter
then replay window (you will just have a = penalty of dropping too old packets
even when replay = protection allows them in), but what may be the reason
for = having reassembly window longer than replay window? If you have some = gaps
at the far left end of reassembly window waiting for = missing packets,
you'll never receive them if replay = window is shorter - they will fall
outside it. So, it's = just a waste of resources.
 
The = implementation may wish to allow the user to have replayed packets = logged (one can have a very large replay window w/o consuming many = resources).
 
          Well, = I probably was unclear, but you missed my point. I=E2=80=99ll try = again.
          The = current text says that if both replay protection and AGGFRAG 
          are = employed, then replay protection window and reassembling window MAY 
          be of = the same size, which is the smaller of both.
 
          Since = MAY means that you think it=E2=80=99s OK for these windows to be of = different
          sizes = in this case, I wondered in which situations you think it=E2=80=99s = OK.
          You = gave me an example, for situation when replay window is longer than 
          = reassembly window, which I can reluctantly buy (I still think that = it=E2=80=99s a waste
          of = resources: some delayed packets will pass the replay protection, 
          = decrypted and then dropped because they would fall outside reassembly = window).
 
          But = can you please give me an example when it=E2=80=99s useful to have = reassembly
          window = longer than replay protection window? 
 
          = Consider an example when reassembly window size is 100 and replay = protection window size is 10.
          For = simplicity let=E2=80=99s assume that reassembly window at the moment is = filled with packets with odd SNs 
          = starting from 1 to 99. So, you are waiting for the rest packets with = even SNs from 0 to 98 to be able
          to = complete reassembly process. But since replay protection window size is = only 10 and the 
          most = recently received ESP packet has SN 99, you never receive packets with = SNs from 0 to 89, 
          = (because the will be dropped by replay protection logic) and the first = 90 packets will never be reassembled.
          It=E2=80= =99s just a waste of resources.
 
          So, I = think that MAY above should be at least SHOULD. Or leave it as MAY and = say that 
          = reassembly window SHOULD NOT (MUST NOT?) be longer that replay = protection (for the reason
          = outlined above).


10. Section 2.2.3:

 Finally, = as sequence numbers are reset when switching SAs (e.g., when
 re-keying a child SA), an implementation SHOULD NOT = send initial
 fragments of an inner packet using one = SA and subsequent fragments in
 a different SA.

Two issues here - first why SHOULD NOT and not = MUST NOT?
In general you cannot reliably reassemble packet = if it is fragmented over
several SAs, so it will be = dropped. Why do you allow this?

Changed to MUST NOT.


Then, IPsec architecture allows several parallel ESP = SAs
to co-exist with the intention that kernel may use any = of these SAs to send packets
(e.g. for improving = performance, see draft-pwouters-multi-sa-performance).
I = think you should mention that in this case a care must be taken not = to
fragment outgoing packets over several parallel SAs. = I.e. if a packet get fragmented,
all its fragments must be = sent over single ESP SA.

Covered by the switch to MUST NOT.

Well, this text is = explicitly about "sequence numbers are reset when switching SAs".
I think it's better to generalize it and say that "packet = fragmentation MUST not take
place over different SAs". = This will cover both cases - rekeying and parallel SAs.
 
It's explaining the restriction. This = adds information/justification w/o changing the actual requirement. I = think that's a good thing not bad. 
 
          If you = have several parallel SAs their SNs are not reset, they are just = different...
          OK, I = can live with this, although I still think the text is a bit = confusing.
 
 
20. Section 6.1.4:

 0:
    6 bits - = reserved, MUST be zero on send, unless defined by later
    specifications.

Add a sentence that these bits MUST be = ignored on receipt.

They= must not be ignored. If they are set and they and not understood then = AGGFRAG mode will not be
enabled as indicated in section = 5.1

Section = 5.1 is about USE_AGGFRAG notification, here we talk about
Reserved bits AGGFRAG_PAYLOAD. How they are related?

As implementer I have a question - what should = I do if these bits
are non-zero on receipt? The draft is = silent about this.
 
I think maybe you mixed something up in = your reading? Section 6.1.4 is:
 

"6.1.4.  IKEv2 USE_AGGFRAG Notification = Message"

It is = not about the AGGFRAG_PAYLOAD.


          You = are right, I somehow mixed up these sections. That=E2=80=99s probably = because
          the = description of USE_AGGFRAG is split over 5.1 and 6.1.4, that 
          was a = cause of my confusion. I=E2=80=99d rather merge them not to confuse 
          other = readers :-)
          
 
22. Security Considerations.

Add a text that correct functionality of the = AGGFRAG mode
requires restoring packets order on the = receiver. Since this
is done by utilizing ESP Sequence = Number field, the ESP
header must be authenticated, and = thus the ESP SA MUST
be created with authentication other = than NONE
or with AEAD cipher.

I think this falls = under the non-IPTFS use case. I'd like to leave it out as it would be = confusing.

No, = it's about any use case of this mechanism.
ESP can be used = without authentication 
(although = it's strictly discouraged) and in this
if AGGFRAG is = employed (regardless of IP-TFS),
then an attacker can = re-order packets on his/her will,
by playing with SN = field, so your reassembly mechanism won't work.
 
You think I = need to state that things are not secure if the user turns off = authentication?
 
          I = think yes. You may have ESP SA  w/o authentication, it=E2=80=99s = not prohibited by RFC 4303.
          In = this case replay protection won=E2=80=99t work (it may be OK for some = application).
          What I = want is to stress that AGGFRAG won=E2=80=99t work either in this = situation.
 
          = Regards,
          = Valery.
 
 
I would think that's = covered already by:
 
"
   Other than
   the additional security afforded by using this =
mechanism, IP-TFS
   utilizes the security =
protocols [RFC4303] and =
[RFC7296] and so their
   security considerations apply to IP-TFS as =
well.
"
 
Thanks,
Chris.



Regards,
Valery.
=
= --Apple-Mail=_BBB7C41A-319D-471F-9C60-F190BD159006-- --Apple-Mail=_3E9677F4-8589-4755-828A-DF92E1818B63 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAlONQACgkQLh2DDte4 MCXKJA//dq8ari2NJET14C7fuxxF8ETsm6z5+zqz057AOO68OLKbH5+EV/5zxnsg SttBxTpzGR2XlXuzZDMHLIRb0ZTsFod6vQaXL/81EKQcBW+7nj9mIy9124jWAFfH dl+X7501mr1HsZMnzQRBf1CYZ6IwvtiKfeGNTgwAwd5ocKIUskiO9mhe/bb5d2Ei JidvdkeB1A0N8qPtRIA58QHzqgwcPxwXv4uX3U+0EhOTQAW5auckz7xHDIYQ2O3n HGYD8i86EwqwqTiWLggC1FjUfmT3QbWiwnP/ckoKk+5gRSthtn15aP1O5rCNgyt0 UANYofF1uLeCQmZhe9LA8Bc6lhfrb6qsG6v95Vfd2EtWKEH20aTMYWijau1ET5+Q JxGGMXdEBFGYM7/UZe34bvyz3QImHo6mZXPAOFfCwY/o1x+J5g3fNKwhTGb+shrk ESq52uQTCiCjdfLYt4tVGR/uzB6xzg+ZcCmbvBgE8XhQPeb+FBGFDZx1pp3SR6hn Cp/INBuEcmxTv17ePT+Ip4Dpe8u/56vKlsQNJJiVUGIugxEAsBK2RNL3smRs6PQo uF619InxOPgD2SlxUJogk4PqFq2PGQ524DEakIIOAxXCFJR96cItW+XWNTJp2xXn 476+g2/y0Csp6I5tyQFo7XwvZX9apowSXJy8x1B9tCQvUp+MYu4= =7l7W -----END PGP SIGNATURE----- --Apple-Mail=_3E9677F4-8589-4755-828A-DF92E1818B63-- From nobody Thu Feb 11 11:17:04 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5045D3A187E for ; Thu, 11 Feb 2021 11:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 rY_mut25aLhC for ; Thu, 11 Feb 2021 11:17:01 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 CDF023A187B for ; Thu, 11 Feb 2021 11:17:00 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 8CECC20230; Thu, 11 Feb 2021 21:16:54 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1613071014; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Frhlwr9NWQI7eMRYc5oz84ITykSjLnhKZo45IZUV2P4=; b=kpIP3Ocyo+zTHdn8+gQD9NcgOZNHSacL1MVeHM78ar7D87S6B9D3Ma4tQYZPeAM4lvbQcP N1TkaT3PY99VqRwIWZ99EtcNMForwrj0b+CSSbDlM4+gHWQDyNuAp2vfs/83UpG3iBJwLg Q5/B3OJmQ68/QmGUve0AD+hiJSiP4X0= Received: by fireball.acr.fi (Postfix, from userid 15204) id 5A37A25C143B; Thu, 11 Feb 2021 21:16:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24613.33445.314481.788667@fireball.acr.fi> Date: Thu, 11 Feb 2021 21:16:53 +0200 From: Tero Kivinen To: Christian Hopps Cc: Valery Smyslov , ipsec@ietf.org In-Reply-To: <820F6E88-C832-43BC-897F-8BF61090CA20@chopps.org> References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> <9E9A8E75-B269-4CFC-904B-272F3E1B59A4@chopps.org> <034d01d6ff87$db060140$911203c0$@gmail.com> <252DEFA7-AE92-4974-9ECE-2B8BD742FED2@chopps.org> <044101d7004f$30cff370$926fda50$@gmail.com> <820F6E88-C832-43BC-897F-8BF61090CA20@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 52 min ARC-Seal: i=1; s=meesny; d=iki.fi; t=1613071014; a=rsa-sha256; cv=none; b=KfOJsnNuFkHccWyDAmypAKcu1yH56snnUUpyYoZThxKYS5hpwFvG0xc+HdoxlgwEZAMQNg aKyNuBbMHt/cw/tTFav8nSXvovoH4GHTaIXwAdHkIXl0vTRoaYOrVUR1jjQJjScNdtzcj8 nLk35Y6H9+yiIt2k5bPcb8N7vPOZMuE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1613071014; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Frhlwr9NWQI7eMRYc5oz84ITykSjLnhKZo45IZUV2P4=; b=YZfCXe18fbumJvYHtWyyCdW3rK6gpjFLZ9Q4AYGCiHoC0nUcXP2ouUXhsq+QIK7r7Mvy4/ CPuoh+4r9R2okiIV7FtLUvep0gxd8WRCfAOz7QFSJ2iBM7+BPfu4+6HSIXBxRRCbDh6dGZ 3rbwDavSCUUxCiypYQEyD87NO1lbcWs= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 19:17:03 -0000 Christian Hopps writes: WGLC is not too late to do changes, it is quite early in the process, we still need to go to the IETF LC, and then through IESG etc. If making these changes now will make document easier to read, that will most likely make IETF LC and further steps easier, so it might save some time and effort from us later. And about the charter, as long as we do get the TFS solution out of that is fine for the charter. We are trying to provide solution to the problem described in the our charter, the charter usually does not try to dictate what the final solution will be, just describe the problem that we need to solve. Our charter says: The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. An example of this is that when we started working on the post quantum cryptography, we realized we need this auxiliary exchange to solve the issue, but then we realized that this could also be used for something else, and it was renamed to intermediate exchange etc. So while working for one solution we can also generate more generic protocol that can be used to perhaps solve other problems in the future, even better. Of course making the protocol more complicated by making it more general is not necessarely good idea, thus sometimes it is better to make more restricted protocol just for simplicitys sake. But my understanding is that here we do not need any protocol changes, just reordering of the document to make it more clear that we have two layers where the first one can be used for other things too, and that the second part uses that first layer as it building block. -- kivinen@iki.fi From nobody Thu Feb 11 14:52:42 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ED13A0D8A for ; Thu, 11 Feb 2021 14:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 QYg475GQJcAS for ; Thu, 11 Feb 2021 14:52:38 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 189C63A0D74 for ; Thu, 11 Feb 2021 14:52:37 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 2B6EE60C05; Thu, 11 Feb 2021 22:52:37 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D4A14E39-72E7-470C-9EF0-EA979E245546"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 11 Feb 2021 17:52:36 -0500 In-Reply-To: <24613.33445.314481.788667@fireball.acr.fi> Cc: Christian Hopps , Valery Smyslov , ipsec@ietf.org To: Tero Kivinen References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> <9E9A8E75-B269-4CFC-904B-272F3E1B59A4@chopps.org> <034d01d6ff87$db060140$911203c0$@gmail.com> <252DEFA7-AE92-4974-9ECE-2B8BD742FED2@chopps.org> <044101d7004f$30cff370$926fda50$@gmail.com> <820F6E88-C832-43BC-897F-8BF61090CA20@chopps.org> <24613.33445.314481.788667@fireball.acr.fi> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 22:52:40 -0000 --Apple-Mail=_D4A14E39-72E7-470C-9EF0-EA979E245546 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tero, I'm sorry some of the previous messages HTML at some point the message = got converted to that format. I actually prefer text as well. It was not my intention to say anything was too late to change, only = that the WG has been discussing an IP-TFS solution for 2 years. This = reorganization of the document obfuscates that and turns the document = into a generic encapsulation document, with IP-TFS as a after-though. If = that's the consensus of the WG then that is what we will do of course. I personally feel this is totally unneeded, it makes things harder to = understand for someone actually trying to implement a TFS solution which = is the chartered goal. Is this the WG consensus, that we should have a generic new ESP = encapsulation document? I have only seen Valery ask for these changes so = far. I would like to ask for WG consensus before we switch directions like = this. Thanks, Chris. > On Feb 11, 2021, at 2:16 PM, Tero Kivinen wrote: >=20 > Christian Hopps writes: > properly as it was in HTML format and my client could not parse that > html out for quoting> >=20 > WGLC is not too late to do changes, it is quite early in the process, > we still need to go to the IETF LC, and then through IESG etc. If > making these changes now will make document easier to read, that will > most likely make IETF LC and further steps easier, so it might save > some time and effort from us later. >=20 > And about the charter, as long as we do get the TFS solution out of > that is fine for the charter. We are trying to provide solution to the > problem described in the our charter, the charter usually does not try > to dictate what the final solution will be, just describe the problem > that we need to solve. >=20 > Our charter says: >=20 > The demand for Traffic Flow Confidentiality has been > increasing in the user community, but the current method > defined in RFC4303 (adding null padding to each ESP payload) > is very inefficient in its use of network resources. The > working group will develop an alternative TFC solution that > uses network resources more efficiently. >=20 > An example of this is that when we started working on the post quantum > cryptography, we realized we need this auxiliary exchange to solve the > issue, but then we realized that this could also be used for something > else, and it was renamed to intermediate exchange etc. So while > working for one solution we can also generate more generic protocol > that can be used to perhaps solve other problems in the future, even > better. Of course making the protocol more complicated by making it > more general is not necessarely good idea, thus sometimes it is better > to make more restricted protocol just for simplicitys sake. >=20 > But my understanding is that here we do not need any protocol changes, > just reordering of the document to make it more clear that we have two > layers where the first one can be used for other things too, and that > the second part uses that first layer as it building block. > -- > kivinen@iki.fi >=20 --Apple-Mail=_D4A14E39-72E7-470C-9EF0-EA979E245546 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAltTQACgkQLh2DDte4 MCVlUw//R1db5oPhCep7YSchwiwNAwcndCf7E1L3gRknbkGY4JEm6WY5Gjer8Az8 bxTsZUleq6gce9HhMHV0viNmZSoa6xN9WTMDTM0Q19bpT7MKZu58MF8YUdE0BCQl whyXwgUweEc0MHNkFW61zC4VKBHXl22Tei+obdcaktvPCHYJbxfckecim9ziqYqW CHp30z9sGB2ioa0XniTjA6AYZGFN7zZUrVuduPMNubP6CrvP+l881g5h85DHvgOC a1CIL4jP4QFqhJnbb4iydqbIT5RUEE508gbNIXbCLFGmMhN+7UxcKO2EJhKX6JdZ tub1pdPxefiKKWkst57AmEFYOzCy9ssl528/l357JCgnNHIng4JHNudhTiKzwwVb FXSJwbdKGwSexDF3MRPs5FxbSKRQH07/+vAaQ57kyqOK1c7FdOqNT4iC3QIGxYcw +U4+CcS+X2pPmh7FYrzYURgZ12oHGA3nEuqnwCrkScKG8ffmqjW5dFnmgPolCzM2 P19LxoZP5K7E15+gasaiHUwD5q8lHPNVPfjrUWdWAIhGPO5SOme2aVMLozKHLYBZ uPhuVgbMOONWu5VCzNkuJvisFDjZNvgTRTkCZWpuPFhZDNbV8xG9RTUxk7JlIm+P 1lJsWlH7QJk67InW+LYHgLgMZmDwhxYiFkL6wVFl+sKPelr/RFE= =pikV -----END PGP SIGNATURE----- --Apple-Mail=_D4A14E39-72E7-470C-9EF0-EA979E245546-- From nobody Thu Feb 11 20:36:13 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B89E3A11D8 for ; Thu, 11 Feb 2021 20:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 L416719cFuQR for ; Thu, 11 Feb 2021 20:36:09 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id AE2F03A11D5 for ; Thu, 11 Feb 2021 20:36:09 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1DBF560C05; Fri, 12 Feb 2021 04:36:08 +0000 (UTC) From: Christian Hopps Message-Id: <3B6C2BEF-4B9B-48A3-A52D-E8184613CD7F@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_4D34AEDD-04CD-4A9F-8CFD-53995A1A2A26"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 11 Feb 2021 23:36:07 -0500 In-Reply-To: Cc: Christian Hopps , ipsec@ietf.org, Valery Smyslov To: Tero Kivinen References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> <9E9A8E75-B269-4CFC-904B-272F3E1B59A4@chopps.org> <034d01d6ff87$db060140$911203c0$@gmail.com> <252DEFA7-AE92-4974-9ECE-2B8BD742FED2@chopps.org> <044101d7004f$30cff370$926fda50$@gmail.com> <820F6E88-C832-43BC-897F-8BF61090CA20@chopps.org> <24613.33445.314481.788667@fireball.acr.fi> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 04:36:11 -0000 --Apple-Mail=_4D34AEDD-04CD-4A9F-8CFD-53995A1A2A26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tero, Just to clarify, are you indicating Valery's changes should be made? If = so then I will update the document so we can continue to make progress. Thanks, Chris. > On Feb 11, 2021, at 5:52 PM, Christian Hopps = wrote: >=20 > Signed PGP part > Hi Tero, >=20 > I'm sorry some of the previous messages HTML at some point the message = got converted to that format. I actually prefer text as well. >=20 > It was not my intention to say anything was too late to change, only = that the WG has been discussing an IP-TFS solution for 2 years. This = reorganization of the document obfuscates that and turns the document = into a generic encapsulation document, with IP-TFS as a after-though. If = that's the consensus of the WG then that is what we will do of course. >=20 > I personally feel this is totally unneeded, it makes things harder to = understand for someone actually trying to implement a TFS solution which = is the chartered goal. >=20 > Is this the WG consensus, that we should have a generic new ESP = encapsulation document? I have only seen Valery ask for these changes so = far. >=20 > I would like to ask for WG consensus before we switch directions like = this. >=20 > Thanks, > Chris. >=20 >> On Feb 11, 2021, at 2:16 PM, Tero Kivinen wrote: >>=20 >> Christian Hopps writes: >> > properly as it was in HTML format and my client could not parse that >> html out for quoting> >>=20 >> WGLC is not too late to do changes, it is quite early in the process, >> we still need to go to the IETF LC, and then through IESG etc. If >> making these changes now will make document easier to read, that will >> most likely make IETF LC and further steps easier, so it might save >> some time and effort from us later. >>=20 >> And about the charter, as long as we do get the TFS solution out of >> that is fine for the charter. We are trying to provide solution to = the >> problem described in the our charter, the charter usually does not = try >> to dictate what the final solution will be, just describe the problem >> that we need to solve. >>=20 >> Our charter says: >>=20 >> The demand for Traffic Flow Confidentiality has been >> increasing in the user community, but the current method >> defined in RFC4303 (adding null padding to each ESP payload) >> is very inefficient in its use of network resources. The >> working group will develop an alternative TFC solution that >> uses network resources more efficiently. >>=20 >> An example of this is that when we started working on the post = quantum >> cryptography, we realized we need this auxiliary exchange to solve = the >> issue, but then we realized that this could also be used for = something >> else, and it was renamed to intermediate exchange etc. So while >> working for one solution we can also generate more generic protocol >> that can be used to perhaps solve other problems in the future, even >> better. Of course making the protocol more complicated by making it >> more general is not necessarely good idea, thus sometimes it is = better >> to make more restricted protocol just for simplicitys sake. >>=20 >> But my understanding is that here we do not need any protocol = changes, >> just reordering of the document to make it more clear that we have = two >> layers where the first one can be used for other things too, and that >> the second part uses that first layer as it building block. >> -- >> kivinen@iki.fi >>=20 >=20 >=20 >=20 --Apple-Mail=_4D34AEDD-04CD-4A9F-8CFD-53995A1A2A26 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAmBbcACgkQLh2DDte4 MCXj5RAAjMJXjKwYYI53U1BptBuWq8/YukQpHXKKMSbTnMCVE/I8ZldnzDz1CR/x 4ny0q9K4fDSCfSGX9ZpP4qVXRYYAavuLbSnInP+HjsRKTxU2lLVA4ZklrY+v/E+g px34XfQsG05wPbBBWqb7Qj5KmsKCBuQ9gPWYebeuNTwHFztn0griLinXoIY721c1 hwMSo0EvJtSH0G4Yr8EYO5MCAObxP6ny4BZa4G5DhjTrwmiAD1Z7apJub2D4OE73 7n+eFqFj//GJKnrnFVvCirauXc1RhXzWSalP4D6GLXUYhIC9ED494OypHAhwIJ/9 zn2bdgtSEf7ptCIDn4/7oIBuyu4o2MU4ez73/Ds8NE1TqBjsw7/AwvSFhkwl5oKM feTf2vC06qTjKmCkdAn41nbQwvIsQRIFfoP4vkGZy5qHXoL7sxyXHVOK0YkAEfuh oTgu86Vun4UYMujog9dssf/VZtU8BGqzqFWZIBkot+POS75Iayq5YxHl8tP6o9oT 704luhJf7PgBizE2OVySBlFaPF5JwlS4zHrMod/Ofd8BOq6WK4+gfJaCVmu6slnl DoGcj4M1yv5cgCe1IY0ronpKF9vX4moc2+wqTb/ilpnzybet6tuaOgby4pjYlaGR lSOLDAwjy5tXJKXwAc41FfFzKJijoOIQLRYbE8DXWI9lGsEOrZ8= =B2N4 -----END PGP SIGNATURE----- --Apple-Mail=_4D34AEDD-04CD-4A9F-8CFD-53995A1A2A26-- From nobody Fri Feb 12 06:30:55 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C3B3A16EC for ; Fri, 12 Feb 2021 06:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 VHnhdbQMq_2c for ; Fri, 12 Feb 2021 06:30:50 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 A547A3A16EA for ; Fri, 12 Feb 2021 06:30:50 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id c5so6819607qth.2 for ; Fri, 12 Feb 2021 06:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=spBZX1iMr6jhKFejyj3uX4lt+5G/NEs9l9IrhEk+zME=; b=bfTWJkldZPd9HkDjp8lzvHeg2zK/bBAljHuDEg5xu6pF15/rNSeVXXWvrnJtL/l2g/ 2Rim+43g9JzHM5EArs+yhSvqavHyhjN4Myw2AXwd97Q9l50DMBAgRMUIlG8naYLXMOXB Nxuf+IDuiPFgG1uk/LbrKRCTi+m/Ifsi/1aek= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=spBZX1iMr6jhKFejyj3uX4lt+5G/NEs9l9IrhEk+zME=; b=A8oLhPuDRtotj+gYgJwCypl9HFDLoebv1SL1Y9ryO44aIwb7G6bydSwLEkdOFSAaNF DXLFfAKplqEOgg6n+wR7BjtrQ/2OGTEqRGKviKA6T4If1qHsphaPX7NXkwgdh4ZNervE 9i+nYDt7CtAw2VXRd+YNQBNj/FydqhR90StssD1Iv1UISdMdqOTw2Gb7nPQYRdbgCc+N kw0uS6OWNdE2lfy+Yilde6Bnpj4rjTxrq1Ie1Pj76US72S6kZCTqoxvCOUo3ZxuR3vjI M04Oe81OMTkGGcM7+T/0OfuNye4naLBuniODqJWajWXmoC9y1UVUBLbKWVFDcFeoHHFO ie4g== X-Gm-Message-State: AOAM530DZcpeepM7sSAw7Qf4cLSn7nGX9D/Q/7qoSUE5weKJdoL+mjBj NdYa2h7mEjEnK1Vax8RQ9f60Qg== X-Google-Smtp-Source: ABdhPJzBo2HAmQeEeE8Aa8qGu52ClBeJYwRlh0pXNZE2qWaNNQdZLu1iFFJaqMRS/pidZU4sVAIjew== X-Received: by 2002:ac8:5854:: with SMTP id h20mr2634097qth.301.1613140249443; Fri, 12 Feb 2021 06:30:49 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id c127sm6382430qkd.87.2021.02.12.06.30.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Feb 2021 06:30:48 -0800 (PST) From: Sean Turner Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E4D51EF1-20E6-4F88-8A9F-DE9F0A749F71"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 12 Feb 2021 09:30:47 -0500 In-Reply-To: <2B7B497D-8759-4E48-85A3-190DC213A5C6@chopps.org> Cc: ipsec@ietf.org To: Christian Hopps References: <24590.9470.995873.674029@fireball.acr.fi> <569B8D50-F0B3-4EA1-8A1D-EFB9BD674578@sn3rd.com> <2B7B497D-8759-4E48-85A3-190DC213A5C6@chopps.org> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 14:30:54 -0000 --Apple-Mail=_E4D51EF1-20E6-4F88-8A9F-DE9F0A749F71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Chris, Thanks for wading through these. Incorporating these will certainly = remove any issues I had. As far as the style suggestions goe, that=E2=80=99= s fine the GENART, IESG, and RFC editor will also ask for their pound of = flesh ;) Spt > On Feb 8, 2021, at 18:19, Christian Hopps wrote: >=20 >=20 >=20 >> On Feb 3, 2021, at 10:38 PM, Sean Turner wrote: >>=20 >> Hi! I mostly just have nits, but there are a couple of questions = interspersed below. >=20 > Hi Sean, >=20 > Thanks so much for this very thorough review! >=20 > I have made the vast majority of the suggested changes with only a few = style exceptions (and incorporated Paul's input in his follow-on email). >=20 > I will post a new version soon with these changes (noted below) as = well as addressing some from Valery as well. >=20 >> s1, para 1: s/While one may directly obscure the data through the use = of/While directly obscuring the data with >=20 > Fixed >=20 >> s1, para 1: s/it=E2=80=99s/its >>=20 >=20 > Fixed >=20 >> s1, para 3: s/IP-TFS/IP-TFS (IP Traffic Flow Security) >=20 > Fixed >=20 >>=20 >> s1, last para: s/IP-TFS provides for dealing with network = congestion/IP-TFS addresses network congestion >=20 > "Additionally, IP-TFS provides for operating fairly within congested = networks" >=20 >> s1: You mention full TFC. Is it partial TFC if you use a non-constant = send-rate? if so that might be good to qualify in the 3rd paragraph with = something like: >=20 >> OLD: >>=20 >> A non- >> constant send-rate is allowed, but the confidentiality properties of >> its use are outside the scope of this document. >>=20 >> NEW: >>=20 >> A non- >> constant send-rate is allowed to support partial TFC, but the >> confidentiality properties of its use are outside the scope of >> this document. >=20 > There are other ideas being studied to achieve full TFC w/o use of = constant send-rate (e.g., using some sort of randomizing), I'm fairly = sure that this just reduces to a lower logical fixed send rate that = utilizes burstiness. In any case since I am aware of there being = research being done in this area I think leaving the text as is makes = sense (i.e., I don't want to claim anything not fixed-rate must be = partial TFC). >=20 >>=20 >> s1.1, para 1: Use updated terminology para from 8174 ("BCP 14=E2=80=9D = is missing): >>=20 >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", >> "MAY", and "OPTIONAL" in this document are to be interpreted as >> described in BCP 14 [RFC2119] [RFC8174] when, and only when, they >> appear in all capitals, as shown here. >=20 > Fixed. >=20 >>=20 >> s2, para 1: >>=20 >> is the "(SA)" needed? ... tunnel (SA) ... >> s/it=E2=80=99s/its >=20 > Fixed. >=20 >> s2, 2nd para: I tripped over this para a couple of times. Does this = get the same point across? >>=20 >> OLD: >>=20 >> The primary input to the tunnel algorithm is the requested bandwidth >> used by the tunnel. Two values are then required to provide for this >> bandwidth, the fixed size of the encapsulating packets, and rate at >> which to send them. >>=20 >> NEW: >>=20 >> The primary input to the tunnel algorithm is the requested >> bandwidth for the tunnel. Two values needed to determine >> the bandwidth are the fixed size of the encapsulating >> packets and the rate at which to send them. >=20 > Changed to: >=20 > The primary input to the tunnel algorithm is the requested bandwidth > to be used by the tunnel. Two values are then required to provide for > this bandwidth use, the fixed size of the encapsulating packets, and > rate at which to send them. >=20 >> s2, 3rd para: s/or could be/or be >=20 > Fixed >=20 >> s2, 4th para: s/requested tunnel used bandwidth/ >> requested tunnel bandwidth >=20 > Changed to: >=20 > "requested bandwidth to be used" >=20 > and "The packet send rate is the requested bandwidth to be used = divided by the size of the encapsulating packet." >=20 >=20 >> s1, last para to make it match the rest of the sentence: s/The egress = of the IP-TFS/The egress (receiving) side of the IP-TFS >=20 > Fixed. >=20 >>=20 >> s2.1, 1st para: s/In order to maximize bandwidth IP-TFS/ >> In order to maximize bandwidth, IP-TFS >=20 > Fixed >=20 >>=20 >> s2.1, 3rd para: Does this say the same thing: >>=20 >> OLD: >>=20 >> This is accomplished using a new Encapsulating Security Payload (ESP, >> [RFC4303]) type which is identified by the number AGGFRAG_PAYLOAD >> (Section 6.1). >>=20 >> NEW: >>=20 >> IP-TFS uses a new Encapsulating Security Payload (ESP, [RFC4303]) >> type identified by the number assigned to AGGFRAG_PAYLOAD >> (Section 6.1). >=20 > I think I prefer the original text, if that's OK, as it is saying how = it does the paragraph above vs. just making another statement (i.e., I = think it ties the text together better). >=20 >> s2.2: I had a really hard time parsing this sentence: >>=20 >> The AGGFRAG_PAYLOAD payload content defined in this document is >> comprised of a 4 or 24 octet header followed by either a partial, a >> full or multiple partial or full data blocks. >>=20 >> There are three options: partial, full or multiple partial, or full = data? Maybe it=E2=80=99s just missing a comma: s/multiple partial = or/multiple partial or, >=20 > Changed to: >=20 > The AGGFRAG_PAYLOAD payload content defined in this document is > comprised of a 4 or 24 octet header followed by either a partial > datablock, a full datablock, or multiple partial or full datablocks. >=20 >>=20 >> s2.2.1: Should we be specific about the IPv4 and IPv6 length=E2=80=99s = field name: >>=20 >> OLD: >>=20 >> Likewise, the length of the data block is extracted from the >> encapsulated IPv4 or IPv6 packet's length field. >>=20 >> NEW: >>=20 >> Likewise, the length of the data block is extracted from the >> encapsulated IPv4=E2=80=99s Total Length or IPv6=E2=80=99s Payload = Length fields. >=20 > Fixed >=20 >>=20 >> s2.2: s/It=E2=80=99s/It is >> s2.2.3: s/to be able to reassemble/to reassemble >> s2.2.3: s/This possible interleaving/This interleaving >> s2.2.3: s/sender to always be able to send a/sender to always send a >> s2.2.3, 4th para: s/Finally, we note/Finally, note >> s2.2.3, 5th para: s/As the amount of reordering that may be present = is hard to predict the window/As the amount of reordering that may be = present is hard to predict, the window >=20 > Fixed. >=20 >>=20 >> 2.2.3, 5th para: I am all about not littering I-Ds with = 2119-language, but here it looks like you are burying the MUST in the = parenthetical. BTW - I think the sentence stands on its own without the = "i.e.=E2=80=9D and it could safely be deleted. Would this rewording = work: >>=20 >> Gaps in the sequence numbers will not work for this document, >> therefore ESP sequence number stream MUST increase monotonically >> by 1 for each subsequent packet. >=20 > Fixed >=20 >>=20 >> s2.2.3, penultimate para: s/b/c/because >=20 > Fixed >=20 >> s2.2.3, last para: Should the I-D state what happens if the = implementation does send initial fragments of an inner packet using one = SA and subsequent fragments in a different SA. I.e., motivate the SHOULD = NOT. >>=20 >> s2.2.3, last para: implementation here refers to sender right so = maybe: senders SHOULD NOT >=20 > Simplified to "senders MUST NOT"... :) >=20 >> s2.2.3.1: Implementations here refers to senders so maybe: >> s/An implementation/Senders >> s/Implementation implementing/Senders implementing ;) >=20 > Fixed >=20 >> s2.2.4: s/In order to support/To support >=20 > Fixed >=20 >> s2.2.5, 1st para: >> s/(by design!)/(by design) ;) >> s/although an implementation/although a sender >> s/An implementation SHOULD/A sender SHOULD >=20 > Fixed >=20 >> s2.2.5, 2nd para: >> s/an implementation/a sender >> s/([RFC3168])/[RFC3168] >=20 > Fixed >=20 >> s2.2.6, 1st para: s/([RFC0791])/[RFC0791] >=20 > Fixed, and update other single refs to not use parens. >=20 >> s2.2.6, 2nd para: 2119 the should?: s/should be/SHOULD be. Is there = a reason you would want to handle the errors differently? If not then = would the following also be true (i.e., replace "should be" with "are": >>=20 >> Any errors (e.g., ICMP errors arriving back at the tunnel ingress due >> to tunnel traffic) are handled the same as with non IP-TFS >> IPsec tunnels. >=20 > Fixed >=20 >> s2.2.7, 1st para: s/am implementation/a sender >=20 > Fixed >=20 >>=20 >> s2.2.7, 2nd para: s/([RFC4301])/[RFC4301] >=20 > Fixed >=20 >> s2.3: Does this work? >>=20 >> OLD: >>=20 >> It is not the intention of this specification to allow >> for mixed use of an AGGFRAG_PAYLOAD enabled SA. >>=20 >> NEW: >>=20 >> This document does not specify mixed use of an >> AGGFRAG_PAYLOAD enabled SA. >=20 > Fixed >=20 >> s2.4.1, 1st para: s/In the non-congestion controlled mode IP_TFS /In = the non-congestion controlled mode, IP-TFS >=20 > Fixed >=20 >> s2.4.1, 2nd para: >> Should the should be SHOULD? >> s/In this case packet/In this case, packet >> There is a reference to a user. Is it really a user? >=20 > I think it's a should (non-normative), as this is guidance on the = right way to deploy IPTFS, but not how to implement it. >=20 >> s2.4.2, 2nd para: >> s/the ingress sends/the ingress side sends >> Maybe just swap this around? >>=20 >> OLD: >>=20 >> An example of an implementation of the [RFC5348] algorithm which >> matches the requirements of IP-TFS (i.e., designed for fixed-size >> packet and send rate varied based on congestion) is documented in >> [RFC4342]. >>=20 >> NEW: >>=20 >> [RFC4342] provides an example of the [RFC5348] algorithm which >> matches the requirements of IP-TFS (i.e., designed for fixed-size >> packet and send rate varied based on congestion. >=20 > Fixed. >=20 >> s2.4.2, 3rd para: s/In particular these/In particular, these >=20 > Fixed >=20 >> s2.4.2, 4th para: >> Should the must be MUST? >> s/The lack of receiving this information/Not receiving this = information >=20 > Yes, and fixed. >=20 >> s2.4.2, 4th and 5th paras: s/it=E2=80=99s/its >=20 > Fixed >=20 >> s2.4.2, 6th para: Does this work? >>=20 >> OLD: >>=20 >> When an implementation is choosing a congestion control algorithm (or >> a selection of algorithms) one should remember that IP-TFS is not >> providing for reliable delivery of IP traffic, and so per packet ACKs >> are not required and are not provided. >>=20 >> NEW: >>=20 >> When choosing a congestion control algorithm (or >> a selection of algorithms) note that IP-TFS is not >> providing for reliable delivery of IP traffic, and so per packet ACKs >> are not required and are not provided. >=20 > Fixed >=20 >> s2.4.2, last para: s/It=E2=80=99s/It is >=20 > Fixed >=20 >> s3, 1st para: >> s/and also be able to approximate/and also to approximate >> s/([RFC5348])/[RFC5348] >> s/In order to obtain these values the/ >> In order to obtain these values, the >> s/Thus in order, to support/Thus, to >=20 > Fixed >=20 >> s/is used to convey/conveys >=20 > This is a style one I think that I'd like to leave be, I think it = better highlights that one needs to send these empty payloads in this = case. >=20 >> s3, 1st and 3rd para: s/it=E2=80=99s/its >=20 > Fixed. >=20 >>=20 >> s3, 3rd para: Nits complained about this so I am assuming it=E2=80=99s = MUST NOT here - s/MUST not/MUST NOT >=20 > Fixed >=20 >>=20 >> s3.1, 1st para: s/egress endpoint/egress (receiving) side >=20 > Fixed >=20 >> s3.1, last para: s/For this reason ECN/For this reason, ECN/ > Fixed >=20 >> s4: s/should be able to be specified/should be specified >=20 > Fixed >=20 >> s4.1: s/For non-congestion controlled mode the/For non-congestion = controlled mode, the >=20 > Fixed >=20 >> s4.1: Does this work: >>=20 >> OLD: >>=20 >> For congestion controlled mode one can configure the >> bandwidth or have no configuration and let congestion >> control discover the maximum bandwidth available. >>=20 >> NEW: >>=20 >> For congestion controlled mode, the bandwidth can be >> configured or the congestion controller discovers >> the maximum bandwidth available. >=20 > Changed to: >=20 > "For congestion controlled mode, the bandwidth can be configured or = the congestion control algorithm discovers and uses the maximum = bandwidth available." >=20 >>=20 >> s5.1, 2nd para: s/is used to enable use of/enables the >=20 > Fixed >=20 >> s5.1, 3rd para: >> s/To request using the/To request use of the >> s/then response/then the response >=20 > Fixed >=20 >> s5.1, penultimate para: Should the should not be SHOULD NOT? >=20 > Fixed >=20 >> s6.1: s/8 bit/8-bit >> s6.1: s/specification/document >=20 > Fixed >=20 >> s6.1.1: s/"DataBlocks=E2=80=9D data/=E2=80=9CDataBlocks" ? >=20 > I'm going to leave this as the ``"DataBlocks" data'' as it is = referring to that area of the packet data. DataBlocks may be spread = across multiple packets or there may be multiple DataBlocks in a single = packet. >=20 >> s6.1.1: s/16 bit/16-bit >> s6.1.2: s/7 bit/7-bit >> s6.1.2: s/1 bit/1-bit >> s6.1.2 x3: s/32 bit/32-bit >> s6.1.2: s/22 bit/22-bit >> s6.1.2 x2: s/21 bit/21-bit >> s6.1.3: s/4 bit/4-bit >> s6.1.3.1/s6.1.3.2/s6.1.3.3: s/4 bit/4-bit >> s6.1.3.1/s6.1.3.2: s/16 bit/16-bit >> s6.1.3.3: s/extends/Extends >=20 > Fixed >=20 >> s6.1.4: s/As discussed in Section 5.1 a/As discussed in Section 5.1, = a >=20 > Fixed >=20 >> s6.1.4, D bullet (make it match C): s/Don't Fragment bit, if/Don't = Fragment bit. If >=20 > Fixed >=20 >> s7: I may have missed this in earlier discussions but why is the = registration policy Standards Action? I thought that most of the = registries were trending more towards Expert Review. >=20 > No particular reason other than it was the conservative choice. :) >=20 >> s8, 1st para: s/Traffic Flow Confidentiality/TFC >=20 > Fixed >=20 >> s8: >>=20 >> You warned in s1 about using a non-constant send-rate, but = shouldn=E2=80=99t that be echoed here? >=20 > As mentioned previously it's not necessarily less secure to use a = non-constant send rate (research being done by others here), we are only = claiming use of constant send rate is more secure. >=20 >> Likewise maybe repeat the ECN covert channel statement. >=20 > Repeated. >=20 >>=20 >> s9.2: r/[draft-iab-wire-image]/[RFC8546] >=20 > Fixed. >=20 >> Appendix B: YMMV here but since this is an Appendix and you=E2=80=99re = repeating the current practice s/SHOULD/should >=20 > Fixed. >=20 > Thanks again for the very thorough review! >=20 > Thanks, > Chris. >=20 >>=20 >> Cheers, >> spt >>=20 >>> On Jan 24, 2021, at 20:55, Tero Kivinen wrote: >>>=20 >>> This is the start of 3 week WGLC on the document, ending 2021-02-15. >>> Please submit your comments to the list, also send a note if you = have >>> reviewed the document, so we can see how many people are interested = in >>> getting this out. >>> -- >>> kivinen@iki.fi >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_E4D51EF1-20E6-4F88-8A9F-DE9F0A749F71 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE5nRo/+BCFVtKzul3/mY1xyb/oi0FAmAmkRcACgkQ/mY1xyb/ oi0yBA//YPwsRhALOCGKBroHWRxH9Xp+U0AxH4SHpWSRolhSFNbogBrTsR9cnusM UKUMck7cDctJmY9X0hi+kYFtw5WrbcQNyP1RZrHEtQS3IMOp2QWbVXYFRKy8l58E /P4o51aZsL/FTNY0OL88jZlUP5ZfqwYu6St+vE3U9V8qbBb6hmcGeOUD4ulenmJI 0ZwLJonbWJUsaaDxBYu7XDVtuW+nZSb7aQLEkB9AilV2Wb5Q9q/2uO6Im0NdqbOH bgkoaO6ljFVcToUFC7Jv/Zw5hnTx8vElcdgZa4OG8ZW6WQs30/ANFM6twL+53r+8 cLSLxr79u42TCnCcMrWId35v+fjNyBhlZM7rxm5eplPpBHKG7X0sYNWea9MoqPWF Y5aKJujrIjlL3GozVgrp3nl16YKNURyP71ndIyj17AM4ia4pr9ClstSuQ+WLS6ND 9K0tUaebJ622+yBaai3rGayop9MhrgVhstcZ5tWiPsENy7j54Bh+SByAjc6/Fwkk DnCxHL8hADPUdiTfcg+7stK3zC+rZrj3FftFJT2GLvc7j6+zSO5aqHWCghLOo8c1 daxdYYQA0saDJFw8F24Si37vlqVP3VecqSeLfBEn8MzgQSkmmctuwUkfsl+op+DN LAL5w1wRO0MHbvi2QOHLb5sBJ79/N79ILhheqPEHZgG/jE6a7Z8= =fFMh -----END PGP SIGNATURE----- --Apple-Mail=_E4D51EF1-20E6-4F88-8A9F-DE9F0A749F71-- From nobody Fri Feb 12 14:02:42 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1283A0652 for ; Fri, 12 Feb 2021 14:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.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 dhr_gMvGSN0H for ; Fri, 12 Feb 2021 14:02:38 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690118.outbound.protection.outlook.com [40.107.69.118]) (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 8C3D23A0FD7 for ; Fri, 12 Feb 2021 14:02:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h9OWsQUmcI0ngI8LqR7/vgZUIMDfdZEMdJtry0CvcmQucgc0ozsBCXWHfS3O83EcRIDYGpGDiRXoO+uVVrCnweu9jg4NZNk5DAGL9VSYPX9B/Ywp//lU4GwuVv/zHRrHnh0x70T1/Zil9oWpSMf0HxUwhycg2owQpcAKo4UihysBqIoYI3z57MztKLG6mxt5XzJnauXEOXTYQTE9R3PL/nyezzM98sZdjsgzDLoylnAuUwMFkPYymvQZ7A+/+rr3HyDd0n96hPXwBDBPn7CCnetORRFpBnmigsq5db6M3yWvtTrKGFb+dmXKmwhqP+VqiSpb3YJtbg2KIvycQ6IciQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=49waTJpChd/VqlsNL9yGbSB4ZjOprOp93REN04lkLI0=; b=LwGVB0JWLgtt2I5vw4wdFvNMS8jncrVyhdmlcjYNF7d4F+ONRhfO9bxKdRYrtrOOaSwiMippPz7zC99BHqaZFVh+yX7GqnCh8znot4D1akqLOFg6GsMSPN7Pgbj5UKEmZOuadoXt5TYDVx5fzd/ppd8Jvv3bS8BqZkBpa2pKluYEmTcySvH0LRNFMusDwjiDDo/pmzM3xaDlf414aRwuVolbfS/TwY3DVrbGqNnG8HVpwxMZnIFIAN1yJlgZj48OE4n4tiUtZoZKrXuzYdgR5SXHHeCRH/S2xeDR9PB5PPiHGn0Pt8BoqKHpCvU1jVlk9xFsQ1ojz9G18ttP6lG/qg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=49waTJpChd/VqlsNL9yGbSB4ZjOprOp93REN04lkLI0=; b=kTcErUbb9/h6RkIIFLATvrtnY3fUYqLpNvqFYHazaJ06eWzO1jRUsqKk9IbyEBhsOTIRnKgQPfPrJiCSkBbJfSm5lPBkcKqISvfTjr0OCohuDJp8eg55wE0OYshtvGGUaJdxdleIPmiRbp2lfUIpwWuFRo7ijh9wX9puYk+mRfs= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=labn.net; Received: from BL0PR14MB3779.namprd14.prod.outlook.com (2603:10b6:208:1c7::24) by MN2PR14MB3504.namprd14.prod.outlook.com (2603:10b6:208:1a3::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.27; Fri, 12 Feb 2021 22:02:32 +0000 Received: from BL0PR14MB3779.namprd14.prod.outlook.com ([fe80::9965:8049:fd3c:6f07]) by BL0PR14MB3779.namprd14.prod.outlook.com ([fe80::9965:8049:fd3c:6f07%3]) with mapi id 15.20.3846.037; Fri, 12 Feb 2021 22:02:32 +0000 To: ipsec@ietf.org References: <24590.9731.586561.210161@fireball.acr.fi> From: Lou Berger Message-ID: Date: Fri, 12 Feb 2021 17:02:28 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <24590.9731.586561.210161@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [100.15.108.238] X-ClientProxiedBy: BL1PR13CA0224.namprd13.prod.outlook.com (2603:10b6:208:2bf::19) To BL0PR14MB3779.namprd14.prod.outlook.com (2603:10b6:208:1c7::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [127.0.0.1] (100.15.108.238) by BL1PR13CA0224.namprd13.prod.outlook.com (2603:10b6:208:2bf::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.12 via Frontend Transport; Fri, 12 Feb 2021 22:02:31 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: afbc7cee-1057-417c-dd49-08d8cfa1e571 X-MS-TrafficTypeDiagnostic: MN2PR14MB3504: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jjnvDnXPuF7IZ2DaWL8IawRgJ71iAVsrubezvZiErAFpn6wdds1wS68Kq3DkvJJEVqjfen3AXLpTg1n+jVY1+Q9DInEBv1XuCeELU7bZmeTJ5b59O0qHF2cZbHhiyaDa7mEY9jMfrvB9T85Uj8GOj6M315jk8iPLR2yHNB1OFiTcla7VXyU/ABqvAJ5p1p2fJFMxCn5olDVgVtFc/mVQmjyNpUsrPQU0dF0HM7gJFbmWxRiEfsKIW3MOBtc1ydxtlf77nr7MTC4BPF9IAvNbQzwtYcOT8zgf/ToXVoOax6wfs5IrmS/RFZ4YA+SwVMO4UZYP0o+Xx/ulbyT3sZACrwipMKVniem63yZ6fICKMRSKleKVavev06HqpcHX9ZqFaLmDI8XO8mo7SlTPl0H2VPU2yX/1UE2C9m/h7u/b/RZffBzAuljVyJQNIO9cE1IRXrVnDBzhLefMlZjNHzHETPbLL3EpmbuGI9vvMvZfFB4U6eXt2/KCsTi8/uwUaI/asu/xnrSX/KqJA5dkakQ2h4mRm+/DdzFOgA3z2fwYJGI52MsA7VcLDULHij0GJdRA9e0FSdS6KJWwIflsmdY1mbBaJYrKP3mYXMwAwWAh4h4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR14MB3779.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39830400003)(376002)(366004)(396003)(136003)(2906002)(4744005)(6486002)(8936002)(45640500001)(186003)(2616005)(5660300002)(7126003)(36756003)(6666004)(8676002)(52116002)(478600001)(31696002)(316002)(31686004)(956004)(26005)(53546011)(7246003)(16576012)(66556008)(66946007)(66476007)(6916009)(86362001)(16526019)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?eXFCRVJLMkZJT1BWMEVybGdzQjdZRVZETnREeTUxM3FVcXZ6a0NzMm1pUUVZ?= =?utf-8?B?ZkpTRjVPYzZUcnc0YU1wVnFMbHRNYVd1VlZDd2Z4b21uMHM1a2tTbDNKSDY3?= =?utf-8?B?czdTSnJPOG52N09CSFMxMU8ydmdydUFXTGZvQS9ZS0dNSXJYZUdMbzQzL0t4?= =?utf-8?B?MHJVN28yNEhhK3ZrdllvZmlUWlJsSFpBUXlSNXQyZnFuSHhMMjJRRHZXVWR0?= =?utf-8?B?UUw2SkROSlpYWFZvcDMrcmU2WjkxQ2twL2twaEdKV1psd1pGN0trSUNheHFI?= =?utf-8?B?ZGFpM2x3ak1pNE52QVRlVktJYWRKMnBrSTV3bE1vZWl1OUlsQmZmZ2hNR0pq?= =?utf-8?B?SzBMZWZNeGJWaFowV3FKSFlINS9yODdRRkNVK0g3MG5uais5bWQ3NnlZSnhC?= =?utf-8?B?Q2p5R3hSUmRjbjREY1hzWDR6WVpVRHBIRFlWMTVnY21OY29VUzdtbTdSU1U2?= =?utf-8?B?RXBWWGk0eWZPdko1N1RRaVRrT01UUEQ4S3JNSUlzQzVUWnczTVg3K0tmWnZG?= =?utf-8?B?bjZZK3Bpa1QwVm41a3dYY3RqWHd6dGNVSU1hVk5wVVc2TEo3anZQSGFFZ0NG?= =?utf-8?B?YXpUTkNoYlh1QjIvbXNJaEdGRUZzTWNKeXVjVkxzbjFMODJkeWwxVXhnd1p6?= =?utf-8?B?cjR0WFcyeFBlTjNJNG1nbkhWNnJBQWt0U2hQYWg3OW5COXhTY2hHKzJidzNI?= =?utf-8?B?L1d0RUdtNWlTZkp0eU56UWYrb2x5NTRKT3ZYME1ZTGljcEZ2cWVSS0hMK0FS?= =?utf-8?B?cmJRcUxRSFlKb081dTJpZ0ZOSWZpYjMydE85MjVVcnpSUmRnZ2JUUW8wYTl4?= =?utf-8?B?UitBRDBZTnlmK2hjWW11bEJKRzZ0KzEySGFodnI0MEdJc3RnNWliZGt2Lzl4?= =?utf-8?B?THFDSm5hTEN5RWM0MUw5cHJpcUhmUHlNd3ZhcGh2VnArTWR6eW5MQ3dHYkQ2?= =?utf-8?B?ZFNPMStYbVZ3eW9MbVVORitCZXF4eFV2b0RmREhaZGhlZ1B1UGVRZC96ZFZF?= =?utf-8?B?TnpORjZYL1M5dmo3NnhLY0VBaE1XQ2p2S1RtU3ozNVBOekkrcDNTa0cwam43?= =?utf-8?B?SGpZVzVLNHptQkd2YUJHNU94bEhKemZtMkRWcmtoUlIwalBORlQ2U1Z2ZzNx?= =?utf-8?B?MlgwS0xtMGVKSWp1N1o2Y2hkeTdFK2ZCQzRFYkt3NHNqOTB4NGdtUjVJQkVY?= =?utf-8?B?U0x4WUp3TTJDMFJucDZCangwV0ZzQmtSNks5WG1yMDk2eE0vY3NQazloMmJ3?= =?utf-8?B?MEl4N003Q2YrSXBpbmkzeEhUVkN6YzBxdDNlNWEyVTREYTVXMGlxbGVTQTUw?= =?utf-8?B?TTd6V2tSc2FUUHlBMHd6TE41M3ExNSs3YmlYMDNIY2xHNEdyYXVNbXhZY2Ux?= =?utf-8?B?SUl2cW80a01NbFhMT3FKRWYrQnhaMHpyQTh4UXZmRENWRE1YcThHSW9CMkVS?= =?utf-8?B?VXVnUUc3aFFIeE55dHZBL3JyRDBZUjkvdHFjZE9DRktyL1ZCY2RqSkVVV0Fn?= =?utf-8?B?SzAxSmNyZEthZ1lQaU5maWJJWmVvRzhncWZHM29NeU9LbUt4cGR6T1c4VkRp?= =?utf-8?B?N0VJUTd4bmp2bWRSYU5VMTJ5NEpYTzFtU0tpZlRyNi9zZ3VUUGpUTmNqbk5C?= =?utf-8?B?cWlwQmx4d1BuZVhxbEZ0K3NkOGpWdW5ZZURkaitYSU53ZUdrN01XTzFQWDlG?= =?utf-8?B?eWMvRjZmTzRSZzlpL3hzcHhSeFN6RFlzL3dGdUpkbXNUeFl2cVhON2xOVVJ0?= =?utf-8?Q?lyXr1Pm20spGb6i1wgcaX3mFZvyYzP1OiO73XU3?= X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-Network-Message-Id: afbc7cee-1057-417c-dd49-08d8cfa1e571 X-MS-Exchange-CrossTenant-AuthSource: BL0PR14MB3779.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2021 22:02:32.2309 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: fq9x/YBSwRe9pwnFEePKgExvfbwxx+6m/5bFKLA1550Mev3t1GZg1ataEHZr9cl9h717IQC0XDfcO5i0PS1qVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3504 Archived-At: Subject: Re: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 22:02:41 -0000 I think yang definition is a necessary compliment of draft-ietf-ipsecme-iptfs, so support the adoption of this document. On 1/24/2021 8:59 PM, Tero Kivinen wrote: > This is the start of 3 week WG adoption call for this document, ending > 2021-02-15. Please send your reply about whether you support adopting > this document as WG document or not. > > This document is not explictly mentioned in our charter, but as this > is part of the traffic flow confidentiality work that is part of our > charter, I think this is something we can and should work on. From nobody Fri Feb 12 14:59:24 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2B73A1065 for ; Fri, 12 Feb 2021 14:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 Sf46JH3PsXmB for ; Fri, 12 Feb 2021 14:59:20 -0800 (PST) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 B36873A1060 for ; Fri, 12 Feb 2021 14:59:20 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 7D7671B00107; Sat, 13 Feb 2021 00:59:15 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1613170755; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xS4DS0vpSw9KC6V/9Ii1JieKTpjKqNJR1tBjak3QPUo=; b=Xvpk51DSwO67Dy7sXz/k/iIm0qt9l/0t2pTiNP8cEhzTgoJsz+hUB5NdR78teSgNngyBVE AVywZDCyAEIH4DzVfIAyCnqQHbAD0C7JY9dtmDNvtnrQ4b8AkGEC0nY3VDGW4g0MLVcrEr teO67Lm13OAoUXAXl9Xif5Q9hGBXHs2pwHdKqNAiRf5lggCURS17d6+DCYhp7DlV9XHbVV vW+ztSwPW25nQ5jTx37v4ilz7zSILkb1iXzXiTBTjlWjfmW7ca5ceQ8wWpAyXK8+hk8P6Q ylP1Gco71sBRggE/aUQvlHfpw7DHWlYQBGcMrPfC8/Ze+adOweM14akLwNGrtQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id 178CC25C1800; Sat, 13 Feb 2021 00:59:15 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24615.2115.37400.884792@fireball.acr.fi> Date: Sat, 13 Feb 2021 00:59:15 +0200 From: Tero Kivinen To: Christian Hopps Cc: ipsec@ietf.org, Valery Smyslov In-Reply-To: <3B6C2BEF-4B9B-48A3-A52D-E8184613CD7F@chopps.org> References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> <9E9A8E75-B269-4CFC-904B-272F3E1B59A4@chopps.org> <034d01d6ff87$db060140$911203c0$@gmail.com> <252DEFA7-AE92-4974-9ECE-2B8BD742FED2@chopps.org> <044101d7004f$30cff370$926fda50$@gmail.com> <820F6E88-C832-43BC-897F-8BF61090CA20@chopps.org> <24613.33445.314481.788667@fireball.acr.fi> <3B6C2BEF-4B9B-48A3-A52D-E8184613CD7F@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1613170755; a=rsa-sha256; cv=none; b=BZJ0KXZfSB6BP6bNL7JneduE7rGgQqXaw0StzLXYPDXC+z01KieNZveynY480mEfMoHyrt JB7mJxPDtlUfTEU2AcTiZG9Ai/pIrIhzYIO3FIgOMY9FMAfpoUyrUX61CMSypqp9YpwUZF sb6e9XAsvFz3zxq1UQjtUdqnvmMRRcpMtO8G8yxjA3CgtqCPfv9J1wd+fqWuBwvXpv0poY 7TwigJCiAvfyHuBvhkUxWDTbPDpPmkXjce0RIaVp7j4hHHPRc2Uoa+5Xsa/Xn8KjiPRrTj MVxQHXqQ8Ab1sEwIRNYYTD9nfVeLkqYvBBONXmM1+FBjJLNVWuwqQSXvQXNtrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1613170755; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xS4DS0vpSw9KC6V/9Ii1JieKTpjKqNJR1tBjak3QPUo=; b=cfx31V5U4xu/VL+/Y2Vp39YCpNiDGcnnv/ua597Flxkm+su4EctcrcTjbvNxCQ9NmhXKOu KWSfeeRUtDU60i4hSeIhT7QJHCv6BJ0fgLIxCjWexTCZwi3Tp2Tttq6T3mActB30BubD3T RdSwYsEDcOYMuvqXLElB6CFoa19llVr9jFflEqf5D60zXsA7cDo1wKTVDTh6Vsn/SO3RQR bbWjKEXPfjC2pY/bWaL2Ua+fRr5clb2flpWvY5B5SucMuyQTfQiPOgu/3GH9XjPQJIwZtc blSXKbniBZ95Ak0Xyr7YPvv9FRMJRGcaHrZ0BLKOgbQkuV8OKEOtf15K760RSg== Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 22:59:23 -0000 Christian Hopps writes: > Just to clarify, are you indicating Valery's changes should be made? > If so then I will update the document so we can continue to make > progress. I have not checked out the draft yet, so I do not have opinion about this. I was just pointing out that this is good time to do the change, if those are needed, this is not too late... And, yes I would think it would be worth of getting other people to say their opinions too before doing too much work. Sometimes having clear layers makes things easier, I think for example having separate intermediate exchange instead of having that same exchange buried inside the post quantum draft makes it easier to understand how it works. Not sure if that is true in this case. -- kivinen@iki.fi From nobody Fri Feb 12 16:36:27 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B65D3A11D7; Fri, 12 Feb 2021 16:33:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ipsec@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317640742.31337.13820757794825083787@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:27 -0800 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 110 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:33:36 -0000 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (2:00 requested) Monday, 8 March 2021, Session I 1300-1500 Room Name: Room 9 size: 509 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/ipsecme.ics Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: tls acme Technology Overlap: cfrg People who must be present: Benjamin Kaduk Tero Kivinen Yoav Nir Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 12 23:13:30 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11C13A100A; Fri, 12 Feb 2021 23:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 HtN5nGcVQxZx; Fri, 12 Feb 2021 23:13:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897183A1001; Fri, 12 Feb 2021 23:13:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4AF16F40757; Fri, 12 Feb 2021 23:12:51 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ipsec@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210213071251.4AF16F40757@rfc-editor.org> Date: Fri, 12 Feb 2021 23:12:51 -0800 (PST) Archived-At: Subject: [IPsec] =?utf-8?q?RFC_8983_on_Internet_Key_Exchange_Protocol_Ver?= =?utf-8?q?sion_2_=28IKEv2=29_Notification_Status_Types_for_IPv4/IPv6_Coex?= =?utf-8?q?istence?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 07:13:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8983 Title: Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence Author: M. Boucadair Status: Standards Track Stream: IETF Date: February 2021 Mailbox: mohamed.boucadair@orange.com Pages: 7 Updates: RFC 7296 I-D Tag: draft-ietf-ipsecme-ipv6-ipv4-codes-06.txt URL: https://www.rfc-editor.org/info/rfc8983 DOI: 10.17487/RFC8983 This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) notification status types to better manage IPv4 and IPv6 coexistence by allowing the responder to signal to the initiator which address families are allowed. This document updates RFC 7296. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Feb 14 20:47:34 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0F33A0887 for ; Sun, 14 Feb 2021 20:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lM2xfNqqvk84 for ; Sun, 14 Feb 2021 20:47:30 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BD23A0902 for ; Sun, 14 Feb 2021 20:46:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 42C1138981 for ; Sun, 14 Feb 2021 23:49:35 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SQw4prsSGbxT for ; Sun, 14 Feb 2021 23:49:34 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AC22038980 for ; Sun, 14 Feb 2021 23:49:34 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1F204A86 for ; Sun, 14 Feb 2021 23:45:59 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <24590.9470.995873.674029@fireball.acr.fi> References: <24590.9470.995873.674029@fireball.acr.fi> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 04:47:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have read draft-ietf-ipsecme-iptfs before it was adopted, and during the adoption call, but have been busy. So I have read it again today from beginning to end before tackling the long thread that has developed. EXEC SUM: I think that the document is not ready. There are a lot of MAYs and future work thoughts on the sender. That's fine. But, in order for future senders to know what's legal and what's not, what we really need is a clearly articulated Receiver Stat= e Machine. I suggest that this is pretty important. =3D=3D=3D The first sentence of the Abstract needs rework. The words "security" and "confidentiality" are used, but really it's about traffic analysis. So, if there is anything with increased confidentiality, it's the pattern, right? Abstracts are really hard to write. Ah, the problem is that "traffic flow security" is not the term, it's traffic flow confidentiality, and it is not capitalized! So, that would help, but... it's not defined yet. I suggest the following terms be added to section 1.1. - TFC * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. How do use PLMTUD? Will you tell us later in the document, or is that ne= w work? (does not look like you tell us) * You are using "CamelCase" for variables, I found that jarring. I wondered what rfc4303 used, but found nothing. RFC7296 uses UPPER_CASE. RFC7296 does not use _ for field names. I might prefer snake_case, but whatever... * I would prefer "If BlockOffset !=3D 0" rather than Conversely, if the "BlockOffset" value is non-zero it points to the > The "BlockOffset" can point past the end of the "DataBlocks" data > which indicates that the next data block occurs in a subsequent > encapsulating packet. I guess, it the actual value does not matter: it's not remembered. As long it is bigger than the packet, it's good. So 0xffff probably works? > 2.2.2. No Implicit End Padding Required =2D- I think you are telling me that the IPv4/IPv6 length field is good eno= ugh to find the end of the packet. If not, I didn't quite understand. Later in 6.1, I learn that AGGFRAG_PAYLOADS are squatting on 'IPv5' I hope this will be acceptable :-) I think it's a reasonable hack, and I don't see us wrapping around IP versions within a hundred years, soooo... And pad blocks are "IPv0" > This possible interleaving of all-pad > payloads allows the sender to always be able to send a tunnel packet, > regardless of the encapsulation computational requirements. I think that you are telling me that a sender can have some pad packets bei= ng created regularly (perhaps on a CPU dedicated to this) and almost ready to send, and the pad packet is just replaced by real data if it happens to be ready. Please split 2.2.5 up by flag type into subsubsubsection. 2.4.21: Maybe need to briefly explain circuit breakers to us non-transport-= types. > If the SA back to the sender is a non- > AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload > (i.e., header only) is used to convey the information. is this really worth supporting? Please break up third paragraph. =3D=3D=3D=3D=3D =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAp/IYACgkQgItw+93Q 3WXxywf/eRwHCJO08fOjIcPQ6tyZCihYt6Mvy3uaAOoxmLpWcI1U/0WK4RdIFd+D ix8wFuk3+I3SRI776ZCGku0vCtMKL9flQEvOrcLLSqch1jaTKfZW7tv0oKfl+J0S wXmtAie7UTP0XPL10NN6lHyBR2mb0u0mEs12ISAEzPiOIANMVaMowN10qtX9Yzed 9+1/VJ9q6YvLfvczkl8XYCPHoOT+MLcwEOI8kn/8NvMFrSEmm6+zRjrckrO1obFk YWCRgX7siaXvIImUujzU0kZYP7o2LTRuARRQp6U6BKZFz2YGn+CHbE/RgntXMVLq pQ1Hhtzt9/1VhhYToHnVnTfak4/D9A== =/Z7r -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 14 20:49:42 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CFB3A08AA for ; Sun, 14 Feb 2021 20:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=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 mfVurJluprOk for ; Sun, 14 Feb 2021 20:49:39 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9CF3A08A5 for ; Sun, 14 Feb 2021 20:49:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B731838981 for ; Sun, 14 Feb 2021 23:53:12 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RnfTuS1M1j31 for ; Sun, 14 Feb 2021 23:53:11 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B0A5A38980 for ; Sun, 14 Feb 2021 23:53:11 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2234D1612 for ; Sun, 14 Feb 2021 23:49:36 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <7d22dad4-4b23-82a1-0c3b-eb66b3013aa5@labn.net> References: <24590.9470.995873.674029@fireball.acr.fi> <018901d6fe0f$b875a2d0$2960e870$@gmail.com> <7d22dad4-4b23-82a1-0c3b-eb66b3013aa5@labn.net> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 04:49:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Lou Berger wrote: > I think you make a number of good mechanism specific technical points > that are worth addressing in the document, but I think that > recasting/redirecting this work goes too far.=C2=A0 This work has alw= ays > been focused on a specific application (TFS) and it's utility beyond > that application is certainly a bonus -- the very recent name changes I agree. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAp/V8ACgkQgItw+93Q 3WUrrgf/dnmP7VqTV+fxlOP4VIWb9OsW/tFwsXKtZET9ZA+DbFXfaBhhYcaAerzn me7S1VrfGY63aWBH/FsGVXdD9lUefYWBJ7I4DNQUEXOZgl1ztGgpwd4IflCFvJNq DeLaiM1wTA+nFYgyQx07VyBRFLw84A19CZ3Mm6u2qR4q9f4SbBWHgGPPu223FaHM 6rg1aP0VX5r0spLEVXgq+qFmYr4odtFLb24nDKPoUlVJ7IBgJvTlK5TOrtPdyxkt ipxpWfCL9gQB2H0qOel+AqcZysFOeo10njlNr06ihtVzYSSOeBMFSf1qZfOZk8O4 Jt29jTmSpb7JlKJrHVeGIpBMoSE5JQ== =DprT -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 16 03:11:23 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF013A11FB for ; Tue, 16 Feb 2021 03:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 2j-nuVAo_7Jy for ; Tue, 16 Feb 2021 03:11:20 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id DE73F3A11FA for ; Tue, 16 Feb 2021 03:11:19 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 49E3361690; Tue, 16 Feb 2021 11:11:19 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_3C531917-C349-4B1E-B67A-AF7E8EE45D65"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 16 Feb 2021 06:11:18 -0500 In-Reply-To: <17099.1613364359@localhost> Cc: Christian Hopps , ipsec@ietf.org To: Michael Richardson References: <24590.9470.995873.674029@fireball.acr.fi> <17099.1613364359@localhost> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 11:11:22 -0000 --Apple-Mail=_3C531917-C349-4B1E-B67A-AF7E8EE45D65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, Thanks for the review, q's, comments, and changes inline.. > On Feb 14, 2021, at 11:45 PM, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > I have read draft-ietf-ipsecme-iptfs before it was adopted, and during = the > adoption call, but have been busy. So I have read it again today from > beginning to end before tackling the long thread that has developed. >=20 > EXEC SUM: I think that the document is not ready. > There are a lot of MAYs and future work thoughts on the sender. > That's fine. But, in order for future senders to know what's = legal and > what's not, what we really need is a clearly articulated Receiver = State Machine. > I suggest that this is pretty important. What did you have in mind? There are purposefully no restrictions for = the receiver to enforce. =46rom section 2: The egress (receiving) side of the IP-TFS tunnel MUST allow for and expect the ingress (sending) side of the IP-TFS tunnel to vary the size and rate of sent encapsulating packets, unless constrained by other policy. > =3D=3D=3D >=20 > The first sentence of the Abstract needs rework. > The words "security" and "confidentiality" are used, but really it's = about > traffic analysis. So, if there is anything with increased = confidentiality, > it's the pattern, right? Abstracts are really hard to write. > Ah, the problem is that "traffic flow security" is not the term, > it's traffic flow confidentiality, and it is not capitalized! > So, that would help, but... it's not defined yet. >=20 > I suggest the following terms be added to section 1.1. > - TFC Capitalized and "acronymized" TFC and called it out specifically now: This document assumes familiarity with IP security concepts including = Traffic Flow Confidentiality as described in [RFC4301]. > * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. > How do use PLMTUD? Will you tell us later in the document, or is = that new work? > (does not look like you tell us) I believed it was enough to just reference the mechanism (as we do for = PMTUD as well). This was added during the transport area review. >=20 > * You are using "CamelCase" for variables, I found that jarring. > I wondered what rfc4303 used, but found nothing. > RFC7296 uses UPPER_CASE. > RFC7296 does not use _ for field names. > I might prefer snake_case, but whatever... You must not like Python very much. :) I used UPPER_CASE for constants = as that's what seemed to be the prior art in ipsec. For field names = camel case seemed to work pretty good differentiates them from constants = and non-actual-field references. I could add spaces instead of using = CamelCase if you think this is important, though. >=20 > * I would prefer "If BlockOffset !=3D 0" rather than > Conversely, if the "BlockOffset" value is non-zero it points to the Usually I don't use "=3D" or "!=3D" in text. I'd prefer to leave this as = is, otherwise when reconciling that change with the rest of the text = e.g.: The "BlockOffset" value is either zero or some offset into or past the end of the "DataBlocks" data. Becomes The "BlockOffset" =3D=3D 0 or some offset into or past the end of the = "DataBlocks" data. Doesn't seem correct to mix and match like that. >> The "BlockOffset" can point past the end of the "DataBlocks" data >> which indicates that the next data block occurs in a subsequent >> encapsulating packet. >=20 > I guess, it the actual value does not matter: it's not remembered. > As long it is bigger than the packet, it's good. So 0xffff probably = works? Your right it just has to point past; however, it helps to have it point = to the exact ending when implementing (the code is easy to implmeent and = it caught multiple bugs for me as well). >> 2.2.2. No Implicit End Padding Required >=20 > -- I think you are telling me that the IPv4/IPv6 length field is good = enough > to find the end of the packet. If not, I didn't quite understand. You understood. > Later in 6.1, I learn that AGGFRAG_PAYLOADS are squatting on 'IPv5' > I hope this will be acceptable :-) > I think it's a reasonable hack, and I don't see us wrapping around > IP versions within a hundred years, soooo... > And pad blocks are "IPv0" >=20 >> This possible interleaving of all-pad >> payloads allows the sender to always be able to send a tunnel = packet, >> regardless of the encapsulation computational requirements. >=20 > I think that you are telling me that a sender can have some pad = packets being > created regularly (perhaps on a CPU dedicated to this) and almost = ready to > send, and the pad packet is just replaced by real data if it happens = to be > ready. You understood perfectly. >=20 > Please split 2.2.5 up by flag type into subsubsubsection. Done. > 2.4.21: Maybe need to briefly explain circuit breakers to us = non-transport-types. I think the reference should serve here. I try to avoid paraphrasing = other documents as one often just gets it wrong (i.e., prefer a single = source of truth). :) >=20 >> If the SA back to the sender is a non- >> AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload >> (i.e., header only) is used to convey the information. >=20 > is this really worth supporting? It doesn't take much to continue to allow for unidirectional use at the = lowest layer (ESP/SA). It isn't relevant once you get to IKE where = bidirectionality is required. > Please break up third paragraph. Done. Thanks again for the review! Chris. >=20 > =3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_3C531917-C349-4B1E-B67A-AF7E8EE45D65 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmArqFYACgkQLh2DDte4 MCU2kA/9GGy8o1IvsTLEYvyAA5o2pGo/Q+b5NQ38ytcQUw66JLDbst0PX0N+8Ojx /KPRMJrRNmSnIGn5fDqrmnKqI59x1m1IKDZRXdxGBofXwLtsVV95VUwCdnMCS0Hz cUMqhBO6yLM0d9ujOVJ3k5EOI3MsDtRrYgQVLuC8qh0HICoQ0clyLE/ZTeGGNigu nOtBF5hJ2SN7eGoRxKdP2vSjC/6y4kvWxBmlQAkdC9iApfeNLATf8NhgQCC3qFpv QtSkBLJSmuOC8wjp03IOivjlqD7fikwln3aabnZJkjsc/cL1eaH9hljRAu5WPgPX pZ1tbRsSs56EtmoHRZuokRboWKfWYjUuU1RIeEQ8FAENJRBlb4HaZgPTyapirNwZ 8gJpobyeNSJ+tHP+ZlRAHQEvYMW7urjcef7fLMJusG716qiTNZKmtvklkaBZxToi LCEmov6Ah3eUcMQ4tDwWG7KrXASz+qb6H5aBd9/e/ukHx8FmH7FPcAZ+6AOVFCFF pVpg1062B+P4I63LtRJhM+1pCr/7BUlshCVyQ49H2PKrIxCzD++2GRLgcIt5DEDr qhU0y19OrRysER56twY6g6PgYt1VSapuyJoj28F/lAa/gg/FLld3A8xkmbzzmeE3 dN83NIqMgrQeLiYy/nvTW1iVjzMoZnIbuSzUJwiRi5KEEzmYLNw= =a1BA -----END PGP SIGNATURE----- --Apple-Mail=_3C531917-C349-4B1E-B67A-AF7E8EE45D65-- From nobody Tue Feb 16 09:49:24 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A603A0D4E for ; Tue, 16 Feb 2021 09:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 a8IGKZBdWuFb for ; Tue, 16 Feb 2021 09:49:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9843A0D39 for ; Tue, 16 Feb 2021 09:47:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 61DB538983; Tue, 16 Feb 2021 12:51:26 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LD2qmSUVyTmF; Tue, 16 Feb 2021 12:51:25 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C81EF3897F; Tue, 16 Feb 2021 12:51:25 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6A0C6A3; Tue, 16 Feb 2021 12:47:44 -0500 (EST) From: Michael Richardson To: Christian Hopps cc: ipsec@ietf.org In-Reply-To: References: <24590.9470.995873.674029@fireball.acr.fi> <17099.1613364359@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 17:49:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian Hopps wrote: >> * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. How do use >> PLMTUD? Will you tell us later in the document, or is that new work? >> (does not look like you tell us) > I believed it was enough to just reference the mechanism (as we do for > PMTUD as well). This was added during the transport area review. PMTUD relies on ICMP to say "too big" PLMTUD relies on TCP to send a repeated ack (packet loss) to tell us that we guessed wrong. We now have RFC8899 too, but I don't know how to apply it, and I think that some advice is in order. I think that we need a PL defined. >>> The "BlockOffset" can point past the end of the "DataBlocks" data >>> which indicates that the next data block occurs in a subsequent >>> encapsulating packet. >> >> I guess, it the actual value does not matter: it's not remembered. = As >> long it is bigger than the packet, it's good. So 0xffff probably >> works? > Your right it just has to point past; however, it helps to have it > point to the exact ending when implementing (the code is easy to > implmeent and it caught multiple bugs for me as well). So, then please tell us exactly what to do, and what the receiver is suppos= ed to pay attention to. I didn't like "can" here, for instance. >>> 2.2.2. No Implicit End Padding Required >> >> -- I think you are telling me that the IPv4/IPv6 length field is good >> enough to find the end of the packet. If not, I didn't quite >> understand. > You understood. okay, please hit me over the head harder here. >> Later in 6.1, I learn that AGGFRAG_PAYLOADS are squatting on 'IPv5' I >> hope this will be acceptable :-) I think it's a reasonable hack, and= I >> don't see us wrapping around IP versions within a hundred years, >> soooo... And pad blocks are "IPv0" >> >>> This possible interleaving of all-pad payloads allows the sender to >>> always be able to send a tunnel packet, regardless of the >>> encapsulation computational requirements. >> >> I think that you are telling me that a sender can have some pad >> packets being created regularly (perhaps on a CPU dedicated to this) >> and almost ready to send, and the pad packet is just replaced by real >> data if it happens to be ready. > You understood perfectly. I think that motivating this design choice with this implementation advice = is worthwhile. >>> If the SA back to the sender is a non- AGGFRAG_PAYLOAD enabled SA >>> then an AGGFRAG_PAYLOAD empty payload (i.e., header only) is used to >>> convey the information. >> >> is this really worth supporting? > It doesn't take much to continue to allow for unidirectional use at t= he > lowest layer (ESP/SA). It isn't relevant once you get to IKE where > bidirectionality is required. I think that maybe this is in the MAY. It's isn't clear to me if I need to support that or not. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAsBUAACgkQgItw+93Q 3WWIngf/VX7rIlnjA/f8AunXdyNW9XOtfhnRPYB11UVL4HkpixVJd94XUzS16hcj 85GDYB1jHNIsgo+9kPYxFZyfN0znOXXl4qa8Idih2CiNc4j0xCLF7VAwaTCuvSP8 7aWSiDnvJUV3F5jd+PThmkHhpxmjkOLvMRjA4OFPsgqytCVJR6b/aKRBLvPIbVFd v0g2jEzvTYy1mxvhdXsvE2q7TF+OdSTrKuinSxhNxfN6p+aEVHzwQ+kClclRqNBz 9vWfyK7WpFHE1mkDT5QQvJZUp9ZzToFtk+VXTYaZFLaJh2cBMoneT9HPY63xbYG2 BPkzXhqq75iWiFy7f3RHwG4xcT3ugQ== =BvBV -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 20 22:26:44 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999813A1519; Sat, 20 Feb 2021 22:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 gPNLGR3UxvD7; Sat, 20 Feb 2021 22:26:38 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2099.outbound.protection.outlook.com [40.107.236.99]) (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 356C23A151A; Sat, 20 Feb 2021 22:26:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ls9ptsL5ztKZUmwPa3F4Nr460fREq7NMvtEhjMXJd23dgzhc63pf9dTyLaSaPfx8x7JyrfLXPXFDu24/JYb+/h8wLpE8CQKDeWvXMZDW0fYmggZwB5oPw44XncS7hiMVtVrJ/InnZpm+iWrUCWU9Fk6LbBWvWOhdyVVHLqdx+lsV2eTuHPzxhKkWHNbJKnCny9su94qp6jfARUwgLd7l7NOWnpUqJCvruD/ZrLe4qPXVhLEIBWuH5H3GXYUiWGBY7N2LUtkSvfKk4uDRv8AdzyKdL8c42e+dTn+IyqQBBtFLM7SwfDAg/ZES3iO+QHusGSQE+EK/EaAZapTtmpgCmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L9sEixf8YmV6SyQhch9/nPCwDynt5Ff87dkZ0s1o728=; b=lCW7yz5NeEusE45TZ4e3Jy87MFko1241zXvuupMZ3Ti9/pnkmnGhRC53y+dJ450KrAfIU3Ec5B6+NsJ6ekYxawJfLhPMT9kS1wfMbAZleUOOI1LbR5ERTQ+CWZMQxzJ/dL/RESNlCu9WDKux2yR6C8ZpfG9gfhFU6y41pscEDeTfOJIgW8dcrYvxcFeDVJzU/wekRhV0HdUcgqDwVxIbXcq9wlSvmTfZNAukaNWFN+iibMfx483Y/AaiWtzsbXEmFkZKeomNCrtyWL6BH8eZESuip8/1cJ3kQ83P1snxEtSmKY5/A3f3gmiIPbUxUp5XsX9t7r0JYzB74sYZC4tzKA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L9sEixf8YmV6SyQhch9/nPCwDynt5Ff87dkZ0s1o728=; b=AqKWJkbUi6nSfNwZ/h0XWKaXoTE+O3WXTRQREGdTyFMxrdwF3JizQoe5rvYIyqCcXn8k2nWAbrMm1B4INcpRx53+cDu+k5LfMFmWM3HW+5II0Fa0nguxeWZ3DsfVc1qBGIyFv5h5XhxacTBII91fT8cuI4cL8WMB7HYz3hDA8oU= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SA0PR13MB4061.namprd13.prod.outlook.com (2603:10b6:806:99::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.22; Sun, 21 Feb 2021 06:26:35 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a%6]) with mapi id 15.20.3868.017; Sun, 21 Feb 2021 06:26:35 +0000 From: Linda Dunbar To: "ipsecme-chairs@ietf.org" , "kivinen@iki.fi" CC: "ipsec@ietf.org" , "draft-dunbar-idr-sdwan-edge-discovery@ietf.org" Thread-Topic: Need a 10 minutes slot at the IPsecme session during IETF 110 Thread-Index: AdcIGn2mklXrRCfoSlGMnPPHu4Jhkw== Date: Sun, 21 Feb 2021 06:26:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22c785ab-19a0-47d8-b618-08d8d631a338 x-ms-traffictypediagnostic: SA0PR13MB4061: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NrhVo+qrMYZiJ39YudeRVr5sZdUoV43qHCa56HLRyGT547mrOXjlF/lQLDauRlRPnwjgYjkNVyusgFZTwO3fqnz1gP2el324WLGkN9DvZ43iISNZ0h2m/kbUh/voe/vEVnsiPLHwRmA1tyCmlP6PalMm2jkbcMMNIwVqMrAmUDGdb1FEuMmcvKRL/hxLDHxz/AtL/x99uUR8AWY1/IpEXksdOMx8Q9Eu87pZp44ZV92/V8+lcB0SFRG7oXFqhT9Tjo2jYL+8iZH7gyCUhjvWRCg3DYtRllP+8fK1c4IvItqL7PfFOU5KOes+2PlDT/h3GBb+GzaXwCjxcULxp5clAp0+0E//EqITAJJWfPsrC3sls/QupnCqbhfDgyZo6b39wd2g9wC8MmrOgfBMz18p9umGuBgSVQUe2dmz8qNU5lpVJm4jAkx12YSCBKWiuRTeTKpwl2n3qzpLk4c51+PsjMlnoSWAkx8e/VdoOvHUE9oXzUJx015I+D6TNqqCo769KmSRtleGPuAxgCgQZ3g6LSgksIo3kA3NYa0S4EAVykawSYe6AhGZ5teMiF+3KW+ElFs+GFuE+Zp+UbFC4QdwO0WBQ0cJsw4qqJRRSw8TFJY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(376002)(366004)(39830400003)(76116006)(53546011)(7696005)(478600001)(66476007)(83380400001)(26005)(66446008)(64756008)(66946007)(186003)(8676002)(45080400002)(52536014)(44832011)(71200400001)(110136005)(966005)(9686003)(6506007)(8936002)(55016002)(5660300002)(66556008)(4326008)(54906003)(2906002)(86362001)(316002)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?FNeen3R9mm+58OxY7GzQ2DxWatdqonp3bIXBPLUodriv0bBl0bDHY1cNL/Z3?= =?us-ascii?Q?OsorcdkhctJwrKE59AaMZ3YwRBrtLVW3hDwjD7fKED9kg6VE+apWEV4Wc00p?= =?us-ascii?Q?gjZE6ac2QtqwGwuLpHfGx8qTMduCbSTAs8KXE/r4xu6KEb+53bb6e/pmt/Je?= =?us-ascii?Q?9k5LPx56pLIX/+5ZkMHx2IYR64BljmVA3jQ4+6h/9PC/AvQAquCaCkJRYAxS?= =?us-ascii?Q?NhbC5SrscTB8W8p6toeavr7EXlUiO9HCPkMvcPaYR4rWUhvs2YVYPQGans5p?= =?us-ascii?Q?YgovlIkOhSisCzigi8Kg7zc5DE5jhYO7dojTrt9l60JgISoIHgeD+iLbrgPL?= =?us-ascii?Q?e+t1uapEJhoiKUq2fUHVRIMj/ElYbFLYzF/Hq+HMlnPcWlww77n/1UcTnQls?= =?us-ascii?Q?gG7P94l2PnANy+eBXJRKq3x2vEkySxaLW+7ymw/IMO2t5f8tLIADxE9NGcZI?= =?us-ascii?Q?efXuiRxcHDu0Reuvx6zx3b4RdbBMgqAKI/9D0hWYlc16LKYbPeeDSD5PcJml?= =?us-ascii?Q?V6aLqCKQSNhFJpd0f5QRe7OhdLqJTYNdY6zMau+Ujns9uEMehZIvCFset9Ab?= =?us-ascii?Q?+b44p2bYJPCY/sucol2Mzf/Y+30kpHRFEpYBJSwilREx/cx+EJ3J00inTZlh?= =?us-ascii?Q?4JhENPn+zsi9hP9Op6WgPN8b7OchwiTCPF0Kk17zgPKBjpKnOzRzbiIRyzUl?= =?us-ascii?Q?rWnuYAy4NasL0q25uh7FC92j1Rxj+nruFw+hSda50fQKRV7IrLYtLnwFcZH3?= =?us-ascii?Q?HjQDZoSUtnXIIfVcSRWOpiBBi97c4IRW2Nd4lCy3k5uXKS4kcNu2llxELrV9?= =?us-ascii?Q?4xq7CmI3swTAT5HdQ/+LO6nxKJi61pGkk7Xj8lRC3PhqV4f6Qcbm2z76//Vw?= =?us-ascii?Q?c3sGeT/8CEX+HlSSt5lo0eeFCOrEOucMYBOcivhqIM0ZcVm6HOHLDV9noNDm?= =?us-ascii?Q?43KyoaaheFl+Ql388yFLPorxs6lkfIPMRwMSMDj9ifjtO660HZ/xTvC2WUyG?= =?us-ascii?Q?RkOQ7JcMoM+cN7uwV7aysMBhtmCV0XqyBM0WwOg5oO0Z56rog61xmMUC3I4j?= =?us-ascii?Q?Is+cZeJJXpd/IgeXy93AuzoPOkwvgfPp7ndvM52olzzbKIRwzuGkxOcyG+E5?= =?us-ascii?Q?sFi/Oz+ip3U/N+JNFpZCZ3TLQCWUeIjm1/Hpvx2Z/BQI67PQr19NbklM1IIh?= =?us-ascii?Q?M8Rb8oN3oPr9fdagp+s1sTVUdIS7PGh28boNgYtc4Mkq6+ovMXW53aCm3IG4?= =?us-ascii?Q?MfsaLt7iLcLvZlD+Omf3Lz4SjN2Zfa6FV9YXw/bcOFG6U69aj9gRjyr7BIXl?= =?us-ascii?Q?P+I=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB2334.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22c785ab-19a0-47d8-b618-08d8d631a338 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2021 06:26:35.2200 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0TOg0wr0jIY9yWH4r3ZxuqpbnHw/LfN+d9giN7oMc671jWvpURVU5MRAFwdODm3bEoey0Za8C7Jh96IA8++QcQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR13MB4061 Archived-At: Subject: [IPsec] Need a 10 minutes slot at the IPsecme session during IETF 110 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 06:26:43 -0000 Tero and Yoav,=20 We have a draft in IDR describing how to use BGP to discover SDWAN edge nod= e properties, including IPsec SA properties: https://datatracker.ietf.org/d= oc/draft-dunbar-idr-sdwan-edge-discovery/ Can we get a 10-15 minutes slot at the IPsecme session during IETF110? Mai= nly to get feedback if our proposed approach, and to learn if there is any = issue of using BGP to replace the traditional IPsec information exchange am= ong peers. =20 Thank you very much.=20 Linda Dunbar -----Original Message----- From: IPsec On Behalf Of "IETF Secretariat" Sent: Friday, February 12, 2021 6:33 PM To: ipsecme-chairs@ietf.org; kivinen@iki.fi Cc: ipsec@ietf.org; kaduk@mit.edu Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 11= 0 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request= .=20 ipsecme Session 1 (2:00 requested) Monday, 8 March 2021, Session I 1300-1500 Room Name: Room 9 size: 509 --------------------------------------------- iCalendar: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Fdatatracker.ietf.org%2Fmeeting%2F110%2Fsessions%2Fipsecme.ics&data= =3D04%7C01%7Clinda.dunbar%40futurewei.com%7Cbe2d4c0b53f34e5510e508d8cfb8bd2= a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637487739639970191%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C1000&sdata=3DOSiRIDnJ%2FMUXoUZvIDRPyiE6pePESiWh5ThfFeUEhAg%3D&= amp;reserved=3D0 Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Secur= ity Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid:=20 Chair Conflict: tls acme Technology Overlap: cfrg People who must be present: Benjamin Kaduk Tero Kivinen Yoav Nir Resources Requested: Special Requests: =20 --------------------------------------------------------- _______________________________________________ IPsec mailing list IPsec@ietf.org https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fipsec&data=3D04%7C01%7Clinda.dunbar%40futu= rewei.com%7Cbe2d4c0b53f34e5510e508d8cfb8bd2a%7C0fee8ff2a3b240189c753a1d5591= fedc%7C1%7C0%7C637487739639970191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM= DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DictmNv= JEbcBR%2Flh29%2BEcQeYSu567LMVfYGkzyhyDX%2BY%3D&reserved=3D0 From nobody Sun Feb 21 19:41:50 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAC83A0C8A for ; Sun, 21 Feb 2021 19:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 gIdg78MpqXAX for ; Sun, 21 Feb 2021 19:41:46 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 1F0283A0C88 for ; Sun, 21 Feb 2021 19:41:44 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DkSfF6wQPz3By; Mon, 22 Feb 2021 04:41:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1613965301; bh=5Dl4NrYk48E9+QUCYP1daWEAWaEJkgayWAhpIzFO7QQ=; h=Date:From:To:cc:Subject; b=Wj7LVubPFHXF/xMT7du96+8l4h2r7r/sHKZu1unibC4ntdxaNLTmNxmEHzar33zI9 +sPT11dW+VppSEkHhZizzpRf5if9Mj33i2bPxIZ32ZcyIECHl4FrwNP41G2m/A7qnl rx0XWyOasxheehqxpOHRY50KKJ92kD0x1NF6Vwfo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 3cHCwJNsP8Od; Mon, 22 Feb 2021 04:41:40 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 22 Feb 2021 04:41:40 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5694C6029B62; Sun, 21 Feb 2021 22:41:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4E46466B1E; Sun, 21 Feb 2021 22:41:39 -0500 (EST) Date: Sun, 21 Feb 2021 22:41:39 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" cc: ipsec-chairs@ietf.org Message-ID: <6c991d8a-64ed-b615-3767-3bdf50f843d0@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] draft-pwouters-ikev1-ipsec-graveyard-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 03:41:48 -0000 Hi, I just bumped the version on the document. There were no oustanding issues on the document. https://datatracker.ietf.org/doc/draft-pwouters-ikev1-ipsec-graveyard/ Just to remind everyone, the document does a few things: - Asks IANA to formally close the IKEv1 registries - Adds a Status column to the crypto algorithms allowing us to clearly mark an algorithm deprecated. - Urge implementors to stop implementing IKEv1 and sort of tell users to migrate to IKEv2. - Note IKEv1 is Historic (mostly for ourselves to push the right buttons to mark it historic) I urge the WG chairs to quickly do a call for adoption so we can finally either get this published, or drop it completely. It has been too long in this stalemate status. If we do decide to NOT adopt and publish, then I will strongly advocate for incorporating at least the Status column and the algorithm deprecation into 8221bis and/or 8247bis. Although I personally thing we should wait another 1-2 years for such a bis document, so we can downgrade 3DES and SHA1 to MUST NOT, and AES-CBC to SHOULD NOT. WG chairs, consider this email both my request for agenda item and my presentation :) Paul From nobody Mon Feb 22 07:58:40 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39B83A1D36 for ; Mon, 22 Feb 2021 07:58:38 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.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 svFmrKXsEhWO for ; Mon, 22 Feb 2021 07:58:35 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2133.outbound.protection.outlook.com [40.107.236.133]) (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 DA5E23A1D30 for ; Mon, 22 Feb 2021 07:58:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f1xryeBQkEdVckYDzcjM36H8hIuOHIvi6DsWL7xPZyPFlNbbQENh8uyrhTHSigMKfeVMSbtJZpL3sBUcRtghqqVtS73B4Mt6XWw0ueS1mMU/Ntr0kBSc6uEZ+dOOYegfyNJsqFsfnjG0/8YdMYtP1iWwqTyuN1lVRxKIqhlUKHpkixZ1fn65Eynyp3ozQFuAZAAcsF0dNFC0j65lmkduCVg1w4GA7vvjq8Bek1pAn6MV0olA6MkPRd0j7yFfMMwOBcZ4CKK7YJ5kAsQHxO2CgVufMwWOPEhV89wvRMnLBzBEU2gTXXsNcwjzawF5UqjYfPaB02N2TzV2TDy6f4zwgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zJAVMidU5iZK0ttWDFP94zxYQI1EImqgOG4JC6PIZnI=; b=DLfsbTGuRqafdI/BDU+M0fhYioDhy51F2WG7ZOGG8K3sVmP0rcuPkQafNeFbbjgpxa9/RfMv2s6HiYcsseer59V4XaEtRf2tgSnPWsVSQIGFsw4CDLAWqWkKNc9KGwDqrozuX8gspaNIjo8xJb7BumKL6a5CWey57IbsjlovB4rqsX9sNMbum6+4EHzCXoUYQTQvmu02Xm1w6FmzJV978z7Ty9Q1QkjtajwHNypp2tpAuTtv9j9tmEYjTiimkOoYkQqV9gMe1mwXdhpkvBtCjafg+Q07Sd6mQAeG8OiHW2w2kdyAKu9HV/dz1PvX/2JOdxUttJW5kGmSUH69pgz9qA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zJAVMidU5iZK0ttWDFP94zxYQI1EImqgOG4JC6PIZnI=; b=T7Sc6rMO6R75ehZOlhpxBq46Rux68Q00/aWWMcjZo4wedZEikcMkrMQdjvRZ3GYeMgDfX09HbJX2xQgz22aGPtLNWF8EIbOejudr3BsQZZBzGQ+97LYCp/GwaQr2Vcbw9UG31pOTIn3hXvFBQugvPyNW4cq+ByLIK6c0m1kOYDE= Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by MN2PR14MB3983.namprd14.prod.outlook.com (2603:10b6:208:1db::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.33; Mon, 22 Feb 2021 15:58:31 +0000 Received: from MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a]) by MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a%7]) with mapi id 15.20.3868.032; Mon, 22 Feb 2021 15:58:31 +0000 From: Don Fedyk To: Tero Kivinen , "ipsec@ietf.org" , Christian Hopps Thread-Topic: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs Thread-Index: AQHW8r3CP5T6pbGiZEC5ACQoiUA5ZKpkgQjg Date: Mon, 22 Feb 2021 15:58:31 +0000 Message-ID: References: <24590.9731.586561.210161@fireball.acr.fi> In-Reply-To: <24590.9731.586561.210161@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=labn.net; x-originating-ip: [173.48.105.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b993fbf-a387-418c-eea8-08d8d74ab398 x-ms-traffictypediagnostic: MN2PR14MB3983: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CwiVdEp9efedsHOs5W+1/Rkiktck4E5LgfT9OJQVRjXav9e64w9PnndaDAH0imqBi31G9/T+JOkqVf+FKmK6iKUKgJdl9KN9K/aunYCmw8jJbjVaRU56eH4DJnw8isHAHEriCsTlpO+lqTE7RDBMBWWLPKuPck9StW332+9PcPCzP6J1ckuM4GJj02YGGLhKwoA6EUpXwKhjAw9MKJmMwX5Zv11GOJTHmFH3227SP9BDV2zow9V1jmh1VXzZres49ypvv85g6wH0mOV+QU8+0Fv4LgqDZxpJxNnfXRQHJo6fZEuXBhxMFDQ3M3fZFNchzdSSmp1Zjcnzbaqb8e0oov6Xxw2CcT08AsFpfw8kjrJ728dHJSDfaYaM+y2C1fTy/L4GQFydJfHKhWBWTBgtt8YxbQfAjdX4H3kXqCm/6YAptXPfCyAWXK4Ztp9HL8b6DL8eHmPwSiIWH1PlgheMIDTQ3k9zmG6yH2M8modPH1Y4/V4RRXDBgVSWu7Zdb55mUpHxobjEHB1XLScA/pOeDhrMuKpI7Q8t71qqePQhar9Vv72Tg1uLtjru7rm2mUab5IH5BkQP1JhIV6ASHfjAMRgQVCqIQYOE+nCbKq8VsL8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB4030.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(366004)(396003)(376002)(39830400003)(64756008)(53546011)(2906002)(6506007)(66446008)(66556008)(76116006)(4744005)(66946007)(66476007)(6636002)(86362001)(7696005)(110136005)(83380400001)(316002)(478600001)(9686003)(966005)(26005)(55016002)(71200400001)(8676002)(52536014)(33656002)(5660300002)(186003)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Qg5C0KamDIGs5VRPcMkcPkjmvrJpsSIHWlFiFNAF253NS8E0K6FTEv5kDf0+?= =?us-ascii?Q?LqY10kxuBzCLAVjgzrjquFdgl/RVoJmNa6lBny+tuRHmRn4RjWmFgrZuJYhu?= =?us-ascii?Q?nYEmu1tCj58iXe8tms5SWEz0IydM1QnX+uMrgICfOBbDDS1S2plnQvfk1Qag?= =?us-ascii?Q?8WNWbMs4In8r4TkOxDHrC4sDofLGbM9B8Ja73iW30bmTHvWmQO5LLJb9NJDx?= =?us-ascii?Q?fZ06TNmVpdddjqTDAcH0X5Sw6PiRzMexB9LLY2vaXpfCiOQ6rEUTJGW8UDWJ?= =?us-ascii?Q?Wyy0s7+OhANZZGJVaX/kfe2yXPDUr7Go1EPjlLKFWD6A80TY0rHAJ4ifWTDK?= =?us-ascii?Q?6X49T8V2/ILLjuOangqTm37vxuiO8LyVQ+4+lAYpH8I/ehk0u2gg8RKSqINB?= =?us-ascii?Q?hpp+ap7ksAmHyHtBTS0eNSKDbf0xWuA3zDXRFonZYviHmW3ff+hKW8edLOOK?= =?us-ascii?Q?+M1UQjNUSW73eJZg5kl7xy5Lp7cqC9PMdiGd3W5xzjq2Jp5+9EjhUGtIDL5N?= =?us-ascii?Q?8zNK6VexZpkZEIPsgwxvAjCGgxR8i0481CgGA9WS7YzOJVbNb8ETrKsmeE3T?= =?us-ascii?Q?9X5JN+s8PHj/+I/K1+A54vsUF+WD9q/D3yMEW7BcU2hecMJjdn0zBCcUXbSu?= =?us-ascii?Q?1g/5DvqQxKWP7Ax/aLznmUw8FIh3adx90xZIZaDN7XdmQNpJQMA5Q52E4HVh?= =?us-ascii?Q?TiIpHYyzPjVIx8thnetrQ/opAGCbhn01Egy0ixduwL9unGxERYubAJg4jSM1?= =?us-ascii?Q?vJG8qlBkEDLHivL20J58eUVWvv6JPM5QTCuoPSg16Ux72QI7nwzwZouJ9gR4?= =?us-ascii?Q?+3pg1+W0EZ7t3o4W7i4Io4UG0c5JxpjTbH6Zr7RE862V2sSKdyfXe9nbToqX?= =?us-ascii?Q?tVaGXuSGR7BVv0VS8AY80pkcy+gDPdAyAMTp+A0aQg90A8J2xlYVtXduBRZy?= =?us-ascii?Q?VhiVlgrL86AZivv0cKK5Qe5y5e59sqzVkHBvGaB2sGE2KaR6iaX1EC9mnqQZ?= =?us-ascii?Q?Wvyfz+3A9slYEHGQ5DvGM0gnCUKJtHKp86Izcl2ysadNFNQ9QZhRZx2JpPB3?= =?us-ascii?Q?XXpRuSWU7nbFU9W9tLqusAh80ANuqmUy7MBZW1SWUVRAyqNvFafz9t2PdX36?= =?us-ascii?Q?Vx+h092FWfC6g7Od7Hs6zWixfGQ548iI98dtN69g8v0zPZf5gjxNRbCw5Rac?= =?us-ascii?Q?D6zhMg+vwaOaogOgQfMIAucUTQNWKsl5jgncAftCoTSakCeQvwUdWcqP/muJ?= =?us-ascii?Q?oKeosdbQGaUwK4RRId9ozTN59k8J7RJPjD3E5l8F2BG/OLBcI9kl/jXxgqvH?= =?us-ascii?Q?EVtLciqy+Eg8SljZZsRJzhjS?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB4030.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b993fbf-a387-418c-eea8-08d8d74ab398 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2021 15:58:31.1809 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NZmwak5kTgFupoOBqzaJZTJfpKZaBti9yibuIR1k4SHQmCHMky88KcAMB/vZYuBb74tbBfZd2FmC5x5wjNEdEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3983 Archived-At: Subject: Re: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 15:58:39 -0000 Hi Can we republish this draft as a WG ie draft-ietf-ipsecme-yang-iptfs-00.yan= g ? Thanks,=20 Don & Chris -----Original Message----- From: IPsec On Behalf Of Tero Kivinen Sent: Sunday, January 24, 2021 9:00 PM To: ipsec@ietf.org Subject: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs This is the start of 3 week WG adoption call for this document, ending 2021= -02-15. Please send your reply about whether you support adopting this docu= ment as WG document or not. This document is not explictly mentioned in our charter, but as this is par= t of the traffic flow confidentiality work that is part of our charter, I t= hink this is something we can and should work on. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Feb 22 13:37:55 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FF83A207F; Mon, 22 Feb 2021 13:37:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <161402986972.2878.2008334228413807566@ietfa.amsl.com> Date: Mon, 22 Feb 2021 13:37:49 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-fedyk-ipsecme-yang-iptfs-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 21:37:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP Traffic Flow Security YANG Module Authors : Don Fedyk Christian Hopps Filename : draft-fedyk-ipsecme-yang-iptfs-02.txt Pages : 27 Date : 2021-02-22 Abstract: This document describes a yang module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-yang-iptfs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-fedyk-ipsecme-yang-iptfs-02 https://datatracker.ietf.org/doc/html/draft-fedyk-ipsecme-yang-iptfs-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-fedyk-ipsecme-yang-iptfs-02 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 Mon Feb 22 14:52:37 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 654223A25BB; Mon, 22 Feb 2021 14:52:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <161403434337.6110.14699404410074399591@ietfa.amsl.com> Date: Mon, 22 Feb 2021 14:52:23 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 22:52:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP-TFS: IP Traffic Flow Security Using Aggregation and Fragmentation Author : Christian Hopps Filename : draft-ietf-ipsecme-iptfs-07.txt Pages : 30 Date : 2021-02-22 Abstract: This document describes a mechanism to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send- rate IPsec tunnel. The solution allows for congestion control as well as non-constant send-rate usage. The mechanisms defined in this document are generic with the intent of allowing for non-TFS uses, but such uses are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-07 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-07 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 Mon Feb 22 18:24:42 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465BE3A245A for ; Mon, 22 Feb 2021 18:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 aa9ZvfUidpls for ; Mon, 22 Feb 2021 18:24:33 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 A54EA3A246A for ; Mon, 22 Feb 2021 18:24:32 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Dl2tk40bCz319 for ; Tue, 23 Feb 2021 03:24:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614047070; bh=HkrFMNFML4TyVP2jquLlfzSXsT9a1751Oo/M1enWrSM=; h=Date:From:To:Subject; b=nCBWtnB/JhGQI0zckrwctBYKCg+qLrXEOA/YMTS+CTHUpn3ROHn19OmOdw/yS1u8R tioXzMKd2pB4INfV04D0VF/QfO3RdedR9sUaVQqzZfRkn61PuYGsJOlxKVq9LZ94Ki WIntX342lj7T136jqliYmtXO5xGBMK/DqSN4XXbo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id OidDXB7lo8jA for ; Tue, 23 Feb 2021 03:24:29 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 23 Feb 2021 03:24:29 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 295B06029BA0; Mon, 22 Feb 2021 21:24:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 20C8666B1E for ; Mon, 22 Feb 2021 21:24:28 -0500 (EST) Date: Mon, 22 Feb 2021 21:24:28 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: <73cdb21b-e7ec-acda-147d-5584f8f5fe75@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: [IPsec] Fwd: New Version Notification for draft-pwouters-multi-sa-performance-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 02:24:40 -0000 Status:         https://datatracker.ietf.org/doc/draft-pwouters-multi-sa-performance/ Htmlized:       https://datatracker.ietf.org/doc/html/draft-pwouters-multi-sa-performance Htmlized:       https://tools.ietf.org/html/draft-pwouters-multi-sa-performance-01 Diff:           https://www.ietf.org/rfcdiff?url2=draft-pwouters-multi-sa-performance-01 Hi, We have updated the multi-sa-performance draft and looked at clarifying the text more. We changed the QUEUE_INFO so that one can also exchange information on which queue/cpu a certain Child SA is for. We clarified that the initial Child must always be kept and that per-CPU child SA's can be deleted when idle. We changed the parameters for NUM_QUEUES to only one value, as we realised doing a too exact min/max number of Child SA's does not work well in many corner cases and it is far easier to just throw in (or let there be) a few more Child SA's then you strictly need. Paul From nobody Tue Feb 23 07:05:50 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACBA3A2C3D for ; Tue, 23 Feb 2021 07:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 KiTI4c-g3tWN for ; Tue, 23 Feb 2021 07:05:46 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 19DA33A2C3A for ; Tue, 23 Feb 2021 07:05:45 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 8086220099; Tue, 23 Feb 2021 17:05:42 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1614092742; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MAgftfqpShekqQrrRd9quAkjv3E186iUcYrrJcb+sHY=; b=LWKmPqy0zMXaQ2S+Rmnvs84uau5zcuFStBOCAvLY2LUzgSofixvCUZ3205rRi2lDvfl40K b+qBXjiF84LYtT9UC+CDXqiHuFh5PSPKKzGwRB+enX1o4s5AlHbBv/PYnYNyynqklXA2ic lPD5+9L5GWoNVngGIgmbRpqIv3528eM= Received: by fireball.acr.fi (Postfix, from userid 15204) id 8D77325C16FB; Tue, 23 Feb 2021 17:05:41 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24629.6597.547827.701311@fireball.acr.fi> Date: Tue, 23 Feb 2021 17:05:41 +0200 From: Tero Kivinen To: Don Fedyk Cc: "ipsec\@ietf.org" , Christian Hopps In-Reply-To: References: <24590.9731.586561.210161@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min ARC-Seal: i=1; s=meesny; d=iki.fi; t=1614092742; a=rsa-sha256; cv=none; b=QSB4lN+zeaOS6xVHwsqvIAltH4Xgm0THLe1XZLHRBt9d3HvZKQRbgcXgM1xqcaBOZLOjma g5TVzJPY6GNbQLfVx0HH2KIDsaUzTN2Rxw8CnsJj05Jij+o4V4z2EtMcSZeUosvsEGcY4r Zf1o9ytXDFpVfnrILDmpogIRnyAPNX8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1614092742; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MAgftfqpShekqQrrRd9quAkjv3E186iUcYrrJcb+sHY=; b=hgg9iUFos7TWScifFoCxlTQB98iaZvDkAT6zlNA/qY29m3s+msMRhz1ihpXBorh8b212dj gbCQkzq7KkomR7XKuPFPlBbE3cGQvHqji0u3yf4asvGoT6imlxHQkAkbf6p/RaC72I5slh FANjjTlostAYDvG1/K3Ld71j1ucGTpw= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 15:05:48 -0000 Don Fedyk writes: > Can we republish this draft as a WG ie > draft-ietf-ipsecme-yang-iptfs-00.yang ? There is no need for that now. The adopted WG drafts are marked as such in the datatracker when I get that far in my process of getting things ready for the ietf, and then when next revision of the draft is needed, it can either be published as new name, or continue using the old name. Usually there is no point of republishing the draft unless there is any changes. -- kivinen@iki.fi From nobody Tue Feb 23 08:50:56 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915803A09DE for ; Tue, 23 Feb 2021 08:50:54 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.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 0tNXwgtEIprS for ; Tue, 23 Feb 2021 08:50:52 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2120.outbound.protection.outlook.com [40.107.243.120]) (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 BD4893A0C81 for ; Tue, 23 Feb 2021 08:50:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MkKOupHGzCIr9ixBHbBv7gh6FstLVew4S5LADBYdBEtlwg8lPq4g+HYrELKxq3WJ6szwCwS9i/7x+DyPc3JtHYkNgfbZ1Udr/pfXnTFLgmOeXRXs+wFprpxTtmtnyIvp8DFME4qCPiwjU+H5ulVSQtSdPnEXrKsdgPp+OBpAypZkL86AC8t6uMO4hNyAUbZsung7VTg25WrC/2BjWiHfTGw0oXMfYol2vUXRcfcGwDNllGU+hyd5yWSLPFZK6DUzx/Kyi6tYOJYMVxHps+mFxNtZ+y3SaNlcKuQACE5Ls/bTQAOR5uPfYLEcEEp99CCRZ685vh2aOMCsYPBSHaEqFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HeYZRf/LcyG0fJdHfu3NrlKGmKGDWGHMsAHZtNT8zuA=; b=C6J46fq3PPGzbzdIUYaGSBuDV7dLWiI78/qcWeFuEAGIxNcIrV5mSge9ZlGzzQuMwQxdOYcqQ/2mdSNjCBxtcKn8f5dTjZTq4X/Ey1Ry2hK8dJruZlDMbx/aoLIQQ1Affo5+CEm4B2vACCtO+EMRI9OijYX8RM8tZe/0EFjyJecmrdgx+/O95sSiHXolCZDmcUl1AV+k1KkboLIMVPVYWtitCEA2AqJTkqzItDDfUXBVokuzl7dBBrDWihMfZzj5fgjQMaFMsE82Gn6oF2PMOb+DYTRRFG+rRCc7g/l7+vAFzQULJDyyoHRv0wJsWX6rF8IxxvEljGfiHLnacYUgog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HeYZRf/LcyG0fJdHfu3NrlKGmKGDWGHMsAHZtNT8zuA=; b=Htx+0bbaiChyxRLMGBsNadThlL0iKLb+7HNpF70VdjBjwCnjV5x7xFLCCuDWT32CzogX9Y5J1xW1rk+nDvTdAV7YeHflNjqB1fqllV6nALZJde7i8oTtWF+slpXv5+XEXDDY5z2XBEy3z8WSBZISM+CZW9fdwqqKf7NtYfOjn00= Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by MN2PR14MB3471.namprd14.prod.outlook.com (2603:10b6:208:1a9::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.32; Tue, 23 Feb 2021 16:50:35 +0000 Received: from MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a]) by MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a%7]) with mapi id 15.20.3868.032; Tue, 23 Feb 2021 16:50:35 +0000 From: Don Fedyk To: Tero Kivinen CC: "ipsec@ietf.org" , Christian Hopps , Eric Kinzie Thread-Topic: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs Thread-Index: AQHW8r3CP5T6pbGiZEC5ACQoiUA5ZKpkgQjggAGEMICAABeU4A== Date: Tue, 23 Feb 2021 16:50:35 +0000 Message-ID: References: <24590.9731.586561.210161@fireball.acr.fi> <24629.6597.547827.701311@fireball.acr.fi> In-Reply-To: <24629.6597.547827.701311@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=labn.net; x-originating-ip: [173.48.105.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c048bf0-a86b-44f1-eaa2-08d8d81b2401 x-ms-traffictypediagnostic: MN2PR14MB3471: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZSmo/tyQY85ZM3vDMn8sckJpXmoyU6UkVtgoBQTWlfNzPvQrimykRqMMz0Oy7mU6yPcjUAvCGzW6SC8Us81u6q0YZZ5hVdSO/OYiIYGdbFRJv7QtXw1wIWVtfrW5/LI1sOqjt8jWCB2nsNWGvuLnwRCCSyp+hxJeTr6iJNhytwfCs/sl/Nw52uoN9QNaKqFlHJbhjf6pX+4VZuDlLnAzyL4iylnyvZxrVEZUQUsgwf7j1WL5JESHQtrqxhAGX2QOUbkcshUFdYYFo7nmSpVGHQHoyETLImup/SNzN7g+l4idjksR1pkVjQJHzZ00uYAYe9o73r/xSmB/QbSE0kdpZZa3d8Ds3LB+ZH9OPj8AQIMh1vVjlU/1t/5Dxpc30zYyngSDin+hKJtQDD0rS4SZ5oQao+3umcAy71LVC7Ha3MHJI2LaReK+8EPdkm8cQde6depOzaLYQlWiIIUhgnjq2obVpQxhs0kx1NxKmuXiP2oAw3t8+9EkSMef1F9mH3aTQNRG1oxIapl3cujwRIVBMw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB4030.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(4326008)(7696005)(52536014)(107886003)(64756008)(33656002)(66556008)(186003)(2906002)(54906003)(66476007)(76116006)(66446008)(5660300002)(66946007)(6916009)(71200400001)(508600001)(83380400001)(26005)(8676002)(53546011)(86362001)(55016002)(8936002)(6506007)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?5TQ+MSL4ewLyK4bqis0Unl+xbnTf36mok9/cTDxan4ghY0nN1LwLmBHpsmZl?= =?us-ascii?Q?TM6K6oMb1nbrtP29f2UB3vtJ/8rNM7SgQO07piTLgkdiQERRqZnIYJB64nkx?= =?us-ascii?Q?wR7T2ni9G8ER3BGeumCtVIHv7y4Fb1o0+DdsL23HpohPQC2B4wkAc0BUAdtE?= =?us-ascii?Q?MY4alO3Gn64hkIfs3XrOqnigIR2QFXKaCO3rWO6ouOtD67QlPHFWlEKobAec?= =?us-ascii?Q?pjqfImRqPTMTG5L60hZrbL7bJdqnIJh3knNDuiRmIWPJM6bIg0Lup5AnY8Yf?= =?us-ascii?Q?H0HeJKbMskwnCW0hK7wWqok0DEGHTl0tXNfu6cgEtej+Is5PUQhEfS6xvLxZ?= =?us-ascii?Q?pzROwDkX+KiozcGfnRAeYNzbbHLA/WZCSuKTgrVOdOC4OfkPUPX5JsVUqp2W?= =?us-ascii?Q?WoAAbl89r/2UYFKtErugrs4+Hk8fb66k19JXUkTx3BrbIz9k/I/mEDI2x2fd?= =?us-ascii?Q?NLt0Dd8i/nkbY85HRI0CNjQuTfhIdlgB1++5oadF/TMXC0h2moOaZwQROUX+?= =?us-ascii?Q?xWauC5IH3lTphaCZIx8YFkgXRQcigSlMVAQUIEUtSaQ9OGH367xRyci47dU+?= =?us-ascii?Q?MnIYJ8xCd0YTpuDqis8MWRhxf2KM1Wuo3n2ieDm9YtyAgi72YmY8HQ7+GXVW?= =?us-ascii?Q?2vU+e8bHpir9pD1djk44L+7ew71LdnSDpr0+SqcvQ82a7VIBQ4P26TBC7Bw3?= =?us-ascii?Q?QUxqtRaMhwwmuV/vSHN/QPvecGG3cemC9ZyqJ2DT6q0rO4xvqxjqIyP1Y54O?= =?us-ascii?Q?mBBMTwhuS2p3OPUatJ43Hb0+/YUz2WgVdMnhvGSQHFZMS++K0akP14lmrgqD?= =?us-ascii?Q?I8kdk+xYQ0cY9S5FeU69k4+SNjgeKWPCB/TGkjk6WODe8vYgl4EZd+pWDmFS?= =?us-ascii?Q?fAXkHuV5Zhy2GJsXHHGPh6emhIpFAciJB4y6qj/0+rEStpq7d+uRLG9DdBAz?= =?us-ascii?Q?V7D/0RlQ2S4X6e5ZjfRQjWGJZynL/sgrltYUCHQhthzbC4SVo/AF3+yiEjFO?= =?us-ascii?Q?nFTdI4DkgQP7cJbyjNAzIONLdqPCVk5JRXOBw6lnGdZowRoijgxyE4eSQDKS?= =?us-ascii?Q?Svul5MN94hKQ7IRVmlI4ROwoX2AUYqcD4vJj4Cb0SiR4PkL4+lph0ZotoSQI?= =?us-ascii?Q?9FYMMKpUTJhUmR7uC5AO3kqK5gncm+Xv10r/gxGs+ONKfgHEREKlm4oakR2z?= =?us-ascii?Q?qvgoAlpOQ0Eh3kd6I/DK3BIwnOse3Dghh7WeAssFDc3/yabsQyhvKO2D5NkM?= =?us-ascii?Q?oQeTBZDtBtSmYC7fx6ytLXxbeV47UFWxKf0CYXtbK0LkX6stTu91dQmHWTPM?= =?us-ascii?Q?2r5zVGsQgjWeqQZLMXrLWFQZ?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB4030.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c048bf0-a86b-44f1-eaa2-08d8d81b2401 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2021 16:50:35.1532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evpbGk6HEQPfwC5QoTYQaufnqRHkwPgtTpTyzS1Iol56AbVXIRjqCl+zzo8vLbWrr7FG1tlkXfA39IYucXgiUw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3471 Archived-At: Subject: Re: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 16:50:55 -0000 Hi Tero OK. We have published a new version that addresses your comments and brings= this model up to date with the main draft. Also, since we augment anothe= r YANG that is still undergoing a bit of change (during IESG review), the s= upplied test configurations were adjusted to satisfy those changes. =20 We also have submitted a MIB module in another draft that is organized base= d on the YANG module for using SNMP to read the configuration.=20 Thanks Don =20 -----Original Message----- From: Tero Kivinen =20 Sent: Tuesday, February 23, 2021 10:06 AM To: Don Fedyk Cc: ipsec@ietf.org; Christian Hopps Subject: RE: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs Don Fedyk writes: > Can we republish this draft as a WG ie=20 > draft-ietf-ipsecme-yang-iptfs-00.yang ? There is no need for that now. The adopted WG drafts are marked as such in = the datatracker when I get that far in my process of getting things ready f= or the ietf, and then when next revision of the draft is needed, it can eit= her be published as new name, or continue using the old name. Usually there is no point of republishing the draft unless there is any cha= nges.=20 -- kivinen@iki.fi From nobody Wed Feb 24 06:24:36 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0343A164A for ; Wed, 24 Feb 2021 06:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 QkebrLELQncX for ; Wed, 24 Feb 2021 06:24:33 -0800 (PST) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 275A73A1649 for ; Wed, 24 Feb 2021 06:24:32 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 8B94F1B00081 for ; Wed, 24 Feb 2021 16:24:27 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1614176668; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Iy9ufVgvDN0A7644tqxqbzDeTqN2/I5JDxdQlhyWwkE=; b=Nz25mwGktNvEMOCaiVDoXiwqhswi4Bj5eyzD9bCk7S8xv6MgRdAQpaoFGSXxAgUf0xRCZ2 ThNgBoz458mH51JhJMKoUWQtt+mLLGzyqONs6uCXmqehnQQdxfOAJqm1x6UGmdQ0VrPsRs 1tcyqaQuF6UpmmkuH+KlwoA74IGTyTMYA9X4VDQ3dXuHVVJ2xfX5iEmyS2cv3oKeiHguBb XmZuykTa274uP8GB0k1f0mESZQUboss+fiOVtBB0ige/8UMpfvt2FOxKfjcG9p9fpW1cEy moUuIpkiai6/TiKqgga2ZK/3aOKuB8Xk/214ir2D191U3WAXm3DGYADXmsqosA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 4217125C17E6; Wed, 24 Feb 2021 16:24:27 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24630.24987.212447.935241@fireball.acr.fi> Date: Wed, 24 Feb 2021 16:24:27 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 27 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1614176668; a=rsa-sha256; cv=none; b=Fg3kZGX6rCrms4MilIrsvhRdz2Lp60LrLmi9DThyqs/tG7W8dfL9pF4q5/65ZmBuYqYoZ7 yPLzYkSErWGPg7G2yobNB0tk1fZnHr2vMA4VeU0CdBI0+Hy/jMkT7PuthS8nSHFmQYdcX7 LncJ39AuBAec+TBaZFyrVSHyOkV15UYUBuLIo7NcrWNYLS0UQpt2oOwZATf3IVCwyRRgrH HCMboUcwCkVfcS6RewNo+Sgg2Jj+wkNnZaTmEuUL+hSK/hr1Q78N81rjh6tRb5GWZxfzqs hBTeW5YzAzKoP5yrahNS5CLnnLUmMnbj/cMfeNf3FLbwKgC83m9DKMTNvFQxAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1614176668; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Iy9ufVgvDN0A7644tqxqbzDeTqN2/I5JDxdQlhyWwkE=; b=cBVi8chLM0qaogIUCtuZJm/1s3ChrZ+CFvLwc4UkcX6lj/10VsD5mSaJW386zloQsP/IRB yoGFQrHFx0j0eLhPy5uuFwQh4ADzI5QIwpQU9VvzGYSVUK8Jgeb3PWU2KbxaOZV18BBQlP tm3wd8HlSQM1JB63LHlziSNFoeEy5gI8NgmVdq/FcbjiazzZ2++8ucq3Uzop7aDtP+ON18 VHsSK9gNkDysYnbaXeYL5RHa0jDtMAkWcOrWXaDGxxPsx70w6zGPoTx1t5OZyHQ/t2IHqp xKDPYVRKzPRyyafUe4e6luXiC8gCNetcCNLtwDlRnFBILKrMU0GOPhEcAv0q7A== Archived-At: Subject: [IPsec] Review of the draft-smyslov-ipsecme-rfc8229bis-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 14:24:36 -0000 I quickly reviewed the draft-smyslov-ipsecme-rfc8229bis-02, or more accurately I reviewed the diff between the rfc8229 and this draft [1] During the review I found this text: Additionally, since TCP headers are longer than UDP headers, and TCP encapsulation adds a 16-bit Length field, some very long ESP and IKE messages that could be sent over UDP cannot be encapsulated in TCP, because their total length after encapsulation would exceed 65535 and thus could not be represented in Length field. In my understanding the length of TCP headers does not matter, as we just send data inside the TCP stream, thus only "expansion" is the extra 16-bit Length field and the non-ESP marker for IKE messages. This means the inner ESP packet can be up to 65535-2 = 65533 octets long, which is longer that you can put in to the IP packet (which will need some headers). The maximum IKE packet you can use in TCP is 65535-2-4 = 65529 octets, which is still more than you can put in the normal IKE UDP packet. So in general I do not think the text above is true, and I do not think we should be adding such text. -- In section 7.3 there is text saying: Note that if this TCP connection is closed, the Responder MUST NOT include the Initiator's TCP port into the Cookie calculation (*), since the Cookie will be returned over a new TCP connection with a different port. As this is used in situation where UDP does not work reliably which usually means there are NATs involved, that might also mean that the TCP source address might also change. So including TCP source address to the cookie calculation might also cause problems. Also adding those to the cookie calculations does not help at all, as we do full round trip exchange to set up the TCP session anyways, so having them there doesn't really make any difference. This might cause attacker to be able to get one cookie, solve it once, and send responses over several TCP connections, but I think responder needs to be able to reject multiple solutions to same puzzle even when source address and port are not included in the cookie. -- In section 7.7 should we also cover what to do with ECN? Ah it is already described in section 10.5, should there be reference to there from here? [1] https://www.ietf.org/rfcdiff?url1=rfc8229&url2=draft-smyslov-ipsecme-rfc8229bis-02 -- kivinen@iki.fi From nobody Wed Feb 24 06:25:10 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 549423A165C; Wed, 24 Feb 2021 06:25:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161417670833.28125.17758193005047255633@ietfa.amsl.com> Date: Wed, 24 Feb 2021 06:25:08 -0800 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-smyslov-ipsecme-rfc8229bis in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 14:25:08 -0000 The IPSECME WG has placed draft-smyslov-ipsecme-rfc8229bis in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-rfc8229bis/ From nobody Wed Feb 24 06:35:17 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641FF3A1664 for ; Wed, 24 Feb 2021 06:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 Yu5DWXeMiPn7 for ; Wed, 24 Feb 2021 06:35:06 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 563E73A1665 for ; Wed, 24 Feb 2021 06:35:06 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 2A788200EB for ; Wed, 24 Feb 2021 16:35:03 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1614177303; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=fg37ytZ0k0kVke/yEeCjOjqCchbRo59W7l5oyBnv2j8=; b=aIvV/TedH8ykl5JWcfpDArwICjniinE5NGIBI+3XzMuCgdrcJ3yOQjKw46Hong8K3XoRMy j5MY4IU9GmNlAGAxhX5OGRSiG/AathXST5LKF8SojN02n9w+JFABiZsJcEneNz1V6SaFl7 APIUsSc3koIQwWI7gLtv15txcg8NQ8Q= Received: by fireball.acr.fi (Postfix, from userid 15204) id E522325C17E7; Wed, 24 Feb 2021 16:35:02 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24630.25622.894368.540704@fireball.acr.fi> Date: Wed, 24 Feb 2021 16:35:02 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 9 min ARC-Seal: i=1; s=meesny; d=iki.fi; t=1614177303; a=rsa-sha256; cv=none; b=htJS01ahxZkPKXZewimBF5OGYujZp8aa8U0NUxUmExPHGeQVMvKfUVB7LXmPy0f8MXlDyX RkVjG8nQcW0FioPOhTlcOHW5sowwOmP9Gy8n4xLZxZ+GJXWkPUq4MPQ9nG77m+g2uDtLVG rhWZFLXgNG3eeVBWOU2qgg7kqHt18/k= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1614177303; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=fg37ytZ0k0kVke/yEeCjOjqCchbRo59W7l5oyBnv2j8=; b=Jdjw37hDnq/O0tU23g/9ezmbCclaIjDosvzMxweuqhb5OOHmN/eRm9o1IVi+i6Hsvd+Pqd CWLwk5SLskx27jehyKWl8RSKiYMnygZB4160fCZi3AIqLpaFj3jP0n/P/3IgbHsOXi0ge8 RlB6xmqQo0rvWaZHhZM0/xzxDndEpmE= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] WG adoption call for draft-smyslov-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 14:35:08 -0000 This is the start of 1.5 week WG adoption call for this document, ending 2021-02-07 (just before our IPsecME session in IETF 110). Please send your reply about whether you support adopting this document as WG document or not. Our charter has item for: RFC8229, published in 2017, specifies how to encapsulate IKEv2 and ESP traffic in TCP. Implementation experience has revealed that not all situations are covered in RFC8229, and that may lead to interoperability problems or to suboptimal performance. The WG will provide a document to give implementors more guidance about how to use reliable stream transport in IKEv2 and clarify some issues that have been discovered. A possible starting point is draft-smyslov-ipsecme-tcp-guidelines. and during that process we decided it might be better to do full bis version of the RFC8229 instead of just providing some kind of guidelines document. This work is that bis document. -- kivinen@iki.fi From nobody Wed Feb 24 15:19:33 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547E53A1D3E for ; Wed, 24 Feb 2021 15:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 hE9Lll9kG34D for ; Wed, 24 Feb 2021 15:19:29 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 355EC3A1D3F for ; Wed, 24 Feb 2021 15:19:28 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id B7843200EB for ; Thu, 25 Feb 2021 01:19:25 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1614208765; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=BJSxEmGyUFJcYr+M4NIIYKf+IesbYDuosWbBJWciQ8Q=; b=rkO2a/3TucJDQhWLx4YauFxB7zDfqrqfThL14egFT1CuI5Enr7+d6ODtEkr7392CgRhLNg dgfQgsNi1T83gpKru5IzCWYjS0Zn7AjQytoAeT35J7sevKh269F9Tn51x4/4LRxnos8RLd F1bfqXSNYpZFXa9ig4Sh3E0v7tYATgA= Received: by fireball.acr.fi (Postfix, from userid 15204) id 8C8A525C0E99; Thu, 25 Feb 2021 01:19:24 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24630.57084.526500.121911@fireball.acr.fi> Date: Thu, 25 Feb 2021 01:19:24 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min ARC-Seal: i=1; s=meesny; d=iki.fi; t=1614208765; a=rsa-sha256; cv=none; b=G/D5dECXz6Zb8zbMqIBogFN10cc1nvAwIf6j3DgObZxqpXTKFtqKBO5HwoH8mYLyAet9gz TV7/enIL7D8lS4h2cJ0J9KSy/XhbAgUr4wuU5aIhHHkvwYaAdkM3W9RiZ/9UkhJb0RLk9g y8ecYoE43xCfUch0S+ANGat8wx68iW4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1614208765; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=BJSxEmGyUFJcYr+M4NIIYKf+IesbYDuosWbBJWciQ8Q=; b=Sc66UVnmVM+fgVzeR0JRAStGj4QR6RU9N7bOICevBDWEypXz9oswqZPvvCIRfpio8piNRO lFXXATExnxWG+CKXV8rOlk2yUp01B/KcfG70cJQVyYVSaIkHhw7+O0/Bc/+xQRU7s7MPk4 2xkn9VBBOkLDRnrsuGa7SNR05AgP7us= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] WGLC of the draft-ietf-ipsecme-ikev2-intermediate X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 23:19:31 -0000 This is the start of 1.5 week WGLC on the document, ending 2021-03-07, i.e. just before the IPsecME WG meeting in IETF 110. Please submit your comments to the list, also send a note if you have reviewed the document, so we can see how many people are interested in getting this out. -- kivinen@iki.fi From nobody Thu Feb 25 00:30:08 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A92A3A15A2 for ; Thu, 25 Feb 2021 00:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2u1Z54dnekX9 for ; Thu, 25 Feb 2021 00:30:05 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::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 A0F643A15A4 for ; Thu, 25 Feb 2021 00:30:05 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id 2so953377ljr.5 for ; Thu, 25 Feb 2021 00:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=8Hk/kpRrwmvx5NXh0gYpBFLBQFiA8yNghnY/pE1jDBM=; b=ji/matiaBpXP8RgSCcHS/A96sT2afRCnKE/03shno3DnySd6xBG66T9hqoEZ/Z+1V0 J2ncEsC8LodRNXYd8QI3QjdM4NwnbdBE3qEYqm5wXWsrEbUd1XYjzzDk/wJwdJTQncDq o6mlAe5j3AIdb4c9CmjBndZj7Ujg883TQ53zuTS3OvUdPJTRPsAHWpHPdiZOMoT+NyaC +YU9tFxTFjrpmaZyHGjwCe79QMIGr62GW+tIaPTOp2kNKBCC7hxEkuxk6FnOhm+HycDK W78Z8tFIlCw2V1y0KCNtd85yjC8xlVjsgghDpebKUNrPz6rBVSnIPmCj9s0q8D6Z+I5S EFaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=8Hk/kpRrwmvx5NXh0gYpBFLBQFiA8yNghnY/pE1jDBM=; b=OGbCSxD/Nq9dbFudlJi94S52l+P8amFRDY9UfOLa2SzttJqyOZNI/MA2htOIvL0kw9 RPOyUK01aEx772QYS8QP016hdmWmL1tnu9i5BVZnZzQ5EiOR+bdyw3wDifbQoPwVk4lw eq0PuSapX9etrBK6V86lgH5tcLzyyQDQ86fs68mPcDUOZjDsSfd4a3akFP1mdKxS7AH+ 1YZnljs2ZeaPnrfHB4rHpGPgVdEzarH4ORFkrICbsr9bI0HK1B0lR8hbrkRtBTVCAehb sZokupTxR0b755LSCVEHi4brY7scFV0m3FbTfgNDwqp1LmSPfL9WTb2eawnIqWDwY4Ho XdVg== X-Gm-Message-State: AOAM533agBYN24Dp5YX5bZGwsVjuOyjFoHLpTAoGFCmUNTdrHUww66yE ZDAc6EDO/9ybjOln1OCQN2ZcPi+4BbA= X-Google-Smtp-Source: ABdhPJybqNU2DIR5cUbjERsLwJbea0FyYAJxTIpDehjBEBfVloTaZSduzY9SpvUDWzEWJMWKTvHX9g== X-Received: by 2002:a2e:88cb:: with SMTP id a11mr1053474ljk.394.1614241803600; Thu, 25 Feb 2021 00:30:03 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id d6sm1006196ljg.5.2021.02.25.00.30.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Feb 2021 00:30:03 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <24630.25622.894368.540704@fireball.acr.fi> In-Reply-To: <24630.25622.894368.540704@fireball.acr.fi> Date: Thu, 25 Feb 2021 11:30:05 +0300 Message-ID: <0f7201d70b50$6bf8ddc0$43ea9940$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFryKB8PP6TLXbAXoLjE1rOrILtAas++EjA Content-Language: ru Archived-At: Subject: Re: [IPsec] WG adoption call for draft-smyslov-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 08:30:07 -0000 Hi, as co-author I support adoption of this document. Regards, Valery. > This is the start of 1.5 week WG adoption call for this document, > ending 2021-02-07 (just before our IPsecME session in IETF 110). > Please send your reply about whether you support adopting this > document as WG document or not. > > Our charter has item for: > > RFC8229, published in 2017, specifies how to encapsulate IKEv2 > and ESP traffic in TCP. Implementation experience has revealed > that not all situations are covered in RFC8229, and that may > lead to interoperability problems or to suboptimal > performance. The WG will provide a document to give > implementors more guidance about how to use reliable stream > transport in IKEv2 and clarify some issues that have been > discovered. A possible starting point is > draft-smyslov-ipsecme-tcp-guidelines. > > and during that process we decided it might be better to do full bis > version of the RFC8229 instead of just providing some kind of > guidelines document. This work is that bis document. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Feb 25 06:30:37 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B5D3A1AA1 for ; Thu, 25 Feb 2021 06:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RnRTHX-sbKi7 for ; Thu, 25 Feb 2021 06:30:34 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21363A1A9F for ; Thu, 25 Feb 2021 06:30:33 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id 2so2139545ljr.5 for ; Thu, 25 Feb 2021 06:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=J63GRjhrTROb5S/nfLWmddiUBwkKgs8n572Z7obfq0w=; b=Rn2feb/oZcHWBdDoO0eGlFYkMh4GKb5O2Wi1zyW3qXBAqNOGTKVc3geXSG4009aurk id1jMNocu+j+CEU51pXo/Pm8bX0HfPYJrG0eIUV6LKFWK7ULQfrbzRgjgOMcklPFnria 5lpmEOXn3MrAzpcUiNoU/kFZDoKaVu5k4ZPEQMP7bxuX2DLb21zFisW6aXKBqzwFdvLb BNbdB+irbgfUqz4lvvYMRzUzi9Zve5B/Q9KFrp3pygeGhuR8jL53OWMbPpwbMQi6VUjF KdT+j4foh9aU5toFUJA2QKELANlyl4LvdRq0kvl0TVCd77fN+QHJH1Kxm1WrUXA/RgZZ PXRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=J63GRjhrTROb5S/nfLWmddiUBwkKgs8n572Z7obfq0w=; b=guEmD7IYhQ1G9RwcS8qFwX0Fk8Nd2DzY0aVQbfu1/gb2iEVLT9tL708/HySeZoMxTw 2vkkHnzIFDH6NKbgF6KkvW/b6BFaB9FFXQBdcuqJBI0Ti2tYzUtf0WaYFSVnHGiWPz7S Ewm8wA7Azb+ybT0uo7ruDBG2Z5kgLD3w5cfZ8gx/SfeYzz24jncJSOY4PDRWj2/94M/t nR2zCTCKqB849GVIqi22XIAcUhBYAjpO43jv+eU9QDASWOJD3DkBgy0RuBTC+LwiL+ki 9az3cWV8rQaPiij1ownZLL8QnLLP5T0T3xCKqqTeL+htXWDJnHHN7EUYnFcGKehPid1q Rhcg== X-Gm-Message-State: AOAM533Dma15xamfpYPR+PL2ra6sQvsycHIn54ccHRxfBe29FOI08I7z R9T0coH9A2uD6jvlYEBSKhFahdlp+S4= X-Google-Smtp-Source: ABdhPJwtO0gnhci1HOuwc5AFfkNE3Vxyry4vLpIqjF5SCyhFONsnkZ1ARgHHKbyqKR/RPg3OQRwjxw== X-Received: by 2002:a2e:9c84:: with SMTP id x4mr1747373lji.141.1614263431346; Thu, 25 Feb 2021 06:30:31 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id d4sm1136461lfq.270.2021.02.25.06.30.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Feb 2021 06:30:30 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <24630.24987.212447.935241@fireball.acr.fi> In-Reply-To: <24630.24987.212447.935241@fireball.acr.fi> Date: Thu, 25 Feb 2021 17:30:33 +0300 Message-ID: <0f9601d70b82$c74c7650$55e562f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE5meq5E2X13ex8pBvHEjICmfXlf6ujVamA Content-Language: ru Archived-At: Subject: Re: [IPsec] Review of the draft-smyslov-ipsecme-rfc8229bis-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 14:30:36 -0000 Hi Tero, thanks for reviewing the draft. > I quickly reviewed the draft-smyslov-ipsecme-rfc8229bis-02, or more > accurately I reviewed the diff between the rfc8229 and this draft [1] > > During the review I found this text: > > Additionally, since TCP headers are longer than UDP headers, and TCP > encapsulation adds a 16-bit Length field, some very long ESP and IKE > messages that could be sent over UDP cannot be encapsulated in TCP, > because their total length after encapsulation would exceed 65535 and > thus could not be represented in Length field. > > In my understanding the length of TCP headers does not matter, as we > just send data inside the TCP stream, thus only "expansion" is the > extra 16-bit Length field and the non-ESP marker for IKE messages. > This means the inner ESP packet can be up to 65535-2 = 65533 octets > long, which is longer that you can put in to the IP packet (which will > need some headers). The maximum IKE packet you can use in TCP is > 65535-2-4 = 65529 octets, which is still more than you can put in the > normal IKE UDP packet. > > So in general I do not think the text above is true, and I do not > think we should be adding such text. OK, will remove it. > -- > > In section 7.3 there is text saying: > > Note that if this TCP connection is > closed, the Responder MUST NOT include the Initiator's TCP port > into the Cookie calculation (*), since the Cookie will be returned > over a new TCP connection with a different port. > > As this is used in situation where UDP does not work reliably which > usually means there are NATs involved, that might also mean that the Not necessary, it may be just firewall blocking UDP. > TCP source address might also change. So including TCP source address Even with NAT source address is less likely to change (though I didn't say it cannot change). > to the cookie calculation might also cause problems. Also adding those > to the cookie calculations does not help at all, as we do full round > trip exchange to set up the TCP session anyways, so having them there > doesn't really make any difference. This might cause attacker to be > able to get one cookie, solve it once, and send responses over several > TCP connections, but I think responder needs to be able to reject > multiple solutions to same puzzle even when source address and port > are not included in the cookie. I don't think the responder should keep track of solved puzzles. At least I don't recall that RFC 8019 contains such a requirement. Anyway, the situation with IP address is less important, since in most cases source IP will be the same even with NATs. Note, that RFC 7296 recommends to include source IP in cookie calculation, so if it NAT changes it each time it creates new state (TCP or UDP), then IKEv2 over UDP won't work too. I think it's a rare situation, so we may ignore it. > -- > > In section 7.7 should we also cover what to do with ECN? Ah it is > already described in section 10.5, should there be reference to there > from here? OK, will add a reference to 10.5. Regards, Valery. > > [1] https://www.ietf.org/rfcdiff?url1=rfc8229&url2=draft-smyslov-ipsecme-rfc8229bis-02 > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Feb 25 07:28:29 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACD83A1B25 for ; Thu, 25 Feb 2021 07:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 mP1ELO56nTRN for ; Thu, 25 Feb 2021 07:28:26 -0800 (PST) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 A23C93A1B20 for ; Thu, 25 Feb 2021 07:28:23 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 6E00C1B000C8; Thu, 25 Feb 2021 17:28:20 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1614266900; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KoeKEHRCfFn2HjM03wnlzP82dgGuR3cRs19TmplLk7s=; b=LZ9jGqMTLIegiKb+GYFiN8QP/KblkdLo70m1K/xvICopEjgCftv3aHaKz2wMfEcdteH0bK dsV/uDAtGVmxeA1qyDq3E+5rtOBHv5DidcS3d589RHtwuI8+0LOp5K+wOMnebnptv2xM7g h7J/OSK8LNyHP9e1vZ7FgpaA7HMx/rqTSPpoSvW+/mtmRuY5xSg+AMbKDKbVB70HPz9/9U E6ynU8HW/z8hqZxJOX47vaLv4y5Y/Mq7/w1Y2Tx+u61pSHy0hl8BC/edLHDBAi0rbLXUbu GNbL0t33YTSjIpEc9PHRv5ky+Al4q85L1kVWX40Bfpp9oAIoX+mB7+eMh7e+SA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 161EA25C1051; Thu, 25 Feb 2021 17:28:18 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24631.49682.32667.706838@fireball.acr.fi> Date: Thu, 25 Feb 2021 17:28:18 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: In-Reply-To: <0f9601d70b82$c74c7650$55e562f0$@gmail.com> References: <24630.24987.212447.935241@fireball.acr.fi> <0f9601d70b82$c74c7650$55e562f0$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1614266900; a=rsa-sha256; cv=none; b=UyoUvqZxu5wmBXe+YpFPHhag2aauDHkPbDOdNfV9VR7crP2JBlKSaD2k2WKS8Y5rMckstt y8bYxJfvBdmN+h120rCQN+pGtnqMIhiP7rrN1C4xd6EDG2ktgTCyHUH6CoWivCC98lLhoM YGJFODoIsGXp43taSA7gZkkZrOwmELv/lzXCYRvJNBh1Nxp/58Lp77V1RB22fFPfQ7T1co JN6gOxIJHqu2kx4F7Mm/9TG4rwtuOgraLyyCOeJ8+8RldR5F523xbNUpixuugxgLGmiaUU dgh6UbyRVqoe998wytHmM6sNK/QIEBsKec01jc0QvOot51LmIt+kc6cH0a+uWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1614266900; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KoeKEHRCfFn2HjM03wnlzP82dgGuR3cRs19TmplLk7s=; b=Npq/g/WCxoh9ns44DoxcNpKvMwFYY6Kw361o/tB18iRSIQOSH1wK0Bin7FjQrGMVjUctAB qxINAVl1jdBanZ6gIIqFITR027ng6JaTiOBEl+O1pP8vLh5xIYVJtx2EQ2MhNj6KdtWidO 8b1VEO38rw9eiG6xZOx85GGRBgIOPL8gf2Ue5kKPu9glEmnvomgwK5lwU5U/NN8XxAQlJv mrOYdt+smNeXNkoah3UBcRS7yJ8yPsi3E0K5pr2CLVsGfhxEP6dsKs8Uyjzl643+OqFIaM EbfPjnDrsJDZR90ohimyTBjYbkHoyqvrjkEeoGlUm/zU1RDRuJKk92l0NuoBbg== Archived-At: Subject: Re: [IPsec] Review of the draft-smyslov-ipsecme-rfc8229bis-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 15:28:28 -0000 Valery Smyslov writes: > > In section 7.3 there is text saying: > > > > Note that if this TCP connection is > > closed, the Responder MUST NOT include the Initiator's TCP port > > into the Cookie calculation (*), since the Cookie will be returned > > over a new TCP connection with a different port. > > > > As this is used in situation where UDP does not work reliably which > > usually means there are NATs involved, that might also mean that the > > Not necessary, it may be just firewall blocking UDP. > > > TCP source address might also change. So including TCP source address > > Even with NAT source address is less likely to change > (though I didn't say it cannot change). With TCP the source address changing is much more common than with UDP. With UDP the expectation is that source address needs to stay table, otherwise it does not work. With TCP it is assumed that each TCP connection is independent and peers should not care what the address is with two different connections. I.e. http or https does not care if two connections from the same browser have different source addresses, everything works just fine. > > to the cookie calculation might also cause problems. Also adding those > > to the cookie calculations does not help at all, as we do full round > > trip exchange to set up the TCP session anyways, so having them there > > doesn't really make any difference. This might cause attacker to be > > able to get one cookie, solve it once, and send responses over several > > TCP connections, but I think responder needs to be able to reject > > multiple solutions to same puzzle even when source address and port > > are not included in the cookie. > > I don't think the responder should keep track of solved puzzles. > At least I don't recall that RFC 8019 contains such a requirement. > > Anyway, the situation with IP address is less important, > since in most cases source IP will be the same even with NATs. > Note, that RFC 7296 recommends to include source IP in cookie > calculation, so if it NAT changes it each time it creates > new state (TCP or UDP), then IKEv2 over UDP won't work too. > I think it's a rare situation, so we may ignore it. NATs quite often try to keep the UDP source addresses stable, for example by mapping each inner IP address to block of UDP addresses on one IP address. For TCP connections there might not be such setup, it might just use any outer address it has for different connections. Especially if the solving of the puzzle takes some time, i.e., you make one TCP connection, get cookie, and puzzle, and then break TCP connection, solve puzzle and then reconnect. With normal RFC7296 cookies, the other end is assumed to be reconnect so quickly that UDP mapping is still in place. With puzzles this might not hold true anymore if solving puzzles takes more than tens of seconds. On the other hand if solving puzzle only takes few seconds, the UDP mapping is still there. -- kivinen@iki.fi From nobody Thu Feb 25 21:50:08 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0A93A0D99 for ; Thu, 25 Feb 2021 21:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 L1urK2IiBwyg for ; Thu, 25 Feb 2021 21:50:04 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id F39AA3A0D91 for ; Thu, 25 Feb 2021 21:50:03 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 61B3F6020B; Fri, 26 Feb 2021 05:50:01 +0000 (UTC) From: Christian Hopps Message-Id: <89CF9594-69A7-4E17-BCC8-08034367DBA7@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_FA410B9A-0760-4871-B170-A08A3F8E740F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 26 Feb 2021 00:50:00 -0500 In-Reply-To: <4350.1613497664@localhost> Cc: Christian Hopps , ipsec@ietf.org To: Michael Richardson References: <24590.9470.995873.674029@fireball.acr.fi> <17099.1613364359@localhost> <4350.1613497664@localhost> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 05:50:06 -0000 --Apple-Mail=_FA410B9A-0760-4871-B170-A08A3F8E740F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 16, 2021, at 12:47 PM, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Christian Hopps wrote: >>> * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. How do = use >>> PLMTUD? Will you tell us later in the document, or is that new = work? >>> (does not look like you tell us) >=20 >> I believed it was enough to just reference the mechanism (as we do = for >> PMTUD as well). This was added during the transport area review. >=20 > PMTUD relies on ICMP to say "too big" >=20 > PLMTUD relies on TCP to send a repeated ack (packet loss) to tell us = that we > guessed wrong. We now have RFC8899 too, but I don't know how to apply = it, > and I think that some advice is in order. +considered the more robust option. For PLMTUD, congestion control +payloads can be used as in-band probes (see [[Congestion Control +AGGFRAG_PAYLOAD Payload Format]] and [[RFC8899]]). Additionally a "P-bit" was added to the CC header so that loss of the = in-band probes can be disregarded as loss-events by the CC algorithm. > I think that we need a PL defined. >=20 >>>> The "BlockOffset" can point past the end of the "DataBlocks" data >>>> which indicates that the next data block occurs in a subsequent >>>> encapsulating packet. >>>=20 >>> I guess, it the actual value does not matter: it's not remembered. = As >>> long it is bigger than the packet, it's good. So 0xffff probably >>> works? >=20 >> Your right it just has to point past; however, it helps to have it >> point to the exact ending when implementing (the code is easy to >> implmeent and it caught multiple bugs for me as well). >=20 > So, then please tell us exactly what to do, and what the receiver is = supposed > to pay attention to. I didn't like "can" here, for instance. ... - new data block. ~BlockOffset~ can count past the end - of the ~DataBlocks~ data in which case all the ... + new data block. If the start of a new data block + occurs in a subsequent payload the ~BlockOffset~ + will point past the end of the ~DataBlocks~ data. + In this case all the ~DataBlocks~ data belongs to + the current data block being assembled. When the + ~BlockOffset~ extends into subsequent payloads it + continues to only count ~DataBlocks~ data (i.e., + it does not count subsequent packets + non-~DataBlocks~ data such as header octets). >=20 >>>> 2.2.2. No Implicit End Padding Required >>>=20 >>> -- I think you are telling me that the IPv4/IPv6 length field is = good >>> enough to find the end of the packet. If not, I didn't quite >>> understand. >=20 >> You understood. >=20 > okay, please hit me over the head harder here. Replaced this entire section (others also found it confusing) with = something much simpler. +*** End Padding + +Since a data block's type is identified in its first 4-bits, the only +time padding is required is when there is no data to encapsulate. For +this end padding a ~Pad Data Block~ is used. >=20 >>> Later in 6.1, I learn that AGGFRAG_PAYLOADS are squatting on 'IPv5' = I >>> hope this will be acceptable :-) I think it's a reasonable hack, and = I >>> don't see us wrapping around IP versions within a hundred years, >>> soooo... And pad blocks are "IPv0" >>>=20 >>>> This possible interleaving of all-pad payloads allows the sender to >>>> always be able to send a tunnel packet, regardless of the >>>> encapsulation computational requirements. >>>=20 >>> I think that you are telling me that a sender can have some pad >>> packets being created regularly (perhaps on a CPU dedicated to this) >>> and almost ready to send, and the pad packet is just replaced by = real >>> data if it happens to be ready. >=20 >> You understood perfectly. >=20 > I think that motivating this design choice with this implementation = advice is worthwhile. >=20 >>>> If the SA back to the sender is a non- AGGFRAG_PAYLOAD enabled SA >>>> then an AGGFRAG_PAYLOAD empty payload (i.e., header only) is used = to >>>> convey the information. >>>=20 >>> is this really worth supporting? >=20 >> It doesn't take much to continue to allow for unidirectional use at = the >> lowest layer (ESP/SA). It isn't relevant once you get to IKE where >> bidirectionality is required. >=20 > I think that maybe this is in the MAY. > It's isn't clear to me if I need to support that or not. Greatly simplified this as well: ** Exclusive SA Use This document does not specify mixed use of an AGGFRAG_PAYLOAD +enabled SA. A sender MUST only send AGGFRAG_PAYLOAD payloads over an +SA configured for AGGFRAG_PAYLOAD use. Thanks, Chris. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 --Apple-Mail=_FA410B9A-0760-4871-B170-A08A3F8E740F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmA4jAgACgkQLh2DDte4 MCVlgg//abgDvHkx8VmWiNyimtiqpWMrclrePyTqNuRRNo848OyMSMlh2Or6h86x +0gj02UVu1WyKuTVzp57lZStnAeuQV/H+r5Bi09odDpPCeCP/CFkQr1CHzgqSK7X 7KZprvp4nydvEOddkOLasEE4TnlciX2KKG36+k7Dn7PjelpZSg8v3z3vPwrZbNDZ Ax40GqHnwdw+CyqPl+eE7PWBlgeIZLqFto7nWxLeWYAaim9yskPOg3/FYRaT8M2k aWqk+xGOBMLF8clFxzHjTs2vMC2XEEtBgF2U8VvPjpjaq7Aftln70OzX+i66371J tLE6olA/KDNMXNaNwspBhB0nvYlUILgWpTI0wv8drsuMWhgJZRA5E76XOQafY7/m ytmWx98GxfZcZ57PGcYCAJm3e+CtwTkfb6p9KCLxS7ehYkeG0eoE7ZFQMevE3RdM ZxcCobk8DEnkwYwtvjr/EflAvmhAffcAgAIu4oSndirVi7AW0dUED7PDa7YxJ1b2 4xoy4VDlIPDbne8c0J/uG5MYeVvYDoX17LU+RN7GqR44I4KNqEl+bYEO+VeQP/Eh VagbX3cDQOlUBARnh98Rs+tb4qhzYCa6sHdwwnklUMnOVReUwLhD63ZyLeZFpSB0 phEwVwiPfH2iQarlEZzfBYNiR8w842nV1Xd/3WjA9kziEszfTJ4= =ZfxR -----END PGP SIGNATURE----- --Apple-Mail=_FA410B9A-0760-4871-B170-A08A3F8E740F-- From nobody Thu Feb 25 21:55:24 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC91D3A0DFB for ; Thu, 25 Feb 2021 21:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 AuxnRGB3z8TB for ; Thu, 25 Feb 2021 21:55:21 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB6F3A0DF7 for ; Thu, 25 Feb 2021 21:55:21 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8E8AB6020B; Fri, 26 Feb 2021 05:55:20 +0000 (UTC) From: Christian Hopps Message-Id: <72F4F523-6DC4-483E-BA16-84254B9609BC@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_63EA098E-DE09-40ED-9724-209B4523758E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 26 Feb 2021 00:55:19 -0500 In-Reply-To: Cc: Christian Hopps , ipsec@ietf.org To: Michael Richardson References: <24590.9470.995873.674029@fireball.acr.fi> <17099.1613364359@localhost> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 05:55:24 -0000 --Apple-Mail=_63EA098E-DE09-40ED-9724-209B4523758E Content-Type: multipart/alternative; boundary="Apple-Mail=_FC673EB7-04F0-4528-BF84-7459BF23DE56" --Apple-Mail=_FC673EB7-04F0-4528-BF84-7459BF23DE56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 16, 2021, at 6:11 AM, Christian Hopps = wrote: >=20 > Hi Michael, >=20 > Thanks for the review, q's, comments, and changes inline.. >=20 >> On Feb 14, 2021, at 11:45 PM, Michael Richardson = > wrote: >>=20 >> Signed PGP part >>=20 >> I have read draft-ietf-ipsecme-iptfs before it was adopted, and = during the >> adoption call, but have been busy. So I have read it again today = from >> beginning to end before tackling the long thread that has developed. >>=20 >> EXEC SUM: I think that the document is not ready. >> There are a lot of MAYs and future work thoughts on the sender. >> That's fine. But, in order for future senders to know what's = legal and >> what's not, what we really need is a clearly articulated Receiver = State Machine. >> I suggest that this is pretty important. >=20 > What did you have in mind? There are purposefully no restrictions for = the receiver to enforce. =46rom section 2: >=20 > The egress (receiving) side of the IP-TFS tunnel MUST allow for and > expect the ingress (sending) side of the IP-TFS tunnel to vary the > size and rate of sent encapsulating packets, unless constrained by > other policy. I've added a summary of "Summary of Receiver Processing" to the latest = revision. This gathers what needs to be paid attention to into a single = place. Thanks, Chris. --Apple-Mail=_FC673EB7-04F0-4528-BF84-7459BF23DE56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Feb 16, 2021, at 6:11 AM, Christian Hopps <chopps@chopps.org> = wrote:

Hi Michael,

Thanks for the review, = q's, comments, and changes inline..

On Feb 14, 2021, at = 11:45 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Signed PGP part

I have read = draft-ietf-ipsecme-iptfs before it was adopted, and during the
adoption call, but have been busy.  So I have read it = again today from
beginning to end before tackling the long = thread that has developed.

EXEC SUM: I = think that the document is not ready.
   There are a lot of MAYs and future work = thoughts on the sender.
   That's fine. =  But, in order for future senders to know what's legal and
   what's not, what we really need is a = clearly articulated Receiver State Machine.
   I suggest that this is pretty important.

What did you have in mind? There = are purposefully no restrictions for the receiver to enforce. =46rom = section 2:

 The egress (receiving) = side of the IP-TFS tunnel MUST allow for and
 expect = the ingress (sending) side of the IP-TFS tunnel to vary the
 size and rate of sent encapsulating packets, unless = constrained by
 other policy.

I've = added a summary of "Summary of Receiver Processing" to the latest = revision. This gathers what needs to be paid attention to into a single = place.

Thanks,
Chris.

= --Apple-Mail=_FC673EB7-04F0-4528-BF84-7459BF23DE56-- --Apple-Mail=_63EA098E-DE09-40ED-9724-209B4523758E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmA4jUcACgkQLh2DDte4 MCXVfhAAg1M7tjTtc0I+2X6kOuB8vbGKdIXjC02w7HBtrz3UW0+P1vp6THIXcSga kFwzGJqfcbN53k+JTzxsY/U5a/6jteaJnMT41KIHwuRNjhBrgDjLZORT1s6okYuX BH00vZ+KHUvQRiwdm1SymHx10e97tmMh2sCxpgl7bNM2E+5RbDA/pixOUhoWCCN8 bqEtEuGs1k9P0gfJH4RH/AYnTRoN3u8MxxTCHrNc+6GRfFare7p99uMYBs1tcHOV DqBGksAUjXixnrROrItQR3FXic5eBXK/do5t/psjB+6wnTSo6E7OPmauKpaR9p8L y9Q/nM5PYJPIkerjHaZMZaVt7nlR17VWjyi8Qiljlkt70lQ9S5+8fC79HbMSMpfd Q/PQMThELNTlVZIq6c1PQFc7+yN1pMFw+qsDIrz+TmLuT75MxJ90GVX7uK7xtLtZ F6Sae6HhXBWm8oCd4JsQmIdztIevr6AFMMKYyui0GpxfD92Rd07jY192zMgjVqup U2ZvU2OQ2Dk5RhOxkEIaisSJwlX6ktp6d5Oeu5jW30nEESsAsV8rbI8gtdrWH/zc yt+AsIpzGEDlC6oRGuFXm3ld4e/5gZjpZI7SKW1CuKKCu9WbVxi/4TUnf3T6z2nG gxHLNPi5vtTpOu/y9CP7BmJANw6g33i6p8vpma/SzJKonnWjsuw= =+Ec1 -----END PGP SIGNATURE----- --Apple-Mail=_63EA098E-DE09-40ED-9724-209B4523758E-- From nobody Thu Feb 25 22:15:50 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94383A0F3A for ; Thu, 25 Feb 2021 22:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 p6-9vLLc1tB2 for ; Thu, 25 Feb 2021 22:15:46 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA813A0F00 for ; Thu, 25 Feb 2021 22:15:46 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id u4so9342371ljh.6 for ; Thu, 25 Feb 2021 22:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=iZwIEL5GQ+qmyzk8rIm0bbzvpsuz3SFLjdnAmk4A4to=; b=T5Ez3zszDqNUF3A5BBwnFc8k3C7Oh4IJiUUYVyM4vvl8OP44VYhuowbOllEclxxWqZ 4PGd/+FX6kCcGi2vaRYIn/sWWonc9D6xQytHUoDLUyecqu/D0emU5qTX9pK0cTH2Z6mN L+CoHp/DHoEsutv+ulvuXyheAXWEgqOBD/e/CjMGgST4CQDczy4/Gso+GN11JKmMke4M vDM6yCoGVnKVzhHUdWE9kiM8Lq3ps/nus1oNjJxPaEC8MQBAPCaFD3Ze0/iYkQ6YCT7u lzGxHk/ZG7JeAI4UWV3dg6juCRnZp9ZVWcwCA4Hje8HpXewmvosj0UmEbVBc7x8+DhGl ekgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=iZwIEL5GQ+qmyzk8rIm0bbzvpsuz3SFLjdnAmk4A4to=; b=V8hq8uMoSUtc+LKRNS9yZNTAgqyG1L59ZN+z4GNwsU3g3dbDntBiiLz3znMvRxsHdm IFXIzCro31sl2RBedtyZiMIcscOzhjS84XAVWPzWCQDYOESn40h9np1dklVlYEMzi9Ic F/MfXiv1jkCcoGgZ5CSYCQilVXZcvjHCvnnd8fgX7C/5qJZPesOFP3zVsDlN2SksXRhX r/hN5f2R117yVY+b6GEj7sDEzfeKv/IY0eb2yUi4EjHPjpwIK2Rm4HVtq+ZKY22fIJii zKCE7o52HTInZ/DHwboOUooMIt3mfirhLzxu5XMbslZOgmEk8F1DfJvTg6U4o2EoyoDM 4Xaw== X-Gm-Message-State: AOAM532CyASNhTcZwf3BB+CZ4sxthZMUweFD2BYeN051BRm6vQ+UJUN9 rS+MloHnImjWW8HBcPSWc2aQXXHdfa4= X-Google-Smtp-Source: ABdhPJwBPkzIhurtfe4W8Vn97ZpzwHtXY7KJIJ2px0iCF6jn96HI8GXxE3/7DfbhSVsLTimo6APfFQ== X-Received: by 2002:a2e:7f11:: with SMTP id a17mr779993ljd.468.1614320144159; Thu, 25 Feb 2021 22:15:44 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id i15sm1304910lfj.7.2021.02.25.22.15.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Feb 2021 22:15:43 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: References: <24630.24987.212447.935241@fireball.acr.fi> <0f9601d70b82$c74c7650$55e562f0$@gmail.com> <24631.49682.32667.706838@fireball.acr.fi> In-Reply-To: <24631.49682.32667.706838@fireball.acr.fi> Date: Fri, 26 Feb 2021 09:15:47 +0300 Message-ID: <109001d70c06$d3254090$796fc1b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE5meq5E2X13ex8pBvHEjICmfXlfwJ+rqGoAcO2mcergsXscA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Review of the draft-smyslov-ipsecme-rfc8229bis-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 06:15:49 -0000 Hi Tero, so, what is the outcome? Do you think we should add a recommendation not to include source IP address in cookie calculation when TCP is in use? Regards, Valery. > Valery Smyslov writes: > > > In section 7.3 there is text saying: > > > > > > Note that if this TCP connection is > > > closed, the Responder MUST NOT include the Initiator's TCP port > > > into the Cookie calculation (*), since the Cookie will be returned > > > over a new TCP connection with a different port. > > > > > > As this is used in situation where UDP does not work reliably which > > > usually means there are NATs involved, that might also mean that the > > > > Not necessary, it may be just firewall blocking UDP. > > > > > TCP source address might also change. So including TCP source address > > > > Even with NAT source address is less likely to change > > (though I didn't say it cannot change). > > With TCP the source address changing is much more common than with > UDP. With UDP the expectation is that source address needs to stay > table, otherwise it does not work. With TCP it is assumed that each > TCP connection is independent and peers should not care what the > address is with two different connections. I.e. http or https does not > care if two connections from the same browser have different source > addresses, everything works just fine. > > > > to the cookie calculation might also cause problems. Also adding those > > > to the cookie calculations does not help at all, as we do full round > > > trip exchange to set up the TCP session anyways, so having them there > > > doesn't really make any difference. This might cause attacker to be > > > able to get one cookie, solve it once, and send responses over several > > > TCP connections, but I think responder needs to be able to reject > > > multiple solutions to same puzzle even when source address and port > > > are not included in the cookie. > > > > I don't think the responder should keep track of solved puzzles. > > At least I don't recall that RFC 8019 contains such a requirement. > > > > Anyway, the situation with IP address is less important, > > since in most cases source IP will be the same even with NATs. > > Note, that RFC 7296 recommends to include source IP in cookie > > calculation, so if it NAT changes it each time it creates > > new state (TCP or UDP), then IKEv2 over UDP won't work too. > > I think it's a rare situation, so we may ignore it. > > NATs quite often try to keep the UDP source addresses stable, for > example by mapping each inner IP address to block of UDP addresses on > one IP address. For TCP connections there might not be such setup, it > might just use any outer address it has for different connections. > Especially if the solving of the puzzle takes some time, i.e., you > make one TCP connection, get cookie, and puzzle, and then break TCP > connection, solve puzzle and then reconnect. > > With normal RFC7296 cookies, the other end is assumed to be reconnect > so quickly that UDP mapping is still in place. With puzzles this might > not hold true anymore if solving puzzles takes more than tens of > seconds. On the other hand if solving puzzle only takes few seconds, > the UDP mapping is still there. > -- > kivinen@iki.fi From nobody Fri Feb 26 09:21:36 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCC23A1353 for ; Fri, 26 Feb 2021 09:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2gKmdPzPMAAv for ; Fri, 26 Feb 2021 09:21:26 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FDF3A130B for ; Fri, 26 Feb 2021 09:21:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4087D389C8; Fri, 26 Feb 2021 12:25:43 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IMyAYp6gMoSv; Fri, 26 Feb 2021 12:25:42 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 29196389C5; Fri, 26 Feb 2021 12:25:42 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1C49852; Fri, 26 Feb 2021 12:21:23 -0500 (EST) From: Michael Richardson To: Christian Hopps , ipsec@ietf.org In-Reply-To: <89CF9594-69A7-4E17-BCC8-08034367DBA7@chopps.org> References: <24590.9470.995873.674029@fireball.acr.fi> <17099.1613364359@localhost> <4350.1613497664@localhost> <89CF9594-69A7-4E17-BCC8-08034367DBA7@chopps.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 17:21:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian Hopps wrote: >> Christian Hopps wrote: >>>> * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. How do >>>> use PLMTUD? Will you tell us later in the document, or is that new >>>> work? (does not look like you tell us) >> >>> I believed it was enough to just reference the mechanism (as we do >>> for PMTUD as well). This was added during the transport area review. >> >> PMTUD relies on ICMP to say "too big" >> >> PLMTUD relies on TCP to send a repeated ack (packet loss) to tell us >> that we guessed wrong. We now have RFC8899 too, but I don't know how >> to apply it, and I think that some advice is in order. > +considered the more robust option. For PLMTUD, congestion control > +payloads can be used as in-band probes (see [[Congestion Control > +AGGFRAG_PAYLOAD Payload Format]] and [[RFC8899]]). > Additionally a "P-bit" was added to the CC header so that loss of the > in-band probes can be disregarded as loss-events by the CC algorithm. I still don't really see enough explanation of: 1) what do my probe packets look like? Can I, for instance, send regular traffic, padded to the extra size? That's an optimistic view of things, but maybe appropriate. How do I get positive response that it was accepted? 2) How do I learn about traffic that was dropped? I'm on about this, because I think that PMTU issues are among the biggest problem for IPsec. If we can auto-tune the tunnel size, that's really a killer use. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmA5LhIACgkQgItw+93Q 3WUQwggAudvqv5hveCAzFW67b+X435Swpm23eBs+flc5IgVf2NdmfvvnV2xEUwSH Ve81uqzs1cujpEvATayzRzOBwP2i0XjSKKhO5nVbG4T6hUSdW4wCHG+U0Voo8njS qcHoTw+/jv3kWEgW2IK7sLQdh/zZsz59IQmYV/i+najLT8eqyxEJg3cKt4L/EiRi gHamkr70cpSF2iTIX7mV5/oXPe2SdOLm969ZITay4w8GI4mdzthS7FeckmiZnEET BnBB3w8YwybdeNJn7i0geU/OU2pJBA7zJFEscJdAkj6yudW4IA4MevG5+9I7A4Es JcYnUtx2QShSUXI7J294UFJcHFrqQg== =ucYG -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 27 11:57:21 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EAB3A1335 for ; Sat, 27 Feb 2021 11:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 M4hd78sjMmBC for ; Sat, 27 Feb 2021 11:57:17 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 79BA93A1330 for ; Sat, 27 Feb 2021 11:57:17 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id BDE4D601DC; Sat, 27 Feb 2021 19:57:16 +0000 (UTC) From: Christian Hopps Message-Id: <94F6938A-9834-4EA2-A927-3E068BCD366E@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_EAF2821C-8DE5-4956-8765-5EFA48532BF7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Sat, 27 Feb 2021 14:57:15 -0500 In-Reply-To: <30058.1614360083@localhost> Cc: Christian Hopps , ipsec@ietf.org To: Michael Richardson References: <24590.9470.995873.674029@fireball.acr.fi> <17099.1613364359@localhost> <4350.1613497664@localhost> <89CF9594-69A7-4E17-BCC8-08034367DBA7@chopps.org> <30058.1614360083@localhost> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2021 19:57:20 -0000 --Apple-Mail=_EAF2821C-8DE5-4956-8765-5EFA48532BF7 Content-Type: multipart/alternative; boundary="Apple-Mail=_55595724-AA6F-452B-B5F9-BFEB8F039E61" --Apple-Mail=_55595724-AA6F-452B-B5F9-BFEB8F039E61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 26, 2021, at 12:21 PM, Michael Richardson = wrote: >=20 >=20 > Christian Hopps wrote: >>> Christian Hopps wrote: >>>>> * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. How do >>>>> use PLMTUD? Will you tell us later in the document, or is that = new >>>>> work? (does not look like you tell us) >>>=20 >>>> I believed it was enough to just reference the mechanism (as we do >>>> for PMTUD as well). This was added during the transport area = review. >>>=20 >>> PMTUD relies on ICMP to say "too big" >>>=20 >>> PLMTUD relies on TCP to send a repeated ack (packet loss) to tell us >>> that we guessed wrong. We now have RFC8899 too, but I don't know = how >>> to apply it, and I think that some advice is in order. >=20 >> +considered the more robust option. For PLMTUD, congestion control >> +payloads can be used as in-band probes (see [[Congestion Control >> +AGGFRAG_PAYLOAD Payload Format]] and [[RFC8899]]). >=20 >> Additionally a "P-bit" was added to the CC header so that loss of the >> in-band probes can be disregarded as loss-events by the CC algorithm. >=20 > I still don't really see enough explanation of: >=20 > 1) what do my probe packets look like? > Can I, for instance, send regular traffic, padded to the extra = size? > That's an optimistic view of things, but maybe appropriate. > How do I get positive response that it was accepted? >=20 > 2) How do I learn about traffic that was dropped? This is what https://tools.ietf.org/html/rfc8899 = documents. All that this document = should do is provide the on the wire mechanism to send a probe packet = and get a reply that it was received, as well as provide for not = considering probe loss as loss events for CC (the p-bit). The CC header = does this (the sender timestamp is echo'd back for RTT estimates). The = implementation of RFC8899 can choose to send user data or not (RFC8899 = recommends that one should avoid doing this if possible). Thanks, Chris. > I'm on about this, because I think that PMTU issues are among the = biggest > problem for IPsec. > If we can auto-tune the tunnel size, that's really a killer use. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 >=20 >=20 --Apple-Mail=_55595724-AA6F-452B-B5F9-BFEB8F039E61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 26, 2021, at 12:21 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Christian Hopps = <chopps@chopps.org> wrote:
Christian = Hopps <chopps@chopps.org> wrote:
* I'm glad = you recommend PLMTUD, I suggest PMTUD is dead.  How do
use PLMTUD?  Will you tell us later in the document, or = is that new
work?  (does not look like you tell = us)

I believed it was enough to just reference the = mechanism (as we do
for PMTUD as well). This was added = during the transport area review.

PMTUD relies on ICMP to say "too big"

PLMTUD relies on TCP to send a repeated ack (packet loss) to = tell us
that we guessed wrong.  We now have RFC8899 = too, but I don't know how
to apply it, and I think that = some advice is in order.

+considered the more = robust option. For PLMTUD, congestion control
+payloads = can be used as in-band probes (see [[Congestion Control
+AGGFRAG_PAYLOAD Payload Format]] and [[RFC8899]]).

Additionally a "P-bit" was added to the CC header so that = loss of the
in-band probes can be disregarded as = loss-events by the CC algorithm.

I still don't really see enough explanation of:

 1) what do my probe packets look = like?
    Can I, for instance, send = regular traffic, padded to the extra size?
=     That's an optimistic view of things, but maybe = appropriate.
    How do I get = positive response that it was accepted?

=  2) How do I learn about traffic that was dropped?

This is what https://tools.ietf.org/html/rfc8899 documents. All = that this document should do is provide the on the wire mechanism to = send a probe packet and get a reply that it was received, as well as = provide for not considering probe loss as loss events for CC (the = p-bit). The CC header does this (the sender timestamp is echo'd back for = RTT estimates). The implementation of RFC8899 can choose to send user = data or not (RFC8899 recommends that one should avoid doing this if = possible).

Thanks,
Chris.

I'm on about this, = because I think that PMTU issues are among the biggest
problem for IPsec.
If we can auto-tune the = tunnel size, that's really a killer use.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T= consulting )
=           Sandelman = Software Works Inc, Ottawa and Worldwide





= --Apple-Mail=_55595724-AA6F-452B-B5F9-BFEB8F039E61-- --Apple-Mail=_EAF2821C-8DE5-4956-8765-5EFA48532BF7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmA6pBsACgkQLh2DDte4 MCU/lQ//cfwEYgAcVaoZWvLjUIOFjvlfk/9AJ5VDC52yij27zx4UwaLVZxNI5QVY Z3h53AW7fsj7beSOxWT5Xd89huUJRh7IPeZObE38TQqvH5Kx4yulFA7/BKHj/AS3 oKCZWe151GTn3gTsi86j9VXwyADp+f+jxzrCHAcbc7F5z0ak//qSgTeU6E3Dx6P5 eRWWbS5cK2JT/2o/LRHfwovUndna7ATMme4yza6lztYSRSAEaB1Pq47HVIvR6z92 GroubWRxF+t/tgE+PsxaXvFcgfaE3ic5nsfw9NRLg57298xuYN2onWXJTlHymlX/ IO1qhLt1ZBoQoxDiy9f/Q0STwH01Z6g9H2hTm9t5MJURDibvb7vvVorHZBy7ZhL7 aWfCgT0cQqJ6NnBIibS3sQVmwTO21f77GbrKJU6JgrIKVmjiSi/2yzVPW0O+53wX QYykM57EIteDdjTX5IryxWjubzjP0HziT7UmcwhqqTkjOpsyGAO79YWvhGDDqEFp OVXjeEGC+518svGDB+adzid4WoTjwAUrKQ69y7gaEgthe/STbVkTLn5Do4X1pRel mUoYzjWO8cieULXsY6noae1ABC0espA3knMhchYBdkD2VZEBC892SJSGvl3U6xb3 ln9AN9ne/N+03FJoiwZr0TPjfkdw+64xW00Zjj33fWJ4Ost52JM= =EB3Z -----END PGP SIGNATURE----- --Apple-Mail=_EAF2821C-8DE5-4956-8765-5EFA48532BF7-- From nobody Sat Feb 27 12:15:09 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07943A1371 for ; Sat, 27 Feb 2021 12:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zWY7LOPNBYaW for ; Sat, 27 Feb 2021 12:15:05 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0AE63A141B for ; Sat, 27 Feb 2021 12:14:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C00DD389C3; Sat, 27 Feb 2021 15:19:10 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iHqOCvwmWl7e; Sat, 27 Feb 2021 15:19:10 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 429FC389B5; Sat, 27 Feb 2021 15:19:10 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EF83063E; Sat, 27 Feb 2021 15:14:46 -0500 (EST) From: Michael Richardson To: Christian Hopps , ipsec@ietf.org In-Reply-To: <94F6938A-9834-4EA2-A927-3E068BCD366E@chopps.org> References: <24590.9470.995873.674029@fireball.acr.fi> <17099.1613364359@localhost> <4350.1613497664@localhost> <89CF9594-69A7-4E17-BCC8-08034367DBA7@chopps.org> <30058.1614360083@localhost> <94F6938A-9834-4EA2-A927-3E068BCD366E@chopps.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2021 20:15:08 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian Hopps wrote: >> I still don't really see enough explanation of: >> >> 1) what do my probe packets look like? Can I, for instance, send >> regular traffic, padded to the extra size? That's an optimistic view >> of things, but maybe appropriate. How do I get positive response th= at >> it was accepted? >> >> 2) How do I learn about traffic that was dropped? > This is what https://tools.ietf.org/html/rfc8899 > documents. All that this docume= nt > should do is provide the on the wire mechanism to send a probe packet > and get a reply that it was received, as well as provide for not > considering probe loss as loss events for CC (the p-bit). The CC head= er > does this (the sender timestamp is echo'd back for RTT estimates). The > implementation of RFC8899 can choose to send user data or not (RFC8899 > recommends that one should avoid doing this if possible). I'll read again, but I am still perceiving a gap between RFC8899 and TFS. Perhaps it is obvious to you, having designed and implemented it all over three or four years. In reading it, I didn't understand. As I understand it then, I have to send a AGGGRAG_PAYLOAD packet of the new size I want to test, I include a sender timestamp in TVal, and I look for that echoed back in the TEcho to confirm receipt. That's my PL? I would know that it failed if I get a sender timestamp X (getting X+1), that the oversize packet was lost. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmA6qDYACgkQgItw+93Q 3WU6ewf/ZSt05DhSI1TF4rsYF+irakdca5Z1kQyU+h9VPLD7ez58qdgcG0JugRNv OhshAgt5HIgE5is3GX4BI5n65vlPLiW3KHFBbBr559+muRZRJyoL5WVfDtZbcLWG KMLuOm3eEnzyNcig4iW/gsm9B40uYoTxbBuU0doF+/oCkHcs+fL5Qf36SuNiucGO F81lvi/JQRirD7s7EkiLZymvZEK1VX/d+nnzMZSNTCB2JGt4nGlzLnDTyZ1RoTdG KTpsYx9pymq1PJ9eoBsI3tBEXctftMpicLKYc28cRpO6eWib3A287wLpygfZmulr do3UacqKX+ljJlhUbf55VQrw8wzSBw== =2X9L -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 28 10:26:30 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FB23A1A5B for ; Sun, 28 Feb 2021 10:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 K-bLnDIrcjCS for ; Sun, 28 Feb 2021 10:26:26 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 B8AFF3A1277 for ; Sun, 28 Feb 2021 10:26:26 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DpX0K3VtwzCZC; Sun, 28 Feb 2021 19:26:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614536785; bh=De6w445NhU/i3u61kr0zSDbTguobU7K8EZFVT5Qpky0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=QeY/G61XCeZtw/qn+uDQ2GqWOzQGS6JMJc74A/jp51apFShFnH60w5pgVyA//B3wl MPa/gj1zWZANckvKwg/fgHUosLJy28Y8SqFkPI60aF7AFlIRnENsG2IiAANF5SVh7N B3O1R1gfSICAVYAB3x6R4jXncJgkByOm/9ntlHlA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id jbK8Nk6K8rvA; Sun, 28 Feb 2021 19:26:24 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 28 Feb 2021 19:26:24 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1F3C46029B62; Sun, 28 Feb 2021 13:26:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 172D666B1E; Sun, 28 Feb 2021 13:26:23 -0500 (EST) Date: Sun, 28 Feb 2021 13:26:23 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <24630.25622.894368.540704@fireball.acr.fi> Message-ID: <7c8d3d-2975-5544-ae77-3317d3ea8fa5@nohats.ca> References: <24630.25622.894368.540704@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] WG adoption call for draft-smyslov-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2021 18:26:28 -0000 On Wed, 24 Feb 2021, Tero Kivinen wrote: > This is the start of 1.5 week WG adoption call for this document, > ending 2021-02-07 (just before our IPsecME session in IETF 110). > Please send your reply about whether you support adopting this > document as WG document or not. I am in favour of adoption. We have been working on this support for Linux XFRM with libreswan IKE. We definately found some issues that we needed to work around or fix. We still have to see about whether those lead to new or different text in the bis document. So while I hope we don't go into WGLC too soon, an updated document is the best solution, and I will review and see about getting some of our own implementation issues written down into the document. Paul From nobody Sun Feb 28 12:35:21 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00963A1C02 for ; Sun, 28 Feb 2021 12:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 5CRz84bXwgry for ; Sun, 28 Feb 2021 12:35:17 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 C42C53A1C01 for ; Sun, 28 Feb 2021 12:35:17 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DpZry48VJzCcj for ; Sun, 28 Feb 2021 21:35:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614544514; bh=gyMX57+O9cuhI+fUvTXNcBma/fLH99Xx74VYd35XPrA=; h=Date:From:To:Subject; b=OnWxmGjzWMtHY2a/2hKBc7TP3FocUBgb3vF2d5lRfyTEJvDKuViXP+L+Zvw5awoOu v+qf00A+P0Ss4EwUanCDOY83drLmOziL3x1NSu5a2cDWpvGZ2pRr5dzCLsd808wSu/ l4lQ6wvJc5TLDysiruA5bpJJNcI+Pj7TrmN5OYPc= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 4Gi5Oy2uKmuE for ; Sun, 28 Feb 2021 21:35:13 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sun, 28 Feb 2021 21:35:13 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D62446029B62; Sun, 28 Feb 2021 15:35:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D4E9466B1E for ; Sun, 28 Feb 2021 15:35:11 -0500 (EST) Date: Sun, 28 Feb 2021 15:35:11 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: <6326d782-3fda-21dc-72a0-60147982a556@nohats.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============0424353351188621189==" Archived-At: Subject: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2021 20:35:20 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============0424353351188621189== Content-Type: text/plain; CHARSET=utf-8; format=flowed Content-Transfer-Encoding: 8BIT So now that OCB is finally free, do we want to implement it? :) I'm honestly not sure if the improvements of AES-GCM are worth it. I haven't heard of vulnerabilities in IKE/ESP wrt. IVs or counters. Paul ---------- Forwarded message ---------- Date: Sat, 27 Feb 2021 14:37:30 From: "Salz, Rich via cryptography" To: "cryptography@metzdowd.com" Subject: [Cryptography] Direct public confirmation from Dr. Rogaway https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ :   I can confirm that I have abandoned all OCB patents and placed into the public domain all OCB-related IP of mine. While I have been telling people this for quite some time, I don't think I ever made a proper announcement to the CFRG or on the OCB webpage. Consider that done.   I hope people will use the scheme to do positive things.   phil --===============0424353351188621189== Content-Type: text/plain; CHARSET=us-ascii Content-ID: <5869755e-ee84-d79c-4228-73b297ab45fa@nohats.ca> Content-Description: Content-Disposition: INLINE _______________________________________________ The cryptography mailing list cryptography@metzdowd.com https://www.metzdowd.com/mailman/listinfo/cryptography --===============0424353351188621189==-- From nobody Sun Feb 28 13:47:11 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B77B3A1CF7 for ; Sun, 28 Feb 2021 13:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OYagZmUfgGR2 for ; Sun, 28 Feb 2021 13:47:07 -0800 (PST) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 6217F3A1CF5 for ; Sun, 28 Feb 2021 13:47:07 -0800 (PST) Received: by mail-ej1-x62e.google.com with SMTP id lr13so24619838ejb.8 for ; Sun, 28 Feb 2021 13:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=a7h9i/AnXNCzOJg8sOzf045QYfnpMw9ilhkwx9MqVmg=; b=YcFroOub0lnti4Zi3hPhLm5J+sRPPiX1/UbxEiqhSQqcRqiQhOMMZu0z1DJ2YGNfnF AolrXHWRbCfj+tlIeOzKlqNQVs6mD4ureFjdKYVLtv4hOGL4Ltb+VyU9SFGHUj7pAjax zAHbZe/rkR9lHVUUeNl9Cs5+IrWqysUu9oc8uhiYL6VwFbeOVP8Qnh3HltdIq8AaZvgy KVQMq+qR9xNCKzFHd2Y1KbSeLdHKrNKqJpgs4Tmzztdb7C96deX9bL3UtlyFlnr1eIfb SxTvmuz62oM6cU38lyn9facpICy/6lrzXwlAx+6QA3tMdfVIuu61wOH/qQSdROzEHLNo 6LaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=a7h9i/AnXNCzOJg8sOzf045QYfnpMw9ilhkwx9MqVmg=; b=CK4rX7Obv7oclzMhidz+9sbiOz2340Z0m0iO2S9imoBlO0400rbEnr3qMbRywtqVi+ hMgYjX8d3LLUGYkTvKcdnQFkl03gWVwW1uME0ifijUDyY+FEAiFTw2U23I2v8+bVjIi6 IQbzMIhS0bkljv9xTS9GcPyT3Np/v/U1bnEpOMOMM4GLu/4ZUZ3f1AEkstSs4ZMJQ8XK MYqqvwxcg4lBYZbbB0iq3wJwB92z6VsC1qY4rMLsRDR6rEOV59AAGRCzDX35FdEmw0p8 QbPwuWbJOx88chmD0oYNMelaSiEvo1+a+Yars0wmhtJxeenbNDCl2YwxXiH9vaiTFZEb ATCw== X-Gm-Message-State: AOAM530bwrcKZG71bVI/TtrKffDy6UxhDUIXgcu7YE/p+xHly1mCzeUh UzOJ5SwtdxaUKoELmEpcgMc= X-Google-Smtp-Source: ABdhPJycOilkQ1CSQt2kw0ojkwKdXc6xC6wy2V+jmLpfw2yluATAvrykCC+DzIImPLwc7hBAcD9lYQ== X-Received: by 2002:a17:906:398c:: with SMTP id h12mr13370538eje.469.1614548824640; Sun, 28 Feb 2021 13:47:04 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id n2sm11599841ejl.1.2021.02.28.13.47.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Feb 2021 13:47:04 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D8EAF24D-BC16-4AA5-95B3-A19A11D4C330" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Sun, 28 Feb 2021 23:47:02 +0200 In-Reply-To: <6326d782-3fda-21dc-72a0-60147982a556@nohats.ca> Cc: "ipsec@ietf.org WG" To: Paul Wouters References: <6326d782-3fda-21dc-72a0-60147982a556@nohats.ca> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2021 21:47:09 -0000 --Apple-Mail=_D8EAF24D-BC16-4AA5-95B3-A19A11D4C330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 IIRC the license has allowed OCB to be used for TLS for several years. = They haven=E2=80=99t taken it up. There are no AES-OCB ciphersuites = inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-p= arameters-4 = So I=E2=80=99m wondering right with you: It has a theoretical advantage = in security and a measurable advantage in speed in software. Neither = were compelling enough for anyone to bother adding it in TLS = ciphersuites. Why should our conclusion be any different? Yoav > On 28 Feb 2021, at 22:35, Paul Wouters wrote: >=20 >=20 > So now that OCB is finally free, do we want to implement it? :) >=20 > I'm honestly not sure if the improvements of AES-GCM are worth it. > I haven't heard of vulnerabilities in IKE/ESP wrt. IVs or counters. >=20 > Paul >=20 > ---------- Forwarded message ---------- > Date: Sat, 27 Feb 2021 14:37:30 > From: "Salz, Rich via cryptography" > To: "cryptography@metzdowd.com" > Subject: [Cryptography] Direct public confirmation from Dr. Rogaway >=20 >=20 > = https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ = : >=20 > =20 >=20 > I can confirm that I have abandoned all OCB patents >=20 > and placed into the public domain all OCB-related IP of mine. >=20 > While I have been telling people this for quite some time, I don't >=20 > think I ever made a proper announcement to the CFRG or on the >=20 > OCB webpage. Consider that done. >=20 > =20 >=20 > I hope people will use the scheme to do positive things. >=20 > =20 >=20 > phil >=20 > _______________________________________________ > The cryptography mailing list > cryptography@metzdowd.com > https://www.metzdowd.com/mailman/listinfo/cryptography > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_D8EAF24D-BC16-4AA5-95B3-A19A11D4C330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 IIRC = the license has allowed OCB to be used for TLS for several years. They = haven=E2=80=99t taken it up. There are no AES-OCB ciphersuites inhttps://www.iana.org/assignments/tls-parameters/tls-parameter= s.xml#tls-parameters-4

So I=E2=80=99m wondering right with you: It has a theoretical = advantage in security and a measurable advantage in speed in software. =  Neither were compelling enough for anyone to bother adding it in = TLS ciphersuites.  Why should our conclusion be any = different?

Yoav


On 28 = Feb 2021, at 22:35, Paul Wouters <paul@nohats.ca> wrote:


So now that OCB is finally free, do we want to implement it? = :)

I'm honestly not sure if the = improvements of AES-GCM are worth it.
I haven't heard of = vulnerabilities in IKE/ESP wrt. IVs or counters.

Paul

---------- Forwarded = message ----------
Date: Sat, 27 Feb 2021 14:37:30
From: "Salz, Rich via cryptography" <cryptography@metzdowd.com>
To: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Subject: = [Cryptography] Direct public confirmation from Dr. Rogaway


https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-= vrj05Vg/ :

 

I can confirm that I have abandoned all OCB patents

and placed into the public domain all = OCB-related IP of mine.

While I have been = telling people this for quite some time, I don't

think I ever made a proper announcement to the CFRG or on = the

OCB webpage. Consider that done.

 

I hope = people will use the scheme to do positive things.

 

phil

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
https://www.metzdowd.com/mailman/listinfo/cryptography
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_D8EAF24D-BC16-4AA5-95B3-A19A11D4C330--