[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Protection Suites in ... (was RE: Comments on draft-ietf-ipsec-ike-01.txt (long) )

  A protection suite is not a bundle nor is it any subset of a bundle.
You may wish to refer to it that way but I will, respectfully, say that
you're wrong. A protection suite is an atomic offer. The whole concept
of this suite was that very early on (perhaps before you took part in this
group) people wanted to mix and match offers. One offer was 3DES and MD5 
and group 2, the other was CAST, SHA, and group 1. So people wanted to 
accept a mix of 3DES, SHA, group 2. That is not allowed and the concept 
of the protection suite was defined to limit that.

  The protection suite is an atomic offer which must be negotiated in
its entirety. RFC2408 is somewhat confusing. Maybe not to you, fine, but
to plenty of other people. I'm attempting to rectify that situation.

  I have no idea whether RFC2408 will be revved but I don't want to leave
the confusion in place.

  You seem upset that the definition explictly disallows your broad idea
of what it was. Can you explain how this impacts your implementation? Are
you somehow constrained because the term "protection suite" does not refer
to a bundle of offers? 

  Dan.

On Wed, 02 Jun 1999 09:35:01 EDT you wrote
> > 
> > On Tue, 01 Jun 1999 09:42:47 EDT you wrote
> > > 
> > > 1) Use of the term "protection suite"
> > > 
> > > I am both concerned and confused by the use of the term 
> > "protection suite"
> > > in this document. As it turns out, this term has been 
> > re-defined from that
> > > in ISAKMP (RFC2408) to refer to only the services provided 
> > by a phase 1 SA.
> > > (See section 3.1 of draft-ietf-ipsec-ike-01.txt.)
> > 
> > The abstract of this draft explicitly says that where there 
> > are conflicts
> > it will be supreme. 
> 
> Even over RFFC2408? We really need that document to be updated
> then.
> 
> That's not my point anyway. My point was that it appears that
> "protection suite" is being re-defined in a completely different
> way than RFC2408, and I don't see why.
> 
> > 
> > > On this issue, what is the purpose of adding any new 
> > definition of these
> > > services? If that is necessary, why change the existing 
> > definition of
> > > protection suite? Why not find a term that won't result in 
> > ambiguity and
> > > confusion.
> > >
> 
> (Above are my original questions; I didn't see a response to them.)
> 
> I think my understanding of your position would be clearer if
> the above questions were answered. I'll expand them:
> 
> 1) What is the purposes of defining any new term for the set of
> proposals and attributes offered for phase 1?
> 
> 2) If question 1's answer is valid, why would the term "protection
> suite" be chosen when it quite clearly (IMHO) already has a very
> different and clear definition?
> 
> (I realize that it's not clear to others.)
> 
> > > To clarify the existing definition of "protection suite", 
> > see section 2.1 of
> > > RFC2408:
> > > 
> > >    Protection Suite: A protection suite is a list of the security
> > >    services that must be applied by various security protocols.  For
> > >    example, a protection suite may consist of DES 
> > encryption in IP ESP,
> > >    and keyed MD5 in IP AH. All of the protections in a suite must be
> > >    treated as a single unit.  This is necessary because security
> > >    services in different security protocols can have subtle
> > >    interactions, and the effects of a suite must be analyzed and
> > >    verified as a whole.
> > 
> > I was under the impression that this was confusing people and 
> > hence decided
> > to spell out what the term means to IKE. If DES in ESP is a protection
> > suite what about the lifetime of the ESP offer? Is that part 
> > of the protection
> > suite as defined by RFC2408? That's not explicitly spelled 
> > out and people
> > asked me about it. I happen to agree with them. That text 
> > doesn't really
> > capture the meaning of the term and is open to interpretation.
> 
> If clarity of the existing definition is the problem, then that
> is what should be done. The existing changes will create more
> problems by re-defining it completely differently.
> 
> Here's my definition of a protection suite:
> 
> "A protection suite is an SA bundle in which the SAs in the bundle
> are negotiated using the same SA payload in the same quick mode."
> 
> That definition is entirely consistent with RFC2408. RFC2408 also says
> that the individual SAs in a suite must be treated as a unit. This
> means that when one SA in a suite expires, all SAs must be expired.
> It also should mean, and this was demonstrated at interoperability
> workshops, that the encapsulation applies to the SAs as a group, or
> stated alternatively, to the suite as a whole. (In other words, there
> are no extra IP headers added between the headers added by the
> individual SAs in the protection suite.)
> 
> > 
> > > Also see the discussion in section 4.2 of RFC2408 and the 
> > example in section
> > > 4.2.1 of RFC2408. All of these quite clearly indicate that the term
> > > "protection suite" applies to phase 2 SA establishment.
> > >
> > > While I agree that it does not necessarily preclude phase 1 SA
> > > establishment, I do not see the need to apply it to that 
> > case only, as
> > > draft-ietf-ipsec-ike-01.txt appears to do.
> > 
> > The DOI defines what IKE negotiates in phase 2. Would it be 
> > better if I
> > called a protection suite "an collection of attributes that 
> > are negotiated 
> > as a single unit"? And then said that during phase one the 
> > components of 
> > such a suite is <blahblahblah> and leave it up to a DOI to 
> > define the term 
> > if it so chooses?
> 
> That might be preferable. But to me (phase 1 aside), that's what
> RFC2408 has already done.
> 
> And I still don't know why you want to apply the term to
> phase 1 anyway.
> 
> >  
> > > Also, the use of the term "protection suite" is a very good 
> > way to refer to
> > > a subset of SA bundles where the SAs in the bundle are 
> > negotiated using a
> > > single SA payload. This allows them to be differentiated 
> > from SA bundles
> > > that are negotiated by the effective recursion of policy to 
> > packets that are
> > > IPSec processed.
> > 
> > This is a slippery slope. If I now state that a protection suite is a
> > subset of a bundle of SAs then what sort of subset? 3 offers 
> > out of the
> > 5 in the bundle? Is that a protection suite? And I don't 
> > think that's the
> > correct meaning. Even if all 3 of the five were ANDed 
> > together, it's still
> > 3 protection suites. Perhaps you can come up with another 
> > term to describe
> > a subset of a bundle.
> 
> The protection suite is a result of the negotiation. If I propose
> 
> (IPCOMP and ESP and AH) or (ESP or AH)
> 
> to you, I'm offering you a choice of two protection suites. Hopefully,
> you'll respond with 1 of those, and the result will be that we create
> between us a single protection suite. That protection suite will contain
> either one or two SAs.
> 
> What's slippery about this?
> 
> > 
> > > As such, I think the use of "protection suite" in this 
> > document is confusing
> > > and should be changed to align with RFC2408, or it should be removed
> > > altogether.
> > 
> > RFC2408 is confusing and I was asked about it many times. I'm 
> > addressing
> > that issue. 
> 
> I've no problems with that: only that I don't think you're clarifying,
> but changing.
> 
> > 
> > At the last bakeoff someone was passing a message ID in the 
> > SPI field of
> > an notify message. This was justified by noting that nothing 
> > expressly 
> > prohibits such behavior. When things reach this state I think 
> > we've gotta 
> > spell everything out in gory detail and RFC2408 doesn't to the job.
> 
> I agree. Is there someone working on a next generation ISAKMP document?
> 
> > 
> > Does my suggested modification come closer to what you think 
> > it should say?
> > 
> 
> I don't know. I don't think we're really that close in what we think
> a protection suite is. I think it's an SA bundle where the SAs in 
> the bundle were negotiated using the same SA payload. I think that
> you think it's a collection of proposals (including transforms and
> attributes). To me, that's still just a proposal.
> 
> To try and further clarify why I think this is important, I'll elaborate
> more on the differences between what I call a protection suite and
> SA bundles in general.
> 
> To say that you support SA bundles (in general) means that you support:
> 
> 1) Iterative SA negotiation with both a single peer and multiple peers,
> and
> 2) Protection suite negotiation.
> 
> To do 1 above is a significantly different implementation issue than
> to do number 2 above, and a significantly different negotiation method.
> 
> For example, a generic SA bundle that results in ESP and AH applied to
> the same packet could result from a policy like the following:
> 
>   H1 --- SG1 ----- SG2 --- H2
> 
>  H1 <-> H2,  all protocols  : (ESP) tunnel
> SG1 <-> SG2, ESP protocol   : (AH) transport
> 
> For number two, a similar (but different result) comes from a policy of
> 
>  H1 <-> H2,  all protocols  : (ESP and AH) tunnel
> 
> Both are SA bundles. The second is also a protection suite since it was
> negotiated in a single SA payload, and both SAs live and die at the same
> time. In the first case, the two SAs are independently negotiated and
> live and die completely independently. The AH SA might also carry traffic
> from other packets that ended up with ESP protection from hosts I didn't
> illustrate above.
> 
> Those rules of negotiation and treatment of the SAs is important, and
> needs to be clearly spelled out, since it is different. This is why
> there were so many issues at the interoperability workshop with respect
> to IPCOMP: Does the IPCOMP SA proposal in the offered protection suite
> have to have the attributes of the protection suite? (I'm offering this
> question to illustrate the protection suite issue, not to start a
> discussion on this issue in this thread...)
> 
> Has this clarified the issue for anyone???
> 
> Tim
> 
> ------_=_NextPart_000_01BEACFC.B728CD50
> Content-Type: application/ms-tnef
> Content-Transfer-Encoding: base64
> 
> eJ8+IgMNAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
> b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcGAAIACQAjAAEAAwAOAQEggAMADgAAAM8HBgAC
> AAkAIwABAAMADgEBCYABACEAAABFOEZEN0EwNUU3MThEMzExOEE1QTAwODBDNzk0NUU2QwAzBwEE
> gAEAUwAAAFByb3RlY3Rpb24gU3VpdGVzIGluIC4uLiAod2FzIFJFOiBDb21tZW50cyBvbiBkcmFm
> dC1pZXRmLWlwc2VjLWlrZS0wMS50eHQgKGxvbmcpICkAfxsBDYAEAAIAAAACAAIAAQOQBgBoGAAA
> MQAAAAsAAgABAAAACwArAAAAAAADAC4AAAAAAEAAOQCwfhm3/Ky+AR4AcAABAAAAMAAAAENvbW1l
> bnRzIG9uIGRyYWZ0LWlldGYtaXBzZWMtaWtlLTAxLnR4dCAobG9uZykgAAIBcQABAAAAGwAAAAG+
> rIxIREQxcCkYVRHTk1AAEEtqqNgAGnh00AAeADFAAQAAAAkAAABUSkVOS0lOUwAAAAADABpAAAAA
> AB4AMEABAAAACQAAAFRKRU5LSU5TAAAAAAMAGUAAAAAAAgEJEAEAAAD2EgAA8hIAAJcoAABMWkZ1
> 1ufIvwMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwEC
> AGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQswsJAWQzNhZQC6dj
> ATAdBgB0AxADIBewbmcsmCBidQVAAiBseR4hwCB0aGUgcANgDrBGYx1AHoFzdWkOsCC7BAEKUC4K
> ogqECoAtISDTIGQHYSBKCfBrC4AEIE8ibyLDB2IdMGVwEiFymnAFsGEfUiBkdGoiBO5AHUAHgSQh
> LgWgIdAix4JoAkBwOi8vdyfQBi4mCiBkKDYxMymgIDU5OS0cIDEWUCB4NDMwNCLNRmFoeDogKTs3
> IGogaj7WICEhISBPBRBnC4AHQMMF0AeQc2FnZS4zLbbWRgNhK5BEA5FICsAiI4ZbAMADEHRvOmQT
> 4RMlswfAdHcFsGstQQJsE9BlbXkuQ088TV0ttgZgAjArkEp1Km4e0DEd0DEpoDkggDg6MDggUE0t
> tp5UMdAjwiHmLbZDYyuQIwUgFBBjQGwEAHRzdSgBcwtgYjiwKKc0IXXOYiWAH0ArkFJlK5AIUN5t
> B4ACMAQgHoFkJLABgL4tCJAAMDvgOCI74GsvcOwwMSgADtEoHZIpcC229T3OTwOgVApQHdA84DSS
> QTUUMDk6NDJAoDdAIEVEVCB5CGAgXncfAi22PiguEDEpcFVbFBAeIGYeow6wciHQIo0e/iJB70JR
> SSBhIdDLBuAesCAFoG5jBJEJgM1GwG5H0EdRZnUUEEfQ/mIeYB6ySHFDiy22RF9FaY8LgB6hBAA7
> gG9jdTsC/i4QwAQgH8AeoAhwBjEIYL50HdBMo0QDE+AEIGIJ4fs+NxggLQEBC4BHwQNSHqEDJMBL
> 20lTQUtNUMEroFJGQzI0NZApcPsxwFBBZhKBU3EeMx6yFBD8cnYN4AeRHvFU8AEAR9B7LbZIwWEe
> 4E9BNNEGAEE7IFVCQigGYFSiH0QzLk8/0EORO588qC4pPc5U+x7BORF0JLAfQEOETMJZUn4gDsAL
> UA3gH8AeUS9Aef9O0VFhQYAewBggHqJfQS22/wrAHtBIMl3xOKAttk3BA/D/HWFPgB+RHvAzQCBA
> PjUgZHxFdk+hVXASgVLgUvQ//CBXHtAYIAdAHlE0wEfB317DTPZTYmIhYmBkJMAJgLslFR7AbiBb
> XBAkwCcEINpuHxAgM1Ae4G8LgAVA2QBweXdegE1wTWm2amDjXqVNwWFwcGUgFABRSd1KvyIf8U9x
> C4BnUEpMca9WkCaRC1AUIGUeUWQGkP9TwTRRIGRqYVFCA6BS5R3Q50fyRrBM8G4nBUAUEB7Q/18Q
> M2AtXEV4P0FMoyADHdB/XxBrol6iHtEIcCSQQ2Rh/mRwkG6xajFlcQfgLbZQg38fwB9iQ5QUEEV4
> VMZkwEmfQ6J2dDTAVREvQHJ5djL/HmAT0R2wX1NdsTiBbqJ4v/95wkV4Hv5kwX0RaWJQoUfR/0P0
> XsRzExggH6AxsExiX9f/BtAuoB+xVnFIAEV4SDQfYfNXWCBqKEEG4GOwYENpoTsFsC6lcQpQfiEC
> IHM7/3LSVZBzJlaQg4EkkACAQ+H7U4AesW1a9iBkRrBMoSIQ/2mSNLAEgSZAR/FuokORQVH/BcB3
> QXmEMrCDsEihYHFwIP9gUQXABpBnh1xBiDKJd0GAl18yAHGSYmRNcEknHWH3XcFH8ovSOiBqQyGB
> kHZ//ztBWSF5Q3gJRAMCEFPhVJP/XMIgZB7xd0EHQAQgR/IkwP1cgGkd8ZZzcMJQ4QWxVrX6PyBq
> Milwe6GJdjTgaTH7krRuQnYHQFWQfOSPlEPP9yTnbeWP8mh3UY9xZ/FNsg+JcB/CkCMeUShJTUju
> TylwB0BlEWQeYE9CVpD9ZAF5IGRwl0fkkDJ5KZw786PwZQNpel9Sa6NpNabE/1QCX3I4sIwrQkI2
> YJARCsDfBpBI1H33eTxtLyId0C22+3NiWFYyWONFeFLllFVCTL0iwVAfCDoAH8ErkEGAb/9uQlaQ
> OHJDhjgxCHGFELM7+1THXsNtSHAFQGIhbAE4cP9IlJ7QBRAIYAQgt2a1M00A/wbwOLArQQWwszsO
> wEbQcBF/coG1P2mQcZFHUQCQtsRE3kUF8C22CfAFAHkFMB9i51IyUrDAUFAssztH8jywInlHwU1E
> NcGlQUj/TXEdYUOVvkhNoW+ivvW5pP+zO1yAZSBnUUbApQIAkB2w/3AgjZEfwLxhXBB1s3xIT3H8
> Y2FJMrdvuHtMcaXou0+/BCDK8AOgE+CIQR+gYl4w/8csafEEkFyhicJyhH2zcLHfYPF3g8ZcR+EH
> QHmpEEfT/7M7ZAEGkLpSpPNfEAbwIEb/PihGsGtCjaMeowdwYnEEEP8fYl7DTKNrQoYVbrFsIJmQ
> /8kRR/IttmfxR4B5IV4QVaH/LbZTcYswcFDEwR4BdlOf58cHgAYiU3FJS0WTMcAk/0xxwhG2RKCO
> euEfs3ZTkWH/HgEesjhwU8AmAkOG4LKbA/97gV6lCrEFQS3FxO/h7E9R/1CGSMFS5WTAaPldyt3C
> Vbnv3hJH8tsEX9dzPLBH0OQR/+MUyWJGsBPgbBEekVOAL1D/CdFhwUchi9PqA6ARDtJ+lv5vB5CD
> RGUyLbbK8AUwCHD/fZTfMo5Fn+dH8kzBmZDvZP/Q82JxAZAfUiBbe6GsY4UR/0OVrS/Bgna1A2AC
> YDNAToLv72JRZ9nyXtJzojCPtXMB/2KxXBJ9931EkkEdUgUAyCL/aZAFsEHV+sVPYR5gUFZuot9N
> wW/vNFEeUCBbSF8xaTHfaaF5PL4vOqAgaiK1L7Y0/7SRB9Ad8EgAyRFMcV8QDeD/8FNXIcXzHrIJ
> lGzEYFI0wP5nCBAQ8MhC2qRUg0bQCrJ95dF5F7B3wAsGDdOjEWN7jVEVcS5FZWiY+Z00UWn/GCAe
> Ub+VZnLwI1LlTXBS5X2kUXPdkV6BZ4bedYIhaf1VgXUu4QrV0w7IC8lEybL/bMTfNV7VY9E0wQlh
> F1ldwf8ScdGixLEK0tOGHHSTIIyV/2oRFPP81N8y0bbZ9ejQ/9D/v7BcgchDg9JEAfXBJLCEwP84
> cMu2MrL8wTgg+zLeddxB/2wAg6H207oF33MKlqTz79D9uwBw+zC8po3xyEMxsEeR//bRY7CjwPsx
> JhToR9ZWo+HnY9FfcoMRcmQj418xC+n/U4DxMVlQwdLm8HfAjdF3sv9IkjKRT5Lm4i2tSNP75RZ/
> /+bsvuSrHrM4xKAVAlgh5uI9ikBzTRDZJExxWFY0Lv4yQ4IUZ9HlwIe9pDZZszj/NxFY5BPXxKhW
> 4aMcMOLPMP/ocRXXRAKzOK6fbjAliVa03zcwCWGdge5gtqFoTTOGvf9F0oGQYeDnAEax79NrhvHy
> n2lTfFZh4LuysKBsdejQ/1apszhCK/swcuJpUzU2ZYT/76G6IT1xZpNew/LYd2JUQf9ygWEXeRFZ
> X1pna/hTgEWQ89bPXBJET4ohbyP8Vd/B7wx4FzNBde7gV4+ja9HT0f+zNi6B0RGQkYoQ8tjrowXf
> /ecAIs9BzuFwIL6Ud5KaaK9L+wxN7VjIrCJkwEGT5P2+0WHcwGXFzjHa0pvTG1L/OEoCIhtRcQCW
> g+HoCmHGRuW2UTz68GFoY5aEgfVh/5AxiEFr0WcQ74NSA92Bfov/fZT1A7M2VoFr0RUBoiGWUuuc
> OxETbYkAaLnD2PFwwbtCUf2RQuNCFRDuMShHdvvaMNzBKSP0ngF2UgdkFGb/pOOkdf1jlGpeIoog
> fiHEsf1zBGtF4HiQfQKOsdfhE1H/Swef587AmRVsZnhA2iADfP+zsTRM+zMNIeQnoC5ARrZT/6VC
> JvBo4NuYdUHdcmrzdAf7hdLGQmKYtAlY/FKScgqf7wmziHKzNgyPYbM4yNUOKP8ZlBzycfD6Y3Py
> /SMC5lwc/maZgPUwfaizOF8DW40wJP/SRSjhASHOIdkz9JGZoOrx/3tzszbl4A/A9rC5JVuBszj9
> weBTsKBXwkZCHldROsnU/10hIsBQAcqhkLD1wd/zSaD/ceIn84glV8+2Q+HofSYtUP8JlX1z+mOi
> cvySm5C2030E/eVAM5r0tmDr+vSUszbD4/9/aOVIkv+bMXC0cXTdB8nA3m4P0G1VmanO4HJG8blx
> +/Qk7uBF1ZCiwVnhxLGYIh/m01JwZOEusFuRQU5E/+vJzsD+0Cvy+zCpk3ETdeb3mCCTHrxRUCIw
> 7yG2YHJi/88yAiHJIWVQ8CNysCsk3Qf/c9Qg8TXQWjHtSJTf1qcQtv8yL7Y12QElALbXgNb28pGk
> H61xYVBHoHWKKuBQQ0++TcRA9VLgsvVSxGApJ2H/KtDks1Zgs0F1it2BcmFJgf4n9TDk8w1ScmIt
> UGjBuPHv9IMjYK1vvFFI9cHakPKh+8JFcmEnxLHZAWFR1HDwI/87A/BAaPHRuK7V/xMYUhrD/zzx
> yBMHZC6G2qBdGDJP8MS/rX//FDbgKAA9kAdkZROR/1ZRG1KzgbdyfvFv60Qw6jP/kLfjFhMQaTs0
> K6SRYpFJgv+eZneXeL95wQ7i4PHxeM4g/0Ky4OLaZ3xJsxH8yP6USuT9IsBnChETmSdSaFP81+/g
> ///Q1ZDUuShho9WPDxRmzUr/9UPX1O3U7mZsAHUR5tDkAf+4sbWiWwcuMK7RzcpFFI7A9nX9kfc7
> J2ThLOEAd/Al/VoAOk0DXvSdZp5kueJbkfn4I2Z5DVG5dVpR/oSgorvHT3YTQT5U+DAdomHt8P+1
> 4WiBbBAbUiDCDlDZ4ybR79iBDdD+0EmQRAsGdeaz0P9JoFJw65AY4PSQWwcb0EXh7+Ah5baDpSDC
> ah2RhUBOkP8wA+jSDWNfIaiyDVI4iPaR/47AEqGL91fgIIAioIzBYoP/z1Bu4BagJ3BUsftkDVGu
> kP/ycQpjroGSRMlWetcEgGTh3wyhKABh+FAQO/FlejLsFP/XoxvQeoDGYVJQwtH/QGRy7xRmRZLe
> 0yYUavrgb+tElf/YsfpjW5HkZyNx9IMb0htgX0/B/tAbYCFxQBJJCWBL77JRzLbHP3YEREWiBMEX
> oP5no+ATIR+xEADqoT3RQBL/p9M9EGjxfAKWxHJi8ZzRqP8VMWk11Jb4RnF42LHeq/Jx/1uRveG5
> QV70ALMJ9L10nmP/C+XBP65xBaKeZKRjWPF9p/9+TzQ1f2mik4DfKYM5IILs/8lYbeYBqAt0WR2w
1B8RKtDfG8BHEutjTkAhQGYncN0R92RxLEVaFynA0WvybTdxFP/qYpvUFKOsbEvRxmKzEc2g/5dA
> qOLf5XITyViQNNhwYVD/l0BysbWC8+LjkMagIXKxpP/SkFuRNuE1dIVURkEud1LU/1czm98p8haG
> fan1AvtzGf//A2Fe9HJiwfBQAJcyfakVEV8lBrNgoGJalScZOnWKMf2zYEl4YQABZOF9oa+5usS/
> xqCocr9XROBWYLMCba8BW8YgLkVz4IUWdzKzYFD/V+6vuhodScFsscagZOJdBP/QYP/DzRA9YYU3
> HbLc8c0B/wAE2wNtQsMFUHNKoMzgz1D/VmBB0DQju8Q0vzXHLIpsEPe7cY72saRGs4Hs8BBgL1H/
> u8H7VIuAC+neQ67UDVOyyP9LI+rCfCYQF4x0zWHPEq7V/4ajInGLZItw5ACh9FkxcfDXtjEqu3ZQ
> SDQALUcgDSCeR0cDRzM5EEciSDJGG/lG8TwtdkBIgLvAoWMiknfMwItgrpAg3dCzsrNgdP9/sMPw
> pPVHYkmiSAG7wLLC/0p2dlBLErNCFcMd4jy+OKX/t3E+Is3AalDf8Shw4PI1uP+u1LNgp9KukEQM
> 6AZJD0of70sksvdLqrGkQi2jW5F9qP/A0vmhE9C6koPjaJEif/mh/xUhZPPqIbGkiMn1Ab9Hgwj/
> u8Qtkw0yi3Bk4bMChTB/8f/jNBBSDaXYcdix5oSiQC/A/+ERdLF3VMRViHP1AKogLnD/ZTE1Y4jJ
> Fndgu6fRL1HxQD/eEWUrWhRBAX2hUSBnaP+IYVsi//CgANhBKQCFUIuA/7GkhqOoxIx7ZXKBYag1
> TTafE9WGo7uBjMGdYWlkcZF/saQY0epxHxI0FKxtB+Jy/88Q/pHKUSyKu+O94szzodX/DTMdqxZ3
> w/Dq0J8RhOMHwP2gcHLeEfOz6tHXobvAXJf/roGFN4Ol6fIckA2niJGik/9bMdgTN0OukeM09QCp
> oZFh9ykA7mCLcHQcYfpR0dGoNf+6UhPRtMeyFN3Q/nO8IrIV/xCiGZXmZrXj6tFbjrGk7yH/N4Ez
> 4IW0vDEXCKHGnA8ocPe1q8bysaRxfYHK89ABcRn/h6+uRNshu8Cosfci8RGXQf+UVf+wqkDNsM3A
> FBLLxTdEv8u23kDwYTyQkWC0W0jW8f/L49/kQXN+AjdTFhHokbZwvcPwP5TQrHvYcLGkfZZgAAAe
> AEIQAQAAADYAAAA8MTk5OTA2MDIwMDA3LlJBQTI0NjQyQHBvdGFzc2l1bS5uZXR3b3JrLWFsY2hl
> bXkuY29tPgAAAAMA3j+vbwAACwADgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAWACCAG
> AAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAA
> HgABgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAMAAoAIIAYAAAAAAMAAAAAA
> AABGAAAAAAGFAAAAAAAACwAEgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAaACCAGAAAA
> AADAAAAAAAAARgAAAAARhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAI
> gAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4ACYAIIAYAAAAAAMAAAAAAAABG
> AAAAADeFAAABAAAAAQAAAAAAAAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAA
> AAAACwALgAsgBgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALAAyACyAGAAAAAADAAAAAAAAARgAA
> AAAFiAAAAAAAAAsAmYAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwBBgAggBgAAAAAAwAAA
> AAAAAEYAAAAABoUAAAAAAAADAPE/CQQAAAMAJgAAAAAAAwA2AAAAAAADAP0/5AQAAAMAgBD/////
> AgFHAAEAAAA7AAAAYz1VUzthPSA7cD1UaW1lU3RlcCBDb3Jwb3JhO2w9RVhDSEFOR0UtOTkwNjAy
> MTMzNTAxWi0zODEyNQAAHgA4QAEAAAAJAAAAVEpFTktJTlMAAAAAHgA5QAEAAAAJAAAAVEpFTktJ
> TlMAAAAAQAAHMBB3Frf8rL4BQAAIMFDNKLf8rL4BHgA9AAEAAAABAAAAAAAAAB4AHQ4BAAAAUwAA
> AFByb3RlY3Rpb24gU3VpdGVzIGluIC4uLiAod2FzIFJFOiBDb21tZW50cyBvbiBkcmFmdC1pZXRm
> LWlwc2VjLWlrZS0wMS50eHQgKGxvbmcpICkAAB4ANRABAAAAMgAAADwzMTlBMUM1Rjk0QzhEMTEx
> OTJERTAwODA1RkJCQURERkFFQjE1Q0BleGNoYW5nZT4AAAALACkAAAAAAAsAIwAAAAAAAwAGEA9+
> 1XkDAAcQmxoAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABTVElMTExPTkcsQlVUT05MWU9O
> VEhFUFJPVEVDVElPTlNVSVRFSVNTVUUtLS1USU1KRU5LSU5TVElNRVNURVBDT1JQT1JBVElPTlRK
> RU5LSU5TQFRJTUVTVEVQQ09NSFRUUDovAAAAAAIBfwABAAAAMgAAADwzMTlBMUM1Rjk0QzhEMTEx
> OTJERTAwODA1RkJCQURERkFFQjE1Q0BleGNoYW5nZT4AAACnsA==
> 
> ------_=_NextPart_000_01BEACFC.B728CD50--
References: