From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "dtn@ietf.org" <dtn@ietf.org>, "draft-ietf-dtn-tcpclv4@ietf.org"
 <draft-ietf-dtn-tcpclv4@ietf.org>
Thread-Topic: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
Thread-Index: AdVG21EHJDIckyVtR8mDiK6Q+2uHtgmtVlwA
Date: Tue, 17 Sep 2019 19:47:00 +0000
Message-ID: <2de394b5914ffd486b92f3119eda28a44f153c35.camel@ericsson.com>
References: <HE1PR0701MB2522C8240E7E28BFC11B80CD95DE0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB2522C8240E7E28BFC11B80CD95DE0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: ericsson.com does not designate
 permitted sender hosts)
Content-Type: multipart/signed; micalg="sha-256";
 protocol="application/x-pkcs7-signature";
 boundary="=-oOFK5EksuQW0TISjLEWJ"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7621f8e4-a4e9-45ac-ff0a-08d73ba7ce57
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 19:47:00.2545 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1KMVgC/vE8TYypAArMtMTpZL/DElgaB/oSIpgIRRLG7CjBk7enJvw1xwhpwRyQfpllFImuGn88XpQJJ8nGoQ0sJozwGLXqhswnqxDohF0r4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6138
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/tlmMJemVVjSA2kKw1uuOYs7c_ok>
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
 <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>,
 <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>,
 <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2019 19:47:09 -0000

--=-oOFK5EksuQW0TISjLEWJ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Sorry about the delay in reviewing your update based on my AD review
comments. Below I have commented on my view how the issue have been
dealt with.=20

We appear to have a small number of things that are still not fully
resolved in my view so please chech these and comment.=20

I am also sorry that my mail client apparently eat the numbering.=20


On Thu, 2019-08-01 at 13:31 +0000, Magnus Westerlund wrote:
> Hi,
> =20
> I have now performed my AD review of draft-ietf-dtn-tcpclv4-12. I
> think most are minor comments, however the TLS and security related
> ones may be more problematic to resolve. I will now be on vacation so
> you know you will not receive any quick replies from me before the
> end of the month.
> =20
> Section 1: What are the applicability of TCPCLv4 to BPv6? I wonder as
> RFC5050 is referenced.=20

Thanks for the new scope section making things much clearer. My
interpretation now is that this document only is for BPv7.=20



>=20
> Section 1.1: Session State Changed. Some editorial issues. Missing
> =E2=80=9C:=E2=80=9D initially. Then double =E2=80=9C..=E2=80=9D on Termin=
ated.=20

Fixed.=20

>=20
> Section 1.1:=20
>    Session Idle Changed  The TCPCL supports indication when the
> live/idle sub-state changes.  This occurs only when the top-level
> session state is Established.  Because TCPCL transmits serially over
> a TCP connection, it suffers from "head of queue blocking" this
> indication provides information about when a session is available for
> immediate transfer start.
>=20
> So in which direction are this change indicated/reported, both or
> only in one of them, or any as implied by Section 2.1=E2=80=99s definitio=
n of
> Live Session?=20

Fixed

>=20
> Section 1.1: Transmission Intermediate Progress: Segment is not
> defined prior to this. Maybe a forward pointe? Or should maybe the
> whole subsection (1.1) be moved to after definitions?=20

Fixed

>=20
> Section 2: Is there a point to use the RFC 8174 language that makes
> only capital words have special meaning?=20

Addressed

>=20
> Section 3.1: =E2=80=9COne of these parameters is a singleton endpoint
> identifier for each node (not the singleton Endpoint Identifier (EID)
> of any application running on the node) to denote the bundle-layer
> identity of each DTN node.=E2=80=9D
>=20
> The above quote does imply something that at least BPBis isn=E2=80=99t ma=
king
> clear that a particular application agent would have its own EID. It
> is not clear that there are a one-to-one relationship between bundle
> nodes and application agents. Can you please clarify what the
> relationship is and lets figure out if that needs to be clarified
> back to BPbis.=20

Ok, so the new text addresses this.=20

>=20
> Section 3.1: =E2=80=9CBundle interleaving can be accomplished by
> fragmentation at the BP layer or by establishing multiple TCPCL
> sessions between the same peers.=E2=80=9D
>=20
> Are there clear rules established for how many TCPCL sessions in
> parallel that may be established? By the end of my reading this is
> unanswered.=20

Answered, no built in limiation. Resource limited.=20

>=20
> Section 3.1: XFER_REFUSE does that indicate that the bundle has
> already been received. How else does one separate other reasons for
> refusing a bundle versus that one have received it prior?

I don't think this needs more texf, section 5.2.4 is clear on that the
reason code will make resolve the reason.=20

>=20
> Section 3:1:    Once a session is established established, TCPCL is a
> symmetric protocol between the peers.=20
> Double established
>=20

Fixed.

> Figure 4: =E2=80=9CClose message=E2=80=9D is this TCP level message, if t=
hat is the
> case can that be clarified by prefix with TCP?

Fixed.=20

>=20
> Section 3.2:=20
>    Notes on Established Session states:=20
>       Session "Live" means transmitting or reeiving over a transfer
>       stream.
>=20
>       Session "Idle" means no transmission/reception over a transfer
>       stream.
>=20
>      Session "Closing" means no new transfers will be allowed.
>=20
> Note that =E2=80=9CClosing=E2=80=9D is not used in Figure 4, it is called=
 ending.
> Note spelling error on =E2=80=9Clive=E2=80=9D receving.

Fixed

>=20
> Section 3.2: Figure 5 and 6 uses PCH without explanation. Figure 5
> could probably also benefit by expanding CH as Contact Header.

Fixed.=20

>=20
> Figure 8 and 10: Uses [SESSTERM] is this the same as using the
> SESS_TERM message, or some other procedure. Please clarify.=20

Okay looking at this again it is clear that [SESSTERM] is used for any
type of session termination. However, as SESSTERM appears to only be
used in the figures in that meaning, and being defined in Figure 13,
despite existing in 8, 9 and 10 also. Also considering that Figure 13
and 14 are signalled termination and the other are failure cases I
think a sentence or two should be spent to explain its meaning prior to
its usage.=20


>=20
> Section 3.3: =E2=80=9C   Many other policies can be established in a TCPC=
L
> network between these two extremes.=E2=80=9D
>=20
> The list above includes three items, so the two extremes needs to be
> enumerated.=20

Addressed.=20

>=20
> Section 4.1: Can TCPCLv3 and TCPCLv4 coexist on Port 4556? Based on
> 9.1 the answer is yes, please clarify here.

Fixed

>=20
> Section 4.1: =E2=80=9CTherefore, the entity MUST retry the connection set=
up
> no earlier than some delay time from the last attempt, and it SHOULD
> use a (binary) exponential backoff mechanism to increase this delay
> in case of repeated failures.=E2=80=9D
>=20
> Any recommended upper limit for the backoff?


Addressed

>=20
> Section 4.2:    Version:  A one-octet field value containing the
> value 4 (current version of the protocol).=20
>=20
> I think the use of =E2=80=9Cthe protocol=E2=80=9D is unclear, maybe call =
it =E2=80=9Cthe TCP
> convergence layer=E2=80=9D. This to avoid confusion with BPv7.=20

Fixed.=20

>=20
> Section 4.2: Please define how to set and ignore reserved bits in the
> Flags field so that it may be extended in the future.=20

Okay, it is defined to not be set, which is likely to be interpret to
mean that they should be 0. However, a lazy implementor could also
interpret that they do not need to set their bit-values at all and may
have a system that have random values at initialization of a memory
buffer. I would recommend to use ".. SHALL be set to zero by the
sender."

>=20
> Section 4.3 and 4.4: Due to how the Contact Header relate to TLS
> there is clear risk for a TLS stripping attack where the CAN_TLS flag
> is cleared. I think there need to be some thought about mitigation of
> this weakness. Depending on the expected mix of entities and their
> capabilities one can either have policy for a deployment where one
> mandates TLS being used, thus preventing the bid-down by not being
> according to policy. It is more difficult to mitigate in a deployment
> where one have some entities that doesn=E2=80=99t support TLS, unless one=
 can
> some way securely learn which entities support it or not and thus can
> detect the manipulation. One can potentially also first attempt to do
> a TLS handshake for the best version one supports. Then run the CH
> inside the TLS to prevent TCPCL version and other flags to be
> manipulated. But that doesn=E2=80=99t solve the down-bid. I did note the
> negotiation in Section 4.7 and the relation to Security Policy. Maybe
> the solution is to write some text on the risk of TLS striping in
> Section 8 and add forward pointers in 4.7 to that risk.=20

Section 8 text makes the biddown clear and indicates the policy
mitigation. I think this is sufficient.=20


>=20
> Section 4.4: Dealing with new TLS versions. BCP 195 does not appear
> to me to define how to deal with newer versions. However, as TLS 1.3
> already exist I think this is from the start a relevant question.=20

I am asking the security ADs if it is current and sufficient with the
BCP 195 reference.=20

>=20
> Section 4.4: So what about entity authentication? Will the TCPCL
> entity have a name / identity that can be authenticated so that one
> know that one are talking to the right entity. And is the solution
> for this a classical PKI, or something else? Also does the passive
> entity expect the active (TLS client) to authenticate itself also?=20

Mostly good new text on the authentication. Here I am going beyond my
expertise, but based on that RFC 5280 has been updated several times, I
think you need to figure out if any of these updates should be
indicated as necssary for TCPCLv4. The relevant updates are RFC 6818
which makes clarifications on RFC 5280 and then the intenationalization
in RFCs 8398, 8399.=20

The other concern I have is the SNI sentence: "The TLS handshake SHOULD
include a Server Name Indication from the active peer." First of all
you need a reference for server name indication. It is an TLS extension
and not included in the main TLS specification. For TLS 1.2 it is
section 3 of RFC 6066. The second part is that I don't think it is
clearly specified what should be in the SNI field in TLS. Looking at
the DTN URI scheme definition I would guess that only the node-name
part of the URI should be included, or?=20

This also relates to the section 4.4.2 TLS host name validation part.
It says that certificates subjectAltName should be the Node ID. That
raises question marks as no part the DTN URI format defines something
as Node ID. The second is what happens if someone uses another URI
scheme with BP? Or maybe this is simple to resolve if the whole URI
should be used, but that looks less than obvious at least in the case
of DTN. And I haven't looked at the IPN scheme.=20

Sorry about being very cautious here. But, I know how much trouble I
have had with URIs and their application in the protocol when I worked
with RTSP 2.0.=20

>=20
> Section 4.8: Please define how to set and ignore the reserved bits.

Same as above about zero.=20

>=20
> Section 4.5: Based on that many later sections just refer to the
> Message Header, shouldn=E2=80=99t the section title for section 4.5 be
> Message Header? Now the first mentioning of =E2=80=9CMessage Header=E2=80=
=9D are in
> Figure 16=E2=80=99s title.=20

Fixed.

>=20
> Section 6.1:
>    After sending a SESS_TERM message, an entity MAY continue a
> possible
>    in-progress transfer in either direction.  After sending a
> SESS_TERM
>    message, an entity SHALL NOT begin any new outgoing transfer (i.e.
>    send an XFER_SEGMENT message) for the remainder of the session.
>    After receving a SESS_TERM message, an entity SHALL NOT accept any
>    new incoming transfer for the remainder of the session.=20
>=20
> To me it seems that the above paragraph contains one contradiction.
> The parenthesis in the second sentence (i.e. send an XFER_SEGMENT
> message) appears to be false. Because as the beginning of the
> sentence implies that it can=E2=80=99t start a new transfer. However
> SESS_TERM is allowed to be inserted in between XFER_SEGEMENT messages
> for a transfer ID, i.e. XFER_SEGMENT(ID=3D7), SESS_TERM,
> XFER_SEGMENT(ID=3D7, end) is an allowed sequence. Can you please
> clarify.

Addressed.=20

>=20
> Section 8.=20
> If this identifier is used outside of a TLS-secured session or=20
>    without further verification as a means to determine which bundles
>    are transmitted over the session, then the node that has falsified
>    its identity would be able to obtain bundles that it otherwise
> would
>    not have.
>=20
> I don=E2=80=99t see how a entity could trust the in SESS_INIT provided EI=
D
> more just because it is in TLS unless there are some mechanism for
> binding the EID to the TLS session endpoint (client or server). Some
> type of authentication is needed to prove the identity.=20
>=20

I think the new text in Section 8 and the clarified TLS procedures
resolves this issue.=20


> Section 8.
> Therefore, an entity SHALL NOT use the EID value of an
> unsecured contact header to derive a peer node's identity unless it
>    can corroborate it via other means.
>=20
> The EID value is not part of the CH, only SESS_INIT. Is this a left
> over from TCPCLv3 or earlier versions?

Fixed.

>=20
> Section 8. Needs text on  TLS stripping attack due to the optional
> TLS usage.

Fixed.=20

>=20
> Section 9: =E2=80=9CIn this section, registration procedures are as defin=
ed
> in [RFC8126].=E2=80=9D =E2=80=A6 defined as in =E2=80=A6
>=20

Fixed.

> Section 9: =E2=80=9CSome of the registries below are created new for TCPC=
Lv4
> but share code values with TCPCLv3.=E2=80=9D
>=20
> I don=E2=80=99t think =E2=80=9Cshare=E2=80=9D is the right word here. May=
be =E2=80=9CSome of the
> registries have been defined as version specific to TCPCLv4, and
> imports some or all codepoints from TCPCLv3.=E2=80=9D

Fixed.

>=20
> Section 9.3: Is RFC Required unnecessary strict? Considering the
> quite large name space, I would think that specification required
> would be a suitable policy? Just trying to understand what you think
> is gained by having someone publish the extension as an RFC, in any
> stream including the independent.=20

So this was changed to Expert Review and that is fine. Any registration
requirements or special considerations for the Expert?=20

>=20
> Section 9.4: Same question as for 30)

Addressed.=20

>=20
> Section 9.5: Here RFC required may be suitable. However, does it make
> sense to allocate 2 or 4 points also here for Private/Experiments?

Addressed.=20
>=20
> Section 9.6: Here I would consider Expert Review with a specification
> requirement. I also do not understand why so much is reserved, a
> reason for that?=20
>=20
> I would expect that the policy for 9.6-9.8 to be aligned so may
> require change if change is decided on 33.=20

Fixed.=20
>=20
> A big question I have after having read this document is how one
> discover / determine the IP+port(s) to connect to for a given EID. Is
> this currently completely deployment specific? And how bound is this
> to Bundle routing?=20
>=20
> What may be missing is the section that tells the intended
> implementor that in addition to follow this specification you do need
> a solution to the following things, like for example authentication
> framework that allows one to verify the TLS connects to EID mappings.
> Or an address resolution protocol that maps EID to IP address and
> port pairs for cases when routing simply give you Forward this bundle
> to EID using TCPCLv4.

So the scope of the document clarifies things and points to some needs.
So I will consider this one resolved.=20

Cheers

Magnus Westerlund=20


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--=-oOFK5EksuQW0TISjLEWJ
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww
ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT
AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD
QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl
cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT
+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9
uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig
GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr
bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD
VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2
aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu
dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu
Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl
cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH
AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW
MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD
VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB
CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c
vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ
yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi
SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD
o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu
bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l
9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC
QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z
la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/
/n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL
MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp
dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI
RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu
dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K
QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR
V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba
9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84
6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE
MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv
bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6
Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp
YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu
dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4
BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw
HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe
xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ
KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO
3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI
X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e
eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr
gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc
rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4
ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH
KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH
rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB
SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B
AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD
QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D
tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK
6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk
TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ
kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2
haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO
UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW
9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0
5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL
sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8
MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH
MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv
b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC
MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v
Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v
dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G
A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU
8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL
Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb
AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4
Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2
d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu
zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg
0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F
04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d
1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7
C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2
aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3
DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDkxNzE5NDY1OFowLwYJKoZIhvcN
AQkEMSIEIAqhWdFPimLQVslAnxDEJfG3sa0ijZzXchIUqNuPAPcHMGoGCSsGAQQBgjcQBDFdMFsw
RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ
bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2
aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEARBdXCnTQZUtP
voNZ87tMNBMkYFcwdirNWMGPsdQznWdEXQxMdwxOGoPKeJ0NQtxKU4D9Igu9f1MnJpBP4sAeC618
A/64OtPmP8ejpixLGvieFSuzeI7eyEAqMcqOYeEXnaCLK5lup3MlV6ZylJ/VcvLJr03HSpFSVT4c
jQL91uMteKDJ8KWDMU+cykzaE8w1fzGJrKrUp0scNQl0IA7r+juHZ7Deqch3AO6Qe3GiI2ieLZ02
7U5Tn/g4pLi7Stjvt73jxSwJsymVBoJldI3t0qKo8/+rEDsY1H6PCGBe6zjmI89n7nfBrJUduEd8
NEOsyqj/6Y5FehUBMn16+zAWzQAAAAAAAA==


--=-oOFK5EksuQW0TISjLEWJ--